Selective Disclosure

The foundational capability to reveal only a specific subset of claims from a larger verifiable credential. A holder can present a credential containing ten attributes but disclose only the two required by a verifier.

• Mechanism: Achieved through W3C Verifiable Credential data model, where each claim is a discrete element in a JSON-LD document.
• Example: A digital driver's license credential contains name, address, birth date, and organ donor status. For age verification at a bar, the holder reveals only the birth_date claim and a derived age_over_21 boolean, concealing the exact address and donor status.
• Technical implementation: Uses JSON-LD framing to select specific fields for presentation, generating a derived credential that contains only the disclosed claims, still signed by the original issuer.

A cryptographic method that allows a holder to prove a claim satisfies a condition without revealing the claim's actual value. This is the mathematical backbone of predicate proofs.

• Mechanism: Uses Bulletproofs or zk-SNARKs to construct a proof that a secret value x falls within a specified range (e.g., x > 21) without disclosing x itself.
• Example: Proving salary > $100,000 for a loan application without revealing the exact salary figure. The verifier receives a cryptographic proof that validates the inequality against a signed commitment to the salary, not the salary itself.
• Key distinction: Unlike atomic claim revelation, the underlying data is never transmitted. The verifier learns only the truth value of the predicate.

Specialized signature schemes that enable the holder to derive a new, valid signature on a subset of signed messages without interacting with the original issuer.

• CL-Signatures (Camenisch-Lysyanskaya): Allow a signer to issue a signature on a block of messages. The holder can then generate a zero-knowledge proof of knowledge of a signature on a specific subset of those messages.
• BBS+ Signatures: An evolution of CL-signatures that supports multi-message signing and efficient proof generation. Standardized at IETF and W3C, BBS+ allows creating a single proof that reveals some messages while keeping others hidden, all verifiable against the issuer's public key.
• Practical impact: Enables unlinkable presentations. A verifier cannot correlate two separate disclosures from the same credential because each presentation generates a distinct, randomized proof.

The ability to attach logical conditions to claim revelation, ensuring that sensitive data is only released when specific criteria are met by the verifier.

• Mechanism: Implemented through presentation definitions that specify constraints and rules. A holder's wallet evaluates these rules before constructing the presentation.
• Example: A credential proving membership in a professional organization is only disclosed if the verifier presents a valid verifiable credential proving they are an accredited auditor. This creates a mutual authentication loop.
• Use case: Regulatory compliance where data can only be shared with entities possessing specific licenses or certifications, enforced cryptographically rather than through policy alone.

Cryptographic mechanisms that bind a disclosed credential to a specific verifier and a specific transaction, preventing replay attacks and unauthorized forwarding.

• Mechanism: The holder's wallet generates a presentation that includes a nonce (a random number provided by the verifier) and the verifier's Decentralized Identifier (DID). The presentation is then signed by the holder's private key.
• Result: The resulting Verifiable Presentation is only valid for that specific verifier and that specific interaction. If a malicious actor intercepts the presentation, it cannot be replayed to a different verifier because the audience DID and nonce will not match.
• Technical detail: This is enforced through the proof section of the Verifiable Presentation, which includes challenge (the nonce) and domain (the verifier's identifier) fields.

The use of predefined, machine-readable schemas to declare which claims within a credential type are selectively disclosable and under what conditions.

• Mechanism: Credential schemas, often defined using JSON Schema and stored on a verifiable data registry (like a blockchain), explicitly mark fields as selectivelyDisclosable: true.
• Function: Issuers publish these schemas to inform holders and verifiers about the disclosure capabilities of a credential type before issuance. A verifier's software can automatically generate a proof request that respects these schema constraints.
• Example: A "Permanent Resident Card" schema defines country_of_citizenship as selectively disclosable, while card_serial_number is not. The verifier's system reads this schema and constructs a request that only asks for the permitted fields.