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

[Joseph Smarr <[e-mail]>]

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 <[e-mail]> 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" <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>