What Selective Disclosure Means in Practice

“Selective disclosure” is one of those phrases that sounds like a policy and is actually a cryptographic property. The difference matters, because policies can be changed by a configuration setting and properties cannot.

The problem it solves

A physical driving licence is all-or-nothing. To prove one fact on it — that you are over 21 — you hand over a card carrying your name, address, height, document number, and photograph. The recipient sees all of it. There is no version of the card that shows less.

Digital credentials do not have to inherit that constraint, but they only avoid it if they are built to. A signed PDF of a licence has exactly the same problem: the signature covers the whole document, so you cannot release part of it and still prove it is genuine.

How it works

The trick is in what gets signed. Rather than signing the document as one blob, the issuing authority signs a structure that commits to the digest of each element separately — in ISO/IEC 18013-5 this is the mobile security object.

Because each element has its own commitment, a holder can release any subset and the verifier can still check each released element against the issuer’s signed commitment. The elements that were not released remain provably absent rather than redacted-but-present.

Each element also incorporates a random value, so a verifier cannot take the digest of a withheld element and test guesses against it. Without that, an element with a small range of possible values — a boolean, or a birth year — would be trivially recoverable from its commitment alone.

What it buys you as a business

A narrower question. You can ask for age_over_21 instead of birth_date, and receive an issuer-signed boolean.

A narrower liability. Data you never receive cannot be breached, subpoenaed, mis-retained, or repurposed by a future product decision. Every data-protection regime in the world treats minimisation as a first-order control, and this is minimisation enforced by the protocol rather than by a settings page.

A narrower conversation with your reviewer. “What do you store?” is a much easier question when the honest answer is a three-value enumeration.

What it does not buy you

It is not automatic. Selective disclosure describes what the credential permits. What actually happens is determined by the request the verifier sends. A verifier that asks for every element in the namespace has used a selectively disclosable credential to collect a full identity record, and can still truthfully say it supports selective disclosure.

This is the single most important thing to understand about the term. When a vendor says their product supports selective disclosure, they have told you about the credential format, not about their behaviour. The follow-up question — what do you actually request? — is the one that carries information.

It does not make presentations unlinkable by itself. The standard includes measures aimed at reducing linkability, including the option to issue single-use security objects. Whether those measures are used in a given deployment depends on the issuing authority and the wallet. A business should not assume a presentation is inherently unlinkable, and should certainly not build anything that depends on it being linkable.

It does not prevent a verifier from deriving its own identifier. A verifier that receives a document number and hashes it has created a stable per-person key. So has one that fingerprints a device. Selective disclosure limits what is released; it cannot limit what a badly designed verifier does with what it received.

A practical test

Ask any mobile-ID vendor two questions in sequence:

1. Does your product support selective disclosure?
2. What is the exact element list in the request you send?

Almost everyone answers yes to the first. The second is where products separate. An answer of “one element” is a different product from an answer of “we request the standard set and filter.”

LaurelID’s answer

Stated as our own position rather than as a description of the standard.

One element: age_over_21, with intentToRetain set to false. No name, no birth date, no portrait, no document number, no other age threshold.

And because it would otherwise be an easy gap to leave open: LaurelID derives no stable per-person value anywhere — no hashed document number, no repeat-visitor identifier, no device-to-person mapping. Selective disclosure limits the input; the privacy architecture explains why nothing downstream reintroduces what the request left out.

Sources

1. ISO/IEC 18013-5:2021 — Mobile driving licence (mDL) application — ISO
2. Digital Identities — Mobile Driver's License (mDL) project — NIST National Cybersecurity Center of Excellence
3. Supported attributes for credentials in Google Wallet — Google