SD-JWT-based Verifiable Credentials with JSON payloads (SD-JWT VC)

1.1. Three-Party-Model

In the so-called Three-Party-Model, Issuers issue Verifiable Credentials to a Holder, who can then present the Verifiable Credentials to Verifiers. Verifiable Credentials are tamper-evident (usually cryptographically signed) statements about a Subject, typically the Holder.¶

         +------------+
         |            |
         |   Issuer   |
         |            |
         +------------+
               |
    Issues Verifiable Credential
               |
               v
         +------------+
         |            |
         |   Holder   |
         |            |
         +------------+
               |
  Presents Verifiable Credential
               |
               v
         +-------------+
         |             |+                                  +------------+
         |  Verifiers  ||+                                 |   Status   |
         |             |||---------- optionally ---------->|  Provider  |
         +-------------+||        retrieve status of       |            |
          +-------------+|       Verifiable Credential     +------------+
           +-------------+

Verifiers can check the authenticity of the data in the Verifiable Credentials and optionally enforce Holder Binding, i.e., ask the Holder to prove that they are the intended holder of the Verifiable Credential, for example, by proving possession of a cryptographic key referenced in the credential. This process is further described in [I-D.ietf-oauth-selective-disclosure-jwt].¶

To support revocation of Verifiable Credentials, an optional fourth party can be involved, a Status Provider, who delivers revocation information to Verifiers. (The Verifier can also serve as the Status Provider.)¶

The three-party-model, i.e., actors, Verifiable Credentials, is also described in [VC-DATA]. This specification defines Verifiable Credentials based on the SD-JWT format and JWT Claim Sets with JSON payloads. A translation algorithm between the two approaches is provided in this specification.¶

1.2. Rationale

JSON Web Tokens (JWTs) [RFC7519] can in principle be used to express Verifiable Credentials in a way that is easy to understand and process as it builds upon established web primitives. However, JWT-based credentials do not support selective disclosure, i.e., the ability for a Holder to disclose only a subset of the claims contained in the JWT, which is a requirement to implement the three-party-model efficiently.¶

Selective Disclosure JWT (SD-JWT) [I-D.ietf-oauth-selective-disclosure-jwt] is a specification that introduces conventions to support selective disclosure for JWTs: For an SD-JWT document, a Holder can decide which claims to release (within bounds defined by the Issuer). This format is therefore perfectly suited for Verifiable Credentials.¶

SD-JWT itself does not define the claims that must be used within the payload or their semantics. This specification therefore defines how Verifiable Credentials can be expressed using SD-JWT.¶

JWTs (and SD-JWTs) can contain claims that are registered in "JSON Web Token Claims" registry as defined in [RFC7519], as well as public and private claims. Private claims are not relevant for this specification due to the openness of the three-party-model. Since SD-JWTs are based on JWTs, this specification aims to express the basic Verifiable Credential data model purely through JWT Claim Sets, using registered claims while allowing Issuers to use additional registered claims, as well as new or existing public claims, to make statements about the Subject of the Verifiable Credential.¶

1.3. Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶

1.4. Terms and Definitions

This specification uses the terms "Holder", "Issuer", "Verifier", defined by [I-D.ietf-oauth-selective-disclosure-jwt], Verifiable Credential defined by [VC-DATA].¶

SD-JWT-based Verifiable Credential (SD-JWT VC):

A Verifiable Credential encoded using the Issuance format defined in [I-D.ietf-oauth-selective-disclosure-jwt].¶

Unsecured payload of an SD-JWT VC:

A JSON object containing all selectively disclosable and non-selectively disclosable claims of the SD-JWT VC. The unsecured payload acts as the input JSON object to issue an SD-JWT VC complying to this specification.¶

Status Provider:

An entity that provides status information (e.g. revocation) about a Verifiable Credential.¶

4.1. Media Type

SD-JWT VCs compliant with this specification MUST use the media type application/vc+sd-jwt as defined in Appendix A.2.1.¶

4.2. Data Format

SD-JWT VCs MUST be encoded using the SD-JWT Combined Format for Issuance as defined in Section 5.3. of [I-D.ietf-oauth-selective-disclosure-jwt].¶

SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per Section 5.1.1.3. of [I-D.ietf-oauth-selective-disclosure-jwt].¶

{
  "alg": "ES256",
  "typ": "vc+sd-jwt"
}

{
  "type": "SomeType"
}

4.3. Example

The following is a non-normative example of an unsecured payload of an SD-JWT VC.¶

{
  "type": "IdentityCredential",
  "given_name": "John",
  "family_name": "Doe",
  "email": "johndoe@example.com",
  "phone_number": "+1-202-555-0101",
  "address": {
    "street_address": "123 Main St",
    "locality": "Anytown",
    "region": "Anystate",
    "country": "US"
  },
  "birthdate": "1940-01-01",
  "is_over_18": true,
  "is_over_21": true,
  "is_over_65": true
}

The following is a non-normative example of how the unsecured payload of the SD-JWT VC above can be used in a SD-JWT where the resulting SD-JWT VC contains only claims about the Subject that are selectively disclosable:¶

{
  "_sd": [
    "09vKrJMOlyTWM0sjpu_pdOBVBQ2M1y3KhpH515nXkpY",
    "2rsjGbaC0ky8mT0pJrPioWTq0_daw1sX76poUlgCwbI",
    "EkO8dhW0dHEJbvUHlE_VCeuC9uRELOieLZhh7XbUTtA",
    "IlDzIKeiZdDwpqpK6ZfbyphFvz5FgnWa-sN6wqQXCiw",
    "JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE",
    "PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI",
    "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo",
    "jdrTE8YcbY4EifugihiAe_BPekxJQZICeiUQwY9QqxI",
    "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4"
  ],
  "iss": "https://example.com/issuer",
  "iat": 1683000000,
  "exp": 1883000000,
  "type": "IdentityCredential",
  "_sd_alg": "sha-256",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  }
}

Note that a cnf claim has been added to the SD-JWT payload to express the confirmation method of the holder binding.¶

The following are the Disclosures belonging to the SD-JWT payload above:¶

Claim given_name:¶

• SHA-256 Hash: jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4¶
• Disclosure:
  WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9o
biJd¶
• Contents: ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]¶

Claim family_name:¶

• SHA-256 Hash: TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo¶
• Disclosure:
  WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRv
ZSJd¶
• Contents: ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]¶

Claim email:¶

• SHA-256 Hash: JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE¶
• Disclosure:
  WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VA
ZXhhbXBsZS5jb20iXQ¶
• Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "email", "johndoe@example.com"]¶

Claim phone_number:¶

• SHA-256 Hash: PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI¶
• Disclosure:
  WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIr
MS0yMDItNTU1LTAxMDEiXQ¶
• Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "phone_number",
"+1-202-555-0101"]¶

Claim address:¶

• SHA-256 Hash: IlDzIKeiZdDwpqpK6ZfbyphFvz5FgnWa-sN6wqQXCiw¶
• Disclosure:
  WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7InN0cmVl
dF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRv
d24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0¶
• Contents: ["Qg_O64zqAxe412a108iroA", "address", {"street_address":
"123 Main St", "locality": "Anytown", "region": "Anystate",
"country": "US"}]¶

Claim birthdate:¶

• SHA-256 Hash: jdrTE8YcbY4EifugihiAe_BPekxJQZICeiUQwY9QqxI¶
• Disclosure:
  WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImJpcnRoZGF0ZSIsICIxOTQw
LTAxLTAxIl0¶
• Contents: ["AJx-095VPrpTtN4QMOqROA", "birthdate", "1940-01-01"]¶

Claim is_over_18:¶

• SHA-256 Hash: 09vKrJMOlyTWM0sjpu_pdOBVBQ2M1y3KhpH515nXkpY¶
• Disclosure:
  WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImlzX292ZXJfMTgiLCB0cnVl
XQ¶
• Contents: ["Pc33JM2LchcU_lHggv_ufQ", "is_over_18", true]¶

Claim is_over_21:¶

• SHA-256 Hash: 2rsjGbaC0ky8mT0pJrPioWTq0_daw1sX76poUlgCwbI¶
• Disclosure:
  WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImlzX292ZXJfMjEiLCB0cnVl
XQ¶
• Contents: ["G02NSrQfjFXQ7Io09syajA", "is_over_21", true]¶

Claim is_over_65:¶

• SHA-256 Hash: EkO8dhW0dHEJbvUHlE_VCeuC9uRELOieLZhh7XbUTtA¶
• Disclosure:
  WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImlzX292ZXJfNjUiLCB0cnVl
XQ¶
• Contents: ["lklxF5jMYlGTPUovMNIvCA", "is_over_65", true]¶

The SD-JWT and the Disclosures would then be serialized by the Issuer into the following format for issuance to the Holder:¶

eyJhbGciOiAiRVMyNTYifQ.eyJfc2QiOiBbIjA5dktySk1PbHlUV00wc2pwdV9wZE9CV
kJRMk0xeTNLaHBINTE1blhrcFkiLCAiMnJzakdiYUMwa3k4bVQwcEpyUGlvV1RxMF9kY
Xcxc1g3NnBvVWxnQ3diSSIsICJFa084ZGhXMGRIRUpidlVIbEVfVkNldUM5dVJFTE9pZ
UxaaGg3WGJVVHRBIiwgIklsRHpJS2VpWmREd3BxcEs2WmZieXBoRnZ6NUZnbldhLXNON
ndxUVhDaXciLCAiSnpZakg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQW
WxTRSIsICJQb3JGYnBLdVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJI
iwgIlRHZjRvTGJnd2Q1SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAia
mRyVEU4WWNiWTRFaWZ1Z2loaUFlX0JQZWt4SlFaSUNlaVVRd1k5UXF4SSIsICJqc3U5e
VZ1bHdRUWxoRmxNXzNKbHpNYVNGemdsaFFHMERwZmF5UXdMVUs0Il0sICJpc3MiOiAia
HR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1ZXIiLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4c
CI6IDE4ODMwMDAwMDAsICJ0eXBlIjogIklkZW50aXR5Q3JlZGVudGlhbCIsICJfc2RfY
WxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiO
iAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsc
zd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2d
DRqVDlGMkhaUSJ9fX0.73WSR9N2fo-AMOgtJ0W6tMbfCnYbckGRZmfT-5yi8wWLJCvaO
S4vO6sR2kR61VziOSCbP2Bu5u1hOvh26GZA4w~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STj
l3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BI
iwgImZhbWlseV9uYW1lIiwgIkRvZSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwg
ImVtYWlsIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ~WyJlSThaV205UW5LUHBOUGVOZ
W5IZGhRIiwgInBob25lX251bWJlciIsICIrMS0yMDItNTU1LTAxMDEiXQ~WyJRZ19PNj
R6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIj
EyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueX
N0YXRlIiwgImNvdW50cnkiOiAiVVMifV0~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIi
wgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdW
ZRIiwgImlzX292ZXJfMTgiLCB0cnVlXQ~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiw
gImlzX292ZXJfMjEiLCB0cnVlXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImlz
X292ZXJfNjUiLCB0cnVlXQ

4.4. Verification and Processing

The recipient of the SD-JWT VC MUST process and verify an SD-JWT VC as follows:¶

1. REQUIRED. Process and verify the SD-JWT as defined in Section 6. of [I-D.ietf-oauth-selective-disclosure-jwt]. For the verification, the iss claim in the SD-JWT MAY be used to retrieve the public key from the JWT Issuer Metadata configuration (as defined in Section 5) of the SD-JWT VC issuer. A Verifier MAY use alternative methods to obtain the public key to verify the signature of the SD-JWT.¶
2. OPTIONAL. If status is present in the verified payload of the SD-JWT, the status SHOULD be checked. It depends on the Verifier policy to reject or accept an SD-JWT VP based on the status of the Verifiable Credential.¶

Any claims used that are not understood MUST be ignored.¶

Additional validation rules MAY apply, but their use is out of the scope of this specification.¶

5.1. JWT Issuer Metadata Request

A JWT Issuer Metadata configuration MUST be queried using an HTTP GET request at the path defined in Section 5.¶

The following is a non-normative example of a HTTP request for the JWT Issuer Metadata configuration when iss is set to https://example.com:¶

GET /.well-known/jwt-issuer HTTP/1.1
Host: example.com

If the iss value contains a path component, any terminating / MUST be removed before inserting /.well-known/ and the well-known URI suffix between the host component and the path component.¶

The following is a non-normative example of a HTTP request for the JWT Issuer Metadata configuration when iss is set to https://example.com/user/1234:¶

GET /.well-known/jwt-issuer/user/1234 HTTP/1.1
Host: example.com

5.2. JWT Issuer Metadata Response

A successful response MUST use the 200 OK HTTP and return the JWT Issuer Metadata configuration using the application/json content type.¶

An error response uses the applicable HTTP status code value.¶

This specification defines the following JWT Issuer Metadata configuration parameters:¶

• issuer REQUIRED. The JWT Issuer identifier, which MUST be identical to the iss value in the JWT.¶

• jwks_uri¶

  • OPTIONAL. URL string referencing the JWT Issuer's JSON Web Key (JWK) Set [RFC7517] document which contains the JWT Issuer's public keys. The value of this field MUST point to a valid JWK Set document. Use of this parameter is RECOMMENDED, as it allows for easy key rotation.¶

• jwks¶

  • OPTIONAL. JWT Issuer's JSON Web Key Set [RFC7517] document value, which contains the JWT Issuer's public keys. The value of this field MUST be a JSON object containing a valid JWK Set. This parameter is intended to be used by JWT Issuer that cannot use the jwks_uri parameter.¶

JWT Issuer Metadata MUST include either jwks_uri or jwks in their JWT Issuer Metadata, but not both.¶

It is RECOMMENDED that the JWT contains a kid JWT header parameter that can be used to lookup the public key in the JWK Set included by value or referenced in the JWT Issuer Metadata.¶

The following is a non-normative example of a JWT Issuer Metadata configuration including jwks:¶

{
   "issuer":"https://example.com",
   "jwks":{
      "keys":[
         {
            "kid":"doc-signer-05-25-2022",
            "e":"AQAB",
            "n":"nj3YJwsLUFl9BmpAbkOswCNVx17Eh9wMO-_AReZwBqfaWFcfG
   HrZXsIV2VMCNVNU8Tpb4obUaSXcRcQ-VMsfQPJm9IzgtRdAY8NN8Xb7PEcYyk
   lBjvTtuPbpzIaqyiUepzUXNDFuAOOkrIol3WmflPUUgMKULBN0EUd1fpOD70p
   RM0rlp_gg_WNUKoW1V-3keYUJoXH9NztEDm_D2MQXj9eGOJJ8yPgGL8PAZMLe
   2R7jb9TxOCPDED7tY_TU4nFPlxptw59A42mldEmViXsKQt60s1SLboazxFKve
   qXC_jpLUt22OC6GUG63p-REw-ZOr3r845z50wMuzifQrMI9bQ",
            "kty":"RSA"
         }
      ]
   }
}

The following is a non-normative example of a JWT Issuer Metadata configuration including jwks_uri:¶

{
   "issuer":"https://example.com",
   "jwks_uri":"https://jwt-issuer.example.org/my_public_keys.jwks"
}

Additional JWT Issuer Metadata configuration parameters MAY also be used.¶

5.3. JWT Issuer Metadata Validation

The issuer value returned MUST be identical to the iss value of the JWT. If these values are not identical, the data contained in the response MUST NOT be used.¶

6.1. Data Format

A presentation of an SD-JWT VC MUST be encoded using the SD-JWT Combined Format for Presentation as defined in Section 5.4. of [I-D.ietf-oauth-selective-disclosure-jwt].¶

A presentation of an SD-JWT VC MAY contain a Holder Binding JWT as described in Section 5.4.1. of [I-D.ietf-oauth-selective-disclosure-jwt].¶

6.2. Examples

The following is a non-normative example of a presentation of the SD-JWT shown above including a Holder Binding JWT:¶

eyJhbGciOiAiRVMyNTYifQ.eyJfc2QiOiBbIjA5dktySk1PbHlUV00wc2pwdV9wZE9CV
kJRMk0xeTNLaHBINTE1blhrcFkiLCAiMnJzakdiYUMwa3k4bVQwcEpyUGlvV1RxMF9kY
Xcxc1g3NnBvVWxnQ3diSSIsICJFa084ZGhXMGRIRUpidlVIbEVfVkNldUM5dVJFTE9pZ
UxaaGg3WGJVVHRBIiwgIklsRHpJS2VpWmREd3BxcEs2WmZieXBoRnZ6NUZnbldhLXNON
ndxUVhDaXciLCAiSnpZakg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQW
WxTRSIsICJQb3JGYnBLdVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJI
iwgIlRHZjRvTGJnd2Q1SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAia
mRyVEU4WWNiWTRFaWZ1Z2loaUFlX0JQZWt4SlFaSUNlaVVRd1k5UXF4SSIsICJqc3U5e
VZ1bHdRUWxoRmxNXzNKbHpNYVNGemdsaFFHMERwZmF5UXdMVUs0Il0sICJpc3MiOiAia
HR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1ZXIiLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4c
CI6IDE4ODMwMDAwMDAsICJ0eXBlIjogIklkZW50aXR5Q3JlZGVudGlhbCIsICJfc2RfY
WxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiO
iAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsc
zd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2d
DRqVDlGMkhaUSJ9fX0.73WSR9N2fo-AMOgtJ0W6tMbfCnYbckGRZmfT-5yi8wWLJCvaO
S4vO6sR2kR61VziOSCbP2Bu5u1hOvh26GZA4w~WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm
9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgIm
xvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cn
kiOiAiVVMifV0~eyJhbGciOiAiRVMyNTYifQ.eyJub25jZSI6ICIxMjM0NTY3ODkwIiw
gImF1ZCI6ICJodHRwczovL2V4YW1wbGUuY29tL3ZlcmlmaWVyIiwgImlhdCI6IDE2ODU
wMjc2MTJ9.ywJS5bd7EeneVZm2e3XY8Xr2lBRA5cThtMIrbFJWR_LnZcUavjubQU15_j
LSm6GEBJy6s0E2wg4VapYv65Y1bQ

In this presentation, the Holder provides only the Disclosure for the claim address. Other claims are not disclosed to the Verifier.¶

The following example shows a presentation of a (different) SD-JWT without a Holder Binding JWT:¶

eyJhbGciOiAiRVMyNTYifQ.eyJfc2QiOiBbIjA5dktySk1PbHlUV00wc2pwdV9wZE9CV
kJRMk0xeTNLaHBINTE1blhrcFkiLCAiMnJzakdiYUMwa3k4bVQwcEpyUGlvV1RxMF9kY
Xcxc1g3NnBvVWxnQ3diSSIsICJFa084ZGhXMGRIRUpidlVIbEVfVkNldUM5dVJFTE9pZ
UxaaGg3WGJVVHRBIiwgIklsRHpJS2VpWmREd3BxcEs2WmZieXBoRnZ6NUZnbldhLXNON
ndxUVhDaXciLCAiSnpZakg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQW
WxTRSIsICJQb3JGYnBLdVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJI
iwgIlRHZjRvTGJnd2Q1SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAia
mRyVEU4WWNiWTRFaWZ1Z2loaUFlX0JQZWt4SlFaSUNlaVVRd1k5UXF4SSIsICJqc3U5e
VZ1bHdRUWxoRmxNXzNKbHpNYVNGemdsaFFHMERwZmF5UXdMVUs0Il0sICJpc3MiOiAia
HR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1ZXIiLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4c
CI6IDE4ODMwMDAwMDAsICJ0eXBlIjogIklkZW50aXR5Q3JlZGVudGlhbCIsICJfc2RfY
WxnIjogInNoYS0yNTYifQ.C5j6NiIWKG2KL5HSfQWns_-uOBo7nCdc2aPKCi6fH5O8ak
dOXpDyo4HieN4y8AnRLM-GRrGBO1ZmK6DKGhfyqw~WyJRZ19PNjR6cUF4ZTQxMmExMDh
pcm9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0Iiw
gImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW5
0cnkiOiAiVVMifV0~

6.3. Verification and Processing

The Verifier MUST process and verify an SD-JWT VP as follows:¶

1. REQUIRED. When processing and verifying the presentation of the SD-JWT VC, the Verifier MUST follow the same verification and processing rules as defined in Section 4.4.¶
2. OPTIONAL. If provided, the Verifier MUST verify the Holder Binding JWT according to Section 6.2. of [I-D.ietf-oauth-selective-disclosure-jwt]. To verify the Holder Binding JWT, the cnf claim of the SD-JWT MUST be used.¶

9.1. W3C Verifiable Credential Data Model 2.0

The W3C VCDM 2.0 [VC-DATA] defines a JSON-LD vocabulary for Verifiable Credentials and Verifiable Presentations. To interop with the W3C VCDM 2.0 data model defined in [VC-DATA], this specification defines a mapping algorithm for SD-JWT VC and SD-JWT VP to the vocabulary and data model defined W3C VCDM 2.0 which is based on JSON-LD.¶

function get_credential_from_vc_sd_jwt(vc_sd_jwt):
  // Reconstruct unsecured payload from SD-JWT and Disclosures
  return payload

function transform_vc_sd_jwt_to_w3c_vc(vc_sd_jwt):

  // construct input credential (JSON object)
  payload = get_unsecured_payload_from_vc_sd_jwt(vc_sd_jwt)

  vc = {
    "@context": [
      "https://www.w3.org/ns/credentials/v2"
    ]
  }
  if (payload.hasProperty("iat")) {
    vc.issuedAt = epoch_time_to_ISO_datetime(payload.iat)
    payload = remove_claim_from_json(payload, "iat")
  }

  if (payload.hasProperty("nbf")) {
    vc.validFrom = epoch_time_to_ISO_datetime(payload.nbf)
    payload = remove_claim_from_json(payload, "nbf")
  }

  if (payload.hasProperty("exp")) {
    vc.validUntil = epoch_time_to_ISO_datetime(payload.exp)
    payload = remove_claim_from_json(payload, "exp")
  }

  if (payload.hasProperty("jti")) {
    vc.id = payload.jti
    payload = remove_claim_from_json(payload, "jti")
  }

  vc.issuer = payload.iss
  payload = remove_claim_from_json(payload, "iss")

  vc.type = [ "VerifiableCredential", payload.type ]
  payload = remove_claim_from_json(payload, "type")

  if (payload.hasProperty("sub")) {
    vc.credentialSubject = {
      "id": payload.sub
    }
    payload = remove_claim_from_json(payload, "sub")
  } else {
    vc.credentialSubject = { }
  }

  // add all remaining claims to credentialSubject
  // ignore other claims such as "cnf" where no
  // corresponding representation exists
  vc.credentialSubject = insert_claims_into_credential_subject(vc, payload)

  return vc

A.1. JSON Web Token Claims Registration

• Claim Name: "type"¶

  • Claim Description: Credential Type¶
  • Change Controller: IESG¶
  • Specification Document(s): Section 4.2.2.1 of this document¶

A.2. Media Types Registry