Selective-Disclosure Credential Presentation¶
Workflow — instantiates Minimal-Disclosure Verification
Presents only required credential attributes or predicates while withholding unrelated attributes from the verifier.
Selective-Disclosure Credential Presentation is the holder-side workflow of revealing only the specific attributes — or predicates over attributes — a verifier actually needs from a multi-field credential, while withholding the rest. The single idea that makes it this mechanism is a per-transaction release rule operating on a rich, issuer-signed credential: it chooses which fields to surface and proves the surfaced subset belongs to a validly signed whole. That is different from proving an inequality about a hidden number, and different from the issued token itself — this is the act of presenting an existing credential minimally, field by field, rather than copying the whole document into every verifier's hands.
Example¶
A traveler picks up a rental car. The counter needs to confirm she may legally drive the class of vehicle she reserved. Her phone holds a state-issued mobile driver's license — a credential with roughly fifteen signed fields. The rental app requests only two: "license class permits this vehicle" and "license status is valid." Her wallet's selective-disclosure workflow releases just those two signed attributes, bound to this rental session, and withholds her home address, exact date of birth, license number, height, and organ-donor status. The clerk's verifier checks the state's signature over the revealed fields and confirms the presentation is bound to this transaction. The rental company gets exactly the two facts it needs and learns nothing else on her license.[1]
How it works¶
The distinguishing machinery is a signature that survives partial revelation:
- Issue for selective release. The issuer signs the credential so individual attributes — or derived predicates — can be revealed independently, using a multi-message signature or per-claim digests.
- Select per request. At presentation the holder picks the minimal attribute set the verifier asked for, and no more.
- Prove membership in a signed whole. The holder proves the revealed subset came from a validly issued credential, without exposing the withheld fields.
- Bind to the session. The presentation is tied to this verifier and transaction so it cannot be forwarded and reused elsewhere.
Tuning parameters¶
- Attribute granularity — how finely the credential is divided; fine-grained fields allow tighter minimization than coarse blobs.
- Predicate vs. raw-attribute release — revealing "class permits this vehicle" versus revealing the raw class value. Predicates leak less but need more machinery.
- Unlinkability — whether repeated presentations of the same credential are correlatable; unlinkable signatures prevent verifiers from stitching a profile.
- Holder binding strength — how firmly the presentation is tied to the legitimate holder and session, resisting theft and forwarding.
When it helps, and when it misleads¶
Its strength is minimizing overcollection while reusing one credential across many verifiers, each seeing only its own slice — the practical backbone of digital identity wallets and verifiable credentials.
Its failure mode is that a greedy verifier can still over-request, and presentations can be linkable across verifiers if the signature scheme is not unlinkable, so metadata quietly reconstructs the profile that field-minimization was meant to prevent. Revealing a raw attribute where a predicate would suffice also leaks more than needed. The classic misuse is a verifier demanding the entire credential "to be safe," collapsing selective disclosure back into wholesale copying. The guarding discipline is request-minimization enforced at the verifier, unlinkable signature schemes, and scope discipline so only the necessary predicate — not the underlying value — is released.
How it implements the components¶
selective_attribute_release_rule— the core: a per-transaction rule choosing exactly which attributes or predicates to reveal and which to withhold.credential_or_attestation_issuer— the presentation rides on an issuer-signed credential; the issuer's signature is what makes the revealed subset trustworthy.minimal_disclosure_boundary— the boundary is drawn field by field, with every unrequested attribute kept on the withheld side.subject_session_or_context_binding— the presentation is bound to this verifier and session so it cannot be forwarded and replayed elsewhere.
It does not implement a revocation_expiration_or_freshness_condition or scope_limited_audit_record — issuing a self-contained, expiring, signed verdict and recording it is Policy-Bound Attestation Token; this is the holder-side act of presenting an existing credential. Nor does it prove a numeric bound on a hidden value the way Range Proof does; it releases named attributes rather than proving inequalities over concealed numbers.
Related¶
- Instantiates: Minimal-Disclosure Verification — the identity-and-governance workflow for revealing only the credential fields a decision requires.
- Consumes: Range Proof — when a requested field is a predicate over a number (for example a minimum-age check), the presentation carries a range proof rather than the raw value.
- Sibling mechanisms: Anonymous Membership Proof · Commitment Scheme with Opening Rule · Interactive Zero-Knowledge Protocol · Non-Interactive Zero-Knowledge Proof · Policy-Bound Attestation Token · Privacy-Preserving Compliance Oracle · Proof of Possession Without Secret Reveal · Range Proof · Succinct Zero-Knowledge Proof System
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: Selective-Disclosure Credential Presentation operates as a repeatable ordered procedure or handoff sequence that coordinates action because it presents only required credential attributes or predicates while withholding unrelated attributes from the verifier.
Independent corroboration: The frozen evidence defines Selective-Disclosure Credential Presentation as 'Presents only required credential attributes or predicates while withholding unrelated attributes from the verifier', so its operative form is Protocol, Workflow & Routine.
Nearest alternative: Control, Automation & Runtime — Selective-Disclosure Credential Presentation includes features of a live operational control that automatically routes, enforces, adapts, or responds during execution, but its defining operation is a repeatable ordered procedure or handoff sequence that coordinates action.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Presenting only necessary claims from a credential is a digital-credential protocol operation. W3C and IETF standards specify selective disclosure, holder presentations, and cryptographic verification; security and privacy law supply threat and minimization constraints.
Related originating lineages:
- Human-Computer Interaction — human_computer_interaction contributes human interpretation, interface design, usability, and decision display to this mechanism's defining operation—Presents only required credential attributes or predicates while withholding unrelated attributes from the verifier—without displacing the selected primary historical lineage.
- Law & Governance — Data-minimization and purpose-limitation norms define why only necessary attributes should be disclosed.
- Mathematics — Zero-knowledge and signature constructions use formal number-theoretic and algebraic proofs to make selective claims verifiable.
- Security Studies & Intelligence Analysis — Privacy engineering makes unlinkability and least disclosure explicit system requirements.
Review resolution: The blind reviewers disagree on primary lineage (computer_science versus security_intelligence). Authoritative or primary research supports computer_science as the best historical origin: Presenting only necessary claims from a credential is a digital-credential protocol operation. W3C and IETF standards specify selective disclosure, holder presentations, and cryptographic verification; security and privacy law supply threat and minimization constraints. The cited W3C, Verifiable Credentials Implementation Guide: Selective Disclosure; IETF RFC 9901, Selective Disclosure for JWTs directly supports the mechanism's defining operation. All independently supported contributing domains are retained without an arbitrary cap. origin_mode=cross_disciplinary_synthesis records the lineage relationship, while domain_reach=specialized records later applicability separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- W3C, Verifiable Credentials Implementation Guide: Selective Disclosure
- IETF RFC 9901, Selective Disclosure for JWTs
References¶
[1] The ISO/IEC 18013-5 mobile driving licence standard and BBS+ multi-message signatures both enable revealing a chosen subset of signed attributes (BBS+ additionally aims for unlinkable presentations) — the concrete realizations of this workflow, and the reason unlinkability is one of its critical dials. registry ↩