Describe SD-JWT as an alternative for selective disclosure #118

Sebastian-Elfors-IDnow · 2022-08-15T09:01:14Z

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 · 2022-08-15T22:07:30Z

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 · 2022-08-18T13:38:58Z

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 · 2022-08-24T15:20:37Z

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

Sakurann · 2022-08-25T18:36:56Z

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 · 2022-09-14T14:48:53Z

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 · 2022-09-16T18:52:15Z

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 · 2022-09-16T20:07:34Z

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 · 2022-09-16T20:57:37Z

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

Sebastian-Elfors-IDnow · 2022-09-16T20:58:51Z

Here's the latest IETF SD-JWT specification.

nadalin · 2022-09-17T00:59:09Z

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 Android<https://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-jose-cose#118) Here's the latest IETF SD-JWT specification<https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-00.html>. — Reply to this email directly, view it on GitHub<#118>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB4R4Y3MY2VLPFSX4GKVUCTV6TNRVANCNFSM56RSJPZA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

selfissued · 2022-09-22T04:35:08Z

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

Sebastian-Elfors-IDnow · 2022-09-22T06:39:36Z

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 · 2022-12-14T19:00:43Z

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 · 2022-12-15T15:11:46Z

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 · 2022-12-16T08:39:28Z

@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 · 2023-01-29T22:50:51Z

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 · 2023-04-04T15:48:42Z

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

iherman · 2023-04-04T16:10:52Z

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.

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 · 2023-06-08T09:07:48Z

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.

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 · 2023-06-26T20:51:51Z

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 · 2023-06-30T20:35:10Z

let's move this to vc-jwt given #114

selfissued · 2023-09-11T10:44:45Z

PR #149 addresses this

iherman · 2023-09-15T05:55:57Z

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.

Michael Jones: this issue will be closed when the PR is merged.

Sakurann · 2023-09-26T20:27:45Z

PR merged

iherman mentioned this issue Aug 24, 2022

Specify the draft Verifiable Credentials v2.0 context. w3c/vc-data-model#905

Merged

Sakurann self-assigned this Apr 4, 2023

Sakurann transferred this issue from w3c/vc-data-model Jun 30, 2023

Sakurann added the has-pr label Jun 30, 2023

selfissued added the before-CR label Sep 11, 2023

Sakurann closed this as completed Sep 26, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Describe SD-JWT as an alternative for selective disclosure #118

Describe SD-JWT as an alternative for selective disclosure #118

Sebastian-Elfors-IDnow commented Aug 15, 2022

Sakurann commented Aug 15, 2022 •

edited

Loading

Sebastian-Elfors-IDnow commented Aug 18, 2022 •

edited

Loading

mprorock commented Aug 24, 2022

Sakurann commented Aug 25, 2022

Sebastian-Elfors-IDnow commented Sep 14, 2022 •

edited

Loading

Sakurann commented Sep 16, 2022

Sebastian-Elfors-IDnow commented Sep 16, 2022 •

edited

Loading

decentralgabe commented Sep 16, 2022 •

edited

Loading

Sebastian-Elfors-IDnow commented Sep 16, 2022

nadalin commented Sep 17, 2022 via email

selfissued commented Sep 22, 2022

Sebastian-Elfors-IDnow commented Sep 22, 2022

selfissued commented Dec 14, 2022

David-Chadwick commented Dec 15, 2022

Sebastian-Elfors-IDnow commented Dec 16, 2022

David-Chadwick commented Jan 29, 2023

OR13 commented Apr 4, 2023

iherman commented Apr 4, 2023

1.13. Describe SD-JWT as an alternative for selective disclosure (issue vc-data-model#908)

iherman commented Jun 8, 2023

2.2. Describe SD-JWT as an alternative for selective disclosure (issue vc-data-model#908)

brentzundel commented Jun 26, 2023

Sakurann commented Jun 30, 2023

selfissued commented Sep 11, 2023

iherman commented Sep 15, 2023

6.7. Describe SD-JWT as an alternative for selective disclosure (issue vc-jose-cose#118)

Sakurann commented Sep 26, 2023

Describe SD-JWT as an alternative for selective disclosure #118

Describe SD-JWT as an alternative for selective disclosure #118

Comments

Sebastian-Elfors-IDnow commented Aug 15, 2022

Sakurann commented Aug 15, 2022 • edited Loading

Sebastian-Elfors-IDnow commented Aug 18, 2022 • edited Loading

mprorock commented Aug 24, 2022

Sakurann commented Aug 25, 2022

Sebastian-Elfors-IDnow commented Sep 14, 2022 • edited Loading

Sakurann commented Sep 16, 2022

Sebastian-Elfors-IDnow commented Sep 16, 2022 • edited Loading

decentralgabe commented Sep 16, 2022 • edited Loading

Sebastian-Elfors-IDnow commented Sep 16, 2022

nadalin commented Sep 17, 2022 via email

selfissued commented Sep 22, 2022

Sebastian-Elfors-IDnow commented Sep 22, 2022

selfissued commented Dec 14, 2022

David-Chadwick commented Dec 15, 2022

Sebastian-Elfors-IDnow commented Dec 16, 2022

David-Chadwick commented Jan 29, 2023

OR13 commented Apr 4, 2023

iherman commented Apr 4, 2023

1.13. Describe SD-JWT as an alternative for selective disclosure (issue vc-data-model#908)

iherman commented Jun 8, 2023

2.2. Describe SD-JWT as an alternative for selective disclosure (issue vc-data-model#908)

brentzundel commented Jun 26, 2023

Sakurann commented Jun 30, 2023

selfissued commented Sep 11, 2023

iherman commented Sep 15, 2023

6.7. Describe SD-JWT as an alternative for selective disclosure (issue vc-jose-cose#118)

Sakurann commented Sep 26, 2023

Sakurann commented Aug 15, 2022 •

edited

Loading

Sebastian-Elfors-IDnow commented Aug 18, 2022 •

edited

Loading

Sebastian-Elfors-IDnow commented Sep 14, 2022 •

edited

Loading

Sebastian-Elfors-IDnow commented Sep 16, 2022 •

edited

Loading

decentralgabe commented Sep 16, 2022 •

edited

Loading