Is nbf a mandatory requirement for request object in FAPI 2 message signing?

Originally submitted by Dima Postnikov (Dima Postnikov) on 2025-08-06

Current text says:

Clients implementing FAPI2 authorization request signing:

…

shall send a nbf claim in the request object

…

I understand that there are circumstances where it’s useful to have but is it required for every request?

Side question. Should this text from FAPI 2 security profile be in FAPI 2 message signing instead?

1. to accommodate clock offsets, shall accept JWTs with an iat or nbf timestamp between 0 and 10 seconds in the future but shall reject JWTs with an iat or nbf timestamp greater than 60 seconds in the future. See Note 3 for further details and rationale; and

NOTE 3: Clock skew is a cause of many interoperability issues. Even a few hundred milliseconds of clock skew can cause JWTs to be rejected for being "issued in the future". The DPoP specification [RFC9449] suggests that JWTs are accepted in the reasonably near future (on the order of seconds or minutes). This document goes further by requiring authorization servers to accept JWTs that have timestamps up to 10 seconds in the future. 10 seconds was chosen as a value that does not affect security while greatly increasing interoperability. Implementers are free to accept JWTs with a timestamp of up to 60 seconds in the future. Some ecosystems have found that the value of 30 seconds is needed to fully eliminate clock skew issues. To prevent implementations switching off iat and nbf checks completely this document imposes a maximum timestamp in the future of 60 seconds.

‌

‌

Bitbucket status: open

Bitbucket origin: issue 753