[Openid-specs-fapi] Issue #753: Is nbf a mandatory requirement for request object in FAPI 2 message signing? (openid/fapi)

[Dima Postnikov]

New issue 753: Is nbf a mandatory requirement for request object in FAPI 2 message signing?
https://bitbucket.org/openid/fapi/issues/753/is-nbf-a-mandatory-requirement-for-request

Dima Postnikov:

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](https://openid.net/specs/fapi-security-profile-2_0-final.html#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.
>
> ‌

‌