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

Sergey Beryozkin <sberyozkin@gmail.com> Fri, 11 May 2012 14:37 UTC

Return-Path: <sberyozkin@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 1E43D21F8570 for <oauth@ietfa.amsl.com>; Fri, 11 May 2012 07:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level:
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 In7352EmaxWY for <oauth@ietfa.amsl.com>; Fri, 11 May 2012 07:37:37 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF8721F8564 for <oauth@ietf.org>; Fri, 11 May 2012 07:37:36 -0700 (PDT)
Received: by bkty8 with SMTP id y8so2667798bkt.31 for <oauth@ietf.org>; Fri, 11 May 2012 07:37:35 -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:content-transfer-encoding; bh=kGkbMCHaymsHuoFnuzJyj5/m5xShdN1jbTwirLEwVUw=; b=G7jkqA/JV0ScLkVPHyiyFLXdtr95aWx9KzrEKzPOPSSckHyjwfBbMNJIogSAEAWEkb phnepF2NCe3KjKgAWvaw1J59kTM3R49zUftzShQugWl4OPcSWXGmlw8zNPen3JfyqdBZ o+SxADY5Wq152k9ZgXWCtzfNzYlnPsLusPByhPe6rambBgNy3I+wB4hPJlXAiwstODb/ 68qrCte9A41RFl8wG2M14YBPD78l0qXaGF5JPfQVcnvARBh9g/UNtpnBxiM8gYVZ2DZ3 5N4HnScdNaqfFelqQu0lC3XVJrxJF0fJgZOYr8egKvaAS7OqDSNOpYqLI7XCoYseEhIW /CxQ==
Received: by 10.205.128.8 with SMTP id hc8mr4946585bkc.17.1336747055575; Fri, 11 May 2012 07:37:35 -0700 (PDT)
Received: from [10.36.226.5] ([217.173.99.61]) by mx.google.com with ESMTPS id u8sm19026843bks.0.2012.05.11.07.37.34 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 07:37:35 -0700 (PDT)
Message-ID: <4FAD242E.9070905@gmail.com>
Date: Fri, 11 May 2012 15:37:34 +0100
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Paul Madsen <paul.madsen@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> <4FAD1DEC.5040304@gmail.com>
In-Reply-To: <4FAD1DEC.5040304@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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:37:38 -0000

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