Re: [OAUTH-WG] Difference between RO and End User (Was: Few questions about client_credentials)

[Sergey Beryozkin <[e-mail]>]

Hi Paul
On 11/05/12 15:10, Paul Madsen wrote:
> Hi Sergey, the point I was trying to make is that the end-user is not
> always the 'owner' of the resource being accessed by the client.
>
> In the archetypical consumer-centric application of OAuth, the user is
> indeed the resource owner.
>
> But, in other OAuth applications (enterprise to cloud, TV Everywhere,
> etc) the owner of the resource may be some other entity (the employee's
> enterprise, the video content owner, etc)
>

Clearer now :-), thanks

Sergey

> paul
>
> On 5/11/12 10:04 AM, Sergey Beryozkin wrote:
>> Hi
>> On 01/03/12 22:36, Paul Madsen wrote:
>>> RO =/= end-user
>>>
>>
>> Can you please elaborate on the difference a bit more ? I do not see
>> the main OAuth specification saying anything about it, and
>> OpenId-Connect seems to use both terms interchangeably, example:
>> http://openid.net/specs/openid-connect-standard-1_0.html#art_res_ok
>>
>> When would you recommend to pay the specific attention to this
>> distinction, when someones reads or implements OAuth2 ?
>>
>> Thanks, Sergey
>>
>>
>>> On 3/1/12 5:33 PM, Zeltsan, Zachary (Zachary) wrote:
>>>>> Are you saying that this can include the resources of possibly
>>>>> different end users ?
>>>> Yes. The specification does not limit a number of the users whose
>>>> resources a client may access using the client credentials flow.
>>>>
>>>> Zachary
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Sergey Beryozkin [mailto:[e-mail]]
>>>> Sent: Thursday, March 01, 2012 5:17 PM
>>>> To: Zeltsan, Zachary (Zachary)
>>>> Cc: 'Richer, Justin P.'; '<[e-mail]>'
>>>> Subject: Re: [OAUTH-WG] Few questions about client_credentials
>>>>
>>>> Hi,
>>>> On 01/03/12 19:23, Zeltsan, Zachary (Zachary) wrote:
>>>>> In the case of the Client Credentials Grant, an authorization
>>>>> servers knows what resources the client is authorized to access
>>>>> (this includes the resources that are not owned by the client). The
>>>>> specification explains that authorization of access to the
>>>>> resources "has been previously arranged with the authorization
>>>>> server (the method of which is beyond
>>>>> the scope of this specification)".
>>>>>
>>>> Are you saying that this can include the resources of possibly
>>>> different
>>>> end users ? Or only of a specific single end-user ?
>>>>
>>>>
>>>>> I have nothing to add to Justin's answer to the second question.
>>>> OK
>>>>
>>>> Thanks
>>>>
>>>> Sergey
>>>>
>>>>> Zachary
>>>>>
>>>>>
>>>>> Zachary
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From:[e-mail] [mailto:[e-mail]] On
>>>>> Behalf Of Richer, Justin P.
>>>>> Sent: Thursday, March 01, 2012 12:01 PM
>>>>> To: Sergey Beryozkin
>>>>> Cc:<[e-mail]>
>>>>> Subject: Re: [OAUTH-WG] Few questions about client_credentials
>>>>>
>>>>> If there's a fully trusted relationship between the client and the
>>>>> server, then the client may in fact be accessing data on behalf of
>>>>> another resource owner. It's a useful pattern when a three-legged
>>>>> flow like the Auth Code is not available. But it's kind of
>>>>> splitting hairs because the client has been granted a blanket
>>>>> access to the resource ahead of time, by virtue of its
>>>>> registration. Showing up to get a token is a method of limiting
>>>>> exposure and power of the client credentials, and making it easier
>>>>> to support both direct-client access and delegated-client access
>>>>> simultaneously with most of the same tooling.
>>>>>
>>>>> To your second question, no -- scopes do not have to be ignored in
>>>>> this case. In fact, a well-designed client and server can make use
>>>>> of scopes to let the client request an access token that's only
>>>>> good for whatever the current transaction is, as opposed to
>>>>> something that's representative of all of the client's
>>>>> capabilities. This is a method known as "downscoping" and it's a
>>>>> very powerful pattern that OAuth enables. Of course, if you want,
>>>>> you are fully allowed to leave the scope out entirely, then it's up
>>>>> to the Authorization Server alone to figure out what the token is
>>>>> really good for.
>>>>>
>>>>> Hope this clears things up,
>>>>>
>>>>> -- Justin
>>>>>
>>>>>
>>>>>
>>>>> On Mar 1, 2012, at 11:39 AM, Sergey Beryozkin wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have few questions about the client_credentials grant type.
>>>>>> Section 4.4 [1] says: "...client is requesting access to the
>>>>>> protected resources under its control, or those of another
>>>>>> resource owner..."
>>>>>>
>>>>>> What I do not understand is the latter part of the above
>>>>>> statement, how to establish a link between the client
>>>>>> authentication (which is an actual grant in this case) and
>>>>>> different resource owners given that the only thing we have is the
>>>>>> client authentication. As far as I can see it is only possible to
>>>>>> get a one to one link with the end user in this case.
>>>>>>
>>>>>> Can someone please clarify what is meant by "those of another
>>>>>> resource owner" phrase ?
>>>>>>
>>>>>> The other question is about an optional scope parameter. It has to
>>>>>> be ignored in case of the client requesting a token for accessing
>>>>>> its own resources, right ?
>>>>>>
>>>>>> Thanks, Sergey
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1]http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.4
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>