[WG-UMA] Fwd: [OAUTH-WG] OAuth & Protected feeds
eve at xmlgrrl.com
Wed Jul 28 20:16:00 EDT 2010
Begin forwarded message:
> From: Darren Bounds <darren at cliqset.com>
> Date: 28 July 2010 1:28:57 PM PDT
> To: oauth at ietf.org, pubsubhubbub at googlegroups.com, federated-social-web at googlegroups.com
> Subject: [OAUTH-WG] OAuth & Protected feeds
> 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.
> POST /token HTTP/1.1
> Host: google.com
> Content-Type: application/x-www-form-urlencoded
> The assertion value in the request is a Base64 encoded JSON string
> with two properties, uri and magic_signature. Example:
> "uri": "acct:dbounds at cliqset.com",
> "magic_signature": "asdlkklafsdjkldsfjlkj="
> HTTP/1.1 200 OK
> Content-Type: application/json
> Cache-Control: no-store
> 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.
> GET /oauth/authorize?state=opaquevalue&response_type=token&client_id=acct:dbounds at cliqset.com&redirect_uri=http://cliqset.com/callback
> Host: google.com
> User acknowledges the precondition. This could be any number of
> activities, including authenticating.
> 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
> 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
> 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
> darren at cliqset.com
> OAuth mailing list
> OAuth at ietf.org
More information about the WG-UMA