Subject: Re: [OAUTH-WG] OAuth & Protected feeds

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 03 Aug 2010 13:45:48 +0200

Darren,
> 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.
>
>    
I would rather put this the other way around. Your particular use case 
can be implemented by utilizing the building blocks already built into 
the specification. Great! That's what I expect from a _standard_. It 
provides people with atomic building blocks, they can create their 
solutions from. I don't think we should add every possible flow to the 
standard.

Even regarding your proposal, much more is possible. You suggest to use 
the web server flow for end-user authorization if the assertion flow 
failed. Why not using the user agent or the username/password flow 
instead? Or any other way of authenticating and authorizing an end-user? 
That way, clients can choose the option matching their requirements and 
capabilities the most.

Please also note your proposal has an significant impact on access token 
lifecycle. In step 1 you propose to issue a none-authorized access 
token. This means an authz server must be able to authorize access 
tokens after issuance, which is not required currently. Additionally, 
resource servers must be able to recognize none-authorized (invalid) 
access tokens and refuse any attempt to access resources with an access 
token in that state. In my opinion, this makes the tokens lifecycle much 
more complex and will not work in all possible setups, especially if the 
authorization server issues self-contained tokens. In such a setup, no 
direct communication takes place during request processing on the 
resource server.

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 03 Aug 2010 13:52:16 +0200

James,
> 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.
>    

In my opinion, this decision is up to the authorization server and not 
the resource server.

egards,
Torsten.

>
> 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
>
> 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]
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 03 Aug 2010 13:52:59 +0200

James,

In my opinion, this decision is up to the authorization server and not 
the resource server. Or should both be possible? What do you think?

egards,
Torsten.

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 4 Aug 2010 13:00:48 +1000

Torsten,

> the resource server. Or should both be possible? What do you think?

Theoretically, the decision should probably be up to the authorization server.
In practise, however, the decision should be *delivered* from the resource server.

It is resources that apps are ultimately interested in.
It is at a resource where an app should start
(unless it can skip some steps by using some service-specific knowledge).
Consequently, delivering the decision from the resource server is more efficient.
It avoids an extra step (resource server -> authz server -> answer).

Separating the authorization server from resource servers is useful for
restricting the exposure of long-term secrets. It is not necessary, however,
for the delivery of discovery information.

--
James Manger

---

From: William Mills <[email-masked]>
Date: Wed, 4 Aug 2010 00:01:36 -0500

At the very least we need to minimize the hoops the client needs to jump through.  The resource server advertising enpoints allows a simple way to minimize on one path.

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Manger, James H
> Sent: Tuesday, August 03, 2010 8:01 PM
> To: Torsten Lodderstedt
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] OAuth & Protected feeds
> 
> Torsten,
> 
> >> 'user-uri' and 'token-uri'. If only one is present, only the 
> >> corresponding mode is useful in this interaction.
> 
> It is at a resource where an app should start (unless it can 
> skip some steps by using some service-specific knowledge).
> Separating the authorization server from resource servers is 
> useful for restricting the exposure of long-term secrets. It 
> is not necessary, however, for the delivery of discovery information.
> 
> --
> James Manger
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 4 Aug 2010 09:01:35 +0200

> James 

So your idea is to use the resource server as discovery Proxy of the authz server? Interesting idea! Would you mind to contribute it to the "Discovery Requirements" thread?

Regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 4 Aug 2010 09:07:25 +0200

Please see my reply to James's posting and contribute to the Discovery requirements thread.

One think I want to point out: proxying the authz server may help during the initial discovery. Once the Client obtained a refresh token, directly discovering the tokens endpoint (or a revocation endpoint) is as efficient then asking the resource server. But it appears more natural to me.

regards,
Torsten.

---

From: Darren Bounds <[email-masked]>
Date: Wed, 4 Aug 2010 12:01:49 -0400

Absolutely, however, I believe the atomic units that make up the OAuth
profile spectrum have not  properly taken into account the tidal wave
of DiSo interactions that are forth coming. Subsequently you can force
them into place and say "they work" but IMO will have a hard time
achieving adoption due to the impact they have on the UX.

Also, seeing as you have James are having your own discussion on this
topic, if you haven't already, you may want to read through this
thread which is taking place concurrently.
http://groups.google.com/group/federated-social-web/browse_thread/thread/842aa86bce762942

Darren

On Tue, Aug 3, 2010 at 7:45 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> I would rather put this the other way around. Your particular use case can
> be implemented by utilizing the building blocks already built into the
> specification. Great! That's what I expect from a _standard_. It provides
> people with atomic building blocks, they can create their solutions from. I
> don't think we should add every possible flow to the standard.
>
> Even regarding your proposal, much more is possible. You suggest to use the
> web server flow for end-user authorization if the assertion flow failed. Why
> not using the user agent or the username/password flow instead? Or any other
> way of authenticating and authorizing an end-user? That way, clients can
> choose the option matching their requirements and capabilities the most.
>
> lifecycle. In step 1 you propose to issue a none-authorized access token.
> This means an authz server must be able to authorize access tokens after
> issuance, which is not required currently. Additionally, resource servers
> must be able to recognize none-authorized (invalid) access tokens and refuse
> any attempt to access resources with an access token in that state. In my
> opinion, this makes the tokens lifecycle much more complex and will not work
> in all possible setups, especially if the authorization server issues
> self-contained tokens. In such a setup, no direct communication takes place
> during request processing on the resource server.
>
> regards,
> Torsten.
>
>

-- 
darren bounds
[email-masked]