Re: [OAUTH-WG] Scope - Coming to a Consensus

Eve Maler <eve@xmlgrrl.com> Sat, 01 May 2010 12:49 UTC

Return-Path: <eve@xmlgrrl.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B26F28C1BA for <oauth@core3.amsl.com>; Sat, 1 May 2010 05:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.191
X-Spam-Level: *
X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_50=0.001, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zEtI7acPZGB for <oauth@core3.amsl.com>; Sat, 1 May 2010 05:49:43 -0700 (PDT)
Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id 1AE3528C941 for <oauth@ietf.org>; Sat, 1 May 2010 05:36:47 -0700 (PDT)
Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.3/8.14.3) with ESMTP id o41CaQWx019265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 May 2010 05:36:27 -0700
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Eve Maler <eve@xmlgrrl.com>
In-Reply-To: <4BDBC389.2090709@lodderstedt.net>
Date: Sat, 1 May 2010 05:36:26 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <23B6AE40-3304-432C-9AB7-DD725C0A1B37@xmlgrrl.com>
References: <90C41DD21FB7C64BB94121FBBC2E723439321772EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4BDB24CA.4050407@lodderstedt.net> <AANLkTikGcyvdMiYKLC3TUaIVChlgwQUxJ2I8eud1ivNU@mail.gmail.com> <4BDBC389.2090709@lodderstedt.net>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: Apple Mail (2.1078)
Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sat, 01 May 2010 12:49:44 -0000

On 30 Apr 2010, at 11:00 PM, Torsten Lodderstedt wrote:

> Am 01.05.2010 03:07, schrieb Marius Scurtescu:
>> On Fri, Apr 30, 2010 at 11:43 AM, Torsten Lodderstedt
>> <torsten@lodderstedt.net>  wrote:
>>   
>>> In my opinion, automatic discovery on scope values is as valuable or not
>>> valuable as automatic discovery for a service API. I would like to echo one
>>> of my postings:
>>> 
>>> A scope defines the set of permissions a client asks for and that becomes
>>> associated with tokens. I don't see the need (and a way) for automatic scope
>>> discovery. In my opinion, scopes are part of the API documentation of a
>>> particular resource server. So if someone implements a client, it needs to
>>> consider the different scopes this client needs the end users authorization
>>> for. If the resource server implements a OAuth2-based standard API (e.g. for
>>> contact management or e-Mail), a client might be interoperable (in terms of
>>> scopes) among the resource servers implementing this standard.
>>>     
>> Not sure I understand, are you saying that for a standard API, like
>> IMAP for example, there should be a standard scope (or set of scopes)?
>>   
> 
> Yes, that's what I said.
> 
> Scopes (~permissions) should be defined allong with the corresponding API. So developers should know upfront
> which scope is required  to perform a particular action. For example, "uploading documents requires scope 'upload'".
> The same holds for IMAP. Depending on the IMAP feature set you want to use there could be plenty of scopes,
> ranging from "read users INBOX" to sharing scenarios, where users have access to other users IMAP folders.

This makes a ton of sense.  It's one of the reasons that, in UMA, we tried to specify a generic way of expressing scope that naturally and closely matches a resource-oriented (RESTful) API: resource + HTTP method is a reliable shorthand for an access feature.  For read and write and even delete permissions on (say) identity data accessed by URL, it's pretty much all the expressiveness you need, and ideally the same documentation easily covers both features and scopes.  For any API that's more "compressed" (e.g. one complex endpoint for many operations), it doesn't really help.

	Eve

Eve Maler
eve@xmlgrrl.com
http://www.xmlgrrl.com/blog