[JWT encoding] JWT claim names `instead of` or `in addition to` their verifiable credential counterparts

[Sakurann]

All JWT-VC examples under a tab named "Verifiable Credential (as JWT)" are not compliant to the Proof Formats section 6.3.
Each property has to get transformed into a JWT claim without being duplicated inside a JWT vc claim.

• issuanceDate -> nbf,
• issuer -> iss,
• credentialSubject.id -> sub,
• id -> jti. Need to change.

For example, Example 4 should be as below:

{
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "type": [
      "VerifiableCredential",
      "UniversityDegreeCredential"
    ],
    "credentialSubject": {
      "degree": {
        "type": "BachelorDegree",
        "name": "Bachelor of Science and Arts"
      }
    }
  },
  "iss": "https://example.edu/issuers/565049",
  "nbf": 1262304000,
  "jti": "http://example.edu/credentials/3732",
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}

This transformation rule might change in v2 but can we please change this in v1.1 because it is very misleading?

[msporny]

@Sakurann wrote:

Each property has to get transformed into a JWT claim without being duplicated inside a JWT vc claim.

Can you please provide the specification text that states the above?

One of the common misunderstandings of that section is missing the text that says "instead of or in addition to"... here's the full spec text:

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

While I disagreed with that particular wording at the time (I thought it should only be "in addition to"), because it would create interoperability issues, there was insistence to leave it in to allow the implementers to decide the best path forward. This is an issue that I hope the people doing JWT implementations fix in v2.0. My preference would be that we do the "in addition to" language so that we remove translation that must be done/undone when going to/from JWTs. The examples in the specification use the "in addition to" approach.

... but perhaps I'm missing something. @Sakurann, did you see the specific text I'm referring to above on your initial read? I'll admit that it's very easy to miss.

[Sakurann]

ok, I see what you mean, and I now recall the conversation in Issue #4. I agree that both, the examples in tab Verifiable Credential (as JWT) and those in the proof` section would be considered following the specification text as it is written in v1.1.

I think what caused confusion is that, probably because the JWT-encoded example using "JWT claim names instead of their verifiable credential counterparts" existed in the specification for longer, I was not aware of any JWT-VC implementations that use in addition to interpretation (obviously I do not claim to know all JWT-VC implementations out there),

Guess a discussion point for V2 :) thanks for clarifying!

[TallTed]

Perhaps the title should instead be —

Should VCDM2 mandate that JWT claim names be used { instead of | in addition to | instead of or in addition to } their verifiable credential counterparts?

My opinion is that in most cases, it should be in addition to, but there was specific argument against only that, and I and others had arguments against strict instead of, so we settled on the imperfect and variously objectionable instead of or in addition to for VCDM1.

[David-Chadwick]

This is an issue that I would like to see resolved as quickly as possible because we will soon be starting conformance testing for the NGI Atlantic project, and we would like to produce JWTs and tests that conform to the v2 data model.

My preferred approach is that for property values that can be directly copied from credential properties into JWT claims, we mandate instead of (i.e. no duplication) and for property values that cannot be directly copied (currently all the time/date properties) we mandate in addition to.

[TallTed]

My preferred approach is that for property values that can be directly copied from credential properties into JWT claims, we mandate instead of (i.e. no duplication) and for property values that cannot be directly copied (currently all the time/date properties) we mandate in addition to.

The major argument I see against this is its inherent complexity for users and developers. "Is this property one that I MUST or MUST NOT duplicate?" Requiring duplication in all cases is the only way I see to avoid this confusion. (Forbidding duplication in all cases has other arguments against it, including but not limited to the fact that some values cannot be directly copied.)

[msporny]

This issue needs to be moved to the vc-jwt spec.

[msporny]

The major argument I see against this (modifying the original VC) is its inherent complexity for users and developers.

+1 -- I'll note that the "instead of" proposal transforms the VC into a non-conformant VC when paired with JWTs (removal of mandatory "issuer" field, for one... "issuanceDate" is another example).

[David-Chadwick]

I can live with duplication. The problem I then see is if the "duplicates" are different, which one takes precedent? I too would not agree with replacement everytime.

Concerning the non-conformance issue regarding removal of values, I have already raised an issue on this wrt selective disclosure.

[TallTed]

The problem I then see is if the "duplicates" are different, which one takes precedent?

This would seem to be addressable by specifying that conforming implementations MUST set both/all "duplicates" to the same value. Yes, non-conforming implementations (including humans) could violate this, but the next conforming tool in the stack should fire an error, so it shouldn't last long.

[OR13]

Seems related to w3c/vc-data-model#844