Subject: [OAUTH-WG] OAuth & Protected feeds

From: Darren Bounds <[email-masked]>
Date: Wed, 28 Jul 2010 16:28:57 -0400

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:[email-masked]",
 "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:[email-masked]&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
[email-masked]

---

From: Eve Maler <[email-masked]>
Date: Wed, 28 Jul 2010 17:23:48 -0700

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:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> 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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 29 Jul 2010 08:40:08 +0200

Darren,

I have got some questions regarding your posting, esp. the assertion.
>   "magic_signature": "asdlkklafsdjkldsfjlkj="

What is the meaning of the assertion? Does the uri represent an end-user 
or the client?
How does the assertion represent an authorization, given that you try to 
make end-user authorization via browser redirect an optional step.

regards,
Torsten,

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 29 Jul 2010 17:51:19 +1000

Darren,

It sounds like you want to use OAuth2 to insert an human/HTML interaction into a app/Atom exchange.

OAuth2 can do that.

You also want to use a direct OAuth2 flow for access control to the feed.

Your "precondition_uri" addition to the token response is an attempt to combine the 2 OAuth2 flows.

An alternative would be to run the 2 OAuth2 flows sequentially.
1. app use a direct OAuth2 flow (eg the assertion flow) to get a token;
2. app tries to get feed with token, but server demands a user-delegation OAuth2 flow;
3. app redirects user to service; Terms of Service are shown; user redirected back;
4. app tries to get feed again, which succeeds this time.

This example illustrates that OAuth2 discovery needs to let a service
explicitly indicate whether a direct and/or user-delegation flow is required.
For instance, a "WWW-Authenticate: OAuth2" response could define 2 parameters:
'user-uri' and 'token-uri'. If only one is present, only the corresponding mode
is useful in this interaction.

Another interesting facet of this example is what token the app uses
at step 4. Is it the token the app got in the first OAuth2 flow (step 1),
or the token from the second OAuth2 flow (step 3)?

Presumably the second token overrides the first.
In this example, however, it may be sufficient to keep using the first token.
OAuth2 doesn’t need to make returning a token mandatory -- it is not
always required in a user-delegation flow.

--
James Manger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Darren Bounds
Sent: Thursday, 29 July 2010 6:29 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [OAUTH-WG] OAuth & Protected feeds

Request:
POST /token HTTP/1.1
Host: google.com

{

Response:
HTTP/1.1 200 OK

{

Request:

Response:
HTTP/1.1 302 Found

--
darren bounds
[email-masked]

---

From: Darren Bounds <[email-masked]>
Date: Thu, 29 Jul 2010 11:32:07 -0400

Torsten,

The URI represents an end-user at a domain. Through this assertion the
provider is able to verify the magic signature and thus confirm user
dbounds at host cliqset.com has requested an access token.

References:
http://code.google.com/p/webfinger/wiki/WebFingerProtocol
http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00.html
http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html

On Thu, Jul 29, 2010 at 2:40 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> What is the meaning of the assertion? Does the uri represent an end-user or
> the client?

-- 
darren bounds
[email-masked]

---

From: Darren Bounds <[email-masked]>
Date: Thu, 29 Jul 2010 12:43:35 -0400

Thanks James. Comments are inline.

> It sounds like you want to use OAuth2 to insert an human/HTML interaction into a app/Atom exchange.

The proposal was designed to provide a single flow that would
accommodate 0 or more human interaction requirements. Additionally,
the scope should not limited to access protected feed but rather any
protected resource.

While the example usecase illustrated access to a protected feed, you
can imagine this being used in more traditional flow scenarios, such
as that of the Web Server client profile.

For example, if a user has already negotiated an access token in the
proposed manner, additional access tokens *could* be granted on the
user's behalf without the requirement of a redirect.

> Your "precondition_uri" addition to the token response is an attempt to combine the 2 OAuth2 flows.

I'd say it's an attempt to create a new flow that's more flexible and
suitable for the type of interactions DiSo requires.

> is useful in this interaction.

Interesting.

> always required in a user-delegation flow.

Also, when the user delegation flow is executed (step 3), how does the
provider associate acknowledgement of the ToS with the assertion grant
(step 1)?

-- 
darren bounds
[email-masked]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 29 Jul 2010 19:05:13 +0200

So this assertion is conceptually equivalent to a case where the client 
would have sent username and password of dbounds at the authz server. Is 
this correct?

---

From: Darren Bounds <[email-masked]>
Date: Thu, 29 Jul 2010 14:36:32 -0400

Yes, but with no requirement that the user have an account on the
provider. It is merely an assertion the UserA on HostX made the
request.

On Thu, Jul 29, 2010 at 1:05 PM, Torsten Lodderstedt
<[email-masked]> wrote:
>>> or

-- 
darren bounds
[email-masked]

---

From: George Fletcher <[email-masked]>
Date: Thu, 29 Jul 2010 14:51:48 -0400

Question.  In the proposal, how does google know that the request is 
being presented by "acct:[email-masked]"? Is the secret used for 
the magic signature in the first request, the user's private key? So in 
this case cliqset.com would have dbounds' private key in order to 
generate the signature? (This seems to be implied from the oauth-push 
doc; at least from my reading).

I love the idea of allowing access to protected resources by individuals 
that do not have an "account" at the provider. This is a critical next 
step in the set of capabilities supported by OAuth and other 
technologies. However, I'm not quite show how the provider verifies the 
presented user identifier. Meaning, how does the provider protect 
against me specifying someone else's identifier and getting access to 
the protected resource.

Thanks,
George

---

From: Darren Bounds <[email-masked]>
Date: Thu, 29 Jul 2010 15:15:01 -0400

Thanks George. My response is inline.

On Thu, Jul 29, 2010 at 2:51 PM, George Fletcher <[email-masked]> wrote:
> Question.  In the proposal, how does google know that the request is being
> presented by "acct:[email-masked]"? Is the secret used for the magic
> signature in the first request, the user's private key? So in this case
> cliqset.com would have dbounds' private key in order to generate the
> signature? (This seems to be implied from the oauth-push doc; at least from
> my reading).

Google would perform a WebFinger on the acct: URI, discovery XRD
(http://cliqset.com/etc/webfinger/?q=acct:[email-masked]). The
XRD would present my Magic Signature Key which would be used to
verification the signature in the assertion.

> that do not have an "account" at the provider. This is a critical next step
> in the set of capabilities supported by OAuth and other technologies.
> However, I'm not quite show how the provider verifies the presented user
> identifier. Meaning, how does the provider protect against me specifying
> someone else's identifier and getting access to the protected resource.

The actions mentioned above ensure the assertion was made by
cliqset.com and not spoofed.

References:

-- 
darren bounds
[email-masked]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 29 Jul 2010 22:47:40 +0200

So what the value of that assertion? The authz server cannot 
authenticate the user (probably not even identify). Or do you assume 
some kind of federation between the two domains?

---

From: Darren Bounds <[email-masked]>
Date: Thu, 29 Jul 2010 17:13:49 -0400

Torsten,

Yes. Federation is the basis for proposal. Federated social interactions.

The value is that the provider is able to verify the assertion that
user dbounds on host cliqset.com has requested access token which it
will use to access and/or request access to protected resources within
the google.com realm, such as remote friending/following.

The provider does not need to, or necessarily want to authenticate the
remote user. It merely needs to verify the assertion in order to
confirm the origin user/host.

References:

http://status.net/2010/07/13/what-is-the-federated-social-web
http://status.net/2010/07/14/features-of-a-federated-social-web

--
darren bounds
[email-masked]

On Thu, Jul 29, 2010 at 4:47 PM, Torsten Lodderstedt
<[email-masked]> wrote:
> So what the value of that assertion? The authz server cannot authenticate
> the user (probably not even identify). Or do you assume some kind of
> federation between the two domains?
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 30 Jul 2010 17:20:59 +1000

Darren,

>> Your "precondition_uri" addition to the token response is
>> an attempt to combine the 2 OAuth2 flows.

> suitable for the type of interactions DiSo requires.

precondition_uri seems to address a requirement for optional human interaction
when an app starts accessing a protected resource.
A solution that changes the token response can only add the human interaction:
a) if OAuth is used for direct authentication/authorization of the app; and
b) at the instant in time when the app does its direct OAuth flow.
I'm note sure a requirement for human interaction will necessarily be tied to
either of those conditions, which is why an independent OAuth2 flow for
the human interaction is appealing.

> provider associate acknowledgement of the ToS with the assertion grant

The server provides a user-authorization URI in step 2 which can encode details
about the initial token.
A new token issued in the second OAuth2 flow can encode the ToS acknowledgement
along with details from the initial token.

OAuth2 needs a way to identity an existing token when making a subsequent OAuth2
flow -- not just for this example, but when an app asks for extra permissions.
The spec might not need to explicitly define this if, as in this example, the
server can dynamically provide a user-authz URI. It would be helpful in other
circumstances, though.
It probable requires a token_id that is separate from the token.

--
James Manger

---

From: Darren Bounds <[email-masked]>
Date: Fri, 30 Jul 2010 11:42:24 -0400

James,

> the human interaction is appealing.

Technically what I've proposed reverses the order of operations. Doing
so allows for redirect decisions to be made by the provider on a
case-by-case basis. As a result, I would submit that with the changes
I'm suggesting, OAuth direct flows are much more flexible and could
even be used in place of a Web Server, Native and User-Agent client
profiles.

> It probable requires a token_id that is separate from the token.

As an OAuth 2 provider and consumer as well as someone who's preparing
to build the DiSo interactions my proposal was based on, I would
prefer a single flow that addresses what I feel will be a increasingly
common set of requirements rather than combining two flows designed
for two distinct purposes.

-- 
darren bounds
[email-masked]