Retain issuanceDate and don't introduce validFrom

[selfissued]

I disagree with removing IssuanceDate and replacing it with ValidFrom. The time that a token was issued is normally included in it. For instance, that's for SAML and ID Tokens. It's true of current VCs.

Whereas, the ability to future/past date tokens is esoteric and will likely cause more problems than it solves. We should not introduce validFrom so that this remains impossible. That will help interoperability.

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). (See w3c/vc-jose-cose#9 for an issue proposing that fix.)

For context, https://www.w3.org/TR/2022/REC-vc-data-model-20220303/#issuance-date contains this note:

It is expected that the next version of this specification will add the validFrom property and will deprecate the issuanceDate property in favor of a new issued property. The range of values for both properties are expected to remain as [XMLSCHEMA11-2] combined date-time strings. Implementers are advised that the validFrom and issued properties are reserved and use for any other purpose is discouraged.

I believe this is moving us in the wrong direction - towards complexity and away from simplicity. Likewise, issue #913 , which in some ways is the dual of this issue, would also move us in the wrong direction - towards unnecessary complexity.

[awoie]

The ideal situation would be...

• deprecate issuanceDate since the semantical definition is a bit misleading.
• add issued that matches the iat JWT claim definition.
• add validFrom that matches the nbf JWT claim definition.

+1 for keeping a property that allows us to identify when a VC was issued.

I guess that was already anticipated in VC Data Model 1.1:

It is expected that the next version of this specification will add the validFrom property and will deprecate the issuanceDate property in favor of a new issued property. The range of values for both properties are expected to remain as [XMLSCHEMA11-2] combined date-time strings. Implementers are advised that the validFrom and issued properties are reserved and use for any other purpose is discouraged.

I'm happy to create a PR that makes those changes to the VC Data Model.

[OR13]

We should be careful to avoid standardizing "suite metadata" in the core data model... When a signature was applied (according to the issuer) might not belong in the core data model if we have better layering.

issuanceDate, today, is really the date the claims are meant to be valid... Not the date the credential was secured with JWT or Data Integrity... An issuer might want to signal both dates with clarity... In both representations.

[TallTed]

@selfissued, why create another issue (this, #918) for one side of the discussion already framed to be held in #913? I'm going to keep my responses there, and I strongly suggest that #918 be closed as a duplicate of #913.

[David-Chadwick]

What we need semanically is the cryptographic validity time of the VC, which is independent from the validity time of the underlying credential (claims). So 4 date/times are potentially needed. e.g. a degree claim is valid from the graduation date and does not expire. A UK driving license is valid from when the driver passes their driving test until the driver's age of 65. Multiple VCs with shorter cryptographic validity times could be issued during the claim lifetimes of both of these.
What we currently have is a bit of a mess.
We should define these 4 date/times and only make the 2 cryptographic ones mandatory, with the 2 claim ones being optional. The names of these 4 date/times is less important than clear semantic definitions of them.

[TallTed]

I mostly agree with @David-Chadwick's latest comment, which was duplicated in #918 and #913, because #918 is really a duplicate of #913, and #918 is only serving to dilute, split, and/or replicate the discussion.

I ask the chairs (tagging @brentzundel & @Sakurann) to make a determination of the duplication I assert, and I urge the chairs to close #918 in favor of #913, as #913 has substantially more discussion on the topic. (If the chairs prefer to raise this duplication as a question for the WG as a (participating) whole, I request that it be added to the agenda for August 31.)

[brentzundel]

It does seem to the chairs that This and #913 are duplicates.
I am closing this issue and encourage commenters to continue the conversation on #913.

[selfissued]

For what it's worth, it wasn't my intent to create a duplicate issue. I'd committed to Brent to file an issue on the topic and he encouraged me to do so. I tried to state the case for simplicity positively in the issue. I'm OK with continuing discussion in the other issue.