#social 2017-04-25
2017-04-25 UTC
timbl joined the channel
# 
@ChrisAldrich Curious if @altmetric has looked at Webmentons https://www.w3.org/TR/webmention/ so they could potentially support generic… http://stream.boffosocko.com/2017/curious-if-altmetric-has-looked-at-webmentons-trwebmention-so-they (twitter.com/_/status/856676458193965057)
tantek joined the channel
# 
@accessiblestef Webmention - too complicated for me technically, but conceptually great. https://www.w3.org/TR/webmention/ /v @w3c (twitter.com/_/status/856787678662057984)
tantek, dmitriz, timbl, edhelas and elensil joined the channel
# 
elensil hello :)
# cwebber hi
# elensil I'm interested to know a bit more about the work currently done by the Social WG :)
tantek joined the channel
# cwebber hi tantek
# 
RRSAgent logging to http://www.w3.org/2017/04/25-social-irc
RRSAgent joined the channel
# cwebber it's about that time right?
Zakim joined the channel
# cwebber elensil, well, we have a meeting now, it's socialwg participant early but you're welcome to lurk here on irc, could give you a good indication of what we're up to :)
# cwebber present+
# 
ben_thatmustbeme present+
# cwebber I can scribe
# cwebber tantek: let's get started with first item, which is to review minutes from last week, had a brief telcon to discuss activitypub issues
# cwebber tantek: let's see what the rest of the folks who were here, see if the minutes are good
# dmitriz present+
# ben_thatmustbeme needs to remove the DRAFT header and we usually remove the footer stuff too
# cwebber would it be safe to do PROPOSED now?
# cwebber
# 
sandro PROPOSED: approve https://www.w3.org/wiki/Socialwg/2017-04-18-minutes
# cwebber +1
# cwebber was there
# ben_thatmustbeme majority of those that were there are here
# cwebber TOPIC: next telecon
# cwebber tantek: with excepttion of last week we've done them every other week, that would place next telecon on May 9th
# cwebber tantek: how does that sound for folks?
# cwebber evan: I think it makes sense
# cwebber sandro: I'd propose doing every week
# cwebber would prefer every week at this point, but can do every other
# cwebber evan: could we do half hour every week instead of an hour?
# cwebber sandro: I don't think we've been wasting time in meetings
# cwebber evan: I'm happy to do a full hour I just don't want to take up more of peoples' time than we need
# cwebber evan: and we are down to one to two specs at this point
# cwebber sandro: we only need the people who are there
# cwebber sandro: maybe we can wait till the end of this meeting and see how we're doing
# cwebber tantek: I'll offer my opinion, the key thing I think is to actually have progress on the things we've made progress on
# cwebber tantek: if we don't have a test suite that's ready, a meeting is not going to change that
# cwebber tantek: so that's why I have my doubts about meeting every week
# cwebber tantek: I'd like to allow people to have their time to focus
# cwebber tantek: maybe I should ask chris and aaron
# cwebber tantek: do you think it'll be done in 2 weeks? or will it be done in a week?
# cwebber aaronpk: I don't think I can guarantee having it done in a week... two weeks yeah
# cwebber evan: we also need to get implementations done, 2 weeks sounds right
# cwebber sandro: if I remember right last week we decided to do breaking changes on ActivityPub
# cwebber sandro: and the absolute final deadline for doing breaking changes is 3 weeks from now
# cwebber sandro: so there's a lot of deadline pressure
# cwebber sandro: maybe we're not doing any more deadline pressure
# cwebber tantek: let's at least put up the we need to do in two weeks or three weeks
# cwebber sandro: if there are any open issues in AP, we should do it next week
# cwebber tantek: why not in two weeks
# cwebber sandro: in theory we could do it in two weeks
# cwebber sandro: in a four hour meeting in two weeks? some of these take a while
# cwebber tantek: here's the other side of that... if we're seeing a rate of normative substantiative issues come in, then it might make more sense to give chris and others more time to wrap them up
# cwebber tantek: that was going to be the second question I was going toa sk
# cwebber *ask
# cwebber tantek: if we have a high rate of substantiative meeting
# cwebber +1 to rhiaro
# cwebber tantek: not all these issues need to be discussed in the telcon
# cwebber tantek: if editors and people who raised them can resolve them, we can quickly knock them out
# cwebber rhiaro: in the interest of this meeting to use this week to do things, can we agree to do a meeting next week and see if we need it
# ben_thatmustbeme +1 to schedule it and can always cancel
# cwebber tantek: you're right, let's do a straw poll to see
# cwebber tantek: just enter into irc
# cwebber cwebber: I'd prefer a meeting next week
# cwebber cwebber: all weeks :)
# ben_thatmustbeme do we want to schedule it as an activitypub meeting next week then?
# ben_thatmustbeme nods
# cwebber RESOLVED: will hold meetings on may 2nd and may 9th
# cwebber tantek: please try to resolve issues outside of the call on github
# cwebber tantek: quick PR update status
# cwebber tantek: we do have PRs for AS2 and MicroPub (congrats)
# cwebber tantek: any calls for changes or objections?
# cwebber rhiaro: we have mostly positive comments (?)
# cwebber tantek: we have until may 11th for people to review the PRs
# cwebber rhiaro: so that goes to the last one which is WebSub
# cwebber tantek: oh ok, can you give us a summary of the end date
# cwebber sandro: AP and WebSub don't have deadlines there because thye haven't gone to PR yet
# cwebber sandro: from the perspective of this, it's only the PR that gives us a deadline
# cwebber tantek: last I looked at it I saw a bunch of positive votes saying they like LDN, want to give it their support
# cwebber tantek: last I saw we could use a few more AC reps voting on AS2 and MicroPub
# cwebber tantek: so if you know member organizations, reach out
# cwebber tantek: encourage them to at least say hey, this is a good idea, make this recommendation
# sandro https://www.w3.org/Member/ACList List of W3C companies and their representatives
# cwebber tantek: they have till May 11th, so
eprodrom joined the channel
# cwebber tantek: so that's something everyone can do
# cwebber tantek: that'e enough on that...
# cwebber TOPIC: Websub
# cwebber tantek: any comments from the AC on websub and activity[streams]?
# cwebber tantek: it didn't sound like it, but figured I'd explicitly ask
# cwebber tantek: I assume rhiaro is muted or checking
# cwebber rhiaro: no explicit comments
# cwebber tantek: we'll assume if they are they're filing them in github, etc
# cwebber TOPIC: Social Web Protocols
# cwebber tantek: there's been revisions, suggesting publishing new version
# cwebber rhiaro: need to pull up changelog
# cwebber rhiaro: so I brought all of the websub stuff up to date
# cwebber rhiaro: I'd appreciate it if aaron, etc did so
# cwebber rhiaro: looked at it
# cwebber rhiaro: I also tidied it up a bit
# cwebber tantek: aaronpk, julian, did you look at it recently?
# cwebber aaronpk: I have reviewed it recently but not specifically for websub, I can go through that
# cwebber tantek: ok
# cwebber tantek: let's give you a few minutes to do that; we'll come back to social web protocols
# cwebber tantek: we'll give a few minutes to do that
# cwebber tantek: I don't have any updates on post type discovery, we'll skip for this week
# cwebber tantek: we don't have julian on the phone do we?
# cwebber tantek: no, ok
# cwebber tantek: chris is minuting and has to do AP ;)
# dmitriz (oh, awesome… re convergence between sigs & jose)!
# eprodrom q+
# eprodrom q+
# cwebber scribenick: cwebber
# cwebber aaronpk: I have two issuses open on it, and I do think they should be addressed before publishing
# cwebber tantek: those are new issues, so instead of discussing them in realtime, I'd like rhiaro to look at them
# cwebber tantek: would you be okay with delaying a decision to public next week
# cwebber rhiaro: would publishing with these issues be enough to keep a version from november up
# cwebber rhiaro: would you object with these issues aaronpk
# cwebber aaronpk: I guess I'd be willing to publish even with these issues
# cwebber PROPOSED: publish an update to Social Web Protocol with current draft
# cwebber tantek: one issue is to note the issues inline, or we could try to do another draft next week
# cwebber aaronpk: let's just do another draft
# cwebber cwebber: +1
# eprodrom +1
# cwebber RESOLVED: publish an update to Social Web Protocol with current draft
# cwebber tantek: appreciate the update rhiaro, and let's do more rapid updates too
# cwebber TOPIC: websub
# cwebber tantek: where are we at with normative issues aaronpk ?
# cwebber aaronpk: I believe we haven't had any issues come in
# cwebber tantek: as in terms of group decision issues, do you have any editorial issues that require republishing?
# cwebber aaronpk: one thing that came up two weeks ago, I'm trying to remember if this needs any editing of the text, just gimme a sec
# cwebber tantek: basically is the editor's draft disparate from the CR
# cwebber aaronpk: I don't think there's any difference in the ED right now
# cwebber aaronpk: just trying to remember if this issue requires any editorial changes
# cwebber aaronpk: I remember it doesn't have any functional changes
# cwebber tantek: could you give us an update on the test suite
# cwebber aaronpk: no test suite yet, will work on it in the next 2 weeks
# cwebber tantek: ok in the issue of moving forward, we're done with websub issues this week
# cwebber tantek: I think we can re-address this next week with whether to update with CR updates
# cwebber tantek: that brings us back to AP
# eprodrom +q
# 
rhiaro "To make content available as ActivityStreams 2.0 JSON, one could do so directly when requested with an appropriate Accept header (eg. application/activity+json or application/ld+json), or indirectly via a rel="alternate" type="application/activity+json" link . This link could be to a different domain, for third-party services which dynamically generate ActivityStreams 2.0 JSON on behalf of a publisher."
# eprodrom q?
# cwebber o/
# eprodrom cwebber, aaronpk : let's stay on the channel
# eprodrom I'd like to walk through the flows that we might need to execute to get some basic tasks done
# cwebber eprodrom, sounds good
# RRSAgent I have made the request to generate http://www.w3.org/2017/04/25-social-minutes.html trackbot
# cwebber eprodrom: it's tricky also because we need to actually put these workflows into the test suite
# cwebber ....
# dmitriz @eprodrom / @aaronpk / @cwebber — I’d love to join in on the s2s auth conversation (I’ve been implementing s2s auth using oauth2/oidc for the last several months)&
# cwebber hopes eprodrom reappears
# 
tantek aside: cwebber I took a quick look at https://github.com/w3c/activitypub/issues and take your word for it that none of those require normative changes, however it would be good to process as many of those as possible (even for editorial changes to AP) for next week
# cwebber tantek: there's a lot of them with normative changes, but which we discussed last week and I didn't resolve yet
# cwebber we came to resolutions
# cwebber but they weren't incorporated
# cwebber tantek: yes I think I recorded them
# cwebber yep
# cwebber tantek: was focusing on the test suite
# dmitriz i think he said he’s grabbing coffee?
eprodrom joined the channel
# eprodrom cwebber, aaronpk : are we stepping away for a couple of minutes?
# cwebber hi eprodrom, welcome back
# eprodrom thanks
# cwebber tantek: kk
# cwebber eprodrom: I think aaron was grabbing test suite
# cwebber er
# cwebber grabbing coffee
# cwebber words!
# eprodrom OK
# eprodrom cwebber: I'm going to come right back then
# cwebber np, thanks for chairing tantek
# cwebber ajordan: yes that'd help, maybe ping me on irc with which ones you're hopping on first so I have a heads up and we don't duplicate efforts?
# cwebber aaronpk: I think "don't get the recommendations for what to do with oauth in the security considerations section wrong, even better, give something usable" :)
# cwebber I also want to leave in the possibility of signatures via LDS or etc, even if not specific
# cwebber because this is the #1 requested feature from existing federation systems
# cwebber so we don't have to be specific, I just want to reference it at least
# cwebber but I guess I don't need others to leave that vague part in there
# dmitriz speaking of signatures, I have a general auth question. if the specs are using so many components of oidc (oauth2, discovery, signatures), why not use oidc directly?
# eprodrom I'd like to step through some of the flows and make sure we can point to OAuth 2.0 specs that deal with them
# cwebber tantek: +1
# eprodrom Nobody has to be part of this and if you'd rather handle it in an issue happy with that, too
# eprodrom aaronpk: there's 2-legged authentication too
# eprodrom At least in 1.0
# eprodrom That's what pump.io depends on
# eprodrom aaronpk: fair enough
# dmitriz oauth2 is very much usable for server to server
# cwebber dmitriz: we resolved to not be super specific about the auth stuff in this group aside from a general recommendation of bearer tokens given the amount of churn happening
# dmitriz not just bearer tokens (which I’m generally against, since they’re only one step away from signed id tokens, which are much more secure)
# eprodrom Damn
# cwebber dmitriz: so right now the state in AP will be that we're going to recommend loosely a route for auth stuff in activitypub's security considerations section, but it won't be pinned down as normative
# dmitriz but s2s auth is possible if both servers are essentially peer nodes, both identity providers & clients. and dynamically register with each other
# eprodrom wow
# eprodrom lot of chatter
# cwebber yeah
# dmitriz i’m not sure it’s even wrangling, though
# cwebber eprodrom: ok, I want to hear what pump does
# eprodrom maybe we could step through the flows? Seems like we're getting way ahead of ourselves here.
# cwebber yes
# cwebber +1
# eprodrom Thanks
# eprodrom Great
# eprodrom ajordan: are you still around? Maybe you can refresh my memory on some of this
# eprodrom Let's start with a typical client task: posting a new activity
# eprodrom The client only has the identity of the client user
# eprodrom in pump.io that's a webfinger ID like evan@example.com
# eprodrom but in AP it'd be a URI like https://example.com/evan
# eprodrom pump.io uses OAuth 1.0
# elensil hey
# eprodrom So we need an access token to make a post
# eprodrom ajordan: thanks
# elensil should I wait the end of your meeting to ask questions :) ?
# eprodrom So the first step is discovering the oauth 1.0 endpoints: getting a request token, making the authorization request, and then turning the request token into an access token
# cwebber elensil: yes please, we're having a tricky auth convo
# eprodrom pump.io does this using Host Meta discovery
# elensil ajordan, that's fine ;)
# eprodrom It also has a discovery method for getting a client ID
# cwebber eprodrom: when pump.io clients continue to communicate with the server, they supply *just* the access token right?
# eprodrom which it needs for doing the 0auth 1.0 flow
# eprodrom cwebber: correct
# cwebber ok
# eprodrom cwebber: well, mostly
# eprodrom you need the client id and the access token for OAuth 1.0
# eprodrom in Oauth 2.0 it's just bearer tokens
# cwebber right ok
# eprodrom Right
# eprodrom So that's the main parts of discovery for pump.io, if you're a client trying to post on behalf of a users
# cwebber has commentary but will wait until we finish the pump.io workflow
# eprodrom I think for AP, you could do the same thing starting out with the user ID as an URI
# eprodrom cwebber: go ahead with the commentary, I'm done on this one
# eprodrom Otherwise I'd like to step through it for AP
# cwebber so it's observable in desktop clients on gnu/linux how the oauth 1.0 workflow is kinda painful, and I tried to figure out if it can be less painful for oauth 2.0 and it still looks painful
# cwebber the initial setup
# dmitriz which part is painful?
# cwebber in pump clients, you're basically redirected to a uri where you authorize, and then you have to copy paste back the token you get into your client
# cwebber when I looked at how it could be done through oauth 2.0, the recommendation seems to be "use a redirect uri parameter"
# dmitriz oauth2 dynamic registration lifts the need for cutting & pasting
# cwebber but, that assumes that either a) you have a web server as a client
# cwebber or b) you have the id to set up custom myapp:// type things
# cwebber which you don't have on all systems
# cwebber ajordan: that's also very wonky
# cwebber embedding a browser is not great
# eprodrom So, are we going to fix this?
# eprodrom I feel like this UI discussion is a distraction
# cwebber ok
# eprodrom Sweet
# cwebber fwiw I think having a signature direction for auth workflows could actually resolve this
# cwebber but
# eprodrom OK, so, the tricky part with this in pump.io is the client registration
# cwebber that's out of scope of this conversation
# eprodrom Unlike, say, Twitter, there's not an out-of-band mechanism for getting a client ID
# eprodrom Right
# cwebber yeah client secrets don't make sense for FOSS projects anyway
# cwebber anyone can look at pumpa's source code to find out what its client secret would be
# dmitriz well wait though
# eprodrom Well, sorry kids, but they do
# dmitriz for oauth2, you need client secrets for confidential clients
# eprodrom In this case, for s2s, we use the client id and secret
# dmitriz (ie, server-side apps).
# eprodrom That's the 2-legged auth
# cwebber eprodrom: ok for *server to server*
# cwebber yes
# cwebber for client to server, no
# eprodrom Fair enough
# dmitriz k.
# dmitriz client registration is still necessary though
# eprodrom So, I'm trying to remember how the client registration works in pump.io
# dmitriz because it’s essentially the only way to verify public clients (read: in-browser apps, desktop apps, etc)
# eprodrom If I remember correctly we used an early version of 0auth 2.0 client reg
# dmitriz registration is the way to get those urls
# 
ajordan eprodrom: https://openid.net/specs/openid-connect-registration-1_0.html is what's linked to
# eprodrom ajordan: thanks!
# eprodrom for pump.io, we also use dialback authentication
# eprodrom Basically, it's a way for a server to say "I am this server" and be able to prove it.
# eprodrom Yes
# eprodrom But it's the same client registration endpoint
# eprodrom OK, so I think that's it for C2S
# eprodrom I think for AP, it should be possible to go from a user's URI to a bearer token
# eprodrom First, by doing 0auth 2.0 discovery for the endpoints
# eprodrom I don't remember if a client id is necessary there
# 
aaronpk here is oauth2 discovery https://tools.ietf.org/html/draft-ietf-oauth-discovery
# cwebber eprodrom: what do you mean oauth 2.0 discovery for the dnpointts?
# cwebber oh
# dmitriz (this is what we’re doing in solid, fwiw. user’s uri -> token, via discovery)
# dmitriz (except using oidc discovery, which is basically a slightly more specified version of oauth discovery)
# eprodrom Do you have to do client registration, too?
# dmitriz yes
# dmitriz dynamic registration, if that helps
# aaronpk fwiw PKCE basically makes client secrets unnecessary, and google has already implemented this https://tools.ietf.org/html/rfc7636
# eprodrom So, uri -> (optionally client registration) -> (optionally endpoint discovery) -> oauth 2.0 authorization -> token
# dmitriz so, PKCE is useful, but is often overkill for s2s
# eprodrom I think we're done talking about c2s
# dmitriz oh, I thought eprodrom said that was it for c2s
# eprodrom Is there a part of the flow that isn't specified that we couldn't speak to?
# dmitriz sorry bout that.
# cwebber so
# eprodrom I think the only part I'd be concerned about is that if my id uri is https://example.com/evan then the host for oauth discovery would be example.com
# dmitriz that’s true
# cwebber we're describing some pretty complicated workflows
# cwebber and we had talked about watering down that section
# cwebber now it feels like it's going to actually get way more complex
# cwebber which, the reality is
# cwebber the implementation stuff is going to be complex
# cwebber the question is, where do we put this
# eprodrom Security notes section
# eprodrom cwebber: so, what I'm more concerned with is having an unimplementable spec
# cwebber eprodrom: I'm concerned about this too
# dmitriz why unimplementable?
# eprodrom So let's make sure there's one path through, and that we can describe in about a paragraph how to do this with Oauth 2.0
# eprodrom aaronpk: that sounds correct to me
# eprodrom The only problem is that some of those oauth 2.0 specs are not yet final
# dmitriz which ones?
# eprodrom oauth discovery
# cwebber eprodrom: this stuff not only needs to be implementable, we actually also need to have it implemented in the test suite... in the next two weeks!
# eprodrom cwebber: yes
# dmitriz hmm, that’s odd. I didn’t realize that one was still in draft. fwiw, the OIDC discovery is 1.0, out of draft.
# eprodrom dmitriz: true
# cwebber so also, I'm just going to say that as an individual
# eprodrom We'll need to decide whether to go with one or the other
# cwebber about 9 months ago I sat down to try to learn how to do these oauth workflows and etc
# cwebber and I printed out a ton of docs
# eprodrom OK
# cwebber and it was one of the worst weeks of my life
# dmitriz (in fact, the list of authors on the oauth discovery spec is pretty much the same as the oidc discovery. so I think they just moved on.)
# eprodrom I don't know if this is a fruitful path for this conversation
# eprodrom Or a good way to use people's time
# cwebber what I'm saying is
# cwebber I want to have a single paragraph that describes a workflow
# eprodrom OK, I will write that paragraph for you
# cwebber *without* people having to traverse too many other docs finding out the right ways
# eprodrom Could we move on to S2S?
# cwebber yes
# eprodrom ajordan: we have to have something in the test suite
# eprodrom Could be unauthenticated, could be HTTP basic, could be access token acquired out-of-band
# eprodrom I'm going to move on to s2s
# eprodrom So for pump.io we use 2-legged Oauth 1.0 authorization
# eprodrom OK, sure
# eprodrom Yes
# eprodrom If that's OK with everyone, it seems like the right direction to go
# cwebber thank you eprodrom :)
# eprodrom No problem
# cwebber +1
# eprodrom So let's go to S2S
# eprodrom [12:48] <eprodrom> So for pump.io we use 2-legged Oauth 1.0 authorization
# eprodrom Let's say a pump.io server needs to deliver an activity to the inbox of a user on another server
# eprodrom Yes
# eprodrom so, example.net is delivering an activity by evan@example.net to the inbox of jane@example.com on example.com
# eprodrom aaronpk: it's too hard to do
# dmitriz what is?
# cwebber bipedal
# cwebber (sorry)
# eprodrom I took the expedient of saying "If it's from example.net, and they say that it's by evan@example.net, it's probably actually by evan@example.net"
# dmitriz are there signatures involved?
# eprodrom You could make a case for saying, "No, evan@example.net has to authenticate to example.com and the delivery should happen with that token"
# dmitriz as in, does example.net sign it?
# eprodrom But that's really tedious
# eprodrom dmitriz: Oauth 1.0 2-legged authentication
# eprodrom So yes
# eprodrom aaronpk: yes
# dmitriz it’s tedious, but isn’t it kind of necessary? (for evan to authenticate to example.com) at very least, evan needs to consent to that trust relationship the first time that server is encountered?
# eprodrom Anyway the flow works kind of like this:
# eprodrom dmitriz: I think that's asking too much
# dmitriz go on, re work flow
# eprodrom If every time someone from somerandomserver.example follows me, I have to go authenticate to their server to allow delivery of activities, that's a big pain
# dmitriz oh, agreed
# eprodrom OK, thanks
# dmitriz I assume you allow that server once.
# eprodrom So, for delivery, flow goes something like this:
# eprodrom discovery via hostmeta -> client registration with dialback authentication -> 2-legged Oauth 1.0 authentication for delivery
# eprodrom I'm a little foggier for what we'd do for AP S2S
# dmitriz just to be clear, who is authenticating in that last 2-legged step?
# eprodrom example.net server
# dmitriz k
# eprodrom Right
# dmitriz makes sense. what’s the difficulty for s2s for AP?
# eprodrom Well, I guess we'd do client registration the same way
# dmitriz yeah!
# dmitriz the servers just register with each other as clients
# eprodrom But
# eprodrom Is there a callback mechanism in OAuth 2.0 client registration?
# dmitriz there is
# dmitriz one sec
# eprodrom Or some way of knowing that the client registration came from example.net
# aaronpk i don't see anything in http://openid.net/specs/openid-connect-registration-1_0.html#RegistrationRequest which is where i'd expect to find it
# dmitriz ah, well, so, with oidc registration, the callback happens not at registration but at code exchange (getting the access token) step
# dmitriz it’s postponed till that
# dmitriz should be just in the authorization code workflow
# dmitriz lemme find link
# dmitriz yeah I hear you there
# dmitriz specifically...
# cwebber so
# cwebber this is why the diaspora and ostatus users from mastodon and etc want signatures I think right?
# cwebber because if you had a key tied to a user
# cwebber you could sign the message before shooting it over the wire
# dmitriz https://openid.net/specs/openid-connect-core-1_0.html#AuthResponse <- callback
# cwebber and if the server can look up the user's key once
# cwebber it can verify posts coming over the wire
# cwebber and that's already how diaspora does it
# dmitriz the user at the browser part is not necessary for s2s
# eprodrom blushes
# dmitriz and yes, oidc relies on signatures on both sides
# dmitriz and the key discovery mechanism
# dmitriz I think there’s a POST response type also
# dmitriz but lets step back
# dmitriz what’s the core meta-question? how do the two servers verify each other?
# eprodrom dmitriz: yes
# eprodrom Well, one-way
# eprodrom Presumable example.net already knows that example.com is example.com
JanKusanagi joined the channel
# JanKusanagi o/
# eprodrom JanKusanagi: yo
# cwebber so, I'm going to wait until this OAuth mechanism is fully described, but I do want to describe one alternate workflow at the end of this
# ajordan JanKusanagi: heya! logs if you want to read back: https://chat.indieweb.org/social/2017-04-25
# cwebber but there's productive discussion
# cwebber so I don't want to interrupt
# cwebber okay actually aaronpk just queued me to say it :)
# cwebber right exactly
# cwebber so here's a super simple workflow
# cwebber the linked data signatures route would be:
# cwebber the user has their public key embedded *in their actor profile*
# cwebber so a server either has already retrieved that user's profile
# cwebber or they do so when first seeing the user
# cwebber when you get a message
# cwebber the signature is *attached* to the message sent server to server
# cwebber and whammo, no need to look back and forth for any token things
# cwebber you just sign messages
# cwebber aaronpk: already done
# eprodrom So, I've always liked what Blaine Cook says about security specs
# eprodrom Which is, "If you get to public key infrastructure, back up, because you've gone too far."
# cwebber aaronpk: it's part of the LDS spec, it uses normalization of linked data
# cwebber I really don't agree with this eprodrom
# cwebber but I know others in the group feel strongly about it
# cwebber so
# cwebber I think we should provide the signature-less direction I guess
# eprodrom I understand
# cwebber and also provide this other route
# cwebber I'm willing to implement both
# dmitriz (ok, found the part in the OIDC spec for client verification)
# cwebber aaronpk: it moved
# cwebber I informed them, they haven't updated the spec
# cwebber but here it is:
# dmitriz (it’s sort of hidden in https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata — the client passes its keys (either embedded or as a uri) that the server uses to verify it during registration)
# dmitriz (if you look at the jwks_uri section “ If the Client signs requests to the Server, it contains the signing key(s) the Server uses to validate signatures from the Client.”)
# eprodrom OK
# cwebber aaronpk: looks easier once you have a library that already implements the normalization :)
# cwebber everything there on out I think is honestly easier
# cwebber but
# aaronpk i don't even know what half these words mean in the algorithm section https://json-ld.github.io/normalization/spec/#normalization-algorithm
# cwebber ok
# cwebber well
# cwebber I'm not going to fight on this, at least we should move forward with a route that works and uses an oauth worklow resembling something like what the world currently uses
# cwebber I agree that LDS route needs to incubate itself more
# eprodrom So, I get foggy when I try to understand where LDN fits in here
# cwebber ok
# eprodrom well, actually
# cwebber forget I raised it!
# eprodrom I meant LDN
# aaronpk cwebber: i mean if you can tell me how I can sign this example object in a paragraph then i'll reconsider https://www.w3.org/TR/activitypub/#obj
# eprodrom It looks like LDN just punts on AuthC which is fine
# cwebber aaronpk: the signing algorithm itself is very short once you have it normalized
# cwebber aaronpk: and in fact it looks like jose will be used
# cwebber aaronpk: well, you shouldn't have to, any more than you should have to write an html parser
# eprodrom So, it seems we're at a bit of an impasse
# cwebber eprodrom: I guess it was a mistake to bring it up.
# eprodrom No, it's fine
# cwebber eprodrom: the LDS direction isn't ready yet, but
# cwebber eprodrom: this is also something *very specifically* asked for by the Diaspora and Mastodon communities
# eprodrom cwebber: that doesn't make any sense for Mastodon since they use OStatus
# cwebber eprodrom: they use salmon too, and I think they want to do more along that direction
# eprodrom aaronpk: I think we're there
# eprodrom cwebber: right
# eprodrom OK, so, if I can characterize the discussion so far
# cwebber I think the best direction is to support the workflow you have described for OAuth, but leave open the signatures direction
# eprodrom 1) We have a path for C2S, which eprodrom will document for cwebber to include in security considerations
# cwebber +1
# eprodrom (Probably with group approval?)
# eprodrom 2) We have a couple of paths for S2S authentication
# eprodrom UNFORTUNATELY, this happens to be a part of your spec where you don't want to have a lot of options
# cwebber totally agreed :\
# eprodrom A user can sit in front of their client and try a couple of different C2S auth mechanisms
# eprodrom Server implementations won't do that
# eprodrom It's better to have one
# eprodrom S2S, that is
# dmitriz +1
# eprodrom We don't have to decide today, but we should probably work up a couple of proposals for discussion for the next meeting
# eprodrom I'd suggest having one mechanism as a SHOULD and mention other mechanisms as a MAY
# eprodrom cwebber: does that sound about right?
# cwebber eprodrom: so you're suggesting we make it normative?
# cwebber eprodrom: it could also be a Very Strongly Worded section of the security considerations section :)
# eprodrom tantek: agreed
# eprodrom cwebber: I think you can just be suggestive for c2s
# eprodrom But for s2s it just won't work without some bedrock SHOULD
# cwebber eprodrom: we're going to need to implement like hell to make sure this works enough with a SHOULD
# eprodrom cwebber: I don't think we have a choice
# cwebber feels really nervous!
# cwebber I'm not saying you're wrong, I feel like we're dancing near the edge of a cliff on this though
# eprodrom I know!
# eprodrom yeah
# eprodrom cwebber: we have to implement s2s
# cwebber hey pubstrate implements server to server without any checks right now ;)
# cwebber isn't that good enough ;)
# cwebber I'm joking
# cwebber so
# cwebber points gun footward
# eprodrom I guess I just don't know what else to do
# cwebber we've been having a *lot* of recent activity and interest in activitypub right now
# cwebber but it's right up to the line
# cwebber it feels hard to believe we're going to make this without an extension
# eprodrom If I were going to move stuff to a different spec, I'd move the whole S2S section with authentication
# cwebber we have the right level of interest and activity right now
# cwebber but it's happening all right up near the finish line
# cwebber and that's not great
# eprodrom aaronpk++
# dmitriz see, I dont think the requirements are that different
# cwebber oops
# cwebber aaronpk: I'll do that this week
# cwebber hopefully today even
# cwebber so
# cwebber this is literally the one big gaping hole left open in the spec
# cwebber what's the shot of an extension? :)
# cwebber like seriously
# cwebber we're so close on this stuff
# cwebber but
# cwebber aaronpk: are you making an accounting joke or are you talking about community interest
# cwebber because right now I think the community interest level is high
# cwebber we have several *existing* federation communities actively talking about implementing activitypub
# cwebber so
# cwebber I feel like with 3-6 more months? we'd have activitypub out the door for sure
# cwebber ok
# cwebber so are you saying, I should join the SWICG and ask people to join?
# cwebber but if the SWICG isn't doing anything yet
# cwebber am I just asking them to fill seats?
# eprodrom cwebber: can I propose
# eprodrom That we make sure to publish the c2s part of AP
# eprodrom It's the most mature and ready to go
# cwebber :(
# eprodrom And let's figure out whether we will also do the s2s
# eprodrom Again, if we get N implementations, I'm happy to see it happen
# cwebber I actually think that's a worse plan, becasue it gives a good shot at punting on AP's S2S as being a deliverable of this group
# cwebber and definitely seems to punt on an extension
# cwebber and I think AP S2S is the interesting thing
# cwebber C2S I think is not as interesting without S2S
# eprodrom cwebber, client-to-server is a huge part of social
# cwebber aaronpk: but right, we're now at the piont where people ares starting to implement
# cwebber aaronpk: not sure if you saw
# cwebber but mastodon got a PR for the outbox
# cwebber I'll say that I'm not interested in working on that, because it doesn't tell a useful story
# eprodrom cwebber: what do you mean?
# eprodrom Well, here's where I sit
# cwebber this is what I mean
# cwebber eprodrom: this justifies, and makes interesting, the whole inbox/outbox workflow
# cwebber aaronpk: +1
# eprodrom So, here's where I stand
# eprodrom We have a little under a month to get interoperating S2S versions going, under the auspices of this WG
# eprodrom I think it's possible to do, but we have a lot of hacking to do
# cwebber and it's probably true that we can do it if we implement the pump.io workflow
# eprodrom If it's not possible to get those interoperating S2S versions going, I'd very much like to ship the C2S stuff
# cwebber ok, can I modify that?
# eprodrom Because I've spend about 10 years working with client developers and I can say very conclusively that they find client APIs interesting
# cwebber If it's not possible to get those interoperating S2S versions going, and we can't get an extension, I'd very much like to ship the C2S stuff
# cwebber (but, I'm not really excited about that)
# cwebber I know that C2S is interesting, but it's not why I'm here
# eprodrom Why not?
# cwebber and I feel like we're going to blow an opportunity
# eprodrom OK
# cwebber I'm not saying I'm opposed
# eprodrom Well, the opportunity is now to define and implement the S2S part
# cwebber I'm just not excited
# eprodrom OK
# eprodrom Oh, crap
# eprodrom aaronpk, dmitriz, cwebber : I forgot to talk about one flow
# dmitriz go on
# eprodrom It's c2s where the end user doesn't have an account on the server
# eprodrom Say, when evan@example.net wants to look at the contents of an object at https://example.com/note/note-by-jane-1
# cwebber eprodrom: (note we do have a workflow for that in the AP spec right now for reading)
# cwebber but keep going!
# eprodrom cwebber: https://www.w3.org/TR/activitypub/#client-to-foreign-oauth ?
# eprodrom Cool
# eprodrom With pump.io we use proxies
# eprodrom So evan@example.net's client requests from example.net to get the content, and then example.net requests the content from example.com
# dmitriz yeah, this is something i’ve been working on too, the foreign auth
# eprodrom ajordan: agreed
# eprodrom ajordan: right
# cwebber eprodrom: we have proxy stuff in AP too
# JanKusanagi well, in my experience the proxy thing works quite allright, except when there's an "API route" that's not proxied, or the fact that proxy errors don't carry the original error
# JanKusanagi also, double server load when you need to download media (say, a big video) through the proxy
# eprodrom JanKusanagi: yeah, that stinks
# dmitriz yeah. and the other problem w proxy is for “unattended” server side apps
# dmitriz the classical oauth2 use case
# dmitriz just made harder with more actors in the mix
# eprodrom cwebber: so, the spec right now says s2s with LDS and/or JWKS
# eprodrom Again, PKI
# eprodrom But I'd rather ship with that then have nothing
# eprodrom s/then/than/
# cwebber eprodrom: yeah
# dmitriz well wait though. there’s two different kinds of PKI. there’s PKI for people, in which case sure, that saying holds true. and then there’s PKI for servers (for oauth2 discovery / oidc). which is an easy, and solved problem
# cwebber eprodrom: so what I was hoping for out of this
# cwebber was for you to define the oauth workflow
# cwebber in a couple paragraphs
# cwebber maybe a PR?
# cwebber and then I could implement it over this week
# cwebber both in the test suite and pubstrate's implementation
# cwebber eprodrom: could we do that? That would be moving forward
# eprodrom Sounds fine-ish
# cwebber eprodrom: the current state of the test suite and pubstrate is that I've done the C2S, though obviously since I missed an endpoint
# cwebber I must have done the workflow wrong
# cwebber so I'd like to correct it, but I haven't done S2S
# cwebber so if I could get that in
# cwebber since pubstrate currently doesn't do any auth (and that's one reason I don't have a public instance up)
# cwebber and then I can also add it to the test suite
# cwebber and we can get moving
# cwebber and as for the LDS, I still uphold that it's interesting, and may be even the right way to go, but it shouldn't hold things back, and obviously bringing it up here is doing so
# cwebber eprodrom: could you make that an item you can deliver on today or tomorrow?
# eprodrom cwebber: I think if we can stick with just one kind of JSON signature, we'll be better off
# cwebber getting a PR with that workflow in the text?
# cwebber eprodrom: good news
# cwebber LDS and JWS are converging.
# cwebber so there's no conflict.
# eprodrom cwebber: the c2s workflow? ye
# eprodrom yes
# cwebber that's my rough understanding
# cwebber LDS will be probably using JWS, and will instead be how you embed the signature and key on the object
# cwebber sorta.
# eprodrom I don't get how JWK works so I don't think I can get it to you today or tomorrw
# cwebber eprodrom: ok, well you described a workflow today though
# cwebber do you think that workflow is worth putting down?
# cwebber into spectext?
# eprodrom Yes
# cwebber and is it understood enough to be sufficient/implementable?
# cwebber sweet
# cwebber eprodrom: then get a PR for that too!
# dmitriz (this is the single coolest thing I’ve learned today, that JWS and LDS are converging)
# eprodrom I think so
# cwebber dmitriz: that's my understanding, don't quote it as definitive
# eprodrom cwebber: could you explain to me how the S2S signature system works?
# dmitriz no worries. I just thought the LDS crowd was thoroughly opposed
# eprodrom Don't you have replay problems?
# dmitriz I’m happy to explain, too
# eprodrom I guess that's always a problem with bearer tokens too
# dmitriz it is. which is why I wanted to ask why the insistence on bearer tokens, for many of these specs
# cwebber eprodrom: https://w3c-dvcg.github.io/ld-signatures/#dfn-nonce
# eprodrom Developers like bearer tokens
# dmitriz and the solution is fairly simple (if not always easy in the details). which is to have an audience property in the token.
# dmitriz which is the route OIDC took. (and Facebook’s oauth2 implementation)
# eprodrom OK, I have to go
# cwebber dmitriz: I wonder if OIDC's use of signatures and linked data signatures' use of signatures aren't too different in the path they take
# cwebber not in implementation
# cwebber but for the direction they're used for
# dmitriz I think they’re very similar. (I’d need to look again at the LDS spec)
# cwebber eprodrom: ok, please get those PRs up there
# cwebber eprodrom: thanks for taking the time, and to everyone else who did too :)
# dmitriz from what I understood from talking to Manu & crowd, LDS considered JWS but rejected it initally due to a very specific constraint. (having to do with being able to index JWKs in databases, etc)
# eprodrom ajordan: just hit me now, I'm still here
# eprodrom Prrrrobably?
# eprodrom Not for a little while
# eprodrom Right
# eprodrom It's very host-meta/webfinger-centric
# eprodrom Cool
# cwebber eprodrom: brief PM before you vanish
# cwebber sent!
# ajordan cwebber: https://www.w3.org/community/swicg/ to sign up for the SWICG btw. it's just a button
# cwebber oh right
# cwebber aaronpk: I'll add one :)
# aaronpk I don't see you on https://www.w3.org/wiki/Irc-people
# cwebber aaronpk: wow, so easy! why'd I put it off so long :)
# cwebber oh now I remember
# cwebber I made the mistake of trying to sign up as an individual before
# cwebber when I should have just clicked [X] on mediagoblin
# cwebber since I run it :P
# cwebber and then there was a process snafu. but I could have just resubmitted
# cwebber oops!
# cwebber aaronpk: happy to be co-chair with you, should be fun :)
# aaronpk you're on https://socialwg.indiewebcamp.com/irc/social/2017-04-25#bottom now tho
# elensil hi guys
# elensil I'm the author of Movim an open and decentralized social network fully build on XMPP
# elensil I'm also part of the XSF and I'm interested to know more about your work done here
# elensil to also see if we can work together (the XSF and the SocialWG)
# cwebber heya elensil :D
# cwebber elensil: sorry we were so wrapped up in meeting for so long
# cwebber elensil: that sounds great; I am a big XMPP fan :)
# elensil did you already had a look at XMPP, especially Pubsub and related XEPs ?
# cwebber elensil: I've read them in the past yes
# cwebber elensil: so, the status of the SocialWG is we are wrapping up some specs already in process
# cwebber elensil: but, we have a social community group that will also be more broadly about the topic of federation
# cwebber elensil: it would be great to have you part of that
# cwebber https://www.w3.org/community/swicg/
# elensil I have a couple of issues here
# elensil first it looks like you are working on Social protocols that are really bound to the web standards
# elensil JSON/HTTP …
# cwebber elensil: yup
# cwebber that's true :)
# dmitriz cwebber: as far as the mailing lists for the community group - which one of the 3 is the main one? (worth joining,e tc)
# elensil so I'd like to know where we can fit together, XMPP is TCP/real-time/XML :D
# dmitriz np
# dmitriz elensil: it would be interesting to discuss/specify how the various XEPs would interop with the corresponding web protocols. like the XMPP Pubsub vs Websub. etc.
# dmitriz how to bridge between the two
# elensil yeah
# cwebber I think bridging would be the most useful
# cwebber elensil: I think the XMPP group has already has its own groups to incubate its federation XEPs
# cwebber and our group is specifically about web stuff
# cwebber but, bridges are good
# elensil the first thin would be to define common URI, all your protocols seems to be defined using hrefs
# cwebber so maybe that would be a good role for you in the CG elensil ?
# elensil in XMPP we have uri="xmpp:" or uri="http://…"
# dmitriz so if there’s no mailing list for the CG, where does the discussion take place?
# elensil I also invite you to join xsf@muc.xmpp.org :)
# aaronpk we have https://github.com/swicg/general and can also make new repos if we start having more focused projects/specs/docs
# dmitriz aaronpk: got it, thanks.
# elensil there is big discussions at the moment on MIX, the Pubsub on steroids
# cwebber elensil: I joined
# cwebber elensil: however I think we will remain a focused on web-type-technologies group
# cwebber but, as said
# cwebber bridging is good
# elensil yes, but I trully think that we are solving similar issues
# cwebber the eternal problem, federating federations :)
# elensil basically what is changing is the support (XML/JSON and TCP/HTTP)
# cwebber elensil: though some caution, the "so close but not quite" dream often ends up not being close enough to merge
# cwebber as even this WG has seen ;)
# cwebber I wish that weren't true though
# cwebber tantek: :)
# cwebber tantek: the Meta Federation Protocol
# cwebber likes the Meta Object Protocol, so...
# cwebber ah
# cwebber yeah
# dmitriz wow. sign me up.
# dmitriz :)
# tantek Next telcon agenda is up: https://www.w3.org/wiki/Socialwg/2017-05-02 (and even stubbed 2017-05-09 while at it). Please add anything we missed this week.
# cwebber runs rhiaro's tool https://www.w3.org/wiki/Socialwg/2017-04-25-minutes
# tantek all those dates, details, links here: https://www.w3.org/wiki/Socialwg#Future_Meetings
timbl joined the channel
# 
Loqi Aaronpk made 1 edit to [[Socialwg/2017-04-18-minutes]] https://www.w3.org/wiki/index.php?diff=102844&oldid=102572
# Loqi Tantekelik made 1 edit to [[Socialwg/2017-04-25]] https://www.w3.org/wiki/index.php?diff=102851&oldid=102590
# Loqi Tantekelik made 2 edits to [[Socialwg/2017-05-02]] https://www.w3.org/wiki/index.php?diff=102854&oldid=0
# Loqi Tantekelik made 1 edit to [[Socialwg/2017-05-09]] https://www.w3.org/wiki/index.php?diff=102853&oldid=0
# Loqi Tantekelik made 1 edit to [[Socialwg]] https://www.w3.org/wiki/index.php?diff=102856&oldid=102580
# Loqi Cwebber2 made 1 edit to [[Socialwg/2017-04-25-minutes]] https://www.w3.org/wiki/index.php?diff=102855&oldid=0
# cwebber wow nice, thx ajordan
# cwebber ajordan: regarding closing issues btw
# cwebber ajordan: we need to either have satisfied the poster or get consensus from the group before closing an issue
# cwebber in general
# ajordan so in particular I'm looking at https://github.com/w3c/activitypub/issues/188 which I think we resolved last week on the telecon?
# cwebber https://socialwg.indiewebcamp.com/irc/social/2017-04-18#t1492532287320 convo from last week
# cwebber hm
# cwebber I thoguht I started to reply to this one
# cwebber oh
# cwebber we were going to put it on the agenda for this week :P
# cwebber oops
# cwebber what we said resolving it didn't get logged if we had something apparently
# cwebber I don't see anything in the minutes re: that one
# cwebber yeah
# cwebber I mean, concluding it or etc
# cwebber I guess so
timbl joined the channel
# cwebber thank you ajordan :)
# cwebber it's greatly appreciated
# cwebber ajordan++
elensil joined the channel
# JanKusanagi ajordan++
# JanKusanagi the least I could do =)