+1 on option 3. Commas seem slightly cleaner, but can go either way.
We should also consider naming this parameter "scopes" if we go with option 3 Evan On Mon, May 3, 2010 at 6:23 AM, Manger, James H < [email protected]> wrote: > A comma is a better separator here. > Allow URIs as scopes -- as long as the chosen URIs don't have commas. This > isn't a big restriction on services. > > [If a service provider really needs to include arbitrary URIs in an > authorization URI they can still do so by defining another parameter, say > "urls". We are barely defining any semantics for "scope" -- at least none > that libraries can use -- so not much is lost in using a different parameter > name.] > > > A space-separated list (encoded as per the transport) sounds nice at a > logical level, but is just a bit unnecessarily awkward. The only place scope > values appear is in an authz URI so the only encoding is URI-encoding. Are > the spaces escaped as "%20" or "+"? Even if we try to pick one answer I > suspect both will occur (it depends on which part of the software builds the > authz URI -- ie prepare for interop glitches). > Any spaces in a URI used as a scope value needs to be %-escaped twice. It > seems unnecessary to even allow this. > > > Facebook define values like scope=read,write. > However, if you build an authz URI from an HTML form with an input value of > "read,write" you get scope=read%2Cwrite -- as comma is not an unreserved > character. > <input name="scope" value="read,write"/> > I suspect authz services might need to accept "read%2Cwrite" as equivalent > to "read,write" [I wonder if Facebook does?]. Which gets produced will > depend on how the client app (or client OAuth library) is designed, and will > vary between apps. The spec probably need to say services MUST accept "," > and "%2C" as separators -- and consequently individual scope values MUST NOT > contain "," or "%2C". > > > I think the best definition (least potential for any developer or interop > grief) would restrict individual scope values to chars that can be placed in > a query parameter value without any special treatment. > Allow any chars allowed in URIs, except "&", "#", "%", or ",". > This doesn't allow arbitrary URIs, but I suspect it allows any URIs being > used as scopes at present. > > -- > James Manger > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
