I find the following sentence confusing:
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-7.2
Base64url decode the Encoded JOSE Header following the
restriction that no line breaks, white space, or other
additional characters have been used.
When it says to decode following the restriction that certain
characters have not been used, is this supposed to mean (A) that those
characters are illegal in the encoded representation, or (B) that
those characters must be discarded if encountered in the decode
function?
Disregarding domain knowledge and examining the prose alone, I would
warily conclude A.
The difference is significant, affecting the strictness of token
validation. Consider a JWT with an arbitrary 0x0A line break somewhere
before the first period, resulting in the following JOSE header with a
line break:
eyJ0eXAiOiJKV1Qi
LA0KICJhbGciOiJIUzI1NiJ9
Similarly, the following header could result from a base64url encoder
that retains the common "=" padding:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0=
Under interpretation A, the headers are invalid and cannot be decoded.
Under interpretation B, the line break and "=" would be ignored, and
the headers would be decoded successfully.
How strict do we want JWT/JWS/JWE validation to be?
Whichever the case, I think the paragraph quoted above should simply
omit the 'restriction' comment:
Base64url decode the Encoded JOSE Header.
The original phrasing apparently comes from the JWS spec, and is
duplicated for JWE:
https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-5.2
https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40#section-5.2
If needed, further instruction on how to handle unexpected characters
should be done normatively in the base64url definition
(https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-2)
or maybe in the JWT structure overview.
Notice also that the example C# base64urldecode() function
(https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#appendix-C)
is lenient. So lenient in fact that it accepts BOTH the regular base64
and base64url encodings from RFC 4648.
Regards,
Andre DeMarre
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
