Clarify relationship between validity times

[David-Chadwick]

The VCDMv2 has validFrom and validUntil properties to define the validity period of the verifiable credential.
JWT has nbf and exp to describe the validity period of the JWT.
The relationship between these two validity periods is not clearly specified in the current draft, or is specified wrongly.
Section 2.1 uses "issuanceDate" instead of "validFrom". It also uses iat instead of nbf. Furthermore it does not provide any rules for the conversion between the two, which can be problematical due to leap seconds etc.
Section 3 provides no guidance of how to convert the JWT claim set into a valid VCDMv2 document

[OR13]

This is blocked by #88 we can't provide clarity on this, until thats merged.

[OR13]

As a general principle, using registered claim names in JWT or SD-JWT allows off the shelf libraries to be used to issue and verify.

There as been consistent confusion regarding the core data model and JOSE / COSE.

I will summarize here one more time:

• issuanceDate (VCDMv1) / notBefore (x509) / nbf (VCDMv1) / validFrom (VCDMv2)
• expirationDate (VCDMv1) / notAfter (x509) / exp (VCDMv1) / validUntil (VCDMv2)
• proof.created (VCDMv1) / ??? (x509) / iat (VCDMv1) / ( proof.created || iat) (VCDMv2)

We don't plan to describe how to do "mappings" for anything in this specification after #88 is merged.

This will leave the default behavior consistent with existing processors, and the core data model business validation out of scope... where it belongs.

[TallTed]

I think a table like this is clearer than @OR13's presentation above, though I'm confused about the two columns for VCDMv1. I've changed the third column title from VCDMv1 to JWT, for hopefully obvious reasons.

VCDMv1	X.509	JWT	VCDMv2
issuanceDate	notBefore	nbf	validFrom
expirationDate	notAfter	exp	validUntil
proof.created	???	iat	proof.created OR iat

[OR13]

@TallTed the 2 columns for vcdm v1 correspond to the problem with that spec.. that it required mappings... 100% of the time.

So you always had 2 representations... and then you optionally deleted the "core data model ones"... which would have been "issuanceDate" or "expirationDate"... the "proof.created" was never even acknowledged... in general I feel VCDM v1 was not implementable using JWTs....

This caused the RDF for JWT representations to be totally broken / useless.

We fixed this in v2 (assuming #88 is merged).

You will now get a full payload is is valid vc+ld+json... but you might also see other claims the issuer added, or their library added... for example:

{
    "_sd_alg": "sha-256",
    "iss": "https://example.com/issuer",
    "iat": 1683000000,
    "exp": 1883000000,
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://w3id.org/vaccination/v1"
    ],
    "type": [
      "VerifiableCredential",
      "VaccinationCertificate"
    ],
    "issuer": "https://example.com/issuer",
    "issuanceDate": "2023-02-09T11:01:59Z",
    "expirationDate": "2028-02-08T11:01:59Z",
    "name": "COVID-19 Vaccination Certificate",
    "description": "COVID-19 Vaccination Certificate",
    "credentialSubject": {
      "vaccine": {
        "type": "Vaccine",
        "atcCode": "J07BX03",
        "medicinalProductName": "COVID-19 Vaccine Moderna"
      },
      "recipient": {
        "type": "VaccineRecipient"
      },
      "type": "VaccinationEvent",
      "order": "3/3",
      "dateOfVaccination": "2021-06-23T13:40:12Z"
    },
  "proof": [{
   "type": "DataIntegrityProof",
   "cryptosuite": "eddsa-2022",
   "created": "2020-11-05T19:23:24Z",
   "verificationMethod": "https://ldi.example/issuer/1#z6MkjLrk3gKS2nnkeWcmcxiZPGskmesDpuwRBorgHxUXfxnG",
   "proofPurpose": "assertionMethod",
   "proofValue": "z4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYVQeVbY8nQAVHMrXFkXJpmEcqdoDwLWxaqA3Q1geV6"
 }, {
   "type": "DataIntegrityProof",
   "cryptosuite": "eddsa-2022",
   "created": "2020-11-05T13:08:49Z",
   "verificationMethod": "https://pfps.example/issuer/2#z6MkGskxnGjLrk3gKS2mesDpuwRBokeWcmrgHxUXfnncxiZP",
   "proofPurpose": "assertionMethod",
   "proofValue": "z5QLBrp19KiWXerb8ByPnAZ9wujVFN8PDsxxXeMoyvDqhZ6Qnzr5CG9876zNht8BpStWi8H2Mi7XCY3inbLrZrm95"
 }]
  }

In these cases you will get an interesting RDF graph, with lots of potentially conflicting time and security information... but at least the graph is valid... and the terms are defined as best as we can do.

[TallTed]

[@OR13] payload is is valid vc+ld+json

No. The payload is valid application/vc+ld+json. There is no such thing as vc+ld+json.

That value is only seen in the JWT typ, where (IMNSHO) they foolishly advise omission of the application/ part of the media type, while all tools and users are advised to act as if it were present. As demonstrated by your consistent abbreviation everywhere, where there is no such "act as if it were present" advice, this abbreviation is problematic.

---

I've changed the second VCDMv1 column title to JWT for hopefully obvious reasons. Each claim there is now linked to its description in RFC7519. It would be clever to link all the other properties in that table to their description in the relevant spec. Perhaps I'll do that later.

[OR13]

Here you go:

VCDMv1	X.509	VCDMv1 (typ: JWT)	VCDMv2 (typ: vc+ld+json+jwt)	VCDMv2 (cty: vc+ld+json)
issuanceDate	notBefore	nbf	nbf	validFrom
expirationDate	notAfter	exp	exp	validUntil
proof.created	???	iat	iat	(optional proof.created)

A note on optionality... I think all the datetime formats are optional in v2... thats a recent change.

[David-Chadwick]

This is getting clearer now. It will be good to see the final text to see if the clarity remains :-)

[Sakurann]

I think validfrom/validuntil in vcdm and iat/exp in vc-jose-cose have different meaning - please review the PR.

[iherman]

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

• no resolutions were taken

View the transcript

6.15. Clarify relationship between validity times (issue vc-jose-cose#133)

See github issue vc-jose-cose#133.

Brent Zundel: matching PR has been merged. this issue can be closed.

Joe Andrieu: validation section references VCDM.
� , correct?

Michael Jones: yes.