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

Mark Mcgloin <mark.mcgloin@ie.ibm.com> Tue, 04 May 2010 09:08 UTC

Return-Path: <mark.mcgloin@ie.ibm.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 3A0843A69CC; Tue, 4 May 2010 02:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.562
X-Spam-Level:
X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
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 PAnHgrROl3O8; Tue, 4 May 2010 02:08:25 -0700 (PDT)
Received: from mtagate2.uk.ibm.com (mtagate2.uk.ibm.com [194.196.100.162]) by core3.amsl.com (Postfix) with ESMTP id DAC0E3A69C1; Tue, 4 May 2010 02:08:24 -0700 (PDT)
Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate2.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o44989qJ000922; Tue, 4 May 2010 09:08:09 GMT
Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o44989jp1441948; Tue, 4 May 2010 10:08:09 +0100
Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o44989op009892; Tue, 4 May 2010 10:08:09 +0100
Received: from d06ml901.portsmouth.uk.ibm.com (d06ml901.portsmouth.uk.ibm.com [9.149.39.138]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id o449893T009883; Tue, 4 May 2010 10:08:09 +0100
In-Reply-To: <23B6AE40-3304-432C-9AB7-DD725C0A1B37@xmlgrrl.com>
To: <oauth@ietf.org>, oauth-bounces@ietf.org
X-Mailer: Lotus Notes Release 7.0 HF400 February 20, 2008
Message-ID: <OF8ECCAC3A.C41EF1AC-ON80257719.0031B2FF-80257719.00322EA9@ie.ibm.com>
From: Mark Mcgloin <mark.mcgloin@ie.ibm.com>
Date: Tue, 4 May 2010 10:08:07 +0100
X-MIMETrack: Serialize by Router on D06ML901/06/M/IBM(Release 8.0.2FP2|June 22, 2009) at 04/05/2010 10:08:08
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
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: Tue, 04 May 2010 09:08:26 -0000

+1  to option 3


I think the suggestion below from Torsten makes great sense, especially in
relation to standardized apis such as mail


Mark


On 01 May 2010, at 13:36 PM, Eve Maier 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