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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
