> I would like to proposal that the spec remains mute on the allowed parameter > values
The spec isn't mute. Currently, the draft spec uses HTTP's 'token' production for the value of an access token. Perhaps not surprising given the names. The ABNF for HTTP's 'token' allows only 89 characters. It excludes '=' for instance. It is designed NOT to need quoting in an HTTP header. Contradicting this, the draft spec requires double quotes around the access token value when in an HTTP header. It also uses a base64-encoding as an example that ends with '=' -- a disallowed character. Something needs to change. Either use 'quoted-string' for access tokens. That allows another ~20 ASCII chars, and \c escaping for other ASCII chars. I don't think there is any defined escaping for Unicode of bytes. Seemingly ad hoc choices such as %xx appeared in earlier OAuth example values, but I don't think it was ever defined. Or stick with 'token'; remove the quoting as unnecessary and hence misleading; change the example not to have '='; note that "normal" base64 cannot be used (need to exclude '=' and '/'). Or restrict access tokens to a restricted set that never needs escaping anywhere (HTTP headers, URIs, query params, XML...). Recommend base64-url-safe without terminators whenever a byte array, or (UTF-8 encoded) unicode needs to be represented. I favour this approach. The client app and user browser that are just passing these opaque values around don't have to do any escaping. They should just do input validation (reject values with any disallowed chars). P.S. 'token' may be changing in the revision of HTTP currently being written. -- James Manger -----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Friday, 16 April 2010 3:57 AM To: OAuth WG Subject: [OAUTH-WG] Issue: restriction on values characters Given the current proposal for signatures (no parsing of the request URI or body, or any encoding), I would like to proposal that the spec remains mute on the allowed parameter values. While it is best to issue values that do not require any encoding (or decoding when receiving a token response), encoding and decoding form-encoded parameter is trivial and provided automatically by every platform. The only issues with encoding in 1.0a related to signatures and the production of the base string. This is no longer an issue. Proposal: close issue without further action. EHL _______________________________________________ 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
