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

Torsten Lodderstedt <torsten@lodderstedt.net> Fri, 30 April 2010 18:43 UTC

Return-Path: <torsten@lodderstedt.net>
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 F374B3A6868 for <oauth@core3.amsl.com>; Fri, 30 Apr 2010 11:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.614
X-Spam-Level:
X-Spam-Status: No, score=-0.614 tagged_above=-999 required=5 tests=[AWL=-0.965, BAYES_50=0.001, HELO_EQ_DE=0.35]
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 HVXq9D37Cgr0 for <oauth@core3.amsl.com>; Fri, 30 Apr 2010 11:43:43 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id E923E3A6808 for <oauth@ietf.org>; Fri, 30 Apr 2010 11:43:42 -0700 (PDT)
Received: from p4fff1540.dip.t-dialin.net ([79.255.21.64] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1O7vBO-0007a5-Sf; Fri, 30 Apr 2010 20:43:27 +0200
Message-ID: <4BDB24CA.4050407@lodderstedt.net>
Date: Fri, 30 Apr 2010 20:43:22 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Eran Hammer-Lahav <eran@hueniverse.com>
References: <90C41DD21FB7C64BB94121FBBC2E723439321772EF@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723439321772EF@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: 141509
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: Fri, 30 Apr 2010 18:43:44 -0000

+1 on option 3.

Am 30.04.2010 17:43, schrieb Eran Hammer-Lahav:
> 3. Space-Delimited Scope Parameter Value
>
> Define a 'scope' parameter with value of space-delimited strings (which can include any character that is not a space - the entire parameter value is encoded per the transport rules regardless). Space allows using URIs or simple strings as values.
>
> Pros:
>
> - A separator-delimited list of values is the common format for scope parameters in existing implementations and represents actual deployment experience.
> - Most vendors define a set of opaque strings used for requesting scope. This enables libraries to concatenate these in a standard way.
> - Enables simple extensions in the future for discovering which scope is required by each resource.
>
> Cons:
>
> - Defining a format without a discovery method for the values needs doesn't offer much more than the other options.
>    

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.

> - Doesn't go far enough to actually achieve interoperability.
> - Adds complexity for little value.
>    

I think it adds a lot of value. It introduces the concept of client 
permissions to OAuth, which allows to restrict client access to services 
at a fine-grained level. At Deutsche Telekom, we have some use cases 
requiring such a feature and would be happy to see it supported by the 
standard.

regards,
Torsten.





>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>