Zero-Knowledge Proofs Guide: Prove Identity Facts Without Revealing Data

Most identity checks still collect far more personal data than the decision needs, because the only way to prove "over 18" or "holds a valid licence" has been to show the whole document. A zero-knowledge proof (ZKP) is a cryptographic protocol that lets one party prove a statement is true without revealing anything beyond the fact that it is true. This guide explains what ZKPs are, how they work inside identity wallets and age verification, where they differ from selective disclosure, and what an identity team has to decide before accepting them. It is written for identity architects, privacy engineers and relying party teams who will meet ZKPs through the EU Digital Identity Wallet, mobile driving licences and verifiable credentials.

Key takeaways

• A ZKP proves a statement, not a value. The verifier learns "the holder has a valid issuer-signed credential saying age over 18 is true" and nothing about name, birth date or the signature itself.
• Selective disclosure is not the same thing. RFC 9901 SD-JWT hides undisclosed claims with salted hashes, but the issuer signature and digests are shown every time, so repeated presentations can be correlated unless credentials are used once.
• Two families matter for identity. Multi-message signatures such as BBS give unlinkable proofs but need issuers to change how they sign; circuit-based proofs over existing ECDSA credentials need no issuer change but cost more computation.
• The EU age verification blueprint already uses one. Its Annex B selects ECDSA anonymous credentials (the Longfellow scheme), with a plain ISO mdoc presentation kept as a fallback for devices that cannot generate proofs.
• Proofs do not fix weak inputs. A ZKP is only as trustworthy as the issuer, the circuit, the device binding and the revocation design around it, and disclosed attributes can still identify people.

What it is

NIST's Privacy-Enhancing Cryptography project describes the ZKP as a main tool of privacy-enhancing cryptography: it proves the truthfulness of a statement without revealing additional information. Most identity uses are a zero-knowledge proof of knowledge: the prover shows it knows a secret witness (for example a signed credential and the private key bound to it) that is consistent with a public instance (the issuer public key, the requested attribute, a verifier nonce).

The ZKProof Community Reference (version 0.3, July 2022, which NIST helped edit) defines the three properties every scheme must have:

• Completeness: an honest prover holding a valid witness convinces an honest verifier when the statement is true.
• Soundness: a cheating prover has negligible chance of convincing the verifier of a false statement. Systems sound only against computationally bounded provers are strictly called arguments, which is why the "AR" in SNARK stands for argument.
• Zero knowledge: the verifier learns nothing beyond the truth of the statement. Formally, a simulator without the witness can produce transcripts the verifier cannot tell apart from real ones. The reference distinguishes perfect, statistical and computational zero knowledge.

For identity, a fourth property is usually required on top: unlinkability, meaning two presentations of the same credential cannot be recognised as coming from the same holder. Zero knowledge about hidden attributes does not automatically give unlinkability if any fixed value, such as a serial number or the issuer signature, travels with every proof.

How it works

An identity ZKP has the same actors as any credential flow: an issuer signs attributes, a wallet holds them, and a relying party (verifier) requests a statement. What changes is the presentation step.

Interactive, non-interactive and setup

Classic protocols are interactive: commit, challenge, response. The Fiat-Shamir transform replaces the verifier's random challenge with a hash, giving a non-interactive proof that is a single message. The ZKProof reference notes that non-interactive proofs are often transferable: anyone holding a copy can verify it. Identity schemes therefore bind every proof to a verifier nonce or presentation header so a captured proof cannot be replayed elsewhere.

Some proof systems need public parameters. A trusted setup (common reference string) is generated by a party or ceremony that could forge proofs if it kept the secret; a trustless or transparent setup derives parameters from public randomness. The Ligero-based scheme used for EU age verification needs no trusted setup.

The two identity families compared

Worked example: proving age over 18

Annex B of the EU age verification technical specification describes the circuit precisely. The witness is the Proof of Age attestation. The public inputs are the attestation provider's public key, the attribute and a nonce. The circuit outputs true only if all four checks pass:

1. The attestation carries a signature that verifies under the provider's public key.
2. The requested attribute (age over 18) is set to true.
3. The app can sign the verifier's nonce with the private key whose public key is in the attestation (device binding).
4. The attestation is inside its validity period.

The app runs the prover over this circuit and sends only the succinct proof. The relying party verifies it against the same public inputs. The issuer is unaware the scheme exists, so no change is needed to issuance. Annex B records that the scheme was externally reviewed by Trail of Bits (August 2025), ISRG (October 2025) and an academic panel assembled by Ligero (December 2025), that ISRG produced a second, bit-compatible Rust implementation, and that the scheme is deployed in Google Wallet.

Why it matters

ZKPs turn data minimisation from a policy promise into a property of the protocol. A relying party that never receives a birth date cannot leak, sell or over-retain it, and two websites cannot join their logs on a credential serial number. The EUDI Architecture and Reference Framework discussion paper on ZKP (Topic G, version 1.4) traces the requirement to selective disclosure and unlinkability in the revised eIDAS Regulation, and its proposed requirements include using only standardised algorithms, adding no extra communication that could enable tracking, and keeping "high" level of assurance authentication possible. Those proposals were not yet adopted text when checked.

Decision guidance for relying parties

Rolling it out

1. Write the statement first: list exactly which predicate the service needs ("age over 18", "resident of a member state") and which attributes, if any, must be revealed.
2. Pick the presentation path: ZKP where wallets support it, single-use attestations otherwise, and decide what happens when neither is available.
3. Pin issuer trust: load issuer public keys from the official trusted list, not from the presentation itself.
4. Bind and check freshness: generate a fresh nonce per request and reject proofs that do not commit to it.
5. Pilot in log-only mode: verify proofs alongside the existing check, compare outcomes, and record proof generation and verification times.
6. Roll back cleanly: keep the fallback path switchable by configuration so a library or circuit fault does not block users.

What to measure

• Proof success rate: share of presentations that verify first time, split by device and wallet.
• Fallback rate: share of users who could not produce a ZKP and used the plain path.
• Median and 95th percentile proof time: the ARF notes proofs may take seconds, which matters more in proximity flows.
• Personal data fields stored per verification: the target for an age gate is zero.
• Replay rejections: proofs refused for a stale or wrong nonce, which should be rare but never zero in a real attack.

Common misconceptions

• "SD-JWT is a zero-knowledge proof": it is selective disclosure by salted hashes. The verifier sees the issuer signature and digests, which are stable across presentations. See the SD-JWT and SD-JWT VC Guide.
• "Zero knowledge means anonymous": whatever you disclose is still disclosed. W3C's BBS cryptosuite notes that the verifier learns how many statements the issuer signed and recommends padding to a common length where that matters. A rare postcode plus birth year can identify someone without any credential linkage. See the Anonymisation and Re-identification Risk Guide.
• "A proof proves the user is the holder": it proves possession of a key. Device binding, wallet attestation and the issuer's identity proofing decide whether that key belongs to the right person.
• "Expiry and revocation take care of themselves": a fine-grained validity date or a revocation index is itself a tracking vector. Annex B treats hiding the validity period as optional and recommends other mechanisms; the ARF paper lists privacy-preserving revocation as a desired property rather than a solved one.
• "Drafts are safe to hard-code": the BBS and Longfellow documents are research-group drafts and change between versions. Pin library versions and plan for algorithm agility.
• "ZKPs are post-quantum": security depends on the construction. BBS relies on pairing-based assumptions, and ECDSA-based credentials inherit ECDSA's exposure to a future quantum computer. See the Post-Quantum Readiness Guide.

Related concepts

ZKPs sit inside a wider privacy and identity toolset. The framework mapping below shows where controls for them belong.

• Verifiable credentials and wallets: the container ZKPs operate on. See the Verifiable Credentials Guide and the Digital Identity Wallets Guide.
• Age assurance: the most mature consumer use. See the Age Assurance Guide.
• Mobile driving licences: ISO mdoc credentials that circuit-based proofs can wrap without issuer change. See the Mobile Driving Licence (mDL) Guide.
• Other privacy-enhancing technologies: secure multi-party computation, homomorphic encryption and differential privacy solve different problems. See the Privacy-Enhancing Technologies Guide.

Practitioner checklist

• Write down the exact predicate each service needs and remove every attribute it does not.
• Confirm whether your wallets and issuers support BBS, circuit-based proofs, or only salted-hash disclosure.
• Load issuer keys from the official trusted list and reject self-asserted keys.
• Require a fresh verifier nonce in every proof and log replay rejections.
• Keep a configurable fallback path and measure how often it is used.
• Pin proof library versions and record the specification draft version each one implements.
• Review disclosed attribute combinations for re-identification risk, not just the cryptography.
• Track the status of the IRTF BBS and Longfellow drafts and the W3C BBS cryptosuite at each review.

Standards and references

• NIST: Privacy-Enhancing Cryptography, Zero-Knowledge Proofs
• ZKProof: ZKProof Community Reference
• IRTF CFRG: The BBS Signature Scheme (Internet-Draft)
• W3C: Data Integrity BBS Cryptosuites v1.0
• IETF: RFC 9901 Selective Disclosure for JSON Web Tokens
• European Commission: Age Verification Solution Technical Specification
• European Commission: EUDI ARF Discussion Topic G, Zero Knowledge Proof
• Google: longfellow-zk reference implementation

Related NHI Mgmt Group resources: Verifiable Credentials Guide · eIDAS 2.0 and the European Digital Identity Framework Guide · Age Assurance Guide · Privacy-Enhancing Technologies Guide