In draft-ietf-oauth-v2-bearer-01 section 2.1 "The Authorization Request Header Field" an access-token can use 93 ASCII characters, including: comma, double-quote, equals, backslash etc. These have no special meaning. No escaping is defined.
This is fairly diabolical. It is incompatible with the RFC2617 spec for the Authorization header, where after the scheme name come comma-separated name=value pairs. A name is a <token> (77 allowed ASCII chars). A value is a <token> or a <quoted-string> (226 allowed ISO-8859-1 chars, 2 needing escaping). It is incompatible with draft-ietf-httpbis-p7-auth-12 (the httpbis update for RFC2617). That draft is more lenient to reflect BASIC and NTLM etc that have a single base64 blob, instead of comma-separated name=value pairs. The bearer draft wants an initial blob AND comma-separate name=value pairs. Please pick one - unless you can first convince the httpbis group to make the Authorization header even more lenient (which I suspect they will reject as it isn't necessary and there isn't a deployed based actively using the more lenient syntax). The bearer draft allows the initial blob (access-token) to look like: name=value but not be a parameter; comma-separated params, but not be; a quoted-string, but not use the defined escaping mechanism for quoted-string; an internationalized RFC2047 word in another charset, but it is not supposed to be processed as such. Please restrict access-token to the 66 web-safe chars. -- James Manger
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
