If we are considering adding this restriction for the exp claim, or warning that some implementations may have this restriction, it might be convenient to include a similar statement for the jti claim according to RFC 7523:

The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant.

some implementations may have this restriction

ALL implementations will have some limitation on acceptable token lifetime. I am proposing that we make it explicit to the API consumer that tokens with a lifetime less that 300 seconds will be accepted by all authorisation servers. This would be new information for the API consumer.

Your proposed text on jti values is an implementation hint for authorisation servers, but adds no new information for API consumers. CAMARA should try to keep its specifications compact by only providing information that the API consumer needs to know. So I'd prefer not to include such hints.

Please propose some text to https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md#client-credentials-flow

Please propose some text to https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md#client-credentials-flow

I think you mean https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md#client-authentication, right?

Following up from today's meeting:

• For now, I propose this change apply only to the JWT used for client authentication (i.e. the client_assertion), and hence will only propose text for client authentication section referenced by @jpengar. If we make progress on the issues discussing signed authentication requests, then restrictions on the lifetimes of these tokens can be agreed in those issues.
• If the authorisation server rejects a JWT used for client authentication because its expiration date is "unreasonably far in the future", the appropriate error to return appears to be invalid_client, delivered with a 400 for the /token endpoint or a 401 for the /bc-authorize endpoint.
• @MarkCornall mentioned he would like all authorisation servers to apply the 300 second limit, and reject tokens with a longer lifetime. The issue with trying to standardise this behaviour is that the iat (issued at) field of the JWT is not mandatory, and so the authorisation server can only measure the remaining lifetime from when they receive the token. I see two options here:
  • Mandate the iat claim for private_key_jwt tokens (this is already mandatory for CIBA signed authentication requests) and thus limit the allowed token lifetime, irrespective of when the token was presented to the authorisation server; or
  • Limit the allowed remaining lifetime of the token when presented to the authorisation server, irrespective of whether or not the token contains an iat claim

Let me have any further thoughts by end of the week, and I'll propose some text early next week