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
