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