+1 for #3. If the delimiter becomes an issue then: - for application/x-www-form-urlencoded and query parameters we can allow multiple values for this parameter - for json this parameter can be defined as an array
Marius 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
