By definition the header ABNF is going to limit the allowed characters. There is no way around that. As of right now, the only problem is with the token value because the other fit well with the 'token' ABNF. The signature is already base64 encoded and included as a quoted string.
So the question is, do we define an encoding scheme for tokens containing other characters not allowed, or not, leaving each server to figure out how to encode their tokens to fit the allowed set? EHL On 4/16/10 8:14 AM, "James Manger" <james.h.man...@team.telstra.com> wrote: > We will need to choose an encoding method for the header values Not if we restrict the allowed chars in tokens to a very safe set of ~64 chars. > and percent-encoding seems to make the most sense It makes sense in URIs. In HTTP headers, however, I think it is more novel. There are quoted strings, \-escapes for a few chars, and some strange beast that does use %-encoding but not in double quotes and with a charset label. > (though unlike OAuth 1.0, we will not detail the encoding function). > Base64-ed values are hard to debug. Debugging pesky %-escapes in base64 is annoying. That can be avoided by specifying the base64-url encoding without '=' terminators. If a party wants to represent an arbitrary byte array... that's easy: apply the base64-url encoding without '=' terminators to the bytes If a party wants to represent an arbitrary Unicode string... that's easy: apply the base64-url encoding without '=' terminators to the UTF-8 encoding -- James Manger
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
