Why HAIP implies that there are temporal validation rules for iat when it has none, and at the same time does not mention nbf at all?

[joelposti]

Currently section ‘Validity Period of the Signature and the Claim Values’ has this to say about iat claim:

iat and exp JWT claims express both the validity period of both the signature and the claims about the subject, unless there is a separate claim used to express the validity of the claims.

Why is it implied that iat claim has temporal validation rules? The JWT standard does not define any rules for iat in section 4.1.6. "iat" (Issued At) Claim.

Meanwhile, the JWT standard has temporal validation rules for nbf claim in section 4.1.5. "nbf" (Not Before) Claim, but HAIP does not mention that claim.

I created a pull request #165 that proposes adding nbf to the claims table in section ‘SD-JWT VCs’ and replacing iat in section ‘Validity Period of the Signature and the Claim Values’ with nbf.

[selfissued]

nbf is only useful if tokens are going to be future-dated and not valid when issued. That doesn't match our use cases. Therefore, we should not add or mention nbf.

For what it's worth, the validation logic for iat in OpenID Connect ID Tokens is:

10. The iat Claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is Client specific.

We could add similar language to this spec.

[scvenema]

nbf is only useful if tokens are going to be future-dated and not valid when issued. That doesn't match our use cases. Therefore, we should not add or mention nbf.

Is there an authoritative set of use cases stashed somewhere? Perhaps this is too contrived, but would it make sense pre-issue a replacement credential such as an international passport without automatically invalidating an existing credential? Generally, an individual isn't allowed to have more than one valid passport, but there may be reasons to not invalidate an existing passport when the new one is issued.

Or what about, say, an event pass which is valid for only one day of a multi-day event (like a one-day pass for Identiverse)? One could argue that validity periods could be embedded in issuer-specific credential metadata, but I kind'a like a standardized way to express this. A Wallet could also provide a credential selection UX that hides or de-emphasizes creds which aren't (yet) in their validity range.
These pre-validity issuance use cases seem to argue for an nbf`` claim as a separate beast from the iat` claim.

[As an aside, how many of use just love the idea of sending in our still-valid physical passport to a government agency to hopefully be replaced by a new one at some vague future time? A new digital passport being issued before the existing one expires seems pretty attractive and it may make sense to not invalidate an existing credential at the time of replacement.]

[joelposti]

nbf is only useful if tokens are going to be future-dated and not valid when issued. That doesn't match our use cases. Therefore, we should not add or mention nbf.

I do not know if it needs to be considered in the context of HAIP, but I have recently reviewed draft version 0.0.6 of ETSI TS 119 472-1 Electronic Signatures and Trust Infrastructures (ESI); Profiles for Electronic Attestations of Attributes; Part 1: General requirements standard. That draft standard has requirements that say that EUDIW ecosystem attestations (EAAs, QEAAS and PuB-EAAs) must express their validity period with two instant times. The same draft standard also specifies this further by saying that these instant times shall be expressed with nbf and exp claims in SD-JWT VC attestations. I could provide citations from the draft standard, but I am unsure if that is allowed.