Charlie and I put together a working flow that leverages his magic-sig OAuth2 assertion flow combined with JRD (JSON XRD) and JSON Activity Streams. It's very easily implemented and works quite well for our usecase and I would assume most others. We've also been purposeful in using JSON exclusively.
The flow is as follows: 1) Feed request with 200 or 401 response. Response includes WWW-Authenticate and OAuth2-Discovery headers (OAuth2-Discovery includes supported grant types and OAuth2 endpoints. See below). 2) OAuth2 assertion initiated with magicsig identity assertion. Success results in a valid access token response. (See below for details) 3) Access token is included in feed request as qs param and made again. Response now includes the hub link. 3) PSHB subscription is initiated as per the spec with the topic URL as included in step 3. (e.g. http://ooava.com/dbounds?format=json&oauth_token=12345) 4) During subscription verification the oauth_token included in the topic is verified and used to validate the response. Working PoC here: http://ooava.com/dbounds (profile page) http://ooava.com/dbounds?format=json (protected JSON AS feed) http://ooava.com/.well-known/host-meta?format=json (host-meta JRD) http://ooava.com/etc/webfinger?format=json&q=acct:[email protected] (webfinger JRD) One interesting aspect what we've introduced here is the OAuth2-Discovery header in the protected feed response. The value is a JSON resource specifying the supported grant types and associated OAuth2 resource endpoints. Example: GET /dbounds?format=json HTTP/1.1 Host: ooava.com HTTP/1.1 200 OK Date: Tue, 01 Feb 2011 20:21:10 GMT WWW-Authenticate: OAuth2 OAuth2-Discovery: {"grant_types":["urn:magic-sig:identity:assertion"],"token_endpoint":"http://ooava.com/api/v1/oauth/server/access_token"} Content-Type: application/stream+json Content-Length: 0 MagicSig Assertion: We use the OAuth2 Assertion flow to post an assertion with a grant-type of: urn:magic-sig:identity:assertion The assertion is a Magic Envelope in the Compact Serialization form with a payload of the JSON structure below. With a data-type of "application/magic-identity-assertion+json" { identity_uri:"acct:[email protected]", create_date:"Jan 17, 2011 11:48:36 PM", destination_url:"http://ooava.com/api/v1/oauth/server/access_token"; } So basically we are signing the uri, the date, and the URL we are posting to (follow the same URL normalization rules as Oauth signing). The receiver can validate by following the process in the magic-sig spec. http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-01.html On Tue, Feb 1, 2011 at 2:54 PM, John Panzer <[email protected]> wrote: > Check out this doc for ACL'd PubSubHubbub (a little old, but solid and still > valid): https://docs.google.com/a/google.com/document/pub?id=1HrVmSCQM2r5bCnQk5uZPbhH0sGVHHFOGhxJ0thoKEO8 > I've been doing a bit of coding work towards this here at Google w/Brett for > Buzz as I have time. It's fairly straightforward to do, and I encourage > others to try it out on their sites as well. > -- > John Panzer / Google > [email protected] / abstractioneer.org / @jpanzer > > > On Tue, Feb 1, 2011 at 7:00 AM, Andrea Messina <[email protected]> > wrote: >> >> Is there any attempt to evolve the current specs? >> Having a pubsubhubbub protocol which takes account of private feeds >> (in general non public information source) would be worth. Embedding >> OAuth behaviour or other authorization mechanisms could significantly >> improve the whole. > > -- Thank you, Darren Bounds
