Anonymous credentials and selective disclosure

Understand how a credential can be issued once and shown many times while revealing only the attributes a verifier needs — and nothing that links two showings together. Learn the issuer/holder/verifier model, the properties (unlinkability, multi-show, predicate proofs), the role of BBS+-style signatures, and the honest boundary: a valid credential proof attests to signed attributes under an issuer's key, not to the truth of the world or the safety of granting access.

Track

Research

Module

13 · Zero-Knowledge identity & private protocols

Prerequisites

Digital signatures · What is a zero-knowledge proof · Commitment schemes in depth: Pedersen, KZG and IPA

Physical identity documents overshare. To prove you are an adult at a door, you hand over a card that also reveals your exact birth date, full name, address and document number. Every verifier sees everything, every showing is linkable, and the data is copied and stored far beyond its purpose. Anonymous credentials are the cryptographic answer: prove exactly the needed statement, reveal nothing else, and leave no link between showings.

The idea is old — Chaum proposed credential systems without identification in the 1980s — and matured through systems like Idemix and U-Prove and, more recently, BBS+ signatures. What they share is a separation of three roles and a discipline about disclosure: the holder, not the issuer or verifier, decides what is revealed, one attribute at a time, with cryptography guaranteeing the rest stays hidden and unlinkable.

Three parties and three operations define the system. The structure is what makes selective disclosure and unlinkability possible.

Issuer

A party trusted for some domain (a government, a KYC provider, a university) that verifies real-world facts once and issues a signed credential over a set of attributes. Its public key is the root of trust a verifier checks against.

Holder

The subject of the credential, who stores it and later generates presentation proofs. Crucially, the holder chooses which attributes to disclose and derives a fresh, unlinkable proof each time.

Verifier

A party that checks a presentation: that the disclosed attributes (or predicates over hidden ones) are consistent with a valid issuer signature, without learning the hidden attributes or being able to link this showing to any other.

Presentation / proof

A zero-knowledge proof derived from the credential that reveals a chosen subset (or predicates) and proves the rest exist under the issuer's signature.

Compare two trust models. In traditional KYC, a user hands documents to every service, so the data is replicated across providers, each a breach target. In the ZK model, the user does KYC once, receives a signed credential, and thereafter shows only proofs — an exchange learns "not sanctioned, not a politically-exposed person", a DeFi protocol learns "resident of an allowed country", a venue learns "over 21" — and none receives the underlying documents.

Selective disclosure

Reveal only a chosen subset of attributes from a credential that signs many. The verifier is cryptographically assured the disclosed values are part of the same issuer-signed set, without seeing the undisclosed ones.

Predicate proofs

Prove an attribute satisfies a condition without revealing its value: age ≥ 18 from a signed birth date, income in a band, a date before a cutoff. The predicate result is disclosed; the value is not.

Unlinkability

Two presentations of the same credential cannot be linked to each other, and a presentation cannot be linked back to the issuance. Each proof is freshly randomised, so colluding verifiers cannot correlate a user across services.

Multi-show

The same credential can be presented many times, each presentation unlinkable from the others — unlike a one-time-show token that must be re-issued after use.

Unlinkability is the property that distinguishes a privacy credential from a signed JSON blob. Handing a verifier the issuer's signature directly would let any two verifiers compare signatures and link the user. Anonymous credentials instead let the holder prove knowledge of a valid signature over the attributes, re-randomised each time, so no linkable artifact is ever shown.

BBS+ is a modern signature scheme built for exactly this: it signs a vector of messages (attributes) with a single compact signature, and the holder can then produce a zero-knowledge proof of knowledge of that signature while disclosing any chosen subset of the messages. It is the scheme behind much recent Verifiable Credential work.

synthetic — the shape of a BBS+ selective-disclosure flow (illustrative)
# Issue (once): issuer signs the whole attribute vector
attrs     = [name, birth_date, nationality, is_sanctioned, risk_level]
signature = BBS_sign(issuer_sk, attrs)          # ONE signature over all

# Present (many times): holder discloses a subset, hides the rest
disclosed = { nationality }                      # reveal only nationality
proof     = BBS_prove(issuer_pk, signature, attrs,
                      reveal = disclosed)         # re-randomised each call

# Verify: checks the disclosed values sit under a valid issuer signature
BBS_verify(issuer_pk, proof, disclosed) -> accept/reject
# verifier learns 'nationality' and that the rest exist & are signed;
# it learns nothing else and cannot link this proof to another.

A common pattern combines a signature with a commitment structure (for example a Merkle tree over attributes), so disclosure becomes "reveal this attribute plus a membership path, hide the rest". Whatever the construction, the invariant is the same: the proof binds disclosed attributes to a valid issuer signature while the hidden ones and the link to other showings stay private.

When a verifier accepts a selective-disclosure proof, it has established a precise statement: an issuer with this public key signed a set of attributes, the disclosed values (or the disclosed predicates) are part of that set, and the proof is unlinkable to other showings — all under the signature scheme's assumptions. That is genuinely useful and genuinely narrow.

It does not establish that the attributes are true (the issuer could be wrong or deceived), that they are current (a credential can be stale unless freshness or revocation is checked — a later lesson's subject), that the issuer is honest or uncompromised, or that granting the requested access is safe. For RootRaven the framing is the usual one: the proof is evidence that an authority attested to attributes under stated assumptions; it is not evidence that the attributes reflect reality or that the resulting access decision is correct. Report the issuer, the assumptions, and the freshness/revocation posture as part of the evidence — not the bare "the proof verified".

Expected direction: The credential proof establishes only that the issuer signed those attributes and that the disclosed predicate ("not sanctioned", "over 18") holds within that signed set, unlinkably, under the scheme's assumptions. (1) The user becoming sanctioned later is a freshness/revocation problem, not a proof-soundness problem: the proof was a true statement about the attributes at issuance but says nothing about the present. The exchange should have required a fresh presentation and checked revocation/expiry (e.g. a non-membership proof against a current sanctions set, covered in a later lesson) rather than treating a one-time proof as permanent. (2) The forging issuer is a root-of-trust failure: anonymous credentials move trust to the issuer, so a dishonest or deceived issuer produces perfectly valid proofs of false attributes. No amount of ZK fixes a bad issuer. The exchange should have assessed which issuers it trusts and for what, and treated issuer compromise as part of its threat model. The honest reading: a valid credential proof attests to signed attributes under an issuer's key — not that they are true, current, or safe to act on.

What are the three roles in an anonymous-credential system and who decides what is disclosed?

Issuer (verifies facts once and signs a set of attributes; its public key is the root of trust), holder (stores the credential and generates presentations), and verifier (checks a presentation without learning hidden attributes). The holder decides what is disclosed, choosing a subset or predicates per presentation.

Distinguish selective disclosure from a predicate proof.

Selective disclosure reveals a chosen subset of the signed attribute values while proving the rest exist under the issuer's signature. A predicate proof reveals only that a hidden attribute satisfies a condition (e.g. age ≥ 18 from a signed birth date) without revealing its value at all.

Why is unlinkability essential, and how do BBS+-style credentials achieve multi-show unlinkability?

Without unlinkability, two verifiers could correlate a user across services by comparing a shown signature, defeating privacy. BBS+ lets the holder prove knowledge of a single issuer signature over many attributes while disclosing any subset, with each proof freshly re-randomised — so the same credential can be shown many times with no linkable artifact between showings.

A credential proof verifies. Name two things it does NOT establish.

Any two of: that the attributes are true (the issuer may be wrong or deceived); that they are current (staleness/revocation must be checked separately); that the issuer is honest or uncompromised; or that granting the requested access is safe or correct. The proof attests only that an issuer signed those attributes under its key.