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

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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] 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 [torsten@lodderstedt.net]
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 <beaton@google.com>:

> 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
> <torsten@lodderstedt.net> 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" <Doug_Foiles@intuit.com> 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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] 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
>>
>> eve@xmlgrrl.com
>>
>> http://www.xmlgrrl.com/blog
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth