"During subscription verification the oauth_token included in the topic is verified and used to validate the response. "
So, the hub checks if the token provided in the subscription_request matches that sent before in the OAuth2 assertion? What about when you say: ...and used to validate the response??.. I have noticed that the endpoint is not protected.....but OAuth2 requires TLS protected ones. According to which conditions, are you issuing access tokens?? I suppose, that, in your case, it is sufficient to validate the salmon(assertion). In principle, you could automatically ACL'ed the identity_uri. I wonder, what kind of flow, you would use, to personally check the request and approve it asynchronously. How would you send the access token?? In my opinion you could send it, to some kind of callback indicated in the assertion, maybe ciphered with the recipient publick key(XRD discovery). WHat's your opinion? thanks a lot. On Feb 1, 9:42 pm, Darren Bounds <[email protected]> wrote: > 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... > > > > > > > > > > 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=1HrVmSCQM2r5bCnQ... > > 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
