Describe SD-JWT as an alternative for selective disclosure

[Sebastian-Elfors-IDnow]

The descriptions about selective disclosure in the W3C Verifiable Credentials specification could be extended by mentioning SD-JWT (Selective Disclosure JWT).

The SD-JWT specification is currently an IETF Internet-Draft, which specifies the SD-JWT as a signed JWT with salted/hashed values of a list of claims. The SD-JWT draft also specifies SD-JWT Salt/Value Container (SVC) that contains mappings between raw claim values contained in the SD-JWT and the salts for each claim value. It also specifies the SD-JWT-R, which is a JWT created by the holder that contains a subset of the claim values the holder wants to release during presentment.

The approach with SD-JWT is similar to the MSO object in the ISO 18013-5 (mobile driving license). SD-JWTs can be presented both online and offline.

There is an example of a SD-JWT as a W3C Verifiable Credential in an appendix of the specification.

[Sakurann]

Thanks for the issue, Sebastian!

Multiple options have been explored how to define SD-JWT-VC. Inputs from this group will be appreciated!

Option 1 (current spec text):

{
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "jti": "http://example.edu/credentials/3732",
  "iss": "https://example.com/keys/foo.jwk",
  "nbf": 1541493724,
  "iat": 1541493724,
  "exp": 1573029723,
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "type": [
      "VerifiableCredential",
      "UniversityDegreeCredential"
    ],
   "credentialSubject": {...}
  },
  "sd_digests": {
    "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",
    "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",
    "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ"
  }
}

Option 2 (Issue 110 in SD JWT-repo)

{
      "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "jti": "http://example.edu/credentials/3732",
      "iss": "https://example.com/keys/foo.jwk",
      "nbf": 1541493724,
      "iat": 1541493724,
      "exp": 1573029723,
     "vc": {
       "@context": [
         "https://www.w3.org/2018/credentials/v1",
         "https://www.w3.org/2018/credentials/examples/v1"
       ],
       "type": [
         "VerifiableCredential",
         "UniversityDegreeCredential"
       ],
     "credentialSubject": {
      "given_name": "Alice",
      "sd_digests": {
         "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",
         "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",
         "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ"
        }
     }
  }
}

Option 3 (Issue Comment on Issue 110):

{
    "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "jti": "http://example.edu/credentials/3732",
    "iss": "https://example.com/keys/foo.jwk",
    "nbf": 1541493724,
    "iat": 1541493724,
    "exp": 1573029723,
     "vc": {
       "@context": [
         "https://www.w3.org/2018/credentials/v1",
         "https://www.w3.org/2018/credentials/examples/v1"
       ],
       "type": [
         "VerifiableCredential",
         "UniversityDegreeCredential"
       ],
       "credentialSubject": {claims}
     },
     "sd_digests": {
       "vc": {
           "credentialSubject": {
                 "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",
                 "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",
                 "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ"
             }
        }
     }
   }
}

	Pros	Cons
Option 1	Extensible / Compliant to the current spec (sd_digest as a top level JWT claim)	Verifier needs to combine two objects from different places to get all of the user claims
Option 2	all user claims under claimsSubject property	might not be compatible with core SD-JWT spec (sd_digest not a top level JWT claim) (spec changeable)
Option 3	easier processing because can combine all use claims under vc claim when processing	might not be compatible with core SD-JWT spec (same reasons as above)

[Sebastian-Elfors-IDnow]

Thanks for your feedback, Kristina!

Option 1 makes most sense in my view, since it is compatible with the JWT format according to the existing SD-JWT draft standard.

Combining two objects (SD-JWT and SD-JWT-R) should not be an issue, since that is common practice for W3C Verifiable Presentation with multiple W3C VCs.

The SD-JWT-R could be formatted as a W3C VP with the custom type "SelectiveDisclosureRelease", which indicates that the "sd_release" element with released claims and salted hashes must be present.

Proposed example of SD-JWT-R-VC:

{
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "jti": "http://example.edu/credentials/3732",
  "iss": "https://example.com/keys/foo.jwk",
  "nbf": 1541493724,
  "iat": 1541493724,
  "exp": 1573029723,
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "type": [
      "VerifiableCredential",
      "SelectiveDisclosureRelease"
    ]
  },
 "sd_release": {
    "given_name": "[\"eluV5Og3gSNII8EYnsxA_A\", \"John\"]",
    "family_name": "[\"6Ij7tM-a5iVPGboS5tmvVA\", \"Doe\"]",
    "address": "[\"AJx-095VPrpTtN4QMOqROA\", {\"street_address\": \"123 Main St\", \"locality\": \"Anytown\", \"region\": \"Anystate\", \"country\": \"US\"}]"
  }
}

The SD-JWT-VC/SD-JWT-R-VC approach would also fit nicely with the DIF Presentation Exchange formats, where the Presentation Request could specify the claims to be released, and the Presentation Submission could be a Verifiable Presentation with a combination of the Verifiable Credentials SD-JWT-VC and the SD-JWT-R-VC.

The DIF Presentation Exchange formats for SD-JWT-VC/SD-JWT-R-VC could in turn be used to specify new parameters/profiles for the WACI-DIDcomm Presentation Exchange and/or OIDC4VP protocols.

The SD-JWT-VC/SD-JWT-R-VC parameters for WACI-DIDcomm and/or OIDC4VP could instruct the wallet (client) to generate a VP with combined SD-JWT-VC/SD-JWT-R-VC and instruct the relying party (verifier) to verify the salted hashes in the SD-JWT-VC with the claims and salts in the SD-JWT-R-VC.

[mprorock]

Is this possibly a better topic for the Implementation Guide or VC-JWT?

[Sakurann]

Depends on where we decide transformation of the data model prior to “securing” it sits - in each “securing” document or data model itself

[Sebastian-Elfors-IDnow]

Here are some comments on the options above.

Option 1:

The SD-JWT example has been changed from the option 1 example above to this example in the latest IETF SD-JWT draft:

{
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "jti": "http://example.edu/credentials/3732",
  "iss": "https://example.com/keys/foo.jwk",
  "nbf": 1541493724,
  "iat": 1541493724,
  "exp": 1573029723,
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "type": [
      "VerifiableCredential",
      "UniversityDegreeCredential"
    ]
  },
  "sd_digests": {
    "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",
    "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",
    "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ"
  }
}

The difference is that the credentialSubject has been removed:

"credentialSubject": {...}

This change is important, since the SD-JWT only contains the sd_digests (and no claims in clear text), which should be the case.

Option 2:

The example in option 2 above only contains one claim in clear text ("givenName"), but three sd_digests ("givenName", "familyName" and "birthdate"):

     "credentialSubject": {
      "given_name": "Alice",
      "sd_digests": {
         "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",
         "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",
         "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ"
        }

This gives the impression that it is the SD-JWT-R or a short-lived VC that has been produced to create the SD-JWT-R. The example may be updated to reflect that all claims should be in the SD-JWT-VC.

Option 3:

Option 3 is probably the best alternative. It may however be clarified that the SD-JWT JSON object would need its own proof, so it can be parsed out from the SD-JWT-VC without breaking the signature. The example in option 3 could be updated with such proof.

{
    "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "jti": "http://example.edu/credentials/3732",
    "iss": "https://example.com/keys/foo.jwk",
    "nbf": 1541493724,
    "iat": 1541493724,
    "exp": 1573029723,
     "vc": {
       "@context": [
         "https://www.w3.org/2018/credentials/v1",
         "https://www.w3.org/2018/credentials/examples/v1"
       ],
       "type": [
         "VerifiableCredential",
         "UniversityDegreeCredential"
       ],
       "credentialSubject": {claims}
     },
     "sd_digests": {
       "vc": {
           "credentialSubject": {
                 "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",
                 "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",
                 "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ"
             }
            // Proof of the SD-JWT digests
            "proof": {...}
        }
        // Proof of entire SD-JWT-VC 
        "proof": {...}
     }
   }
}

With a separate proof of the SD-JWT sd_digests, this JWT can be parsed out and be used with the SD-JWT-R VP without breaking the signature. The claims in the "credentialSubject" can however be parsed out one by one when creating the SD-JWT-R VP, since the sd_digests proof will cater for each claim's integrity.

Tbd: Can JWT with JOSE be used if the SD-JWT will be signed with a separate proof, or would LD-Signature be needed?

The top claim "sd_digest" claim would also be need to be added to the "JSON Web Token Claims Registry" for registration with IANA, I assume.

Potential edits to the VC Data Model v2.0:

The VC Data Model v2.0 section "5.8 Zero-Knowledge Proofs" could be updated with one more bullet, which may briefly describe the concept of SD-JWT with salted hashes of the claims, and how to release selected claims in a SD-JWT-R. This bullet description may refer to the SD-JWT-VC format, which may be specified in the "Verifiable Credentials JSON Web Token specification".

[Sakurann]

This change is important, since the SD-JWT only contains the sd_digests (and no claims in clear text), which should be the case.

I believe SD-JWT can contain claims in credentialSubject with the difference being claims in credentialSubject are not selectively disclosable, while claims in sd_digests are selectively disclosable.

Option 3 is probably the best alternative.

I personally think Option 3 is the best balance of processing ease and no changes to vc-data-model and sd-wt specs

[Sebastian-Elfors-IDnow]

Thanks for clarifying, Kristina.

So to be clear, the "credentialSubject": {claims} in option 3 are other claims than the claims+salts in the SVC.

As regards to section 5.8 in the W3C VC Data Model 2.0, it could be renamed to "Selective Disclosure", since that will allow for more technologies than ZKP. The ZKP schemes (BBS+, AnonCreds, etc) could be one of the options in the bullet list, SD-JWT could be a second option, atomic VCs a third, etc.

[decentralgabe]

@Sebastian-Elfors-IDnow the links in your original post are broken, are there updated links?

[Sebastian-Elfors-IDnow]

Here's the latest IETF SD-JWT specification.

[nadalin]

Thank you for presenting aw this make a lot of sense as it reduces complexity in C14N and in algorithms, very simple solution for JWT usage.

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: Sebastian Elfors (IDnow) @.> Sent: Friday, September 16, 2022 1:59:06 PM To: w3c/vc-data-model @.> Cc: Subscribed @.***> Subject: Re: [w3c/vc-data-model] Describe SD-JWT as an alternative for selective disclosure (Issue w3c/vc-jwt#118)

Here's the latest IETF SD-JWT specificationhttps://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-00.html.

— Reply to this email directly, view it on GitHubhttps://github.com/w3c/vc-jwt/issues/118, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB4R4Y3MY2VLPFSX4GKVUCTV6TNRVANCNFSM56RSJPZA. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[selfissued]

I don't understand "credentialSubject": {claims} in Option 3. What is it shorthand for?

[Sebastian-Elfors-IDnow]

I don't understand "credentialSubject": {claims} in Option 3. What is it shorthand for?

Hi Mike,

The credentialSubject property is mandatory according to the VC Data Model, so it has to be present. The "{claims}" may contain the user's DID or other data that is anonymized or acceptable by the user to share at any time. If possible, we could leave the {claims} empty or nullified.

The rest of the user's claims and related salts are stored in the SD-JWT Salt/Value Container (SVC), which is a separate JSON object. The corresponding hashes of the SVC claims+salts are the ones that are shown in the VC option 3 example.

     "sd_digests": {
       "vc": {
           "credentialSubject": {
                 "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",
                 "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",
                 "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ"
             }

When creating a VP of this, it can contain the VC credentialSubject along with the selected SVC claims+salts and the VC hashes.

Hope this clarifies.

[selfissued]

I'll note that the SD-JWT spec includes an appendix that proposes a VC representation for SD-JWTs. See https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-02.html#name-example-4-w3c-verifiable-cr .

[David-Chadwick]

The problem with the currrent IETF draft is that it does not start with a valid VC, but instead has its own IdentityCredential type of object. If the IETF draft wants to model a W3C VC then it should use a valid one to start with.

My next question, is how does SD-JWT model properties such as credentialSubject.address.streetName or any other multi-level JSON object that is a claim?

[Sebastian-Elfors-IDnow]

@David-Chadwick: In the latest IETF draft on SD-JWT, the section "A.4. Example 4 - W3C Verifiable Credentials Data Model (work in progress)" will describe how SD-JWT may be applied for the W3C VC data model.

@Sakurann, do you have any news from the IETF working group on how SD-JWT could be formatted as W3C VC and the object properties? (See the questions from @David-Chadwick above.) Thanks!

[David-Chadwick]

I have created a new issue w3c/vc-data-model#1019 related to this one, because I think most of this discussion is now out of date due to the evolution of the SD-JWT draft e.g. property names are now protected. Furthermore the IETF is not the correct place to say how W3C VCs are selectively disclosed using SD-JWT since the examples do not include @context and are therefore non-conformant to the W3C VC DM. Rather I think it should be in the remit of this WG to specify how SD-JWT is used to protect a credential.

[OR13]

I think we can perhaps move this to https://github.com/w3c/vc-jwt ?

[iherman]

The issue was discussed in a meeting on 2023-04-04

• no resolutions were taken

View the transcript

#### 1.13. Describe SD-JWT as an alternative for selective disclosure (issue vc-data-model#908) _See github issue [vc-data-model#908](https://github.com/w3c/vc-jwt/issues/118)._ **Kristina Yasuda:** About SD-JWT. Some back and forth between me and Sebastian.. … Anyone willing to be assigned to this one?. **Brent Zundel:** Since David has opened another issue, should we just close this issue?. **David Chadwick:** I think this should be closed, because this is stale. The later issue is more up-to-date. We should close and refer.. **Brent Zundel:** In general it would be best practice to change the title of an existing issue to reflect the state of a conversation, instead of creating a new separate issue.. **Kristina Yasuda:** I don't think this is stale. Last comment was in January.. … Assigning both issues to me..

[iherman]

The issue was discussed in a meeting on 2023-06-07

• no resolutions were taken

View the transcript

#### 2.2. Describe SD-JWT as an alternative for selective disclosure (issue vc-data-model#908) _See github issue [vc-data-model#908](https://github.com/w3c/vc-jwt/issues/118)._ > *David Chadwick:* Please add a reference to Oliver's proposed work item. **Brent Zundel:** Issue raised by Sebastian, current assigned to Kristina. Is this work that should be done before we go into CR? > *Orie Steele:* Suggest this issue be closed, that work is happening in other working groups. **Joe Andrieu:** since the W3C isn't doing this work, we should move this into the directory of related work and mark pending close. **Brent Zundel:** Going to mark issue pending close. **Joe Andrieu:** Someone has to move it, right. Have to capture that task. > *Orie Steele:* nobody needs to add it though... people can list their work there... if they want to. > *Joe Andrieu:* agreed, Orie. Just seemed like the right resolution of the issue.

[brentzundel]

I believe the intention of the last conversation we had in the WG was that this issue be marked pending close We will close it in 7 days if there are no objections.

[Sakurann]

let's move this to vc-jwt given https://github.com/w3c/vc-jwt/pull/114

[selfissued]

PR #149 addresses this

[iherman]

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

• no resolutions were taken

View the transcript

#### 6.7. Describe SD-JWT as an alternative for selective disclosure (issue vc-jose-cose#118) _See github issue [vc-jose-cose#118](https://github.com/w3c/vc-jose-cose/issues/118)._ **Michael Jones:** this issue will be closed when the PR is merged.

[Sakurann]

PR merged