#SD-JWT VC

SD-JWT-VC (specified here) is a verifiable credential with selective disclosure capabilities, enhancing the privacy of users. It allows the holder to decide which claims to disclose during credential presentation.

#Intro

#The Issuer-Holder-Verifier Model

At the core of SD-JWT VC is the Issuer-Holder-Verifier model. Here’s how it works:

1. Issuer: This entity issues a Verifiable Credential to a Holder.
2. Holder: The recipient of the credential who can store and manage it.
3. Verifier: The entity that verifies the authenticity of the credential when presented by the Holder.

#Example: A Verifiable Credential Journey

1. Issuance: A university (Issuer) issues a degree certificate (Verifiable Credential) to a student (Holder).
2. Presentation: The student later presents this credential to a potential employer (Verifier) during a job application process.
3. Verification: The employer verifies the authenticity of the degree certificate and ensures that it was indeed issued by the university and not altered or forged.

#SD-JWT as a Credential Format

#What is SD-JWT?

JSON Web Tokens (JWTs) are widely used for transmitting information securely between parties as JSON objects. SD-JWT extends JWT by introducing conventions to support selective disclosure. It allows the Holder to decide which claims to disclose during the credential presentation.

#Selective Disclosure

Selective disclosure is a key feature of SD-JWT. It enables the Holder to share only the necessary information with the Verifier, thereby minimizing data exposure and enhancing privacy. For instance, a job applicant might choose to disclose only their degree and not other details like their date of birth or address.

#How SD-JWT VC Works

#Media Type

SD-JWT VCs compliant with this specification must use the media type application/vc+sd-jwt.

#Verifiable Credential Type and Type Metadata

The Verifiable Credential Type or the vct claim within an SD-JWT payload specifies the type/category of the credential being issued. The vct value points to a definition of the credential type, associated with Type Metadata.

Type Metadata provides details such as the schema and rules defining the credential type and may include optional properties such as name, description, extends, and either schema or schema_uri.

Type Metadata can be retrieved through various mechanisms, including URLs, registries, standard-defined sources, local caches, and glue documents.

#Data Model

SD-JWT VCs are encoded using the SD-JWT format. Here’s an example of an SD-JWT VC:

{
  "_sd": [
    "09vKrJMOlyTWM0sjpu_pdOBVBQ2M1y3KhpH515nXkpY",
    ...
  ],
  "iss": "https://example.com/issuer",
  "iat": 1683000000,
  "exp": 1883000000,
  "vct": "https://credentials.example.com/identity_credential",
  ...
}

#Claims and Headers

The JWT header for an SD-JWT VC includes:

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

The payload includes various claims such as iss (issuer), iat (issued at), exp (expiry), and vct (verifiable credential type).

#Verification and Processing

When a Verifier receives an SD-JWT VC, they must:

1. Verify the JWT signature.
2. Check if the credential is still valid (i.e., it hasn't expired or been revoked).
3. Optionally, verify Key Binding if required for additional security.

#Integrating with Existing Standards

SD-JWT VC integrates smoothly with existing standards like JSON Web Tokens (JWT) and supports various public key verification methods, exchange protocols (e.g. OID4VC) and Decentralized Identifiers (DIDs).

#Working With SD-JWT VCs

The walt.id stack offers various methods to integrate SD-JWT-VCs issuer, verifier and holder solutions into any system.

Get started by using:

• The Issuer API - Issue SD-JWT VCs via OID4VC to your users.
• The Verifier API - Request and verify SD-JWT VCs via the OID4VP from users.
• The Wallet API - Enable users to receive and present SD-JWT VCs via OID4VC & VP.