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

Torsten Lodderstedt <> Fri, 30 April 2010 18:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F374B3A6868 for <>; Fri, 30 Apr 2010 11:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.614
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HVXq9D37Cgr0 for <>; Fri, 30 Apr 2010 11:43:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E923E3A6808 for <>; Fri, 30 Apr 2010 11:43:42 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1O7vBO-0007a5-Sf; Fri, 30 Apr 2010 20:43:27 +0200
Message-ID: <>
Date: Fri, 30 Apr 2010 20:43:22 +0200
From: Torsten Lodderstedt <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv: Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Eran Hammer-Lahav <>
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 (" <>
Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 


> _______________________________________________
> OAuth mailing list