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

Joseph Smarr <jsmarr@gmail.com> Fri, 30 April 2010 20:58 UTC

Return-Path: <jsmarr@gmail.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 D82163A6A36 for <oauth@core3.amsl.com>; Fri, 30 Apr 2010 13:58:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.198
X-Spam-Level:
X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_50=0.001, HTML_MESSAGE=0.001]
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 1KJBPuqAj5gF for <oauth@core3.amsl.com>; Fri, 30 Apr 2010 13:58:09 -0700 (PDT)
Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id B95B83A69E5 for <oauth@ietf.org>; Fri, 30 Apr 2010 13:58:07 -0700 (PDT)
Received: by pxi19 with SMTP id 19so392162pxi.31 for <oauth@ietf.org>; Fri, 30 Apr 2010 13:57:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:reply-to :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; bh=LChtLVF1xJZZdueNBgI0Mz4qrSSaVGYV/4LYKEi9X4A=; b=TA19zisRbou8/QnR7xZGV7YKq26upsRopg+Yj+GVyUJhkDwLYtMsf/n58JckoGhUY2 2+cC2vnPlmyRAjebTNzL5Y3Wt2gAB3H/M4E7JzesmL4jnvz5bksN1f6CugWMgWli4puQ s1zBBp7t+s5ZJrVXMzVNVajYfVmMT7pN8z5q8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; b=Qs28o4pMx9XiWQadk7nlQt7+wUwFbhPRvfGNMkATafdMATYD+pQ7OSoIkYmARdbHJ+ Zzt3lr/tNW0BJGGi2Ybbo1djkm1oEynbMiHYBr2awyCZWfArxl2vjC05qv0idhLLODSP rTlxG6wn/9N+IdJ45l0NK9niT/JFyqmirma4w=
Received: by 10.142.248.1 with SMTP id v1mr7049667wfh.107.1272661071491; Fri, 30 Apr 2010 13:57:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.143.164.14 with HTTP; Fri, 30 Apr 2010 13:52:16 -0700 (PDT)
In-Reply-To: <C80078D0.2D681%atom@yahoo-inc.com>
References: <90C41DD21FB7C64BB94121FBBC2E723439321772EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <C80078D0.2D681%atom@yahoo-inc.com>
From: Joseph Smarr <jsmarr@gmail.com>
Date: Fri, 30 Apr 2010 13:52:16 -0700
Message-ID: <m2tc334d54e1004301352zf2a7f1cbi3fc90525ffddbf8@mail.gmail.com>
To: Allen Tom <atom@yahoo-inc.com>
Content-Type: multipart/alternative; boundary=00504502cc9115f58504857a7f38
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
Reply-To: jsmarr@stanfordalumni.org
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 20:58:10 -0000

I also vote for #3. I think our field experience has shown that a) lack of a
standard place to stick scope info in access token requests leads to
per-provider inconsistencies that further complicate libraries, b) lots of
providers do want to offer scoped access tokens (and show the list of scopes
being requested on consent UI), and c) we're likely to want to have some
cross-vendor standard scopes (e.g. "access profile data", PoCo, "post
activities", etc.) so it's natural to express those as URIs, thus favoring
space-delimited scope values.

Thanks,js

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
>