Represent issuance time with "iat" rather than "nbf"

[selfissued]

The JWT claim iat was designed to represent the time that a token is issued. We should be using in the VC-JWT representation, rather than nbf.

For context, the JWT nbf claim was copied from SAML's NotBefore for completeness, but it is essentially never used (except for JWT-VCs, where its inclusion was a mistake that we should fix in V2).

The ability to future/past date tokens with nbf is esoteric and will likely cause more problems than it solves. We should remove the use of nbf so that this becomes impossible. That will help interoperability.

Note that the VC Data Model issue w3c/vc-data-model#918 is related - requesting that we retain issuanceDate in the Data Model not enable future/past dating of VCs.

[bellebaum]

I think we should still allow nbf, but ensure that issuers understand this claim and its implications.
There are still some valid use cases. E.g. If I purchase a train ticket which lets me ride a train for a month, the nbf claim of that ticket should reference the beginning of this time frame, and any attempt by me of using this ticket before then should fail, even if I have already purchased (and been issued - iat) the ticket before the month started.

[TallTed]

Resolution of this issue should follow and be based on the resolution of w3c/vc-data-model#913, which I believe will be to align nbf with validFrom, and iat with created or issuedAt. Most further discussion should therefore be on w3c/vc-data-model#913.

(@bellebaum -- I request that you repeat your comment above on w3c/vc-data-model#913, as your use case is different from the others raised there, and lends weight to my expected resolution.)

(For sake of clarity here on #9, w3c/vc-data-model#918, referenced above, was closed as a duplicate of w3c/vc-data-model#913.)

[David-Chadwick]

I think that the validity time of the crypto proof is fundamentally different from the validity time of the embedded claims (the latter can start before the proof was created and expire years after the crypto is invalid). So the former two are metadata of the claims and should be in the top level of the VC (as now). They should be iat and exp. However the validity time of the claims should be moved into the subject's properties, and not appear anywhere in the JWT as they will be buried in the vc claim of the JWT.

[Sakurann]

isuance of a credential, that has been agreed to be ValidFrom property defined in the vc-data-model, so this issue should be closed.
if we want to talk about date when credential is signed, we can keep this issue open and yes, it should be iat without any mapping to a vc-data-model property.

[David-Chadwick]

I think it is important that the JWT does contain the time the credential was signed, and that iat should be used for this, without any reference to the validity period of the embedded vc or vp claim.
In addition we can map ValidFrom into nbf and this time can be before, after or approx the same as the 'iat'

[alenhorvat]

I believe (and there are valid use cases), that we need to distinguish between a VC validity and signature validity.

jwt.vc.validFrom
jwt.vc.validUntil
should represent a period when the VC is considered valid. At the time of issuance, validFrom can be in the past or in the future. Example: I got my diploma in 201? in a physical form. If I ask for a digital version of it today, validFrom will be 201?.

jwt.iat
jwt.exp
iat represents a date and time at which the VC is issued, i.e., the signature becomes valid
exp is a date and time and at which the signature becomes invalid

signing certificate lifetime might be shorter than the lifetime of the VC; e.g., diploma doesn't have an expiration date, however, certificates used to e-seal them, do.

if nbf is used, it should match the value of jwt.vc.validFrom

[David-Chadwick]

@alenhorvat I agree with everything you say with one minor correction "should represent a period when the VC is considered valid." should be "should represent a period when the embedded credential is considered valid." As I have pointed out before, my original UK issued driving licence was valid from my age of 17 (when I passed my test) until my age of 65, but when issued as multiple VCs during its 49 year lifetime both the iat and exp would not match either of vc validity fields.

We need a PR to represent this.

[OR13]

This can be closed when #88 is merged

[OR13]

@selfissued blocked by #88

[TallTed]

@OR13 — Again, "the same PR" ... meaning #88?

[Sakurann]

PR #88 merged + PR #151 open