<cwebber> tantek: yeah but we're biweekly

<Loqi> ajordan: lol

<eprodrom> chairnick: eprodrom

<Loqi> Strugee made 1 edit to [[Socialwg/2017-09-19]] https://www.w3.org/wiki/index.php?diff=104469&oldid=104461

can scribe

though I did leave my typing gloves at the office

<scribe> scribenick: rhiaro

last week's minutes

https://www.w3.org/wiki/Socialwg/2017-09-05-minutes

<eprodrom> PROPOSED: Approve https://www.w3.org/wiki/Socialwg/2017-09-05-minutes as minutes for 05 Sep 2017 telcon

<ajordan> SV_MEETING_CHAIR?

<rhiaro> 0 I wans't here

<cwebber> +1

<ajordan> tantek: you chaired right?

<tantek> +1

<tantek> yes

<ajordan> +1

eprodrom: do we have people who were actually there? sandro?

<Loqi> [AJ Jordan] AJ Jordan AJ Jordan at 2017-09-19T17:03:06Z (As seen today on the SocialWG call) @Christopher Allan Webber: I'm here to clack keyboards and ...

RESOLUTION: Approve https://www.w3.org/wiki/Socialwg/2017-09-05-minutes as minutes for 05 Sep 2017 telcon

October meeting schedule

eprodrom: We have a proposal from tantek to continue with our every other week unless we have runover
... My concern I think we have a december ??
... We are far enough along that it's going to be up to us to mess this up. My feeling is we don't need to do more than two during October. Any objectiosn?

sandro: seems good for now

eprodrom: 3rd, 17th and 31st of October

sandro: hallowe'en meeting yay

eprodrom: when is tpac?

<Loqi> :D

tantek: the week after

<eprodrom> PROPOSED: hold telcons on 3 Oct, 17 Oct and 31 Oct 2017

<eprodrom> +1

tantek: so far we haven't decided to meet at tpac

??: Burlingate

<tantek> Burlingame

scribe: San Francisco

<tantek> "San Francisco"

<eprodrom> Burlingame

eprodrom: do we still have time to schedule for tpac?

tantek: I don't know that we have a reason to

cwebber2: I'm going, not specifically for swwg, but I'd love to hang out and talk about that stuff
... tantek suggested I set up a cg thing but I didn't
... but I'd love to if someone else organised it

eprodrom: I feel like if we booked a room and some time we would fill it up with work that we don't necessarily need to do

cwebber: a BoF meetup sounds good

<Loqi> Eprodrom made 1 edit to [[Socialwg/2017-09-05-minutes]] https://www.w3.org/wiki/index.php?diff=104471&oldid=104202

RESOLUTION: hold telcons on 3 Oct, 17 Oct and 31 Oct 2017

<tantek> I can't make 10/3 FYI

<eprodrom> tantek: I think I owe you one

cwebber: I'm going to be at rebooting web of trust on Oct 3rd. I can maybe step away to be at the meeting. I also want to set expectations that I might not have that much to say because I'm representing a client all next week in DC and then I'm at rebooting web of trust, so that's going to take up a bunch of my time

<tantek> 10/17 I have conflict W3C #ab meeting

<eprodrom> People with loud keyboards, please mute

?? *typing*

<tantek> sorry

<tantek> so I'm -0

<tantek> oh well

tantek: can we consider the alternates?

eprodrom: I don't have a problem with that

<tantek> or 10/10 and 10/24?

tantek: next week also if we feel like we didn't have enough time today

<eprodrom> PROPOSED: hold telcons on 10 Oct, 24 Oct

<tantek> +1

<eprodrom> +1

<cwebber> +1

+1

<ajordan> +1

RESOLUTION: hold telcons on 10 Oct, 24 Oct

eprodrom: and if we get to the end today and we need one on the 26th we can do that

<ajordan> eprodrom: 26 September you mean?

ActivityPub

cwebber: Update on the test suite is that I've been working onit, had an unexpected item pushed onto the queue for it. Since Mastodon has taken the lead and a couple of other implementations are using http signatures be mandatory for server-to-server, I had to implement that
... in the process I found out the examples had a bug in them..
... but got that implemented and checked it is interoperable with another person in the channel
... I'm working on trying to get the.. I think the remaining two sections of the tests will be done at the end of october realistically
... There is one major issue that came up this week
... May be considered normative

<cwebber> https://github.com/w3c/activitypub/issues/256

cwebber: Seems like a clear thing to do but I'm not sure if it's normative

<Loqi> [erincandescent] #256 Content type of server-to-server request bodies unspecified

cwebber: an ommission basically
... we didn't specify the mime type in server to server
... as far as I know every implementation did this. It was just omitted. Something we should add. Not sure if it is considered normative, technically it's a requirement, but it was a bug in the spec
... does this sound normative?

eprodrom: it does sound like it would be normative

<tantek> perhaps normative but not substantive unless impls are not compat?

eprodrom: however from a practical standpoint I don't think it would have the same sort of effect as a normative change

sandro: is anybody going to have to change any code?

cwebber: not as far as I know, I think this is what everybody is doing

sandro: this was the implication of the spec all along we just didn't spell it out?

cwebber: right, it was in a different section

sandro: that's not normative. our spec didn't clearly communicate our belief but we didn't change our belief

tantek: this shouldn't be a surprise to anyone
... if anyone can raise an objection saying they didn't think this was a requirement we have to reassesss

sandro: http signatures. Are we talking about a normative change to require them?

cwebber: No, in practice some implementations ... we left open the auth method
... I have implemented it [in the test suite] because actual implementations will ignore the content that I send

sandro: do we have a non-normative reference about this?

cwebber: we do

<Loqi> Eprodrom made 1 edit to [[Socialwg/2017-09-19]] https://www.w3.org/wiki/index.php?diff=104473&oldid=104469

<Loqi> Eprodrom made 1 edit to [[Socialwg/2017-10-10]] https://www.w3.org/wiki/index.php?diff=104474&oldid=0

<cwebber> https://www.w3.org/TR/activitypub/#authorization

cwebber: this was the result that we came to because it wasn't clear waht the future direction was. I'm still not going to say that the worl dhas completely ... basically we left two routes, one was oauth2, one was LD signatures and http signatures
... in practice http signatures has become required and the LD signatures has become optional
... it's the in-practice what's being used route that we're seeing

sandro: what do you mean the LD signatures part is optional?

cwebber: it's being used in mastodon for the use case where... say you're doing a share
... how does that server know that if it's coming from you, the other person really said that thing
... it might not be feasible for themt o go back and retreive the original easily because of complicated access control stuff
... you just want to make sure that person really said the thing that was forwarded
... in practice mastodon realised that to make this work with AP they need the signatures
... they're only being checked in mastodon's usage when someone forwards to their followers cos it was the top post in the chain
... no other case is the signature actually checked. It's not required unless you're doing that
... maybe not everyone on the cal is familar with this probelm
... it sometimes results in a problem where the top poster in a comments chain gets comments from other servers and people in the thread miss out on messages

<cwebber> https://www.w3.org/TR/activitypub/#inbox-delivery

cwebber: we worked out this forwarding mechanism that makes sure messages get sent to peoples' followers
... that use case uses LD signatures
... it's comparitively small
... I'm not sure if I'll need to implement that in the tests as well

sandro: sounds great in terms of interop. Trying to think of how to best help people who come along and read the spec right now
... they'll probably be a bit confused about what they're supposed to do

cwebber: it sounds like you're saying if it seems like things ar econverging shoudl we be nudging people?

sandro: yeahh th e two main ways are that we could take the oauth part out and just use the one that seems to be being used
... or just have section 8 be a pointer to some document maintained by the CG that can refine this going forward and maybe eventually put it into a separate spec

<tantek> +1 sandro

eprodrom: I would be really surprised if taking out.. I know tha tmastodon doens't use the c2s part. I would be surprised to remove that
... but for s2s we wouldn't have any oauth stuff, it's gonna be all signatures?

<tantek> in general we need to be converging the spec on what we know interops so we can increase chances of exiting CR sooner

<eprodrom> https://tools.ietf.org/html/draft-cavage-http-signatures-07

eprodrom: I would love having oauth for c2s and having signatures for s2s and having that be it
... HTTP Signatures is a draft?

cwebber: ietf draft

<tantek> I think I agree with eprodrom just proposed

eprodrom: that means we can't reference it normatively?

sandro: right this whole section is non-normative
... we can't require http signatures

cwebber: I think we should leave the section non-normative and just remove the options

sandro: I don't really like the hack of marking the section as non-normative and still telling you what to do

<Zakim> tantek, you wanted to note there is something very odd with an entire non-normative section that we are depending on for interop of a specific set of features

<eprodrom> \o/

tantek: I'm trying to understand what we're trying to do with this section
... It feels like we're trying to express an expectation of a feature and yet we're trying to do it via guidence instead of normative text
... doesn't feel right

cwebber: we did already do that

tantek: the spec advertises a set of features you get if you interop. We're trying to capture features that are essential noted by folks like mastodon. Good we're listening to our implementors. But not good it's in non-normative text
... I understand why
... THe reality is that part of the spec is not the same level of maturity

sandro: the normal solution is to put that in a Note or more mutable text

cwebber: I would be fine with that
... having a document maintained by the CG is fine with me
... evan? How do you feel about having pointers to an auth doc written by the CG which is mutable but starts out recommending what's actually in practice?

eprodrom: that sounds fantastic
... I feel like it would decouple the auth part of the spec from the api part

tantek: this is for private content right

cwebber: not just. The forwarding use case .. it's most likely to protect private content becuase that' swhen you can't necessarily look it up. There are two other cases where you still want it
... you could dial back and look at it publicly if it is public. But this means you don't hav eto do that
... you can use signatures as a uniform method

<rhiaro> sounds to me like it's not required if everything is public though..

tantek: sounds like a path to this ability in the spec is how to handle private content

cwebber: verification is important. It's right that it's not required if things are public
... you could use another mechanism which is to go look at the content
... but it sitll is important that i fyou get a post to your inbox that says here's some content, you have to make sure that the contnet really is from that server, and there are two ways to do it
... if it's public you can look at it
... or in eithe rcase you can use the signature check

<eprodrom> It would make me cry, that's for sure

<cwebber> PROPOSED: Remove section 8 on Authentication and Authorization from spec, move to pointing from security considerations to a mutable document maintained by CG which includes current deployment practices (OAuth 2.0 bearer tokens for C2S, HTTP signatures and sometimes Linked Data Signatures for S2S)

<cwebber> ^_^

<tantek> o_O

<sandro> +1

<cwebber> +1

<tantek> +1

<rhiaro> +1

<eprodrom> +1

<ajordan> +1

<aaronpk> +1

RESOLUTION: Remove section 8 on Authentication and Authorization from spec, move to pointing from security considerations to a mutable document maintained by CG which includes current deployment practices (OAuth 2.0 bearer tokens for C2S, HTTP signatures and sometimes Linked Data Signatures for S2S)

<eprodrom> please mute

<ajordan> question:

<ajordan> are we specifying what type of document the CG might publish? e.g. Note?

<ajordan> fine with this either way though

eprodrom: good question

sandro: cgs can't publish notes. I think they're called reports
... if we wanted to solidify it at some point, some w3c member like mozilla could turn it into a member submission and get it formally archived at w3c

eprodrom: this seems liek the right way to do things
... anything more on AP?

cwebber: in my view we've exhausted it

tantek: the new CR got published right?

cwebber: oh yeah. Yay!

<Loqi> 😄

sandro: I just want to confirm our timeline
... particularly I'm worried about the test suite and test results
... do we have a results matrix yet?

cwebber: i didn't do that yet... implementationr eports or actual running test reports?

sandro: I mean an easy way to see how many tests are passed by implementations

cwebber: we don't have all the test suite done and I havne't been pushing people to use it, so no

sandro: we have about a month and a half to get enough test results to prove implementations

cwebber: it's gonna be difficult
... I guess I have no choice

sandro: there may be some alternative. one alternative is we don't necessarily use the test suite to prove interop. There are other ways, that's the usual one. I can imagine in the s2s thing that it might be more demonstrative to show these two systems federate by running them by hand with people watching
... that I think would suffice an dmight be less work
... make sense?

cwebber: makes sense as an option. DO you think we should hold off on this until midway through next month to say it's an optino on the table?

sandro: I'm saying don't spend all your time getting a s2s test suite if your'e afraid it's not even gonna get done
... if you know you can do it that would be great

cwebber: if there was an option for me to focus on my implementation and encouraging people to test implementations that are already happening
... that's hwo mastodon dev was mostly done, gargon and puckipedia were testing their implementations until they worked

sandro: if there are three implementations that interop that's good
... three makes the case

tantek: I'm not entirely comfortable with that
... if interop is defined by how two implementations happen to work together, there's no guarnatee we've captured those details in the normative spec

sandro: if you have three and one is written by the editor that.. that's the same guarantee as if the test suite aligns with the spec
... if the editor is making an implementation and that interops with two external ones, that's a good case we have interop
... and I think s2s testing is really hard

tantek: right about that

aaronpk: I would have beend one with websub and micropub a looottt sooner...

tantek: the big concern is because the editor is doing both there are assumptions that are not reflected

sandro: that's why you have those two other implementations

tantek: at that point the third implementation might as well be the test suite rather than a third implementation

sandro: if you want to call it the test suite sure, but it wouldn't be doing the same thing as what a test suite would do because it would be driven by hand

tantek: I don't think tha'ts accurate to call it a validator
... we noted it as such as a distinction from a regular implementation

sandro: I think the AP s2s test suite / validator, we can think creatively about it
... it doesn' thave to be a thing you can connect to and run automatically

tantek: I think driven by hand is fine. No requirement for automation

sandro: the standard I just specified is lower than what i was saying before because it doens't invovle puckipedia and mastodon talking to each other

tantek: you're saying we define interoperation by checking that these two interop. We need a textual description of what should happen when you runt wo implementatiosn against each other. That's a test suite.
... You can't avoid documenting hte epxected result

sandro: agreed

cwebber: There's some good news
... When I initially was working on the test suite, I implemented this promty thing that asked you questions
... and the response was you don't want to give people that many prompts
... I can start implementing and see if it can be automated, and if I can't I can have it be a bunch of questions that people can respond to
... and accomplish that way faster

sandro: sounds good

tantek: that's a better approach

<cwebber> sure did

cwebber: knowing that I think we have a safe way forward
... I'll switch to the prompty question direction if automatiion doesn't work

ajordan: if we're going down the prompty path, which seems fine, after we ship a rec I think it would be nice to go back and make that stuff automated, to make new implementations easier

cwebber: the path will still be left open to code i nthe automated tests

WebSub

eprodrom: status

<eprodrom> Someone has background chatter going on

<eprodrom> rhiaro: jinx

<eprodrom> Please mute if you're not on

aaronpk: we have a couple of issues that popped up since ralph started looking

<aaronpk> https://github.com/w3c/websub/issues/125

<Loqi> [sandhawke] #125 Hash Algorithm Selection

aaronpk: the biggest one is the hashing algorithm thing

<ajordan> OK I gotta go to class but just want to say that I've finally been sending stuff to ben_thatmustbeme

<ajordan> nothing major, lots of clarifications merged

aaronpk: essentially PuSH had only specified sha1 as the only valid hash algorithm. A while ago we had added other algorithsm and sha1 is mostly broken now
... but then there was a concern that servers and the hub need a way to negotiate which algorithm to use, which is a rather large new mechanism to add

<ajordan> bye all! thanks for a good (partial) meeting

aaronpk: the current proposal is to drop all the new algorithms from the spec, goign back to the way it was in PuSH and then mention that we may add new algorithms as an extension so we can actually better specify how these algorithms are negotiated
... is that fair sandro?

sandro: I was not proposing formally dropping the other 3
... that struck me as hard to do without restarting CR

aaronpk: I guess I was assumign that the... oh you're right the proposed text doens't drop th eother three
... that leaves it in the same sort of undefined state

sandro: i"m not thrilled with the undefined state but I think tha'ts the most expedient way forward

aaronpk: julien's comment is that it's not a big deal to use a weak hash beacuse if you're also using https there are a lot of layers to break before you can take advantage of a weak hash

sandro: and also if the callback url is secret that also protects you

aaronpk: yeah right
... there's a bunch of layers that are useful even if you have no secret, no hash

sandro: julien's wrong though
... *reads from issue*
... the attacker is trying to alter the content
... not read it
... but as long as it's over https, you could put the secret in cleartext in the packet and it would be fine
... you'd still have to break tls to get through that

aaronpk: the suggestion is to drop the undefined extension
... makes sense to me
... and we don't bother with the rest of the issue?

sandro: I think so. If somebody wants to go ahead and write otu that formal extension
... I think the two reasonable options are my proposed text, or we specify the extension now and do another quick cr

aaronpk: that seems like a pretty drastic thing to be adding

sandro: my guess is nobody has the energy to do that

tantek: I lost track

sandro: I'm not advocating define the negotiation mechanism now
... tha twould be too much work

tantek: which spec change are you advocating?

sandro: the one that's described in issue 125
... remove one sentence and replace it with those two sentences

tantek: and that leaves an opportunity for a later spec to say something?

sandro: yeah

<sandro> In the future, an extension may be specified allowing subscribers to indicate which algorithms they can use for validation. As of this writing, most hubs sign with SHA-1, despite its known cryptographic weakness, in order to be interoperable with older subscribers.

aaronpk: it explicitly says we should define the algorith selection as an extension

tantek: aaronpk can you take that up as a CG item? Create an issue? make sure it continues

aaronpk: yeah

sandro: put the timeline as around the time TLS is broken..

<sandro> PROPOSED: Resolve websub #125 by accepting proposal as written

aaronpk: resolution on proposed text?

<eprodrom> +1

<rhiaro> +1

<aaronpk> +1

<sandro> +1

<cwebber> +1

<tantek> +1

RESOLUTION: Resolve websub #125 by accepting proposal as written

tantek: the text sandro put does touch on a security vulnerability, could you include a list item in security & privacy considerations that calls it out explicitly?

aaronpk: good idea

sandro: yeah
... and I think if the CG puts together an editor's note type thing in github we could probably link to that as an example
... when the rec actually goes out
... that's a reason to write up a draft for the extension in the next few weeks if somebody feels motivated
... 124. We have this content negotiation solution we came up with a while ago. Richard the i18n guy pointed out there's language negotiation too
... and he's asking if we forgot or chose not to do it
... and could we do something about it
... I think the answer is we forgot and should include text saying for either content type negotiation or language negotiation you should be doing the same thing
... I think that solves the problem

eprodrom: next step?

sandro: ben has suggested some text

aaronpk: I want to rephrase that slightly but it has the idea

sandro: sounds good to me
... shall we delegate to aaron to adopt something similar to ben's text and say we'll try to also get richard's approval but I don't think we need to

<sandro> PROPOSED: Resolved websub #124 with something like https://github.com/w3c/websub/issues/124#issuecomment-330580664 but actual wording up to editors

<Loqi> [dissolve] Suggested text

<Loqi> For practical purposes, it is important that the rel=self URL only offers a single representation. As the hub has no way of knowing what mime-type or language may have been requested by the subscriber upon discovery, it would not be...

<sandro> (it's non-normative -- it's explaining what's implied already)

<sandro> +1

<aaronpk> +1

<rhiaro> +1

<eprodrom> +1

eprodrom: any objections?
... anyone still thinking?

<tantek> +1

RESOLUTION: Resolved websub #124 with something like https://github.com/w3c/websub/issues/124#issuecomment-330580664 but actual wording up to editors

<Loqi> [dissolve] Suggested text

<Loqi> For practical purposes, it is important that the rel=self URL only offers a single representation. As the hub has no way of knowing what mime-type or language may have been requested by the subscriber upon discovery, it would not be...

sandro: can we have another resolution to request PR?

tantek: good idea, with the new approvals

<cwebber> +1

<eprodrom> PROPOSED: Advance Websub to PR upon completion of issues #124 and #125

<erincandescent> Hmm, why does #124 not propose the option of multiple hubs? :P

<sandro> +1

<cwebber> +1

<Loqi> Tantekelik made 1 edit to [[Socialwg/2017-09-19]] https://www.w3.org/wiki/index.php?diff=104476&oldid=104473

<rhiaro> +1

<eprodrom> +1

<tantek> +1

<aaronpk> +1

RESOLUTION: Advance Websub to PR upon completion of issues #124 and #125

sandro: aaronpk can you do these changes today? it would be nice to get this stuff off

aaronpk: yeah

tantek: and update the changelog

aaronpk: yep

eprodrom: that wrap sthings up for websub?

AOB

Post type discovery

tantek: nothing this week

jf2

tantek: I think ajordan submitted a bunch of patches and ben merged some of them but we dno't have aj or ben

SWP

rhiaro: Nothing to report

SWICG update

cwebber: only thing is that we have a new member of the group who is excited about anti abuse stuff
... so we should discuss that next week

tantek: cwebber can you email Coralie Mercier requesting space and time at tpac for the social cg

coralie@w3.org

scribe: THe CG has enough stuff to discuss
... We could also do a break out

eprodrom: I think that concludes

tantek: next meeting in 3 weeks, 10th October

<eprodrom> trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/??/BoF/
Succeeded: s/security/maturity/
Succeeded: s/algorithm extension/algorith selection/
Succeeded: s/working/wording/
Default Present: eprodrom, rhiaro, ajordan, aaronpk, tantek, sandro, cwebber
Present: eprodrom rhiaro ajordan aaronpk tantek sandro cwebber
Found ScribeNick: rhiaro
Inferring Scribes: rhiaro

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 19 Sep 2017
Guessing minutes URL: http://www.w3.org/2017/09/19-social-minutes.html
People with action items: