Folks interested in protected feeds may be interested in UMA's solution, which proposes mechanisms to demand "claims" from the requesting side based on user-specified policyon the authorizing server side. An example of UMA-protected resources that require agreement to terms can be seen in the SMART project documented here (if you want, you can sign up to take part in a UX study they're conducting right now:
http://smartjisc.wordpress.com/ More general info about UMA is here: http://kantarainitiative.org/confluence/display/uma/Home Note that UMA is OAuth-based and tries to make its profiling and extensions as small as possible to achieve its requirements, but I suspect its requirements list is a bit longer/more comprehensive than what is described below. Eve On 28 Jul 2010, at 1:28 PM, Darren Bounds wrote: > Please excuse the cross posting. > > Following the Federated Social Web Summit in Portland a couple weeks > ago, there has been a lot of chatter around protected feeds and how > they'll function to achieve SWAT0 > (http://federatedsocialweb.net/wiki/SWAT0). Protected feed > subscriptions are clearly an important component of DiSo and necessary > for features like remote follow/friending. > > During the summit Brett Stlakin published and discussed a document > (http://tinyurl.com/push-oauth) where he proposes one technique for > how OAuth may be used with PuSH to achieve the requirements. The > proposal details an OAuth 2 flow (in addition to OAuth 1x) for > handling a usecase that involves ToS acknowledgement before a > protected feed subscription may be granted. The flow is essentially > the web server client profile combined with the assertion grant type. > While the flow will work and achieve the goals it also has a > fundamental need for a user-agent redirect, something that not all > providers may desire or require. > > What I'd like to propose is a variant of the assertion grant type that > would make the user-agent redirect optional. The goal here was to stay > within the bounds of the current spec where ever possible. That said; > it may be desirable to break this out into it's own client profile. > > The flow detailed below is using the OAuth 2 scenario described in > Brett's document (http://tinyurl.com/push-oauth). > > 1) cliqset.com would like to request an access token from google.com. > Sends a request with grant_type=assertion. > > Request: > POST /token HTTP/1.1 > Host: google.com > Content-Type: application/x-www-form-urlencoded > > grant_type=assertion&assertion_type=http://webfinger.org/&; > assertion=eyJ1cmkiOiAiYWNjdDpkYm91bmRzQGNsaXFzZXQuY29tIiwibWFnaWNfc2lnbmF0dXJlIjogImFzZGxra2xhZnNkamtsZHNmamxraj0ifQ== > > The assertion value in the request is a Base64 encoded JSON string > with two properties, uri and magic_signature. Example: > > { > "uri": "acct:dbou...@cliqset.com", > "magic_signature": "asdlkklafsdjkldsfjlkj=" > } > > Response: > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "access_token":"supersecrettoken" > "precondition_uri","http://google.com/oauth/authorize?state=opaquevalue > "code","myrandomcode123" > } > > The access token response introduces two new optional properties: > precondition_uri and code > > The existence of a precondition_uri means the consumer will be > required to redirect the user to this uri in order to complete the > activation of the provided access token. > > The precondition_uri resource has the same characteristics of the > OAuth 2.0 Web Server client profile with the ‘state’ property being > used to maintain state between the assertion request and the user > redirect. Successful acknowledgement of the precondition results in a > 302 response with the code provided in the assertion response (see > example below). > > The existence of a code is required upon the presence of a precondition_uri. > > If no precondition_uri is provided, the access token should be > considered active and immediately usable barring any provider specific > back-end authorization (e.g. user acceptance of remote follow). > > 2) access token received optional precondition_uri. Issuing user > redirect to precondition_uri with redirect_uri. > > Request: > GET > /oauth/authorize?state=opaquevalue&response_type=token&client_id=acct:dbou...@cliqset.com&redirect_uri=http://cliqset.com/callback > HTTP/1.1 > Host: google.com > > User acknowledges the precondition. This could be any number of > activities, including authenticating. > > > Response: > HTTP/1.1 302 Found > Location: http://cliqset.com/callback?code=myrandomcode123 > > 3) Subscription has been authorized. ToS has been acknowledged. Compete. > > The consumer is able to activate the access_token by confirming the > code provided in the redirect. > > This flow offers what we feel are several significant advantages over > the hybrid approach. > > 1) Redirection becomes optional and is only required when the > precondition_uri is defined by the provider in the access token > response. > > 2) For providers who require TOS acknowledgement, it enables > additional flexibility in how they go about it. For example, if a > provider only requires TOS acknowledgement on the initial subscription > request by a given user, subsequent requests will not provide a > precondition_uri. > > 3) It is also worth exploring this flow as a suitable and more > flexible alternative to the traditional Web Server flow. > > > Questions? Comments? Suggestions? > > > -- > darren bounds > dar...@cliqset.com > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
