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

Paul Madsen <paul.madsen@gmail.com> Fri, 11 May 2012 14:11 UTC

Return-Path: <paul.madsen@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9F221F871A for <oauth@ietfa.amsl.com>; Fri, 11 May 2012 07:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN71Y0KLM+YT for <oauth@ietfa.amsl.com>; Fri, 11 May 2012 07:10:54 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 70F5C21F8705 for <oauth@ietf.org>; Fri, 11 May 2012 07:10:54 -0700 (PDT)
Received: by obbeh20 with SMTP id eh20so4021782obb.31 for <oauth@ietf.org>; Fri, 11 May 2012 07:10:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=P/j0e1gSow09qpspYWYvbIaCUfJo4tXoDbL97tyLIig=; b=ZCI/F6TKiM/m7rY9X5Qav0w1UIvxEksFUS8mMarAvK1+FPqLWlT2RrggXcsRafP74s 9fGuoERBQ2st2vRl0l+vfHZIefKe2crPB//yLULBzB5RNB8lbgs3DqdpEa3TuUr+47+i Hf9d3WaHY0bhFasECjMiJVS9+kJ1EokhAdGn0q98plXoCU2U3SQbyQ8PHVtBrXLU9y80 hNzs93x4l3VkbBp5G8Op9fQ0OnFBIQRt0ciPq8OunUg7FG/iIJ0jVeNBn83kFddSgCie R3lY7g73W9r+ixvKbkTwd7NH1faZHVBAUSkU7Pep4eQC77+j8+SjBLmHdxsnjfns1p2W Y0mw==
Received: by 10.182.141.9 with SMTP id rk9mr11764811obb.50.1336745453997; Fri, 11 May 2012 07:10:53 -0700 (PDT)
Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [99.224.20.155]) by mx.google.com with ESMTPS id r8sm7698160oer.6.2012.05.11.07.10.52 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 07:10:53 -0700 (PDT)
Message-ID: <4FAD1DEC.5040304@gmail.com>
Date: Fri, 11 May 2012 10:10:52 -0400
From: Paul Madsen <paul.madsen@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
To: Sergey Beryozkin <sberyozkin@gmail.com>
References: <E33E01DFD5BEA24B9F3F18671078951F156D8F4B@szxeml534-mbx.china.huawei.com> <4F3BB6B8.1030501@mitre.org> <4F4FA62F.7010404@gmail.com> <5E5D54C4-092B-4D7F-810D-39FFAF08FF6B@mitre.org> <5710F82C0E73B04FA559560098BF95B1250DBA5E89@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4F4FF563.3070806@gmail.com> <5710F82C0E73B04FA559560098BF95B1250DBA5F93@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4F4FF9E3.3010007@gmail.com> <4FAD1C52.6060708@gmail.com>
In-Reply-To: <4FAD1C52.6060708@gmail.com>
Content-Type: multipart/alternative; boundary="------------050809050202000005080502"
Cc: "'<oauth@ietf.org>'" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Difference between RO and End User (Was: Few questions about client_credentials)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 May 2012 14:11:06 -0000

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)

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:sberyozkin@gmail.com]
>>> Sent: Thursday, March 01, 2012 5:17 PM
>>> To: Zeltsan, Zachary (Zachary)
>>> Cc: 'Richer, Justin P.'; '<oauth@ietf.org>'
>>> 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:oauth-bounces@ietf.org  [mailto:oauth-bounces@ietf.org] On 
>>>> Behalf Of Richer, Justin P.
>>>> Sent: Thursday, March 01, 2012 12:01 PM
>>>> To: Sergey Beryozkin
>>>> Cc:<oauth@ietf.org>
>>>> 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
>>>>> 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
>
>