Selective Disclosure: Proving Without Revealing Everything

How selective-disclosure credentials reduce exposed personal data, where correlation remains possible, and what issuers, wallets, and verifiers must test.

Naked News Desk · September 26, 2026

Selective disclosure lets a person present some facts from a credential without handing the verifier every fact the issuer placed in it. A customer could prove that an age threshold is satisfied without disclosing a full birth date, or demonstrate a professional qualification without sharing an address and unrelated identifiers.

That sounds like a simple privacy improvement, but the cryptography solves only part of the problem. A presentation can expose fewer claims and still be linkable through stable identifiers, credential status checks, device signals, timing, network data, or an unusually distinctive combination of attributes. A sound design therefore starts with the verifier’s real decision and works backward to the minimum evidence needed.

Separate the credential from the presentation

In the W3C Verifiable Credentials Data Model 2.0, an issuer makes claims and gives a secured credential to a holder. The holder can later create a presentation for a verifier. Verification determines whether a credential or presentation is authentic and current under its securing mechanism; it does not establish that every claim is true or suitable for the verifier’s purpose.

This distinction matters operationally:

• the issuer decides which claims to attest and how to secure the credential;
• the holder stores the credential and decides what presentation to generate, subject to format and policy constraints;
• the verifier requests evidence, verifies it, checks status and context, and applies its own business rules;
• the subject is the person or thing described by the claims and is often, but not always, the holder.

Selective disclosure occurs at presentation time. The verifier should receive a derived or reconstructed presentation containing the requested claims and the proof material needed to validate them, rather than the complete original credential.

Three different privacy goals

Teams often use “selective disclosure” to describe several different properties. They should be tested separately.

Claim minimization means omitting unrelated claims. Showing overAgeThreshold: true instead of a birth date is stronger minimization than selectively revealing the birth date while hiding an address.

Predicate proof means proving that a condition holds without revealing the source value. Examples include proving that an age exceeds a threshold or that a number lies in an allowed range. Not every selective-disclosure format supports arbitrary predicates.

Unlinkability means that separate presentations cannot be correlated through their cryptographic artifacts. The W3C model explicitly distinguishes selective disclosure from unlinkable disclosure. Hiding claims does not automatically make two uses unlinkable.

A product requirement that says only “support selective disclosure” is therefore incomplete. It should identify which claims can be hidden, whether derived facts are issued or proved, who chooses the disclosed set, and which parties must be unable to correlate presentations.

Common construction patterns

Selective disclosure can be implemented in more than one way. The choice affects privacy, interoperability, size, key management, and verifier complexity.

Individually packaged claims

An issuer can issue separate credentials for separate facts. The holder presents only the credential needed for the transaction. This is conceptually simple, but repeated issuer metadata, stable subject identifiers, status mechanisms, and credential identifiers can still enable correlation. Managing many small credentials also increases lifecycle work.

Hash-and-salt disclosure

RFC 9901 specifies Selective Disclosure JSON Web Tokens, or SD-JWT. An issuer signs a JWT containing disclosures represented by salted hashes. The holder later sends selected disclosure values so the verifier can recompute their digests and relate them to the signed object. Undisclosed values are not sent.

Salts are essential because a verifier could otherwise guess a low-entropy value, hash it, and compare the result. Even with proper salts, visible claims and metadata may be correlatable. Implementers must also distinguish an issuer-signed SD-JWT from the holder’s presentation and follow the specification’s rules for holder binding, serialization, digest processing, and duplicate or malformed disclosures.

Derived cryptographic proofs

Some signature systems let a holder derive a proof over a subset of signed messages. The W3C BBS cryptosuite defines base proofs issued to holders and derived proofs for selectively revealed claims. Its privacy goals include proof artifacts that do not themselves link presentations to the original signature or to other derived presentations.

That property does not remove application-level correlation. A disclosed email address, membership number, exact timestamp, rare qualification, or persistent pseudonym can link interactions even when the proof bytes cannot.

Issued abstract claims

Sometimes the safest design does not require a sophisticated zero-knowledge predicate. An issuer can provide an abstract claim such as age-over-threshold, licence-valid-for-class, or resident-of-region. This reduces disclosure, but the issuer must define how the claim is derived, how often it is refreshed, and whether it is precise enough for the verifier’s legitimate purpose.

Ask for a decision, not a document

Many over-disclosure failures begin with a verifier requesting a familiar document instead of specifying the decision it must make. “Upload your driver’s licence” bundles name, photograph, address, birth date, document number, signature, and other attributes even if the service needs only an age threshold.

For each transaction, document:

1. the decision being made;
2. the minimum claim or predicate required;
3. acceptable issuers and assurance levels;
4. required freshness and status behavior;
5. whether holder binding or proof of possession is necessary;
6. retention, audit, dispute, and deletion requirements;
7. what happens when a user cannot or will not use the preferred wallet flow.

NIST’s current federation and assertions guidance treats privacy, consent, subscriber-controlled wallets, and selective use or disclosure of attributes as parts of a broader risk model. Data minimization should not erase accessibility, redress, fraud controls, or the ability to explain an adverse decision.

Correlation survives in unexpected places

Evaluate the complete transaction, not just the credential payload. Potential correlators include:

• stable subject, credential, issuer, wallet, device, or account identifiers;
• identical signatures, salts, disclosures, public keys, or holder-binding keys;
• credential status queries made directly to an issuer;
• exact issuance and expiry timestamps;
• uncommon claim combinations or overly precise values;
• presentation request identifiers and redirect URLs;
• IP addresses, cookies, browser fingerprints, push-notification tokens, and telemetry;
• verifier collusion or issuer-verifier communication;
• backup and synchronization providers that can observe wallet contents or use.

Use pairwise identifiers where a persistent relationship is actually required. Avoid identifiers entirely when the transaction does not need continuity. Batch or privacy-preserve status mechanisms where the applicable specification permits it, and test whether issuer infrastructure can learn when and where a credential is presented.

Status creates a difficult trade-off

A verifier may need to know whether a credential was suspended or revoked. A direct request containing a unique credential identifier can tell the status provider exactly which credential is being used and when. A downloaded status list can reduce per-presentation contact but introduces freshness, size, caching, and false-positive considerations. Short-lived credentials reduce the status window but require more frequent issuance.

There is no universal answer. Choose a method based on the harm of accepting a revoked credential, the harm of presentation tracking, expected connectivity, credential lifetime, and recovery process. Document what “current” means and how the verifier behaves when status information is unavailable.

Holder control must be meaningful

A consent screen is not meaningful if it shows internal claim names, obscures the verifier, bundles optional and required data, or offers no practical alternative. Before release, the wallet should clearly show:

• who is asking and how that identity was authenticated;
• which facts will be disclosed or proved;
• why each fact is requested;
• whether the verifier expects to retain it;
• which items are optional;
• whether the presentation can be linked to earlier uses;
• what declining means.

Do not let a verifier silently escalate from an age predicate to a birth date because one format is easier to process. Wallet policy can flag requests that exceed a purpose-specific template, but automated warnings should not be the only protection against systematic overcollection.

Verification is more than signature checking

A verifier needs a policy for the issuer, credential type, securing mechanism, schema, validity period, status, audience, nonce or challenge, holder binding, and expected disclosed claims. It must reject extra claims it did not request rather than quietly storing them. It also needs replay protection and clear separation between verified content and unprotected envelope data.

Test at least:

• a valid minimal presentation;
• missing mandatory claims and unexpected additional claims;
• altered, duplicated, reordered, or malformed disclosures;
• digest and salt edge cases;
• expired, not-yet-valid, suspended, and revoked credentials;
• an untrusted issuer or key;
• replayed presentations and mismatched audience or nonce;
• holder-binding failure and device replacement;
• offline and unavailable-status behavior;
• cross-verifier and issuer-verifier correlation attempts;
• recovery, backup restoration, deletion, and account redress.

Use official test vectors and cross-implementation suites for the exact specification versions deployed. A library that parses a format is not proof that the full trust and privacy model is correct.

Minimize what every party retains

The verifier should normally store the decision and the evidence necessary to justify it, not an entire reusable presentation. The issuer should avoid learning presentation history unless the use case genuinely requires it. The wallet should protect credentials, keys, consent history, backups, and recovery paths as sensitive data.

Retention policies need technical enforcement: field-level logging controls, redaction, deletion jobs, access restrictions, backup expiry, and tests that prevent raw credentials from entering analytics or support systems. Incident planning should assume that disclosed claims and wallet metadata can be breached.

A practical acceptance standard

A selective-disclosure system is ready when it can demonstrate, for defined use cases, that:

• the verifier requests only claims tied to a documented decision;
• the holder sees and controls the actual disclosure;
• hidden claims cannot be recovered by guessing or implementation mistakes;
• replay, substitution, downgrade, and malformed-presentation cases fail safely;
• status and holder binding meet the risk requirement without unnecessary tracking;
• pairwise or one-time use prevents correlation where promised;
• logs, backups, analytics, and support tools do not recreate the full identity profile;
• accessible fallback and redress paths exist;
• independent implementations exchange and verify the same profiles.

Selective disclosure is valuable because it changes the default from sharing a document to proving a necessary fact. Its success should be measured by the personal data that never reaches the verifier, not by the number of cryptographic features in the wallet.