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

Luke Shepard <lshepard@facebook.com> Sat, 01 May 2010 22:49 UTC

Return-Path: <lshepard@facebook.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 E10373A6813 for <oauth@core3.amsl.com>; Sat, 1 May 2010 15:49:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.74
X-Spam-Level:
X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=-1.075, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1]
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 QSOyjG5BUPwG for <oauth@core3.amsl.com>; Sat, 1 May 2010 15:49:06 -0700 (PDT)
Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id F152D3A67FB for <oauth@ietf.org>; Sat, 1 May 2010 15:49:05 -0700 (PDT)
Received: from mail.thefacebook.com ([192.168.18.104]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o41MmRp5017810 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 1 May 2010 15:48:27 -0700
Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Sat, 1 May 2010 15:48:44 -0700
From: Luke Shepard <lshepard@facebook.com>
To: Marius Scurtescu <mscurtescu@google.com>
Date: Sat, 1 May 2010 15:48:44 -0700
Thread-Topic: [OAUTH-WG] Scope - Coming to a Consensus
Thread-Index: AcrpgHQhpAQhY7nLSTiQ2yYoSbzJKQ==
Message-ID: <60C3123B-4FCF-425C-A808-AFB4745AECC6@facebook.com>
References: <90C41DD21FB7C64BB94121FBBC2E723439321772EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <C80078D0.2D681%atom@yahoo-inc.com> <AANLkTikJBx-BwdLvgszIhSo9cf5WsJZvtjrWznei44Te@mail.gmail.com>
In-Reply-To: <AANLkTikJBx-BwdLvgszIhSo9cf5WsJZvtjrWznei44Te@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-01_02:2010-02-06, 2010-05-01, 2010-04-30 signatures=0
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 22:49:07 -0000

I agree with approach #3.

As for the delimiter, I'm fine if the spec wants to do space-delimited. 

Just FYI Facebook will also continue to support and document commas in addition to whatever the spec says, because spaces are typically URL-encoded while commas are considered reserved characters and so not encoded. It's easier to write "read,write" than "read%20write".

On Apr 30, 2010, at 6:11 PM, Marius Scurtescu wrote:

> +1 for #3.
> 
> If the delimiter becomes an issue then:
> - for application/x-www-form-urlencoded and query parameters we can
> allow multiple values for this parameter
> - for json this parameter can be defined as an array
> 
> Marius
> 
> 
> 
> On Fri, Apr 30, 2010 at 12:08 PM, Allen Tom <atom@yahoo-inc.com> wrote:
>> I vote for #3
>> 
>> There are already plenty of implementations that use a scope parameter:
>> 
>> Facebook:
>> http://developers.facebook.com/docs/authentication/
>> 
>> Google:
>> http://code.google.com/apis/accounts/docs/OAuth_ref.html#RequestToken
>> 
>> Flickr: (called "perm")
>> http://www.flickr.com/services/api/auth.spec.html
>> 
>> Yahoo currently requires developers to tell us the scopes that they need
>> when registering for a consumer key. We've received plenty of feedback that
>> developers would rather specify the scope(s) at authorization time, so we
>> would support a multi-valued scope parameter. Space is a reasonable
>> delimiter.
>> 
>> Allen
>> 
>> 
>> 
>> On 4/30/10 8:43 AM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:
>> 
>>> 
>>> 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.
>>> - Doesn't go far enough to actually achieve interoperability.
>>> - Adds complexity for little value.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth