Most digital services do not need to know everything about a person.

An age-restricted platform may need to know that a customer is over 18. It does not necessarily need the customer’s exact date of birth, home address, passport number and photograph.

An employer portal may need confirmation that a contractor holds a valid qualification. It may not need a complete academic transcript.

A healthcare service may need proof of insurance eligibility. It may not need to retain the person’s entire insurance document.

Yet conventional digital verification often requires users to upload full identity documents, complete lengthy forms or create another centralised profile containing information unrelated to the transaction.

Selective disclosure offers a different model.

Instead of transferring an entire document or identity record, a person can present only the specific claims required for a decision. The receiving service verifies the authenticity and integrity of those claims without automatically receiving everything else in the original credential.

This changes the central design question from:

Which identity document should we collect?

to:

What is the minimum verifiable fact required to make this decision?

That is the foundation of verification without over-collection.

---

Quick answer: What is selective disclosure?

Selective disclosure is a privacy-preserving method that allows a person to reveal only specific claims from a larger credential or dataset.

For example, a digital credential may contain:

• Full name
• Date of birth
• Address
• Nationality
• Identification number
• Photograph

An age-restricted service may receive only:

Age over 18: confirmed

The service can verify that the claim was issued by a recognised authority and has not been altered, without receiving the person’s exact birth date or unrelated identity details.

A well-designed selective-disclosure service combines:

1. A trusted issuer
2. A secure credential
3. A user-controlled wallet or presentation mechanism
4. A verifier requesting defined claims
5. A consent and policy layer
6. Cryptographic verification
7. Minimal retention after the decision

Selective disclosure is therefore both a cryptographic capability and a product-design discipline.

Key takeaways

1. Selective disclosure lets users reveal specific claims without presenting every claim in the original credential.
2. Data minimisation begins with the verifier’s request. A service that asks for unnecessary claims is not privacy-preserving simply because the credential supports selective disclosure.
3. Proving a condition such as “over 18” is different from merely disclosing a date of birth.
4. Not every selective-disclosure technology provides presentation unlinkability.
5. W3C Verifiable Credentials 2.0 provides a standard data model but does not require one particular selective-disclosure cryptographic mechanism. [2]
6. SD-JWT is now standardised as RFC 9901 for selectively disclosing individual elements of signed JSON data. [3]
7. BBS-based credentials can produce selectively disclosed and cryptographically unlinkable derived proofs, although the W3C BBS cryptosuite remains on the Recommendation track rather than being a final Recommendation as of June 2026. [4]
8. OpenID4VP provides a standard protocol through which verifiers can request particular credentials and claims and wallets can return user-approved presentations. [5]
9. Selective disclosure supports GDPR principles such as data minimisation and data protection by design, but it does not by itself establish a lawful basis or satisfy every data-protection obligation. [1]
10. The strongest system verifies the minimum necessary fact and then stores the minimum necessary result.

What problem does selective disclosure solve?

Many verification processes collect source documents rather than the facts actually required.

A hotel may ask for a passport when it needs identity and residency information.

An online marketplace may request an identity-document scan when it needs to know that a seller completed a defined verification process.

A membership platform may collect a full employee record when it needs proof that the person belongs to an approved organisation.

This approach creates several problems.

Unnecessary exposure

The document contains more information than the decision requires.

A driving licence shown for age verification may expose:

• Full name
• Exact date of birth
• Photograph
• Address
• Licence number
• Signature
• Vehicle entitlements

Larger breach impact

Every additional stored attribute creates more information that may be:

• Stolen
• Leaked
• Misused
• Shared improperly
• Retained too long
• Combined with other datasets

Repeated verification

The same person may upload the same document to:

• Employers
• Financial services
• Marketplaces
• Travel services
• Healthcare portals
• Education platforms

Each organisation creates another copy and another potential exposure point.

Weak user control

Users frequently cannot determine:

• Which fields are actually required
• Which fields will be retained
• Who can access them
• How they will be reused
• When they will be deleted

Expensive operations

Full-document verification can require:

• Image capture
• Optical character recognition
• Fraud detection
• Manual review
• Secure document storage
• Data-subject request handling
• Retention management
• Breach-response planning

Selective disclosure attempts to separate the evidence required for a decision from the complete document that originally established that evidence.

---

Selective disclosure begins with data minimisation

Selective disclosure is often described as a credential feature.

Its real value begins before a credential is requested.

The verifier must first determine:

• What decision is being made?
• Which information is genuinely necessary?
• Can the decision be made with a yes-or-no result?
• Is an identifying attribute required?
• Does the information need to be retained?
• How long should the result remain valid?
• Which issuer or assurance level is acceptable?

The GDPR defines data minimisation as processing data that is adequate, relevant and limited to what is necessary for the stated purpose. It also requires controllers to implement data-protection principles through appropriate technical and organisational measures and, by default, process only the personal data necessary for each purpose. [1]

Selective disclosure can become one of those technical measures.

It does not replace the underlying analysis.

A useful design sequence

Do not begin with:

Request passport

Begin with:

Decision:
Is the user old enough to access this service?

Minimum evidence:
A trusted assertion that the required age threshold is satisfied.

Not required:
Full name
Exact date of birth
Address
Passport number
Passport photograph
Nationality

The difference is architectural.

One design verifies a condition.

The other collects a person.

What selective disclosure is not

It is not simply hiding fields in the interface

A service may receive the complete identity record while displaying only selected fields to an employee.

That is interface-level masking, not selective disclosure.

The unnecessary information has still been transferred and may still be stored.

It is not ordinary access control

Access control determines who can view stored information.

Selective disclosure reduces which information enters the receiving system in the first place.

It is not encryption alone

Encryption protects data from unauthorised access.

Once the intended service decrypts the information, it receives the full dataset.

Selective disclosure limits the information disclosed to the authorised service.

It is not pseudonymisation

Pseudonymisation replaces or separates identifiers so that information cannot be attributed to a person without additional data.

Selective disclosure controls which claims are presented during a transaction.

The approaches can be combined.

It is not automatically a zero-knowledge proof

Some selective-disclosure schemes reveal chosen signed claims while hiding other claims.

A zero-knowledge proof can prove a statement without revealing the underlying value.

These are related but distinct capabilities.

It is not anonymous access by default

A presentation can disclose:

• Full name
• Account identifier
• Employee number
• Email address
• Stable pseudonym

Even when all other claims remain hidden, the presentation may still identify or correlate the person.

Core concepts

Concept	Meaning
Claim	A statement about a subject, such as a date of birth or membership status
Credential	A collection of claims issued and cryptographically secured by an issuer
Issuer	The organisation that makes and signs the claims
Holder	The person or entity that receives and presents the credential
Verifier	The service that requests and evaluates evidence
Presentation	The package of credential information sent to the verifier
Selective disclosure	Revealing chosen claims while withholding others
Predicate proof	Proving a condition, such as age being above a threshold, without revealing the underlying value
Holder binding	Evidence that the presenter legitimately controls or possesses the credential
Purpose binding	Connecting a data request to a defined and communicated purpose
Unlinkability	Preventing separate presentations from being correlated as belonging to the same holder
Trust registry	A mechanism for identifying recognised issuers, schemas or authorities
Status service	A mechanism for determining whether a credential is valid, suspended or revoked

Claim disclosure versus predicate proof

Suppose a credential contains:

Date of birth: 1992-08-17

There are several ways a service might verify age.

Full disclosure

The wallet reveals the complete date of birth.

The verifier calculates the age.

This is simple, but the verifier receives more information than needed.

Attribute disclosure

The issuer includes another claim:

Age over 18: true

The wallet reveals that claim but withholds the date of birth.

This is selective disclosure and is sufficient for many services.

Predicate proof

The wallet creates cryptographic evidence that:

Current date - date of birth >= 18 years

without revealing the date of birth.

This is a stronger privacy capability, but it requires a credential and proof system that supports the relevant predicate.

Selective disclosure should not be described as predicate proving unless the technology genuinely supports it.

For many practical deployments, issuing purpose-specific claims such as age_over_18 may be simpler than implementing general cryptographic range proofs.

How selective disclosure works

The common model contains four stages:

1. Issuance
2. Wallet storage and selection
3. Presentation and verification
4. Decision

Step 1: An issuer verifies the original information

A recognised organisation establishes the facts it intends to certify.

Examples include:

• A government confirming an age or residency attribute
• A university confirming a degree
• An employer confirming a role
• An insurer confirming coverage
• A professional body confirming a licence
• A membership organisation confirming status

Selective disclosure does not remove the original evidence-validation process.

It changes how the result is later presented.

Step 2: The issuer creates a credential

The credential contains defined claims and supporting metadata such as:

• Issuer
• Credential type
• Validity period
• Subject information
• Status information
• Cryptographic protection
• Holder-binding information where applicable

W3C Verifiable Credentials 2.0 standardises an issuer-holder-verifier data model for expressing and securing such credentials. [2]

Step 3: The holder receives the credential

The holder stores the credential in a wallet or another secure credential-management environment.

OpenID4VCI provides an OAuth-protected protocol for issuing credentials to wallets and supports multiple credential formats. [6]

Step 4: The verifier defines its requirements

The verifier should request a business requirement rather than a broad document category.

For example:

Required:
Proof that age is at least 18

Accepted issuers:
Recognised government authorities

Required freshness:
Credential must be valid at presentation

Retention:
Store verification result, not credential

OpenID4VP’s Digital Credentials Query Language allows verifiers to describe credential and individual-claim requirements. [5]

Step 5: The wallet evaluates the request

The wallet determines:

• Which credential can satisfy the request
• Which claims would be disclosed
• Whether the verifier is recognised
• Whether the request is permitted
• Whether the user must approve it
• Whether a less revealing presentation is available

Step 6: The wallet explains the disclosure

A useful consent screen should identify:

• The requesting service
• The purpose
• The claims being requested
• Which issuer provided them
• Whether the service intends to retain them
• Whether presentation is optional
• What happens if the user declines

A checkbox labelled “I agree” is not meaningful transparency when the user cannot understand what is being shared.

Step 7: The holder approves the claims

The holder approves the presentation.

OpenID4VP recommends explicit, informed consent before a wallet releases a credential or presentation. [5]

Step 8: The wallet creates the presentation

Depending on the credential technology, the wallet may:

• Attach chosen disclosures to an issuer-signed token
• Derive a new proof containing only selected claims
• Present chosen data elements
• Combine claims from several credentials
• Bind the presentation to the intended verifier and transaction

Step 9: The verifier checks the presentation

Verification may include:

• Issuer signature
• Credential integrity
• Issuer trust
• Credential type
• Validity period
• Credential status
• Holder binding
• Audience binding
• Transaction nonce
• Requested claim satisfaction
• Applicable policy

Step 10: The service makes the decision

The service should use the verified result for the intended purpose.

It should not automatically convert every presentation into a permanent identity profile.

Selective-disclosure technologies

There is no single universal implementation.

The correct approach depends on:

• Credential format
• Privacy requirements
• Existing infrastructure
• Interoperability profile
• Device constraints
• Issuer capabilities
• Required unlinkability
• Offline requirements
• Regulatory environment

W3C Verifiable Credentials 2.0

The W3C Verifiable Credentials Data Model defines how issuers, holders and verifiers represent credentials and presentations.

It is a data model rather than one mandatory cryptographic format.

Different proof mechanisms can be used to secure credentials and provide different privacy properties. [2]

SD-JWT

Selective Disclosure for JSON Web Tokens is defined by RFC 9901.

The issuer signs a JWT containing cryptographic digests of claims that can be selectively disclosed.

The holder retains the associated disclosures and later releases only the selected ones.

The verifier checks that:

• The issuer signed the SD-JWT
• Each disclosed value matches its signed digest
• The token and disclosure are valid
• Holder binding is valid where required

Advantages include:

• Familiar JWT and JOSE foundations
• Straightforward JSON processing
• Claim-level selective disclosure
• Compatibility with OAuth-oriented systems

Important limitations include:

• Undisclosed values remain hidden, but presentation unlinkability is not automatic.
• The issuer-signed credential is visible to the verifier.
• Colluding issuers and verifiers may be able to correlate presentations.
• Stable metadata or disclosed claims may permit correlation.
• Credential storage and logging must be minimised.

RFC 9901 explicitly distinguishes selective disclosure from anonymous credentials and documents its unlinkability limitations. [3]

SD-JWT VC

SD-JWT VC applies SD-JWT mechanisms to verifiable digital credentials.

As of June 2026, the core SD-JWT mechanism is an RFC, while the SD-JWT VC credential-format specification remains an active IETF Internet-Draft. [11]

Organisations should therefore follow the exact interoperability profile required by their ecosystem rather than assuming that every implementation uses identical claims or metadata.

BBS-based proofs

BBS signatures can allow a holder to generate a derived proof containing selected claims.

Each derived proof can use cryptographic randomisation, making the proof artefact unlinkable to:

• The original issuer signature
• Another derived proof from the same credential

This provides stronger presentation-privacy properties than salted-hash selective-disclosure methods.

However:

• BBS integration is more cryptographically complex.
• The current W3C BBS cryptosuite is still advancing through the Recommendation process.
• Unlinkable proof artefacts do not prevent correlation through disclosed values, IP addresses, cookies, device fingerprints or other metadata.
• Selective disclosure does not automatically provide arbitrary predicate proofs.

[4]

ISO mobile-document formats

Mobile-document formats can support selective presentation of individual data elements and are used in high-assurance identity ecosystems.

OpenID4VP can carry presentations using formats including ISO mdoc, SD-JWT VC and W3C Verifiable Credentials. [5]

As with SD-JWT, selective data-element disclosure should not be assumed to provide complete unlinkability.

OpenID4VP

OpenID for Verifiable Presentations standardises how a verifier requests credentials or claims and how a wallet returns presentations.

It provides:

• Same-device flows
• Cross-device flows
• Credential queries
• Selective claim requests
• User consent
• Holder-binding support
• Audience and nonce binding
• Replay protection
• Multiple credential-format support

OpenID4VP does not itself determine which claims a service is legally or ethically justified in requesting.

Comparison

Approach	Minimises disclosure	Portable credential	Strong presentation unlinkability	Typical strength
Full document upload	No	Limited	No	Familiar but data-heavy
Conventional account database	Depends on design	No	Usually no	Effective inside one service
OpenID Connect claim filtering	Yes, to a degree	Limited	Identity provider remains involved	Federated login
Signed credential without selective disclosure	No	Yes	No	Portable authenticity
SD-JWT	Yes	Yes	Limited by design and deployment	Web-friendly claim disclosure
ISO mdoc data-element disclosure	Yes	Yes	Limited by design and deployment	High-assurance identity documents
BBS-derived proof	Yes	Yes	Stronger cryptographic unlinkability	Privacy-focused VC presentation
Purpose-specific predicate credential	Yes	Yes	Depends on format	Simple yes-or-no verification

Selective disclosure versus OpenID Connect

OpenID Connect can already release selected identity claims.

For example, an identity provider might return:

name
email
email_verified

instead of a complete user profile.

That is useful data minimisation, but the trust model differs.

Federated identity

The identity provider participates in the interaction and authenticates the user.

The service receives claims from that provider during the login flow.

Holder-mediated credentials

The issuer provides a credential earlier.

The holder later presents it through a wallet, potentially without the issuer participating in each transaction.

This can improve:

• Portability
• Offline or proximity use
• Cross-ecosystem verification
• Holder control
• Reduced issuer visibility

The correct choice depends on the use case.

A service that only needs ordinary login may not require verifiable credentials.

Real-world applications

1. Age verification

The service requests:

Age threshold satisfied: yes

instead of:

Full date of birth
Identity-document scan
Home address
Document number

The European Digital Identity Wallet programme presents age verification as a key selective-disclosure use case: confirming an age threshold without revealing a complete date of birth or unrelated identifying information. [9]

2. Employee and contractor access

A workplace may need to verify:

• Active employment
• Approved organisation
• Role
• Safety training
• Site authorisation

It may not need a worker’s personal address, salary or full employment record.

3. Education and qualifications

An applicant may prove:

• Degree awarded
• Professional licence
• Certification status
• Completion date
• Accreditation

without sharing unrelated grades or a full academic transcript.

4. Healthcare eligibility

A patient may prove:

• Active insurance coverage
• Eligibility for a programme
• Approved referral
• Professional-provider status

without exposing the complete insurance or medical record.

Healthcare implementations require particularly careful metadata and correlation analysis because even the type of credential presented may reveal sensitive information.

5. Customer onboarding

A service might verify:

• Identity assurance completed
• Residency
• Address verification
• Age threshold
• Sanctions screening completed

without retaining the source identity documents used by the issuer.

The service must still determine whether regulations require it to retain particular evidence.

Selective disclosure cannot override legal record-keeping obligations.

6. Membership and entitlement

A service can verify:

• Active membership
• Subscription tier
• Employee entitlement
• Student status
• Professional association status

without collecting the complete membership file.

7. Travel and mobility

A traveller may present selected identity or entitlement information to:

• Transport operators
• Car-rental companies
• Hotels
• Border-related services
• Local mobility systems

The required attributes may vary by service and jurisdiction.

8. Business and supplier verification

Selective disclosure also applies to organisations.

A company may prove:

• Legal registration
• Tax status
• Insurance coverage
• Certification
• Authorised representative
• Supplier approval

without disclosing its complete internal compliance record.

A production selective-disclosure architecture

Selective disclosure is not implemented by adding one cryptographic library to a checkout form.

A production system needs several coordinated layers.

1. Digital service and channel layer

Users may interact through:

• Websites
• Mobile applications
• Kiosks
• Partner portals
• In-person devices
• Call-centre-assisted journeys

Each channel should request the same minimum evidence for the same decision.

2. Verification API

The verification interface should accept a business-oriented request such as:

{
  "decision": "age_restricted_access",
  "required_claim": "age_over_18",
  "accepted_trust_framework": "approved_public_issuers",
  "retention_policy": "result_only"
}

It should not require every product team to understand the internal cryptographic format.

3. Policy and consent engine

This layer determines:

• Which claims may be requested
• Which purpose justifies the request
• Which issuers are accepted
• Which assurance level is required
• Whether user consent is necessary
• What may be stored
• How long it may be retained
• Whether a less revealing presentation is available

4. Credential wallet

The wallet manages:

• Credentials
• Holder keys
• User authentication
• Presentation selection
• Consent
• Disclosure
• Transaction history
• Recovery

5. Issuance service

The issuer requires:

• Identity or evidence verification
• Credential construction
• Cryptographic signing
• Holder binding
• Renewal
• Suspension or revocation
• Support and correction processes

6. Trust registry

The verifier needs to determine:

• Which issuers are recognised
• Which credential schemas are accepted
• Which trust framework applies
• Which accreditation remains valid
• Which keys belong to an issuer

Cryptographic validity alone does not establish that an issuer is legally or professionally authorised to make a claim.

7. Credential-status service

The verifier may need to determine whether a credential has been:

• Revoked
• Suspended
• Replaced
• Expired

Status checking should be designed to avoid informing the issuer whenever and wherever a credential is used.

8. Audit and observability

The system needs enough evidence to investigate:

• Which policy was applied
• Which verifier made the request
• Which claim categories were disclosed
• Whether the user approved the request
• Whether verification succeeded

It should avoid storing complete presentations in logs merely because logging is technically convenient.

9. Security and privacy controls

These include:

• Encryption
• Key management
• Secret protection
• Rate limiting
• Anti-replay controls
• Verifier authentication
• Data-loss prevention
• Retention enforcement
• Incident response
• Privacy-impact assessment

Design principles

1. Start with the decision, not the document

Define:

Decision:
Allow access to an age-restricted service.

Required evidence:
Trusted proof that the threshold is satisfied.

Do not default to:

Required evidence:
Government identity document.

2. Request the least revealing evidence

A good preference order is:

1. Boolean or predicate result
2. Purpose-specific attribute
3. Broader attribute
4. Complete credential
5. Source document

Move down the list only when necessary.

3. Separate verification from account creation

A service may need to verify age without creating a permanent identified account.

Do not automatically turn every verified interaction into a customer identity profile.

4. Explain the purpose

A wallet prompt should not say only:

Example.com requests date of birth.

It should say:

Example.com needs to confirm that you are over 18
to provide access to age-restricted content.

It will receive:
Over 18: confirmed

It will not receive:
Your exact date of birth
Your full identity document
Your home address

5. Make the verifier identifiable

The holder should know which legal or organisational entity is requesting information.

A familiar logo alone is insufficient.

The wallet may need to validate:

• Registered verifier identity
• Domain or application binding
• Authorised request endpoint
• Trust-framework membership
• Credential-request permissions

6. Bind presentations to the transaction

Presentations should be bound to:

• The intended verifier
• The current transaction
• A fresh nonce
• The expected audience

This prevents a valid presentation captured during one transaction from being replayed elsewhere.

OpenID4VP specifies audience and nonce binding for replay protection. [5]

7. Minimise retention

After a successful age check, the service may need to store:

Age requirement checked: yes
Policy version: 4
Checked at: timestamp
Credential trust level: accepted

It may not need to store:

• The credential
• The full presentation
• The issuer-signed token
• The underlying date of birth
• The user’s other claims

Retention requirements depend on applicable law, risk and dispute needs.

8. Minimise logs

Credentials and signed presentations are high-value records.

Do not place them in:

• Debug logs
• Analytics events
• Error-monitoring payloads
• URL query parameters
• Support tickets
• Data warehouses

RFC 9901 specifically recommends minimising storage of SD-JWTs and disclosures, including in log files. [3]

9. Avoid unnecessary stable identifiers

A globally stable holder identifier can allow several services to correlate the person.

Use a stable identifier only where the business genuinely requires account continuity.

Alternatives can include:

• Pairwise identifiers
• Per-verifier pseudonyms
• Limited-use credentials
• One-time presentations
• Session-bound evidence

10. Support refusal and alternatives

A person should be able to understand:

• Whether presentation is mandatory
• Why it is required
• What happens if they refuse
• Whether an alternative verification route exists
• How to challenge an incorrect result

11. Design for accessibility

A wallet-only process can exclude users who:

• Do not own a compatible device
• Cannot use the interface
• Lack connectivity
• Lost access to their wallet
• Cannot obtain the required credential

Privacy-preserving technology should not create a new barrier to essential services.

Privacy and security risks

Selective disclosure reduces some risks while introducing others.

Over-disclosure

A verifier may request more claims than the transaction requires.

The wallet may technically support selective disclosure while approving an excessive request.

The W3C decentralized-credential threat model identifies over-disclosure and failure to prefer the least revealing presentation as core privacy risks. [10]

Correlation through disclosed claims

A combination such as:

Profession
Postcode
Age range
Employer

may uniquely identify a person even when their name is withheld.

Data minimisation must consider combinations, not only individual fields.

Cryptographic correlation

Some formats reuse issuer-signed material or stable key-binding information across presentations.

RFC 9901 explains that SD-JWT does not provide all anonymous-credential unlinkability properties. [3]

Metadata correlation

A verifier may correlate users through:

• IP address
• Browser fingerprint
• Device characteristics
• Wallet metadata
• Cookies
• Request timing
• Network identifiers
• Stable public keys

Cryptographically unlinkable proofs do not remove ordinary web tracking.

Issuer tracking

If the verifier contacts the issuer to validate every presentation, the issuer may learn where or when the credential is used.

Status mechanisms should minimise this leakage.

Verifier impersonation

A malicious service may imitate a legitimate verifier and request valuable credentials.

Wallets should authenticate or evaluate the requesting party and clearly show its identity.

Replay attacks

An attacker may capture a presentation and reuse it.

Audience, nonce and holder-binding controls help prevent replay.

Wallet compromise

A compromised device or wallet could expose:

• Credentials
• Holder keys
• Presentation history
• Personal attributes

Recovery mechanisms must balance usability with resistance to account takeover.

Coercive consent

A user may technically approve a disclosure but have no meaningful choice because the service is essential or the request is confusing.

Consent screens do not make unnecessary collection legitimate.

Verification confused with truth

A valid signature proves that an issuer made a claim and that the credential has not been altered.

It does not prove that the issuer’s original investigation was correct.

Disclosure normalisation

Making digital credentials easy to request could encourage services to demand official attestations for ordinary interactions that previously did not require them.

Selective disclosure should reduce evidence, not normalise identity checks everywhere. [10]

A practical implementation roadmap

Phase 1: Select one decision

Choose a narrow use case:

• Confirm age threshold
• Confirm employment
• Confirm membership
• Confirm qualification
• Confirm insurance eligibility

Phase 2: Define the minimum evidence

For each decision, document:

• Required fact
• Accepted issuer
• Required assurance
• Freshness
• Retention
• Whether identity continuity is needed

Phase 3: Conduct a data-protection analysis

Determine:

• Purpose
• Legal basis
• Necessity
• Data categories
• Risks
• Retention
• User rights
• Alternative processes
• Applicable jurisdiction

Phase 4: Choose the credential strategy

Decide whether the requirement is best served by:

• Conventional federation
• Signed API response
• Verifiable credential
• SD-JWT
• ISO mdoc
• BBS-derived proof
• Purpose-specific credential
• A combination

Phase 5: Define claim semantics

A claim such as:

verified = true

is ambiguous.

Define:

• Verified by whom
• Against which process
• At which assurance level
• On which date
• For which jurisdiction
• Until when it remains valid

Phase 6: Design the verifier request

Specify:

• Requested claim
• Purpose
• Retention
• Accepted credential types
• Accepted issuers
• Optional versus required claims
• Presentation format
• Transaction binding

Phase 7: Design the consent experience

Test whether users can correctly explain:

• Who is requesting data
• Which data will be shared
• Why it is needed
• Which data remains private
• What happens after approval

Phase 8: Implement verification

Validate:

• Signature or proof
• Disclosure digests
• Issuer trust
• Credential status
• Expiry
• Holder binding
• Audience
• Nonce
• Policy satisfaction

Phase 9: Implement retention controls

Automate:

• Presentation deletion
• Log redaction
• Token expiry
• Access review
• Data-subject requests
• Retention-policy enforcement

Phase 10: Threat-model the complete interaction

Include:

• Issuer
• Wallet
• Verifier
• Browser or operating system
• Status service
• Registry
• Network
• Analytics
• Support systems
• Logs

Phase 11: Test interoperability

Test across:

• Multiple issuers
• Multiple wallets
• Multiple verifiers
• Different credential formats
• Same-device flows
• Cross-device flows
• Expired credentials
• Revoked credentials
• Refused consent
• Recovery scenarios

Phase 12: Measure outcomes

Useful measures include:

• Average claims disclosed per transaction
• Percentage of requests using predicates or purpose-specific attributes
• Complete documents avoided
• Presentation-retention time
• User refusal rate
• User comprehension
• Verification success
• False acceptance
• False rejection
• Support incidents
• Privacy-policy violations
• Time required to complete verification

What should a verifier store?

Data	Typical recommendation
Full credential	Avoid unless legally necessary
Complete presentation	Avoid long-term retention
Undisclosed claims	Should never be received
Verification decision	Store where operationally necessary
Policy version	Useful for auditability
Verification timestamp	Often useful
Issuer or trust level	May be useful
Full subject identifier	Only where continuity is required
Cryptographic proof	Retain only when justified
Consent record	Retain proportionately
Raw wallet metadata	Avoid unless operationally necessary

The correct policy depends on law, dispute handling and sector-specific requirements.

The principle remains:

Store evidence of the decision, not an identity dossier, whenever that satisfies the purpose.

When selective disclosure may be unnecessary

Selective disclosure can add architectural and operational complexity.

A simpler method may be better when:

• One organisation already holds the data and makes the decision internally
• No data crosses an organisational boundary
• A yes-or-no API from an authoritative source is sufficient
• The information changes continuously and must be checked live
• The claim will never be reused
• A conventional anonymous-access model requires no identity evidence
• The service should not verify identity at all

The privacy-preserving alternative to collecting fewer identity claims may sometimes be collecting none.

The emerging standards landscape

Several standards now provide building blocks for interoperable selective disclosure:

• W3C Verifiable Credentials Data Model 2.0 for credential representation [2]
• RFC 9901 for selective disclosure in JWTs [3]
• OpenID4VCI for credential issuance [6]
• OpenID4VP for requesting and presenting credentials [5]
• W3C BBS cryptosuite work for selectively disclosed, unlinkable derived proofs [4]
• EUDI Wallet regulations and implementing rules requiring selective-disclosure support [7][8]

The standards do not remove the need for ecosystem agreements.

Participants must still define:

• Accepted issuers
• Credential schemas
• Assurance levels
• Claim semantics
• Retention
• Status
• Liability
• Dispute resolution
• Accessibility
• Recovery

The EU Digital Identity Wallet as a major implementation driver

The amended European digital-identity framework describes selective disclosure as a basic design capability of the European Digital Identity Wallet.

It states that users should be able to disclose selected attributes, including attributes from multiple attestations, so that relying parties receive only information necessary for the requested service. [7]

Implementing rules also require wallet solutions to support selective disclosure of attributes from personal identification data and electronic attestations of attributes. [8]

This is likely to make selective-disclosure design relevant to far more public and private digital services.

The important lesson extends beyond Europe:

Wallet support does not make a service privacy-preserving unless the service requests, uses and retains information responsibly.

The future of verification

Digital verification is moving away from copying documents and toward evaluating trusted claims.

The old model is:

Collect
Store
Review
Trust

The emerging model is:

Request a defined claim
Receive minimal evidence
Verify cryptographically
Apply policy
Retain the minimum result

This creates an opportunity to redesign onboarding, access and eligibility journeys around decisions rather than identity-document collection.

The most valuable services will not simply support selective-disclosure credentials.

They will understand when identity is unnecessary, when a predicate is sufficient and when a stable relationship is genuinely required.

Conclusion

Selective disclosure makes it possible to verify more while collecting less.

It can help digital services confirm:

• Age
• Residency
• Membership
• Employment
• Qualification
• Eligibility
• Verification status

without automatically receiving the complete underlying identity record.

But privacy does not come from cryptography alone.

A service must still:

• Define a legitimate purpose
• Request the minimum evidence
• Explain the request clearly
• Authenticate the verifier
• Obtain meaningful approval where required
• Prevent replay
• Minimise correlation
• Restrict retention
• Protect logs
• Provide recovery and alternatives
• Respect data-protection obligations

The most important design question is not:

Which attributes can this credential disclose?

It is:

What is the least information this service must know to make the required decision safely and fairly?

When that question guides the architecture, selective disclosure becomes more than an identity feature.

It becomes a practical model for privacy by design.

Frequently Asked Questions

What is selective disclosure?

Selective disclosure lets a person reveal chosen claims from a credential while withholding other claims.

What is an example of selective disclosure?

A person can prove that they are over 18 without revealing their exact birth date, address or identity-document number.

Is selective disclosure the same as data minimisation?

No. Selective disclosure is a technical mechanism. Data minimisation is the wider principle of processing only information necessary for a defined purpose.

Is selective disclosure a zero-knowledge proof?

Not always. Some systems reveal selected signed claims. Zero-knowledge proofs can establish a statement without revealing the underlying value.

What is the difference between selective disclosure and a predicate proof?

Selective disclosure reveals a chosen claim. A predicate proof demonstrates that a condition is true, such as an age being above a threshold, without revealing the source value.

Do verifiable credentials support selective disclosure?

They can, but the privacy properties depend on the credential format and cryptographic proof mechanism.

What is SD-JWT?

SD-JWT is a standard mechanism that allows holders to reveal selected elements from signed JSON Web Token data.

Does SD-JWT provide unlinkability?

Not complete unlinkability. Its privacy properties are more limited than anonymous-credential systems, particularly where issuers and verifiers collude.

What are BBS credentials?

BBS-signed credentials can generate selectively disclosed derived proofs whose cryptographic proof artefacts are unlinkable to the original signature and other proofs.

Does selective disclosure prevent all tracking?

No. IP addresses, cookies, device fingerprints, stable identifiers and disclosed attributes can still enable correlation.

Does selective disclosure satisfy GDPR automatically?

No. It can support data minimisation and privacy by design, but organisations must still establish purpose, legal basis, retention, transparency and other safeguards.

What is OpenID4VP?

OpenID4VP is a standard protocol through which verifiers request credentials or claims and wallets return user-approved presentations.

Does the verifier need to store the credential?

Usually not. Many services can retain the verification result and relevant policy evidence instead of retaining the complete credential.

Can selective disclosure work without blockchain?

Yes. Blockchain is not required for selective disclosure or verifiable credentials.

Can selective disclosure be used for businesses?

Yes. Organisations can selectively prove registration, insurance, accreditation, licences and authorised representation.

What is the biggest selective-disclosure risk?

The greatest risk is designing a technically selective system in which verifiers still request, retain or correlate more information than the transaction requires.