The following errata report has been submitted for RFC7519,
"JSON Web Token (JWT)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8225

--------------------------------------
Type: Technical
Reported by: Alex Giannakakos <alexgiannaka...@gmail.com>

Section: 7.2

Original Text
-------------
   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.

Corrected Text
--------------
   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).

Instructions:
-------------
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7519 (draft-ietf-oauth-json-web-token-32)
--------------------------------------
Title               : JSON Web Token (JWT)
Publication Date    : May 2015
Author(s)           : M. Jones, J. Bradley, N. Sakimura
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Reply via email to