On 2012-07-17 19:15, Mike Jones wrote:
For clarity of discussion, the definition in question is:
b64token = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
Note that b64token is a liberal syntax intended to permit base64 encoded content (hence the inclusion of the "+" and "/"
characters and the optional trailing "=" characters), base64url encoded content (hence the inclusion of the "-" and "_"
characters) and other URL-safe productions (hence the inclusion of the "." and "~" characters).
Its use is definitely not intended to be restricted to base64 encoded content, per RFC
4648. If it were so restricted (by not allowing ".", for instance), this would
exclude the use of JWTs as bearer tokens, for instance, which is something we
*definitely* want to allow.
As a result, I don't think adding a reference to RFC 4648 is either necessary
or appropriate.
Julian may be able to provide more background.
That is correct, in that the constraint on the token contents seems to
be defined elsewhere.
That being said, by changing the reference from HTTPbis to 2617 you
broke the spec:
The "Authorization" header field uses the framework defined by
HTTP/1.1 [RFC2617] as follows:
b64token = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token
...because in RFC 2617, exactly that syntax is not allowed:
credentials = auth-scheme #auth-param
auth-param = token "=" ( token | quoted-string )
I have to say that I'm a bit surprised by that change (was there any
public discussion about it?). It is probably possible to fix this
without having to reference HTTPbis, but, I'm not totally sure about why
you would want that.
(Note that the spec can be approved before HTTPbis, it just would have
to wait for RFC publication a bit longer)
Best regards, Julian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
