Add sd-jwt example

[OR13]

---

Preview | Diff

[mprorock]

We should explicitly note that this is a work in progress draft that may change.

Very useful example though

[OR13]

@mprorock I applied your suggestions, please re-review.

[andresuribe87]

I found this title rather confusing.

Perhaps we could rename it?

My understanding is that it's a VC that is derived from an SD-JWT.

Suggested change

	<h3>Selective Disclosure</h3>
	<h3>Credential derived from SD-JWT</h3>

[OR13]

@Sakurann @bc-pi since I pulled the example from your draft, can you comment on the title of the section that references your example?

[OR13]

@andresuribe87 I've added additional context, based on the other PR feedback we received, perhaps its clearer now? in the case that you feel it is not, is your suggestion here blocking?

[andresuribe87]

Yeah much clearer now. Thanks @OR13 !

[Sakurann]

The example does not contain _sd claims, it's not taken from SD-JWT, what's the purpose?

[bc-pi]

Somewhat naively I would have expected an "sd-jwt example" to be an example showing the SD-JWT mechanisms applied to some VCDM conforming JSON. Or something like that. But other than a stray_sd_alg in the JSON, there's nothing SD-JWT or even generally selective disclosure related in here. To echo @Sakurann's question - what's the purpose?

[OR13]

@Sakurann @bc-pi The goal here is to convey that this W3C work item recognizes that your IETF draft can secure vc+ld+json... I don't see the need to provide much more than what I have in the PR to satisfy this goal initially.

However, I can add a complete example of all the SD-JWT bits that are not vc+ld+json... if that is what is being requested.

[OR13]

For reference, here is where the example was taken from: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-04#name-example-4b-w3c-verifiable-c

{
  "@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",
      "medicinalProductName": "COVID-19 Vaccine Moderna",
      "atcCode": "J07BX03"
    },
    "recipient": {
      "type": "VaccineRecipient"
    },
    "type": "VaccinationEvent",
    "order": "3/3",
    "dateOfVaccination": "2021-06-23T13:40:12Z"
  },
  "_sd_alg": "sha-256",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  }
}

[Sakurann]

That is input claim set before all the sd-jwt processing is applied, the actual sd-jwt payload is the example after the one you used, with an _sd claim.

https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-05.html#appendix-A.4-7

[OR13]

@Sakurann hmm, I don't want to comment on "input" and "mapping"... I just want to say that the verifier ends with something that can be processed as vc+ld+json... like they can for vc+ld+jwt today.

I'm ok adding more examples that are not vc+ld+json, but I think its cleaner to just add an example of vc+ld+json that is produced by applying SD-JWT, and direct readers to the spec for the details.

From the section you referenced above:

This is identical to how "after the validation" for "vc+ld+jwt", the verifier has a JSON (LD) payload that can be further processed.

[bc-pi]

I just want to say that the verifier ends with something that can be processed as vc+ld+json... like they can for vc+ld+jwt today.

Maybe just say that in text and link to https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-05.html#appendix-A.4 for readers that want to see an example?

[OR13]

@bc-pi are you requesting that no JSON-LD example of the final SD-JWT validated / verified form be included in this spec?

Is this a blocking change request?

[bc-pi]

@OR13 it was not meant to be adversarial or blocking. I think that an JSON-LD example of the final SD-JWT form on its own without context or explanation isn't particularly useful (and maybe confusing to some). Stating what you said previously here, that verifier ends up with something after consuming the SD-JWT that can be processed as vc+ld+json is helpful and should probably be in this PR. Beyond that I was suggesting that maybe rather than pulling in parts of https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-05.html#appendix-A.4 you could just reference it or link to it.

[OR13]

@bc-pi

I think that an JSON-LD example of the final SD-JWT form on its own without context or explanation isn't particularly useful (and maybe confusing to some).

Yes, I agree with this, but I chose the simple PR first, because its easier to add then it is to remove.

I am trying to understand what changes to apply, which is why I ask if its blocking... @Sakurann has requested changes, but not clarified, so I cannot implement her feedback.

Stating what you said previously here, that verifier ends up with something after consuming the SD-JWT that can be processed as vc+ld+json is helpful and should probably be in this PR.

@Sakurann ^ If I implement these changes, will you approve? Can you clarify what changes you would like to see.

Beyond that I was suggesting that maybe rather than pulling in parts of https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-05.html#appendix-A.4 you could just reference it or link to it.

I am already referencing it, I think it's better to reference it and copy the example, so that readers are not required to navigate in order to see an example.

[Sakurann]

Sorry it was not clear what changes I was requesting. I would suggest either a) directly put the URL to the JSON-LD example in the SD-JWT spec with some explanation text, but without copying any payload example, or b) copying the payload of the Issuer-Signed JWT with _sd array (to illustrate what is the out put after sd-jwt processing is applied to vc+ld+jwt input claimset) and add that "this results in a valid vc+ld+jwt payload, for details see ". I agree that copying input claimset (pretty much vc+ld+jwt as-is) does not illustrate anything specific to sd-jwt and can be confusing.

[OR13]

@Sakurann thanks, I will take path B.

I think it's important for folks to understand that the verification process for both vc+ld+jwt and vc+ld+sd-jwt produce vc+ld+json claimset , which can be processed further, in a consistent way, regardless of which securing mechanism was used.

In the case of vc+ld+sd-jwt, and unlike vc+ld+jwt, the verified payload is different from the secured payload, I agree the current example is therefore confusing.

As an aside, related to the sentence above, you can't refer to the cty of vc+ld+sd-jwt as vc+ld+json, but you can when referring to vc+ld+jwt.

I think its very important that sd-jwt follow the JWT BCP, and use typ to reduce this confusion.

[OR13]

Maybe cty can be used... but I suspect that will be more confusing than not using it.

[Sakurann]

If approach analogous to what was taken for vc+sd-jwt is to be taken, only vc+ld+sd-jwt would be sufficient. And the only difference from the current approach of having two media types will be that even when there is no selective disclosure, there is a ~ in the end of a JWS, but after that ~ is removed, usual JWT libraries can be used.

[OR13]

@Sakurann @bc-pi I tried to implement your feedback.

I copied several examples from the section on conformance to W3C Verifiable Credentials in JSON-LD, and I added text that can be aligned with the term definitions of the core data model, for example regarding issuer, holder and verifier.

Please let me know if there are any further change requests, what you would like to see.