Re: [OAUTH-WG] Few questions about client_credentials

Sergey Beryozkin <sberyozkin@gmail.com> Thu, 01 March 2012 22:14 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 B0F5321E835C for <oauth@ietfa.amsl.com>; Thu, 1 Mar 2012 14:14:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 7uvkNOvOpRrv for <oauth@ietfa.amsl.com>; Thu, 1 Mar 2012 14:14:10 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8ACF21E8352 for <oauth@ietf.org>; Thu, 1 Mar 2012 14:14:09 -0800 (PST)
Received: by wicr5 with SMTP id r5so330239wic.31 for <oauth@ietf.org>; Thu, 01 Mar 2012 14:14:09 -0800 (PST)
Received-SPF: pass (google.com: domain of sberyozkin@gmail.com designates 10.180.7.231 as permitted sender) client-ip=10.180.7.231;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of sberyozkin@gmail.com designates 10.180.7.231 as permitted sender) smtp.mail=sberyozkin@gmail.com; dkim=pass header.i=sberyozkin@gmail.com
Received: from mr.google.com ([10.180.7.231]) by 10.180.7.231 with SMTP id m7mr7857880wia.3.1330640049055 (num_hops = 1); Thu, 01 Mar 2012 14:14:09 -0800 (PST)
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=hPwUnhmXyX39piNmAjkAPMeOEJoqdrjPnZrqYhKfRxQ=; b=OilFospVPcUzYIb9UlXMOeEZm2hOAHiLdSSjpvz9GAtV97gVMhnt1gc+z5fRRAV+uX 6GPsrJ9t1TUTf5pDZ7mur9hsH3mme6NWkU3faQbCTjLVQGDFZS/W/E6pwfDOlRBxoCeM r1LMxgB7n/3dqNDvQ1RSBU7enFtkbWuB97kpFIiosoz6F4JruFzwRrOmwjEDzQqgbssI rzKK31zFXerD1JoXxK8bCcuHISdTdi86egMWYcWMgG53sf5+ySWyZvY7GGkV8iMzxn43 C5J3hcbsCrvgrEkAvhTkmAH7yteIuqbVmhMIDDD8/A49VnZXgpago4MjkXSOFEF8MWZg cHcw==
Received: by 10.180.7.231 with SMTP id m7mr6348586wia.3.1330640048985; Thu, 01 Mar 2012 14:14:08 -0800 (PST)
Received: from [192.168.2.3] ([89.100.23.77]) by mx.google.com with ESMTPS id df3sm44612074wib.1.2012.03.01.14.14.08 (version=SSLv3 cipher=OTHER); Thu, 01 Mar 2012 14:14:08 -0800 (PST)
Message-ID: <4F4FF4AF.10509@gmail.com>
Date: Thu, 01 Mar 2012 22:14:07 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: "Richer, Justin P." <jricher@mitre.org>
References: <E33E01DFD5BEA24B9F3F18671078951F156D8F4B@szxeml534-mbx.china.huawei.com> <4F3BB6B8.1030501@mitre.org> <4F4FA62F.7010404@gmail.com> <5E5D54C4-092B-4D7F-810D-39FFAF08FF6B@mitre.org>
In-Reply-To: <5E5D54C4-092B-4D7F-810D-39FFAF08FF6B@mitre.org>
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] 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: Thu, 01 Mar 2012 22:14:10 -0000

Thanks for the comments,

On 01/03/12 17:00, Richer, Justin P. wrote:
> 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.

It does make sense. What I'm still missing is how an access token 
returned as part of the client_credentials flow can 'link' to more than 
a single resource owner. The authorization server can establish the fact 
that a specific end user pre-authorized the client, but how to manage 
the case where many end users have pre-authorized the same client ? The 
returned access token won't uniquely identify the end user which have 
pre-authorized this client...

>
> 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.
>
Sure - I can see why it is very useful for an authorization code flow.
Still a bit unclear why the scope can be needed in case where a client 
is accessing its own resources, but do see it can be useful when the 
access to the end user's resources is also thought...

many thanks
Sergey

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