I agree with approach #3. As for the delimiter, I'm fine if the spec wants to do space-delimited.
Just FYI Facebook will also continue to support and document commas in addition to whatever the spec says, because spaces are typically URL-encoded while commas are considered reserved characters and so not encoded. It's easier to write "read,write" than "read%20write". On Apr 30, 2010, at 6:11 PM, Marius Scurtescu wrote: > +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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
