clarify that vc vp claims do not include entire VC/VPs

[Sakurann]

vc and vp claims in the JWT encoding include only the properties such as @context, credentialSubject that do not have equivalent IANA registered JWT claims such as expirationDate, id, etc.

vc and vp claims do not include entire VC/VPs, which is not clear from the description below.

• vc: JSON object, which MUST be present in a JWT verifiable credential. The object contains the verifiable credential according to this specification.
• vp: JSON object, which MUST be present in a JWT verifiable presentation. The object contains the verifiable presentation according to this specification.

Suggest to clarify the description to something like following (happy to do a PR):

• vc: JSON object, which MUST be present in a JWT verifiable credential. The object contains the verifiable credential data model claims defined in this specification that do not have equivalent IANA registered JWT claims.
• vp: JSON object, which MUST be present in a JWT verifiable presentation. The object contains the verifiable presentation data model claims defined in this specification that do not have equivalent IANA registered JWT claims.

[David-Chadwick]

@Sakurann Unfortunately your initial assertion was not fully supported by the v1 specification, because the spec says "For backward compatibility with JWT processors, the following registered JWT claim names MUST be used instead of, or in addition to, their respective standard verifiable credential counterparts: " I initially tried to remove "in addition to" from v1.1 (which is effectively what you are suggesting) but eventually we decided against this for two reasons:
i) it was a normative change (so should be delayed until v2 of the spec) and
ii) some VC properties like the time/date stamps cannot losslessly map into equivalent JWT claims (due to leap seconds) so in this case both values may need to be kept.
We are proposing to produce a JWT Implementation Guidelines document to remove the ambiguities from the v1.1 spec so that v2 will have a better chance of being much clearer.

[OR13]

Agree with @David-Chadwick ... However, if this issue is targeted at v2, we can start to argue over breaking changes...

If we take the "instead of" path... We must define a lossy conversion process between the VC Data Model and JWT representations, and it must account for 100% of the VC Data Model features in v2.

If we take the "in addition too" path, we must define a non lossy conversion process and normative requirements for using the "in addition too" components....

I think "instead of" sets the wrong tone for what a VC is... its not a JWT... JWTs are not the source of truth for the data model... in fact, JWTs are just 1 possible serialization of the data model, and we might want to make better room for JWPs or ZKP-CL, or LD Proofs... without the awkwardness with ended with in v1.

If a proof format cannot represent the information an issuer wants to claim... we should not limit what an issuer can claim, we should be explicit about what you loose / gain by picking that proof format...

Today, at a minimum, you loose leap seconds and any JSON components of the issuer field of verifiable credential other than the id.

I would like to see VC Data Model 2.0 enable JWTs that have issuers that look as nice as LD Proofs... for example:

"issuer": {
    "id": "did:example:123", // instead of or in addition to applies here.
    "type": "Organization",
    "name": "Crona, Hane and Cassin",
    "description": "Realigned coherent budgetary management",
    "address": {
      "type": "PostalAddress",
      "streetAddress": "4001 Maye Meadow",
      "addressLocality": "Langworthland",
      "addressRegion": "Utah",
      "postalCode": "29089",
      "addressCountry": "Macao"
    },
    "email": "Einar79@example.com",
    "phoneNumber": "555-440-7944",
    "faxNumber": "555-618-5704"
  },

This would mean NOT taking the "instead of path"... it would mean taking the "in addition to" path.

Which every path we take, we better be as consistent as possible for all properties... But we can decide to handle dates with "instead of" and all other properties with "in addition too"...

I'm generally opposed to JWT representations that loose semantic information, and thats why we implemented the spec using the "in addition too" instead of "instead of"... also... by convention in JSON, any property not understood is ignored... so its safer to keep the data and ignore it, than try to translate or convert it.

[iherman]

The issue was discussed in a meeting on 2021-12-01

• no resolutions were taken

View the transcript

3.4. clarify that vc vp claims do not include entire VC/VPs (issue vc-data-model#845)

See github issue vc-data-model#845.

Brent Zundel: There's a question whether this is v2.0 which could take substantive changes or v1.1 to clarify editorially..

David Chadwick: Both Microsoft and myself implemented "instead of" and Orie implemented "as well as" -- Kristina wants the standard to support Microsoft way, and Orie and I agree that that's not the best thing to do always -- we need implementation guidance here..

Brent Zundel: She does suggest specific language -- the language she suggests is editorial -- is this v2.0 or v1.1?.

David Chadwick: It's definitely v2.0.
… That's a normative change -- it forbids as well as, it has to be v2.0.

[OR13]

short answer is that they do when you pick the in addition to... path.. which is what we recommend.

[TallTed]

[@OR13] short answer is that they do when you pick the in addition to... path.. which is what we recommend.

I think you're saying that "[vc vp claims] do [include entire VC/VPs] when you pick the in addition to... path,_" in response to the title, but I'm not sure, because there's a lot more text in this issue that "they" might refer back to.

[OR13]

@TallTed thats correct, I am addressing the title of this issue.

In this implementation: https://github.com/transmute-industries/verifiable-credentials

I chose the in addition to path, because it's legal according to v1.1 and it has the added benefit of keeping the vc and vp claims spec compliant without translation.

If you choose to implement the instead of path, you would need to transform these claims into "v1.1 compliant" data models after verification... and on the issuance side, from compliant data model into "intermediate non compliant" representations.

This is another reason why in addition to is simpler when compared to instead of.

[Sakurann]

since this is v2 and we are allowed to make breaking changes...

From the discussions, below seems to be an option that minimizes the need for mapping/transfrming between "vc-data-model" properties and existing registered JWT Claims while correctly uses existing registered JWT Claims enabling to reuse JWT libraries:

• exp JWT Claim is used for the expiration of a JWS signature, so not mapped to ValidUntil property in the "vc-data-model" (currently mapped to expirationDate)
• iss JWT Claim is used for the expiration of a JWS signature, so not mapped to ValidFrom property in the "vc-data-model" (currently not mapped to anything)
• vc JWT claim is an object that contains `
  • ValidFrom property of the "vc-data-model" (used to be mapped to nbf JWT Claim)
  • id property of the "vc-data-model" (used to be mapped to jti JWT Claim)
  • credentialSubject.id property of the "vc-data-model" (used to be mapped to sub JWT Claim)
  • the spec says that when vc JWT claim is present, nbf, id, sub JWT Claims MUST NOT be present
• aud JWT Claim definition is as in vc-data-model v1.1 not mapped to any property in the "vc-data-model"

(focusing on the JWT body claims since there are issues for each of the JOSE header claims (alg (#37), kid (#30) , typ (#5))

[OR13]

Under 1.1 rules, I think making the vc property a valid application/credential+ld+json is my preferred solution to this problem.

I am a strong -1 to "almost" application/credential+ld+json being legal in v2 for the vc property.

[Sakurann]

Under 1.1 rules, I think making the vc property a valid application/credential+ld+json is my preferred solution to this problem.

Ah, that's interesting. In that case, would you define "vc" property similar to what I propose above or as something different?

I am a strong -1 to "almost" application/credential+ld+json being legal in v2 for the vc property.

Not sure I understand. what is "almost" application/credential+ld+json..

[David-Chadwick]

@Sakurann I think you have some typos in your message about the JWT claims. Specifically

exp JWT Claim is used for the expiration of a JWS signature, so not mapped to ValidUntil property in the "vc-data-model" (currently mapped to expirationDate)
iat JWT Claim is used for the creation of a JWS signature, so not mapped to ValidFrom property in the "vc-data-model" (currently not mapped to anything)
vc is a JWT claim that contains a complete Credential (no modifications to it) - Note the JWT contains the proof to make it verifiable.
Similarly
vp is a JWT claim that contains a complete Presentation (no modifications to it).

[OR13]

Not sure I understand. what is "almost" application/credential+ld+json..

An object that is conformant except without any properties that can map to a JWT.... aka the "instead of path".

I am ok giving that content type a unique cty though, so it's clear to tell the difference between it and the "in addition to path" or a "hypothetically improved v2".

[OR13]

I'm going to mark this pending close, since AFAIK, its been overtaken in the latest draft, but I have filed #119

Which I think is a better place to follow up on managing v1 vs v2 compatibility.

[TallTed]

I have filed #119 Which I think is a better place to follow up on managing v1 vs v2 compatibility.

It seems to me that a better place to follow up on managing v1 vs v2 compatibility would be an issue with exactly that focus and title, rather than one asking whether to deprecate vc and vp...

[OR13]

#124

[OR13]

Marked pending close over 1 week ago, closing.