SD-JWT

The core innovation of SD-JWT is enabling a holder to reveal only specific claims from a credential. The issuer signs a disclosure array containing all claims, but the presenter can choose which elements to share, proving authenticity without exposing the full dataset. This is achieved using cryptographic hashes and digests.

Prevents unauthorized presentation of a credential. The issuer can embed a key binding JWT (KB-JWT) that cryptographically ties the credential to a specific holder's public key. During presentation, the holder must sign with the corresponding private key, proving they are the legitimate subject of the claims.

SD-JWTs use a specialized, space-efficient serialization to combine multiple components into a single string. The format typically includes:

• The Issuer-signed JWT (containing claim digests).
• Optional Disclosures (the actual claim values).
• Optional Key Binding JWT. This structure is designed for easy transmission in protocols like OAuth 2.0 and OpenID Connect.

Every disclosed claim is cryptographically linked to the issuer's signature. Each claim value is hashed, and these digests are included in the signed JWT. A verifier recalculates the hash of any presented disclosure and checks it against the signed digest list, ensuring the data is tamper-proof and originated from the legitimate issuer.

A practical application is proving age without revealing other PII. A government could issue a credential with claims for name, dateOfBirth, and address. To access an age-restricted service, the holder discloses only the dateOfBirth digest and its corresponding disclosure, proving they are over 18 without leaking their name or home address.

The foundational, signed base token containing all claims in plaintext. This is the Issuer-signed credential that the Holder receives. It uses standard JWT structure with a header, payload (claims), and signature, following RFC 7519.

A separate array containing the data needed to create selective disclosures. Each entry is a structured object containing:

• A salt (random value) for binding.
• The claim name (key).
• The claim value. These are hashed to create digests referenced in the JWT payload.

Cryptographic hashes of the disclosure objects, embedded within the JWT payload. To disclose a claim, the Holder presents the corresponding disclosure object, not the digest. The Verifier hashes it to match the digest in the signed JWT, proving the claim's integrity and origin.

An optional, Holder-signed JWT that cryptographically binds the presentation of the SD-JWT to a specific Holder's key. This prevents presentation to a Verifier by anyone other than the legitimate Holder, adding a critical layer of presentation integrity.

The W3C Verifiable Credentials-compatible wrapper for an SD-JWT. It packages the SD-JWT components into a standard VC proof format, enabling interoperability with broader VC ecosystems while preserving the selective disclosure capabilities.

A user can prove they are over 21 without revealing their exact birthdate. The issuer signs a credential containing the user's date of birth. The user presents an SD-JWT, disclosing only a boolean claim (e.g., over_21: true) derived from the hidden date, satisfying regulatory requirements while minimizing data exposure.

A banking app can request specific user attributes for a loan application. The user holds a credential with name, address, credit score, and employment status. Using SD-JWT, they can disclose only their name and credit score to the lender, keeping their address and employment details private.

To access an age-restricted online service, a user proves they are an adult. Their government-issued digital ID, issued as an SD-JWT, contains their full birthdate. The service's verifier requests proof of age. The user's wallet computes and discloses a cryptographic hash proving the over_18 claim is valid without leaking the underlying date.

A patient needs to share specific medical history with a new specialist. Their electronic health record, issued as an SD-JWT by their primary care provider, contains allergies, medications, and past procedures. The patient can selectively disclose only their relevant allergy information to the new doctor, maintaining control over their sensitive medical data.

An employee needs to prove their employment status to a vendor for a corporate discount. Their employer issues a credential with employee ID, department, salary, and start date. The employee generates a presentation disclosing only the department and a valid_employee boolean, providing necessary proof without sharing confidential salary information.

The core privacy mechanism. An SD-JWT contains disclosures—separate JSON objects that hold the actual claim values and a salt. The issuer sends these alongside the JWT. The holder can then selectively reveal only the necessary disclosures to a verifier, proving possession without exposing the entire credential. This prevents data minimization violations and limits correlation.

Prevents token replay by binding the credential to a specific holder. After receiving the SD-JWT, the holder must create a Key Proof (e.g., JWT, CWT, or an embedded signature) using a private key they control. The verifier checks this proof to ensure the presenter is the legitimate holder authorized by the issuer, a critical defense against token theft.

Ensures data cannot be tampered with. Claim values in disclosures are hashed (using SHA-256). These digests are embedded in the JWT payload. A verifier recomputes the hash of the presented disclosure and matches it against the digest in the signed JWT. This cryptographically verifies the issuer's signature on the digest and thus the integrity of the revealed claim.

Enhances privacy between issuer and verifier. Using blind signatures, an issuer can sign a credential without seeing its final values (blind issuance). Furthermore, the hashes in the SD-JWT are unique per issuance. This creates issuer unlinkability, meaning the issuer cannot later correlate which specific credential was presented to a verifier.

Provides a verifiable audit trail. The issuer's signature on the SD-JWT provides non-repudiation—they cannot deny issuing the credential. The structure allows auditors to verify that all presented disclosures correctly hash to the signed digests, ensuring the verification process was executed correctly without requiring access to the raw claim data.

Common pitfalls include:

• Salt Management: Weak or reused salts can enable brute-force attacks to uncover undisclosed claims.
• Key Proof Validation: Failing to properly validate the holder's key proof enables replay attacks.
• Claim Name Privacy: The JWT may still leak claim names; use indexed disclosures to hide them.
• Complexity: The multi-component structure increases implementation complexity and attack surface.

An SD-JWT combines a signed JWT with disclosure objects for each claim. The issuer signs the JWT, which contains the digests of all claims. The holder receives the full set of disclosures but can choose to share only the digests for the claims they wish to reveal, allowing the verifier to cryptographically confirm their authenticity without seeing the raw data.

• Decentralized Identity (SSI): Core component of W3C Verifiable Credentials, enabling user-controlled identity.
• Regulatory Compliance: Facilitates GDPR 'data minimization' and privacy-by-design principles.
• On-Chain Verification: Used in DeFi and DAOs for proving attributes (e.g., KYC status, accreditation) without revealing full identity documents.

To prevent credential replay, SD-JWT supports holder binding. The presentation includes a Key Proof JWT (like cnf or jkt), signed by the holder's private key, which cryptographically binds the credential to the specific presenter. This proves the holder is in possession of the credential and the corresponding private key.

While both enable privacy, SD-JWT and zero-knowledge proofs (ZKPs) differ. SD-JWT provides selective disclosure of pre-defined, issuer-signed claims. ZKPs can prove complex statements (e.g., 'age > 18') about hidden data without revealing the underlying claims. They are often complementary technologies in advanced credential systems.