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
