JWT exp claim

[David-Chadwick]

RFC 7519 states that the exp JWT claim "(expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing".
This is fundamentally different to the expirationDate of a W3C credential. The latter is the date that the credential (vc claim) expires and is optional e.g. a birth certificate and degree certificate never expire so they will never have an expirationDate property. My original UK driving license expired 50 years after it was issued. Clearly none of these can or should be mapped into the JWT exp claim. But the current text says that they should.

I contend that a JWT MUST always have an exp claim when it is used to proof a W3C credential, as the JWT crypto will not last forever, unlike some W3C credentials. Thus the current mapping rules are wrong, in that they state that the exp should be set to the expirationDate of the credential.

Proposal. The issuer's JWT signing library should be configured with a cryptographic expiry time, and the exp claim should be set to the earliest of this configuration time and the expirationDate from the vc claim if it is present.

[sbutterfield]

If I understand your proposal here - you are saying that the JOSE exp claim purpose should be decoupled from the W3C VC expirationDate property such that:

• exp only applies to the security envelope's validity
• expirationDate only applies to the usefulness(?) of the claims within the credentialSubject?

If I have that right, this feels a little weird and a slightly different interpretation than currently defined in VCDM. But, if I talk this out -

• if exp is before expirationDate then according to JWT processing rules the expirationDate should never be parsed.
• if exp is after expirationDate then according to that properties definition: representing the date and time the credential ceases to be valid. ... The credential is invalid, but the security envelope is still valid. What purpose does this serve?

[David-Chadwick]

@sbutterfield Not quite. Please read what I proposed again "the exp claim should be set to the earliest of this [signing library] configuration time and the expirationDate from the vc claim if it is present".

[sbutterfield]

I see. Thanks, I have selective reading syndrome at times.

So, in your example:

This is fundamentally different to the expirationDate of a W3C credential. The latter is the date that the credential (vc claim) expires and is optional e.g. a birth certificate and degree certificate never expire so they will never have an expirationDate property.

If we were to implement exp as the earliest cryptographic expiry time and that expirationDate shall not be before exp, then for a birth certificate that should never expire, it would actually cease to be valid after the cryptographic expiry time (exp) elapsed - assuming the relying party processed the vc-jwt according to spec? Or would you propose that a vc-jwt with exp that is < now should still be processed even though the security envelope is no longer authenticatable?

[David-Chadwick]

The reason that cryptographic signatures have an expiry time is that cryptographic algorithms do not last forever and are continually being enhanced and replaced. They become vulnerable to brute force and other attacks. So if a verifier were to receive a VC or VP with exp in the past, then the signature is no longer conceptually verifiable as it has expired (although of course the crypto can still be technically verified, but one must bear in mind that the algorithm might now be easy to break and the signature could have been forged). It is then a business decision (also called validation) as to whether to accept this expired signature or not. Our verification engine reports expired signatures to the application so that a business level decision can be made as to whether it should be accepted or not

[Sakurann]

As I commented on w3c/vc-data-model#965 (comment), I think the simplest would be to say that iat/exp of VC-JWT are validity of the VC-JWT signature and are different from ValifFrom/ValidUntil that are validity of the data in the Credential.

so what would have to change in VC-JWT spec would be

• mapping of ValidFrom/ValidUntil onto iat/exp claims are dropped
• iat/exp claims are redefined.

[OR13]

Is this still relevant assuming we merge #88 ?

I think its resolved then.

[OR13]

Related PR: w3c/vc-data-model#1149

removing the pending close label.

[iherman]

The issue was discussed in a meeting on 2023-09-14

• no resolutions were taken

View the transcript

6.10. JWT exp claim (issue vc-jose-cose#39)

See github issue vc-jose-cose#39.

Michael Jones: this one has a PR too, we agreed to merge that.
� already.

[selfissued]

This was addressed by PR #151