+1 for #3 Since google implemented I always thought it an elegant simple way of requesting access.
On Fri, Apr 30, 2010 at 4:52 PM, Joseph Smarr <jsm...@gmail.com> wrote: > 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 <a...@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" <e...@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 > > -- http://agree2.com - Reach Agreement! http://extraeagle.com - Solutions for the electronic Extra Legal world http://stakeventures.com - Bootstrapping blog _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
