Subject: Re: [OAUTH-WG] Autonomous clients and resource owners (editorial)

From: "Foiles, Doug" <[email-masked]>
Date: Sun, 2 May 2010 08:41:28 -0700

I wanted to poke on the idea of not allowing Refresh Tokens for the
assertion flow.  I personally like the idea discussed here where the
Refresh Token is used across all flows unless it doesn't make sense.
The argument I heard for not including the Refresh Token for the
assertion flow is that the use of Refresh Tokens break the trust
relationship.  It seems the "duration of access" is the key trust
element in question.  The identity of the client and resource owner
(assuming the assertion flow would be made to support this) does not
seem affected.  

For the case where a Refresh Token would NOT be used, a timeframe of "X"
would be granted to the generated Access Token.  That Access Token would
only be usable for that "X" period of time.  For the case where a
Refresh Token were supported, the same "X" timeframe would be granted to
the Refresh Token and the timeframe for the actual Access Token would be
less than that.  So in both cases the client would only be able to
access the protected resource for the same "X" timeframe.  Thoughts???

And I am wondering if the assertion flow where the client is acting on
behalf of a user is on the list of things to be added???  It was
suggested that this had been discussed previously and might be going to
be added.  And sounds like this would NOT be an autonomous flow from
what I understand, as autonomous flows are strictly for cases where the
client is the same as the resource owner.

And I still don't see the corresponding flow in OAuth 2.0 for an OAuth
1.0 - 2 Legged use case where clients are acting on behalf of a resource
owner that is not themselves.  Will there be a flow to support this???
I can actually see how another type of "end user credentials flow" would
work where the credential is something different than the username and
password. 

Thanks.

Doug

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Chuck Mortimore
Sent: Tuesday, April 27, 2010 5:46 PM
To: Keenan, Bill; OAuth WG
Subject: Re: [OAUTH-WG] Autonomous clients and resource owners
(editorial)

Refresh token was explicitly removed from the suggestion I made for
assertion flow.   I'd be curious if others on the list see a need for
it...?

Eran - do you expect to make edits to the assertion flow before pushing
the working group draft?

-cmort

On 4/27/10 12:14 PM, "Keenan, Bill" <[email-masked]> wrote:

With Doug in an all day mtg, we have not sync'd on this...so one of us
may respond again on this topic.

I think I am +1 w/ Brian E.

In the flow from SAML gateway to STS to protected resource, I don't see
caching both an access and refresh token as getting me any efficiency.
Certainly, it adds complexity to regression testing.

I appreciate the desire for symmetry on the set of flows...refresh token
seems like a place for asymmetry.

BillK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Chuck Mortimore
Sent: Tuesday, April 27, 2010 9:06 AM
To: Torsten Lodderstedt; Brian Eaton
Cc: Foiles, Doug; OAuth WG
Subject: Re: [OAUTH-WG] Autonomous clients and resource owners
(editorial)

Same here - we don't intend to issue refresh tokens for either of these
flows, and we'll only be accepting 1 time use assertions.

-cmort
________________________________________
From: Torsten Lodderstedt [[email-masked]]
Sent: Tuesday, April 27, 2010 9:00 AM
To: Brian Eaton
Cc: Chuck Mortimore; Foiles, Doug; OAuth WG
Subject: Re: [OAUTH-WG] Autonomous clients and resource owners
(editorial)

returning access token would suffice in this flow, from my point of
view.

regards,
Torsten.

Am 27.04.2010 um 08:33 schrieb Brian Eaton <[email-masked]>:

> From my perspective, the main thing is that the assertion flow can be
> used to connect existing authentication systems with APIs that are
> using OAuth2 for authorization.
>
> This will let us leverage existing trust relationships across systems.
>
> Note that this breaks, however, if the flow returns a refresh token.
> Refresh tokens are a new trust relationship, and they require
> additional user/administrator involvement to manage.
>
> Cheers,
> Brian
>
> On Mon, Apr 26, 2010 at 10:23 PM, Torsten Lodderstedt
> <[email-masked]> wrote:
>> +1
>>
>> we need the assertion flow for the same purpose. Can we add a
>> variant of the
>> flow to section "End User Credentials Flows"?
>>
>> regards,
>> Torsten.
>>
>> Am 26.04.2010 23:17, schrieb Chuck Mortimore:
>>
>> +1.
>>
>> Our primary use-cases for the assertion flow are for clients acting
>> on
>> behalf of users, and not autonomously.   I believe Eran already has
>> this on
>> his list of feedback when the assertion flow gets edited.
>>
>> We also have need for a 2 legged Oauth model, and are looking at
>> the client
>> credentials flow for exactly that purpose.
>>
>> -cmort
>>
>>
>> On 4/25/10 10:34 AM, "Foiles, Doug" <[email-masked]> wrote:
>>
>> I have a bit of confusion on the Autonomous Client Flows ... and spe
>> cifically
>> related to Eve's comment below that suggests to me that the autono
>> mous
>> client is NOT ALWAYS the resource owner.
>>
>> Can the Autonomous Client Flows support clients that ARE NOT the
>> actual
>> resource owner?  For example for an Assertion Flow where the
>> Subject of the
>> SAML assertion is a user identity (and the resource owner) and not
>> that of
>> the client.
>>
>> Is the intent of the Client Credentials Flow to support something
>> like
>> Google's "OAuth for Google Apps domains" 2 Legged OAuth use ca
>> se?
>>  http://code.google.com/apis/accounts/docs/OAuth.html.
>>
>> If the Autonomous Client Flows support clients that can act on
>> behalf a
>> resource owner that is not themselves  ... it then seems the resourc
>> e owner
>> must provide some level of consent outside the OAuth specific flow.
>>
>> Thanks.
>>
>> Doug
>>
>>
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of
>> Eve Maler
>> Sent: Friday, April 23, 2010 7:21 AM
>> To: OAuth WG
>> Subject: [OAUTH-WG] Autonomous clients and resource owners
>> (editorial)
>>
>>
>> Regarding the second comment I made below: I realized last night that
>> Sections 3.7.1 and 3.7.2 get this more correct, by saying that an
>> autonomous
>> client represents a "separate resource owner". So Section 2.2
>> definitely
>> needs a slight change, from:
>>
>>
>>
>> "...and autonomous flows where the client is acting for itself (the
>> client
>> is also the resource owner)."
>>
>>
>>
>> to something like:
>>
>>
>>
>> "...and autonomous flows where the client is acting on behalf of a
>> different
>> resource owner."
>>
>>
>>
>> Thanks,
>>
>>
>>
>>             Eve
>>
>>
>>
>> On 21 Apr 2010, at 4:43 PM, Eve Maler wrote:
>>
>>
>> Tacking this response to the end of the thread for lack of a better
>> place to
>> do it: The name "username" seems not quite apt in the case of an
>> autonomous
>> client that isn't representing an end-user. Would "identifier" be
>> better?
>> (Actually, it sort of reminds me of SAML's "SessionIndex"...) Or
>> would the
>> parameter be reserved for user-delegation flows?
>>
>>
>>
>> Speaking of autonomous clients, Section 2.2 -- among possibly other
>> places
>> -- states that an autonomous client is also the resource owner, but
>> that's
>> not always the case, is it? The client might be seeking access on
>> behalf of
>> itself. (FWIW, I made roughly this same comment on David's first
>> draft on
>> March 21, and he agreed with my suggested fix at the time.)
>>
>>
>>
>>             Eve
>>
>>
>>
>> Eve Maler
>>
>> [email-masked]
>>
>> http://www.xmlgrrl.com/blog
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 May 2010 10:26:15 -0700

> Of Foiles, Doug
> Sent: Sunday, May 02, 2010 8:41 AM
> To: OAuth WG
> assertion flow.

How not leaving this up to the server to decide a bad thing? Clearly not all assertions will map directly to the OAuth token and expiration, so the token is already a different trust relationship. The current draft has a SHOULD NOT for refresh token.

> And I am wondering if the assertion flow where the client is acting on behalf
> of a user is on the list of things to be added???

This is a problem with the autonomous grouping, not the flow.

> And I still don't see the corresponding flow in OAuth 2.0 for an OAuth 1.0 - 2
> Legged use case where clients are acting on behalf of a resource owner that
> is not themselves.  Will there be a flow to support this???  I can actually see
> how another type of "end user credentials flow" would work where the
> credential is something different than the username and password.

No. The 1.0 2-legged use-case was really an abuse of the OAuth signature method to make signed requests using a username and password (client credentials) instead of using Basic auth. In OAuth 2.0, you have to go through an additional step: the client first uses its client credentials to get a token (over HTTPS) and it uses that token to make requests (signed or not).

EHL

---

From: "Foiles, Doug" <[email-masked]>
Date: Sun, 9 May 2010 13:07:23 -0700

Thanks for addressing my questions Eran.

For the Assertion Flow I would assume the lifetime of the authorization grant would be the same with or without the refresh token support.  It doesn't seem to me like the overall lifetime of the authorization grant would change based upon the use of the refresh token.

However I certainly do see that the usefulness of the refresh token is very questionable based upon wanting the authorization grant lifetimes to be short for the Assertion Flow.  And providing the refresh token for this flow almost leads the resource provider in granting longer than recommended authorization grant lifetimes ... which ultimately should be avoided.  Is this the point?

Thanks.

Doug    

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Sunday, May 09, 2010 10:26 AM
To: Foiles, Doug; OAuth WG
Subject: RE: [OAUTH-WG] Autonomous clients and resource owners (editorial)

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 May 2010 13:56:39 -0700

> From: Foiles, Doug [mailto:[email-masked]]
> Sent: Sunday, May 09, 2010 1:07 PM
> To: Eran Hammer-Lahav; OAuth WG
> For the Assertion Flow I would assume the lifetime of the authorization grant
> would be the same with or without the refresh token support.  It doesn't
> seem to me like the overall lifetime of the authorization grant would change
> based upon the use of the refresh token.

You have three expirations:

- The assertion
- The access token
- The refresh token (if present)

The authorization server can issue an access token with any expiration but should not issue expiration later than that of the assertion. But still, there is nothing to prevent that. The authorization server may issue an access token with a shorter expiration than the assertion. In that case, it can require the use of the same assertion again to get another token, or it can issue a refresh token to accomplish the same thing.

I reject the argument that the expiration policy (and getting it implemented correctly) has much to do with making a refresh token available to the server as a tool.

EHL

---

From: "Foiles, Doug" <[email-masked]>
Date: Mon, 10 May 2010 09:05:03 -0700

Thanks for the clarity Eran and I understand.

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Sunday, May 09, 2010 1:57 PM
To: Foiles, Doug; OAuth WG
Subject: RE: [OAUTH-WG] Autonomous clients and resource owners (editorial)

- The assertion
- The access token

EHL

---

From: Brian Eaton <[email-masked]>
Date: Mon, 10 May 2010 16:14:11 -0700

On Sun, May 9, 2010 at 1:56 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> The authorization server can issue an access token with any expiration but should not issue expiration
> later than that of the assertion. But still, there is nothing to prevent that.

Wait, why shouldn't the authorization server issue an access token
with an expiration past the notAfter date in the assertion?

The common process here is to swap a SAML assertion with a very short
lifetime (a minute or two) for a cookie that lasts a longer period of
time.