RFC Errata
Found 2 records.
Status: Reported (2)
RFC 7519, "JSON Web Token (JWT)", May 2015
Source of RFC: oauth (sec)
Errata ID: 5906
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Erdem Memisyazici
Date Reported: 2019-11-13
Section 7.2 says:
Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWT can be successfully validated, unless the algorithms used in the JWT are acceptable to the application, it SHOULD reject the JWT.
It should say:
Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWT can be successfully validated, unless the algorithms used in the JWT are acceptable to the application, it MUST reject the JWT.
Notes:
A vulnerability exists in certain implementations in the wild where applications simply look for valid JWT tokens which includes the "none" algorithm (https://medium.com/swlh/hacking-json-web-tokens-jwts-9122efe91e4a). A fairly popular library is auth0's java-jwt and at verification (https://github.com/auth0/java-jwt/blob/master/lib/src/main/java/com/auth0/jwt/JWTVerifier.java) quite reasonably you cannot initialize the class without an algorithm. Given all capital SHOULD may be interpreted as a recommendation and as this RFC dictates the algorithm "none" MUST be implemented as a default algorithm under Section 8, one could argue JWTVerifier in the example doesn't have to verifyAlgorithm leading to the vulnerability pointed out in the first article while still complying by the specification. There is no good reason why an algorithm unacceptable to the application must not be rejected as it does more harm than good and all popular library implementations interpret it as such.
Errata ID: 5648
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andy Delcambre
Date Reported: 2019-03-08
Section 1 says:
JSON Web Token (JWT) is a compact claims representation format intended for space constrained environments such as HTTP Authorization headers and URI query parameters. JWTs encode claims to be transmitted as a JSON [RFC7159] object that is used as the payload of a JSON Web Signature (JWS) [JWS] structure or as the plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JWTs are always represented using the JWS Compact Serialization or the JWE Compact Serialization. The suggested pronunciation of JWT is the same as the English word "jot".
It should say:
JSON Web Token (JWT) is a compact claims representation format intended for space constrained environments such as HTTP Authorization headers and URI query parameters. JWTs encode claims to be transmitted as a JSON [RFC7159] object that is used as the payload of a JSON Web Signature (JWS) [JWS] structure or as the plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JWTs are always represented using the JWS Compact Serialization or the JWE Compact Serialization.
Notes:
The suggested pronunciation is strange and confusing. It makes it hard to onboard new people verbally and always requires an explanation of the pronunciation. The standard already has a perfectly reasonable initialism of JWT that clearly refers to JSON Web Tokens. It is jarring to suggest a pronunciation that does not map to the letters of the spec, and in my experience often leads to confusion when used.
