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
>>
>>