Selective attribute disclosure is a technique that lets a person reveal only chosen facts from a digital credential, such as being over a certain age, while keeping every other detail on that credential hidden. The verifier still gets cryptographic assurance that the revealed facts came from a trusted issuer.
With a plastic ID card, showing your age means also showing your name, address and document number. This article explains how digital credentials break that link, which techniques make it possible, where the approach appears in real standards and what it cannot protect against.
Why Showing a Whole Card Is the Wrong Default
Physical documents were designed for a world where a person glanced at a card and handed it back. Nothing was recorded. Digital checks are different, because a scanner or app can capture every field instantly and keep it indefinitely, turning a quick glance into a permanent record.
Imagine a hypothetical concert venue that scans IDs at the door. It needs to know one thing: whether each guest meets the age requirement. A full scan, however, gives the venue names, home addresses and exact birth dates for thousands of people, which becomes a tempting target for attackers.
Selective disclosure changes the default from all or nothing to just enough. The person presents a credential, the venue requests an age claim, and only that claim is released and verified. The rest of the document remains on the person’s device and never reaches the venue’s systems.
The Three Roles in Every Presentation
Selective disclosure systems usually involve three roles. The issuer is the authority that creates and signs the credential, such as a motor vehicle agency or a university. The holder is the person who stores the credential, typically in a digital wallet app on a phone.
The verifier is the party that requests and checks information, such as a retailer, employer or online service. A presentation is the package the holder sends to the verifier, containing the chosen attributes and the cryptographic material that proves they are authentic and unchanged.
The key requirement is that the issuer’s signature must still validate even though some attributes are withheld. Ordinary digital signatures cover a whole document, so removing any field breaks the signature. Selective disclosure schemes are built specifically so that partial presentations remain verifiable without the issuer being contacted.
Three Technical Approaches Behind the Feature
Several cryptographic designs achieve selective disclosure. They differ in complexity, privacy strength and how widely they are supported, so it helps to understand them at a conceptual level before comparing products or standards.
Salted Hash Digests
In this approach, the issuer combines each attribute with a random value called a salt and computes a hash, a short fingerprint of the data. The issuer signs the list of hashes rather than the attributes themselves.
To disclose an attribute, the holder sends its value and salt. The verifier recomputes the hash and checks that it appears in the signed list. Hidden attributes stay protected because their salts are never revealed.
Signatures That Support Derived Proofs
Some signature schemes, such as the BBS family now being standardized, let the holder derive a fresh proof from the original signature that covers only selected attributes.
Because each derived proof looks different, two presentations of the same credential are much harder to connect. This property, called unlinkability, gives stronger privacy than hash-based designs, at the cost of more complex cryptography and narrower tool support today.
Zero-Knowledge Predicates
A zero-knowledge proof lets someone prove a statement is true without revealing the underlying data. Applied to credentials, it can prove that a birth date falls before a cutoff without disclosing the date itself.
These predicate proofs offer fine-grained privacy but are computationally heavier, and their availability depends on the credential format and wallet in use.
Selective Disclosure in Mobile Driver’s Licenses
The international standard for mobile driver’s licenses, ISO/IEC 18013-5, uses a salted hash design. The issuing authority signs a structure containing digests of each data element, and the holder’s device releases only the elements a verifier requests and the holder approves.
The standard also supports age attestation elements, which state whether the holder is over particular ages. A verifier can request one of these instead of the full birth date. This works because the issuer has already computed the answer and signed it as a separate attribute.
Support depends on where you live and which agency issues your license, and acceptance by verifiers varies widely. Readers should check their own licensing authority to learn whether a mobile license is offered and which presentation options it supports in practice.
Selective Disclosure in Web-Oriented Credentials
For credentials used online, an IETF specification known as Selective Disclosure for JWTs, or SD-JWT, applies the salted hash idea to JSON Web Tokens. A JSON Web Token is a compact, signed data format widely used in web authentication and authorization systems.
W3C Verifiable Credentials, a data model for tamper-evident digital credentials, can be secured in several ways, including formats that support selective disclosure. The European Union’s Digital Identity Wallet work also draws on these formats, though technical details and timelines are set by EU and national authorities.
For developers, the practical point is that selective disclosure is becoming a standard capability rather than a research idea. Choosing formats with mature libraries, clear specifications and interoperability testing reduces the risk of building on an approach that verifiers will not accept.
What Selective Disclosure Does Not Hide
Selective disclosure protects the attributes you withhold, but it does not make a presentation anonymous. Several kinds of information can still reveal or connect your identity, and understanding them prevents overconfidence in the technology.
- The disclosed attributes themselves: revealing a name or account number identifies you regardless of what is hidden.
- Repeated signatures and digests: in hash-based designs, the same signed values appear each time, letting colluding verifiers link presentations.
- Device and network metadata: IP addresses and device details travel alongside the credential.
- Issuer contact: if checking revocation requires calling the issuer, the issuer may learn where the credential is used.
- Behavioral context: time, place and purchase details can narrow down who you are.
Issuers can reduce linkability in hash-based systems by giving each holder a batch of credentials and using a fresh one for each presentation. Stronger unlinkability usually requires signature schemes designed for derived proofs.
Holder Binding and Protection Against Replay
If a presentation could be copied and reused, anyone who intercepted it could pretend to be the holder. Holder binding prevents this by linking the credential to a cryptographic key stored on the holder’s device, ideally in secure hardware that resists extraction.
During a presentation, the device signs a fresh challenge from the verifier using that key. The verifier checks that the challenge signature matches the key named in the credential. A recorded presentation fails later because the challenge will be different each time.
Holder binding introduces a tradeoff. If the same device key appears in every presentation, it becomes a stable identifier that links uses together. Well-designed systems either rotate keys across credential batches or use proof techniques that show key possession without exposing the same value repeatedly.
Design Choices That Fall to the Issuer
Much of the privacy a holder enjoys is decided before the credential ever reaches a wallet. The issuer chooses how attributes are split, which predicates are precomputed and how revocation works. A credential that bundles name and birth date into one field cannot reveal them separately later.
Granularity is the first decision. Splitting an address into country, region and street lets a verifier request only the region. Precomputed claims, such as several age thresholds, let holders answer common questions without exposing exact values. Each extra element adds a little size and complexity to the credential.
Revocation is the second decision. A revocation mechanism tells verifiers whether a credential is still valid. Privacy-friendly designs publish status information in large shared lists that verifiers download, so the issuer cannot see which individual credential is being checked or by whom.
Batch issuance is the third. Issuing several copies with different salts and keys lets wallets rotate credentials, reducing linkability in hash-based designs at modest operational cost.
Rules for Verifiers Requesting Attributes
Selective disclosure only helps if verifiers ask for less. A verifier that requests every available attribute recreates the full-card problem in digital form. Responsible verifiers design requests around the decision they actually need to make.
- Start from the decision, such as age eligibility or license validity, and map it to the smallest attribute set.
- Prefer predicates like age-over claims to raw values like full birth dates.
- Declare the purpose in the request so wallets can display it to the holder.
- Avoid retaining presentations beyond what audit or legal duties require.
- Test with real wallets to confirm that requests render clearly for users.
Some digital identity frameworks provide for verifiers to register the attributes they intend to request, giving wallets a basis to warn users about overreaching demands. Requirements vary, so organizations should follow guidance from the authorities in their jurisdiction.
What Holders See and Should Check
For the person holding a credential, selective disclosure usually appears as a consent prompt inside a wallet app. The prompt names the verifier, lists the requested attributes and offers options to share or decline. Some wallets allow deselecting optional items before sharing.
Holders should confirm that the verifier’s name matches the service they are dealing with and that the request fits the situation. A bar asking for a home address, or a website asking for a document number to show a video, is a signal to decline.
Wallets may also show a history of past presentations. Reviewing that history occasionally helps people notice unexpected requests and understand which organizations have received which attributes, making it easier to follow up with access or deletion requests where local law allows.
Preparing for Wider Adoption
Organizations planning to accept digital credentials can begin by listing every place they currently collect identity documents and noting which single fact each process truly needs. That list becomes the blueprint for future selective disclosure requests and highlights where full scans can be retired.
Developers should track the maturity of formats such as SD-JWT, mobile license standards and signature schemes that support derived proofs, and favor well-maintained libraries over custom cryptography. Security reviews should cover holder binding, revocation checks and how presentations are logged.
For individuals, the practical step is simpler: when a service offers a wallet-based check instead of a document upload, consider choosing it, and read each request before approving. Over time, those choices encourage services to ask for one fact instead of everything.