Found 2 records.

Status: Reported (2)

RFC 8225, "PASSporT: Personal Assertion Token", February 2018

Errata ID: 5392
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Invalid "iat" content
Date Reported: 2018-06-14

Section 5.1.1 says:

 
   The JSON claim MUST include the "iat" (Issued At) claim ([RFC7519],
   Section 4.1.6).  As defined, the "iat" claim should be set to the
   date and time of issuance of the JWT and MUST indicate the date and
   time of the origination of the personal communications.  The time
   value should be of the NumericDate format as defined in [RFC7519],
   Section 2.  This is included for securing the token against replay
   and cut-and-paste attacks, as explained further in Section 10
   ("Security Considerations").
 

It should say:

The JSON claim MUST include the "iat" (Issued At) 
claim ([RFC7519], Section 4.1.6).  As defined, the 
"iat" claim should be set to the date and time of 
issuance of the JWT. The time value should be of the 
NumericDate format as defined in [RFC7519], Section 2. 
This is included for securing the token against replay 
and cut-and-paste attacks, as explained further in 
Section 10 ("Security Considerations").

Notes:

It is mentioned that “iat” should be set based on issuance of JWT (which would be when PASSPorT is constructed). OTOH, it is also stated that it MUST indicate the date and time of the origination of the personal communication. The former seems to be the right approach as what we would like to protect against cut-and-paste attacks is the PASSPorT in the context of a particular communication session. The times for these two events are not necessarily the same/close enough to be considered the same.

RFC7519 JSON Web Token (JWT)

4.1.6. "iat" (Issued At) Claim

The "iat" (issued at) claim identifies the time at which the JWT was
issued. This claim can be used to determine the age of the JWT. Its
value MUST be a number containing a NumericDate value. Use of this
claim is OPTIONAL.

This text clearly states that “iat” is for the generation time of JWS.

Errata ID: 5985
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: James Manger
Date Reported: 2020-02-20

Section 7.1 says:

eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI
6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0

It should say:

eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI
6MTQ0MzIwODM0NSwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19Cg

Notes:

The "iat" claim in the example's JWT payload is incorrectly encoded as a string (with double-quotes around its value), instead of a number (without double-quotes).
WRONG: Base64url( ... "iat":"1443208345", ... ) = ... 6IjE0NDMyMDgzNDUiLCJv ...
RIGHT: Base64url( ... "iat":1443208345, ... ) = ... 6MTQ0MzIwODM0NSwi ...

The same example appears in Appendix A, where it is correct. I assume the JWS signature in section 7.1 should also be replaced with the value from Appendix A.

Report New Errata