#Selective Disclosure & SD-JWTs: The Complete Guide to Privacy-Preserving Digital Identity

Selective disclosure is a core capability in modern digital identity, enabling users to reveal only the information that is strictly necessary. This guide explains what selective disclosure is, why it matters for privacy-preserving digital identity, and how it works across credential formats such as SD-JWT VCs, mDL, and mono-claim credentials.

In this guide, you will learn the key concepts behind selective disclosure, the technical flows used during issuance and verification, and practical guidance for choosing the right approach when implementing real-world digital identity systems.

#What is Selective Disclosure?

Selective disclosure is one of the most important capabilities in decentralized identity and Verifiable Credential (VC) ecosystems. It enables a holder to reveal only the minimum amount of information required for a transaction, nothing more.

In today’s digital world, personal data is copied, stored, sold, breached, and shared far beyond user expectations. Centralized and federated identity systems force users to overshare information. For example, showing a driver’s licence at a bar reveals your name, address, licence number, and date of birth, even though the verifier only needs to know that you are over 18.

Selective disclosure reverses this pattern. Instead of the verifier receiving the entire credential, users share only the specific claims that matter:

• Prove age without revealing a date of birth
• Prove residency without showing a full address
• Prove credential validity without sharing unnecessary attributes

This solves a fundamental privacy and data minimization problem: how to prove something about yourself without exposing more personal data than necessary. It directly aligns with modern regulations such as GDPR, CCPA, and eIDAS2, all of which require organizations to limit the amount of data they collect and process.

Selective disclosure also depends on three actors working together:

• Issuer – Creates and signs the credential.
• Holder – Stores the credential inside a digital identity wallet.
• Verifier – Requests only the specific attributes needed for an interaction.

These roles form the foundation of decentralized identity ecosystems. (For a deeper overview of issuers, holders, and verifiers, see the Decentralized Identity Playbook by walt.id.)

#Why Selective Disclosure Matters: Benefits for Users and Enterprises

Selective disclosure is central to the global shift toward data minimization. Identity systems have moved from centralized models, where every service stored its own user database and repeatedly exposed people to breaches and redundant KYC, to federated logins that improved usability but concentrated power and enabled cross-service tracking. Decentralized and self-sovereign identity introduced a new approach where users hold credentials in their own wallet and verifiers rely on cryptographic proofs. In this model, selective disclosure becomes a native feature because holders share only the attributes required, not their entire identity document.

#For Individuals: Privacy and Control

Selective disclosure gives people meaningful control over their personal data:

• Only essential attributes are shared.
• Less data is exposed, reducing tracking and correlation.
• Minimal transmission and storage of PII lowers breach and identity theft risk.

#For Enterprises and Governments: Compliance and Efficiency

Organizations benefit by requesting only what they need:

• Strong alignment with GDPR, CCPA, and eIDAS2.
• Reduced liability from storing unnecessary personal data.
• Increased trust and smoother onboarding because users see exactly what is being requested.

Selective disclosure improves privacy, reduces risk, and enables modern identity ecosystems built on minimal, purpose-based data sharing.

#How Selective Disclosure Actually Works

At its core, selective disclosure relies on modern cryptographic techniques that allow information to remain hidden until the holder intentionally reveals it. Hash functions, salts, and digital signatures ensure that each claim inside a credential can be individually committed to and later verified without exposing the entire dataset.

Protocols such as OpenID for Verifiable Presentations and its query language, DCQL, enable verifiers to request only the precise fields necessary for an interaction. These protocols define how a digital wallet receives a request, evaluates which credentials can satisfy it, and constructs a privacy-preserving presentation containing only the required disclosures. An end-to-end flow with a code example will be presented in a later section to illustrate how this works in practice.

#The Credential Standards That Enable Selective Disclosure

Different credential formats support selective disclosure in different ways. Some, like SD-JWT VCs, enable issuers to choose which claims can be revealed on a per-attribute basis, while others, like ISO mDL/mdoc, hide all data by default and only disclose specific elements during an authenticated session. Mono-claim credentials take a simpler approach by encoding only a single attribute per credential, and W3C VCs can also support selective disclosure when signed using SD-JWT.

This section explains how each format works, how selective disclosure is achieved, and how these formats differ from one another.

#SD-JWT VC (IETF)

Selective Disclosure JWT VCs enable claim-level selective disclosure through a hashing-based mechanism defined by the emerging IETF SD-JWT specification. Instead of storing plaintext values inside the credential, the issuer hashes each selectively disclosable claim and provides the holder with separate “disclosure” objects containing the salted plaintext values. This means a verifier cannot read any claim unless the holder intentionally reveals it. You can view the official IETF SD-JWT standard here or read our guide on the credential type here.

The SD-JWT issuance process works as follows:

1. The issuer prepares the VC payload, including context, types, schemas, and claims.
2. For each claim that should be selectively disclosable, the issuer generates a random salt, concatenates it with the claim name and value, encodes it to form a disclosure, and then hashes that disclosure.
3. These hashed claim values are stored in the SD-JWT, and optional decoy hashes can be added to obscure the true number of claims.
4. The issuer signs the SD-JWT using JWS (for example, EdDSA) and sends the signed credential plus all disclosures to the holder using for example the OID4VCI exchange standard.

For example, an SD-JWT VC for age verification might contain a full date of birth and other personal data, but the holder only discloses a single derived claim such as age_over_18: true to the verifier.

Verification follows a similar pattern. A verifier requests specific attributes using common protocols like OID4VP, and the holder returns only the relevant disclosures along with the SD-JWT. The verifier re-hashes each disclosure, compares it to the stored hashed value, and verifies the issuer’s signature. If everything matches, the verifier knows the claim is valid and untampered. You can refer to the OID4VP guide for further detail on how a typical verification flow looks like.

walt.id’s implementation follows the IETF specification closely and is continuously updated to align with new versions of the standard as they are published.

#mDL/mdoc (ISO 18013-5 and 18013-7)

ISO mobile driving licences (mDL) and mobile documents (mdoc) implement selective disclosure very differently from SD-JWT VC (IETF). Instead of hashing selectively disclosable claims, all data elements are hidden by default. A verifier can only access requested attributes during an authenticated, device-bound session initiated through NFC, BLE, QR code scanning or via OID4VP with 18013-7.

For example, an mDL could disclose only a single attribute such as age_over_18 or driving_privilege: yes, while keeping all other personal details—like full name, address, or licence number—hidden by default.

In this model, the mdoc proves possession of its keys and authorizes the release of specific data elements during the session. It is highly optimized for offline or proximity-based interactions such as border control, airport checkpoints, police stops, and age-restricted purchases.

Characteristics of ISO mDL/mdoc:

• Selective disclosure at the data-element level
• Strong device binding (proof the data is coming from the legitimate device)
• Ephemeral sessions that protect against correlation
• Use of ISO rather than JWT/JWS cryptographic primitives

Where SD-JWT is ideal for web-based, API-driven online verification flows, mDLs excel in controlled, physical environments with secure device-to-verifier sessions, but can also support online verification through ISO 18013-7 and OID4VP.

#Mono-Claim Credentials

Mono-claim credentials achieve selective disclosure through credential granularity instead of cryptography. Each credential contains exactly one attribute, meaning the holder can share or withhold individual attributes simply by choosing which credential to present. Because they rely on this structural approach rather than a specific cryptographic format, mono-claim credentials are largely standard-independent and can be issued as W3C VCs, SD-JWT VCs, or other compatible credential types.

Example of an age-verification credential:

{
  "@context": ["[https://www.w3.org/2018/credentials/v1](https://www.w3.org/2018/credentials/v1)"],
  "type": ["VerifiableCredential", "VerifiableAttestation", "ProofOfAge"],
  "credentialSubject": {
    "id": "did:key:z6MkrHKzgsahxBLyNAbLQyB1pcWNYC9GmywiWPgkrvntAZcj",
    "over18": "true"
  },
  "issuer": {
    "id": "did:key:z6MkrHKzgsahxBLyNAbLQyB1pcWNYC9GmywiWPgkrvntAZcj",
    "name": "Government of Anytown"
  },
  "issuanceDate": "2021-08-31T00:00:00Z"
}

This model is simple, interoperable, and works with any VC stack. While the example is shown in W3C VC format, mono-claim credentials are not tied to a single standard and can equally be issued using SD-JWT VCs or other compatible credential frameworks. It is especially useful when attributes rarely need to be combined and when minimal implementation complexity is important.

#W3C VC With SD-JWT Signature

A W3C Verifiable Credential can also support selective disclosure when its proof layer uses an SD-JWT signature. In this model, the credential still follows the W3C VC Data Model, but its proof section adopts SD-JWT as the underlying cryptographic mechanism for hashing claims and supplying disclosures. This approach is ideal for issuers who want to use the W3C VC model while adopting SD-JWT as the privacy-preserving signature suite. It combines the interoperability of the W3C VC ecosystem with the selective disclosure capabilities of SD-JWT.

#How To Decide Which Credential Standard Is Best

Selecting the right credential format depends on the use case, the environment in which verification occurs, and the level of privacy required. To help readers evaluate their options, this section will include a comparison table summarizing the strengths and trade-offs of SD-JWT VCs, mDL/mdoc, mono-claim credentials, and W3C VCs with SD-JWT signatures. Because some advanced schemes like BBS+ and ZKPs are still emerging and not yet widely deployed in production, they will be mentioned briefly at the bottom with links to future articles once dedicated coverage is available.

#Key Use Cases and Examples

Selective disclosure is already powering real-world digital ID interactions by allowing users to reveal only the specific information needed for a transaction. Common use cases include:

• Age verification (prove you are over 18 without sharing your date of birth)
• Mobile Driver’s License (mDL) (share only required attributes like “over 21” or “valid licence”)
• Mono-claim credentials such as “Over 18,” “Resident of X,” or “Employed by Y,” issued as single-purpose Verifiable Credentials. These can also be leveraged for address verification (confirm residency without revealing full address details) or Salary verification (prove income range without exposing exact salary)

#Global Initiatives & Regulations Driving Selective Disclosure Adoption

Selective disclosure is being accelerated by major global digital identity programs. Mobile Driver’s Licenses (mDLs) and ISO mdocs are already deployed across many US states and are expanding internationally, enabling privacy-preserving ID checks using data-element–level disclosure. In the EU, eIDAS2 and the EUDI Wallet initiative mandate support for selective disclosure through both SD-JWT VCs (IETF) and ISO mDL/mdoc, establishing these as the foundational standards for next-generation digital identity. Together, these efforts are setting worldwide expectations for interoperable, privacy-first credential sharing

#End-to-End Selective Disclosure Example (with Code)

This section walks through a complete SD-JWT VC flow from issuance to verification, demonstrating how selective disclosure works in practice. At each step, we explain the cryptographic mechanics that make privacy-preserving credential sharing possible.

#Understanding How SD-JWT Hashes Work

Before diving into the code, it's essential to understand how SD-JWT achieves selective disclosure through cryptographic hashing.

When an issuer creates an SD-JWT VC, selectively disclosable claims are not stored in plaintext inside the credential. Instead, each claim undergoes a transformation:

1. Salt Generation: The issuer generates a cryptographically random salt for each selectively disclosable claim.
2. Disclosure Creation: The salt, claim name, and claim value are combined into a JSON array: [salt, claim_name, claim_value].
3. Base64url Encoding: This array is encoded as a base64url string, creating the "disclosure."
4. Hash Computation: The disclosure is hashed using SHA-256, and the resulting hash is base64url encoded.
5. Storage: The hash (not the plaintext) is stored in the credential's _sd array. The disclosures are provided separately to the holder.

Example Transformation:

For a claim "birthdate": "1940-01-01", the issuer:

Disclosure: ["zqdrNfRPzxYivbvZevEh1w", "birthdate", "1940-01-01"]
           ↓ Base64url encode
Encoded:   WyJ6cWRyTmZSUHp4WWl2YnZaZXZFaDF3IiwiYmlydGhkYXRlIiwiMTk0MC0wMS0wMSJd
           ↓ SHA-256 hash → Base64url encode
Hash:      vyCkk8nkNZcSNBqzLyhSzDp1AuwnS911ukrFgmFZPFI

The credential payload contains only the hash in _sd:

{
  "given_name": "John",
  "family_name": "Doe",
  "_sd": ["vyCkk8nkNZcSNBqzLyhSzDp1AuwnS911ukrFgmFZPFI"]
}

During verification, the verifier re-hashes any disclosures provided by the holder and compares them against the stored hashes to confirm validity.

#Step 1: Issue an SD-JWT VC with Selective Disclosure

Product: walt.id Issuer API (Open Source)

We use the walt.id Issuer API to create an identity credential where the birthdate and family_name fields are selectively disclosable—meaning the holder can later choose whether to reveal them.

The following request uses an example signing key and issues a credential with selective disclosure configured. You can run this directly against the hosted demo issuer or set up your own instance:

curl -X 'POST' \
  'https://issuer.demo.walt.id/openid4vc/sdjwt/issue' \
  -H 'accept: text/plain' \
  -H 'Content-Type: application/json' \
  -d '{
  "issuerKey": {
    "type": "jwk",
    "jwk": {
      "kty": "OKP",
      "d": "mDhpwaH6JYSrD2Bq7Cs-pzmsjlLj4EOhxyI-9DM1mFI",
      "crv": "Ed25519",
      "kid": "Vzx7l5fh56F3Pf9aR3DECU5BwfrY6ZJe05aiWYWzan8",
      "x": "T3T4-u1Xz3vAV2JwPNxWfs4pik_JLiArz_WTCvrCFUM"
    }
  },
  "issuerDid": "did:key:z6MkjoRhq1jSNJdLiruSXrFFxagqrztZaXHqHGUTKJbcNywp",
  "credentialConfigurationId": "identity_credential_vc+sd-jwt",
  "credentialData": {
    "given_name": "John",
    "family_name": "Doe",
    "email": "johndoe@example.com",
    "birthdate": "1940-01-01",
    "is_over_18": true,
    "is_over_21": true
  },
  "mapping": {
    "id": "<uuid>",
    "iat": "<timestamp-seconds>",
    "nbf": "<timestamp-seconds>",
    "exp": "<timestamp-in-seconds:365d>"
  },
  "selectiveDisclosure": {
    "fields": {
      "birthdate": { "sd": true },
      "family_name": { "sd": true }
    },
    "decoyMode": "NONE",
    "decoys": 0
  },
  "authenticationMethod": "PRE_AUTHORIZED"
}'

Response (Credential Offer URL):

openid-credential-offer://?credential_offer_uri=https%3A%2F%2Fissuer.demo.walt.id%2Fdraft13%2FcredentialOffer%3Fid%3D080726d1-70e0-426c-ab06-10e41225853f

#Step 2: Claim the Credential in a Wallet

Product: walt.id Web Wallet (Open Source)

The holder uses a wallet to claim the credential using the offer URL. The easiest way to try this is using the walt.id Demo Wallet hosted at wallet.demo.walt.id. You can also run the wallet locally or build your own wallet using the Wallet API.

1. Create an account at wallet.demo.walt.id (or log in if you already have one).
2. Click the "Receive" button at the top of the home screen.
3. Paste the Credential Offer URL (from Step 1) into the text field.
4. Review and accept the credential.

The credential is now stored in your wallet.

What the wallet receives and stores:

The wallet now holds:

• The signed SD-JWT credential (containing hashes in _sd)
• All disclosures provided by the issuer

The credential payload stored in the wallet looks like this:

{
  "given_name": "John",
  "email": "johndoe@example.com",
  "is_over_18": true,
  "is_over_21": true,
  "id": "urn:uuid:16db85c2-6a60-4339-94f8-617ef7a7852f",
  "iat": 1765984477,
  "nbf": 1765984477,
  "exp": 1797520477,
  "_sd_alg": "sha-256",
  "iss": "did:key:z6MkjoRhq1jSNJdLiruSXrFFxagqrztZaXHqHGUTKJbcNywp",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "kid": "g5NZkDNcGXI06zy7mFLG09PvFBwdBEDO7I3bn78etlM",
      "x": "woHr8cHiXFB4HYBnIqqeudpZme6XkmkwVgLg9QqlGs0",
      "y": "OtX0EgOF28c6-FYpHfr5xceyGjllH75CV6S92AwBTcU"
    }
  },
  "vct": "https://issuer.demo.walt.id/draft13/identity_credential",
  "_sd": [
    "VcCZB3lnwdRmwsLoiAhXET3U_i09mS-gKO_STqyK9n0",
    "jAyj3j4i8mPCR98nV1jPccTqvqTdZ0tSfmHhQ1HsdFw"
  ]
}

Notice that birthdate and family_name are not visible in the payload, only their hashes appear in _sd. The holder (wallet) has the corresponding disclosures that can reveal these values when needed.

#Step 3: Verify the Credential (Request Specific Claims)

Product: walt.id Verifier API (Open Source)

Now a verifier wants to confirm the holder is over 18 and learn their family name—but does not need their birthdate. Using the walt.id Verifier API, we create a presentation request that specifies exactly which claims are required. You can run this against the hosted demo verifier or set up your own instance:

curl -X 'POST' \
  'https://verifier.demo.walt.id/openid4vc/verify' \
  -H 'accept: */*' \
  -H 'authorizeBaseUrl: openid4vp://authorize' \
  -H 'responseMode: direct_post' \
  -H 'successRedirectUri: https://example.com/success?id=$id' \
  -H 'errorRedirectUri: https://example.com/error?id=$id' \
  -H 'Content-Type: application/json' \
  -d '{
  "vp_policies": ["presentation-definition"],
  "request_credentials": [
    { 
      "vct": "https://issuer.demo.walt.id/draft13/identity_credential", 
      "format": "vc+sd-jwt",
      "input_descriptor": {
        "id": "identity_check",
        "constraints": {
          "fields": [
            {
              "path": ["$.family_name"],
              "filter": { "type": "string" }
            },
            {
              "path": ["$.is_over_18"],
              "filter": { "type": "boolean", "const": true }
            }
          ],
          "limit_disclosure": "required"
        }
      }
    }
  ]
}'

Response (Verification Request URL):

openid4vp://authorize?response_type=vp_token&client_id=https%3A%2F%2Fverifier.demo.walt.id...&state=HMUgYMpanNr8...

#Step 4: Present the Credential with Selective Disclosure

Product: walt.id Web Wallet (Open Source)

Using the walt.id Demo Wallet at wallet.demo.walt.id, you can fulfill the verification request:

1. In the wallet, click the "Scan to receive or present credentials" button (top right corner).
2. Paste the Verification Request URL (from Step 3) into the text field below the QR scanner.
3. The wallet will show which credentials match the request and which claims will be disclosed.
4. Select which attributes to disclose — you can choose to reveal or hide the selectively disclosable fields (family_name and birthdate).
5. Review and approve the presentation.

Try it yourself: Since the verifier's request requires family_name and is_over_18, the verification outcome depends on your selection:

• Success: If you disclose family_name (and is_over_18 is already visible), verification passes.
• Failure: If you choose not to disclose family_name, verification will fail because the required field is missing.
• Privacy preserved: Whether you disclose birthdate or not has no effect on the result—it wasn't requested by the verifier.

What happens during presentation:

The wallet constructs the vp_token as follows:

<SD-JWT>~<disclosure1>~<key_binding_jwt>

Where:

• <SD-JWT> is the original signed credential (with hashes)
• <disclosure1> is only the disclosure for family_name
• <key_binding_jwt> proves the holder controls the credential

The birthdate disclosure is omitted—the verifier cannot learn its value.

Example:

eyJraWQiOiJkaWQ6a2V5Ono2TWtqb1JocTFqU05KZExpcnVTWHJGRnhhZ3FyenRaYVhIcUhHVVRLSmJjTnl3cCN6Nk1ram9SaHExalNOSmRMaXJ1U1hyRkZ4YWdxcnp0WmFYSHFIR1VUS0piY055d3AiLCJ0eXAiOiJ2YytzZC1qd3QiLCJhbGciOiJFZERTQSJ9.eyJnaXZlbl9uYW1lIjoiSm9obiIsImVtYWlsIjoiam9obmRvZUBleGFtcGxlLmNvbSIsImlzX292ZXJfMTgiOnRydWUsImlzX292ZXJfMjEiOnRydWUsImlkIjoidXJuOnV1aWQ6MTZkYjg1YzItNmE2MC00MzM5LTk0ZjgtNjE3ZWY3YTc4NTJmIiwiaWF0IjoxNzY1OTg0NDc3LCJuYmYiOjE3NjU5ODQ0NzcsImV4cCI6MTc5NzUyMDQ3NywiX3NkX2FsZyI6InNoYS0yNTYiLCJpc3MiOiJkaWQ6a2V5Ono2TWtqb1JocTFqU05KZExpcnVTWHJGRnhhZ3FyenRaYVhIcUhHVVRLSmJjTnl3cCIsImNuZiI6eyJqd2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTI1NiIsImtpZCI6Imc1TlprRE5jR1hJMDZ6eTdtRkxHMDlQdkZCd2RCRURPN0kzYm43OGV0bE0iLCJ4Ijoid29IcjhjSGlYRkI0SFlCbklxcWV1ZHBabWU2WGtta3dWZ0xnOVFxbEdzMCIsInkiOiJPdFgwRWdPRjI4YzYtRllwSGZyNXhjZXlHamxsSDc1Q1Y2UzkyQXdCVGNVIn19LCJ2Y3QiOiJodHRwczovL2lzc3Vlci5kZW1vLndhbHQuaWQvZHJhZnQxMy9pZGVudGl0eV9jcmVkZW50aWFsIiwiX3NkIjpbIlZjQ1pCM2xud2RSbXdzTG9pQWhYRVQzVV9pMDltUy1nS09fU1RxeUs5bjAiLCJqQXlqM2o0aThtUENSOThuVjFqUGNjVHF2cVRkWjB0U2ZtSGhRMUhzZEZ3Il19.FF9kDs-vxqsd6serp-5TouRmw3l0JBAINhNcBbATb-3_kEHXSSjURJv4UmVLTc5vV8HDRwmHllfteLb-pR5_Bg~WyJZYmp2aDVjQUg5QlBiVmpHMWJJYnV3IiwiZmFtaWx5X25hbWUiLCJEb2UiXQ~eyJraWQiOiJnNU5aa0ROY0dYSTA2enk3bUZMRzA5UHZGQndkQkVETzdJM2JuNzhldGxNIiwidHlwIjoia2Irand0IiwiYWxnIjoiRVMyNTYifQ.eyJpYXQiOjE3NjU5ODY5ODYsImF1ZCI6Imh0dHBzOi8vdmVyaWZpZXIuZGVtby53YWx0LmlkL29wZW5pZDR2Yy92ZXJpZnkiLCJub25jZSI6ImEzMDUwZTQ1LWU0MGQtNDQzNy1hMjkyLWY2YzBhOTFhY2E2ZiIsInNkX2hhc2giOiJncmF6UGNqaGR5RWxvOFpycllfV3VUX1JTRzNxWkhaUU9vWW9GVjgwajFjIn0.rpgfWZTLLfw55hbEux69wbNmZLa4p0Wb2EPMzW4Y5ULOX5VGH_fqoeA90jugsMXefu65uA86VB08TjSVV_jGEg

#Step 5: Verification Result

The verifier receives the presentation and performs these checks:

1. Signature verification: Confirms the SD-JWT was signed by a trusted issuer.
2. Disclosure verification: Re-hashes each provided disclosure and matches against _sd.
3. Key binding verification: Confirms the presenter holds the credential's private key.

curl -X 'GET' \
  'https://verifier.demo.walt.id/openid4vc/session/{session-id}' \
  -H 'accept: */*'

#Get Started with Selective Disclosure

Ready to implement selective disclosure in your own identity solution? Explore the resources below to dive deeper into credential formats and start building with walt.id's open-source stack.

#Learn More About Credential Formats

Each credential format enables selective disclosure differently. Choose the one that fits your use case:

• SD-JWT VC Guide
• mDL / mdoc Guide
• W3C VC Guide

#Start Building with walt.id

The walt.id Identity Stack provides everything you need to issue, hold, and verify credentials with selective disclosure support:

• Issuer Getting Started - Issue SD-JWT VCs, W3C VCs, and mDL credentials with configurable selective disclosure
• Verifier Getting Started - Request and verify specific claims using OID4VP and presentation definitions
• Wallet Getting Started - Store credentials and present them with user-controlled disclosure selection

All components listed are open source and available on GitHub.