4.8 Expiration

[nadalin]

Suggest that values like expirationDate be changed to match the JWT values already established in the industry, no need to make new claims since when using a JWT you have to use exp anyway and understand the processing

[brentzundel]

A verifiable credential is not a JWT. It has properties that a JWT does not and allows for usages that (to my understanding) JWTs do not.
I do not see the value in conflating the two by using the same names for their property values.

[awoie]

JWTs use exp to represent the expirationDate. The VC spec defines processing rules on how to convert a JWT VC that uses standard JOSE claims and headers onto the vocabulary specified in the VC spec.

[nadalin]

@awoie Why not use exp? is there a need to invent ?

[msporny]

@nadalin wrote:

Why not use exp? is there a need to invent ?

The datatype associated with JWT exp is a POSIX time value (seconds since 1970, e.g. 1300819380)... the datatype associated with the Verifiable Credentials Data Model spec's expirationDate is a RFC3339 combined date and time string (e.g., "2020-01-01T19:23:24Z"), therefore it would be inappropriate to use exp in this particular case.

[nadalin]

@msporny For many cases the JWT "exp" is fine, for others it may not be, all existing JWT claims should be allowed to be used ASIS for interoperability reasons

[stonematt]

VCWG Teleconference Resolution: https://www.w3.org/2019/04/09-vcwg-minutes.html#resolution08

RESOLUTION: Re-using the JWT "exp" claim in a Verifiable Credential is not appropriate because the datatype associated with JWT "exp" is a POSIX time value and the datatype associated with the expirationDate is a RFC3339 combined date and time string. The VCWG prefers the more verbose datatype. Non-normative text should be added to the specification on how deterministic and bi-directional translation should be done and issue #496 should be closed after that PR is
... merged into the specification.

[msporny]

PR #539 is designed to address this issue. There is text in the specification already on how to convert to/from datetimes in the section on JWTs: https://w3c.github.io/vc-data-model/#jwt-encoding and https://w3c.github.io/vc-data-model/#jwt-decoding.

This issue can be closed as soon as PR #539 is merged and the 7 day close delay is over.

[nadalin]

@msporny if a "exp" is all that is needed then it should be acceptable, there is no requirement in the specification that says there is a dependency on RFC3339. So don't agree with the proposed change

[brentzundel]

The text which describes the required dependency on RFC3339 for expiration dates is in section 4.8.

The value of the expirationDate property MUST be a string value of an [RFC3339] combined date and time string representing the date and time the credential ceases to be valid.

The text which describes the need to convert from RFC3339 to a UNIX timestamp if the VC is serialized as a JWT is in section 6.3.1

exp MUST represent expirationDate, encoded as a UNIX timestamp (NumericDate).

And the text which describes the need to convert from a UNIX timestamp to RFC3339 when moving from a JWT serialization of a VC is in section 3.6.1

To transform the JWT specific headers and claims, the following MUST be done. If: exp is present, the UNIX timestamp MUST be converted to an [RFC3339] date-time, and MUST be used to set the value of the expirationDate property of credentialSubject of the new JSON object.

[burnburn]

This issue appears to have been resolved with the additional explanation from @brentzundel , and no new comments have been added in the past 28 days. Closing.