RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 7519, "JSON Web Token (JWT)", May 2015

Note: This RFC has been updated by RFC 7797, RFC 8725

Source of RFC: oauth (sec)

Errata ID: 8225
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Alex Giannakakos
Date Reported: 2024-12-31

Section 7.2 says:

   7.   Depending upon whether the JWT is a JWS or JWE, there are two
        cases:

        *  If the JWT is a JWS, follow the steps specified in [JWS] for
           validating a JWS.  Let the Message be the result of base64url
           decoding the JWS Payload.

        *  Else, if the JWT is a JWE, follow the steps specified in
           [JWE] for validating a JWE.  Let the Message be the resulting
           plaintext.

   8.   If the JOSE Header contains a "cty" (content type) value of
        "JWT", then the Message is a JWT that was the subject of nested
        signing or encryption operations.  In this case, return to Step
        1, using the Message as the JWT.

   9.   Otherwise, base64url decode the Message following the
        restriction that no line breaks, whitespace, or other additional
        characters have been used.

   10.  Verify that the resulting octet sequence is a UTF-8-encoded
        representation of a completely valid JSON object conforming to
        RFC 7159 [RFC7159]; let the JWT Claims Set be this JSON object.

It should say:

   7.   Depending upon whether the JWT is a JWS or JWE, there are two
        cases:

        *  If the JWT is a JWS, follow the steps specified in [JWS] for
           validating a JWS.  Let the Message be the result of base64url
           decoding the JWS Payload.

        *  Else, if the JWT is a JWE, follow the steps specified in
           [JWE] for validating a JWE.  Let the Message be the resulting
           plaintext.

   8.   If the JOSE Header contains a "cty" (content type) value of
        "JWT", then the Message is a JWT that was the subject of nested
        signing or encryption operations.  In this case, return to Step
        1, using the Message as the JWT.

   9.   Verify that the resulting octet sequence is a UTF-8-encoded
        representation of a completely valid JSON object conforming to
        RFC 7159 [RFC7159]; let the JWT Claims Set be this JSON object.

Notes:

If the JWT is a JWS, then the Message, as defined in step (7), is already base64url decoded.

If the JWT is a JWE, then the Message, defined as the resulting plaintext in step (7) is not base64url encoded at all per [JWE].

Repeating the base64url decode operation here would yield a bad octet sequence.

The decoding instructions regarding line breaks, whitespace, and other characters, are also already part of the validations steps in [JWS] and may be redundant here. Otherwise, they could be moved to the relevant passage about base64url decryption in step (7).

Report New Errata



Advanced Search