A zero-knowledge proof (ZKP) lets a prover convince a verifier that a statement is true without revealing the secret information, called the witness, used to establish it. In digital identity, this can support claims such as “I hold an unexpired credential from an accepted issuer” or “the date in my credential makes me over 18” without disclosing the complete credential or the underlying date of birth.

ZKPs are a family of cryptographic techniques, not a credential format, identity system, or complete privacy solution. Their guarantees depend on the exact proof system, statement, public inputs, setup, implementation, and surrounding protocol.

Start here

What zero knowledge means

A proof system is normally analyzed against three core properties:

  • Completeness: an honest prover with a valid witness can convince an honest verifier of a true statement.
  • Soundness: a prover cannot convince the verifier of a false statement except with negligible probability.
  • Zero knowledge: the verifier learns no knowledge beyond what follows from the statement and its public inputs.

A proof of knowledge additionally demonstrates, in a formally defined sense, that the prover knows a witness. This is not automatically proof of a person’s civil identity, physical presence, uniqueness, or control of a certified device. Those conclusions require the statement and protocol to bind the proof to the relevant credential, key, device, session, and policy.

Many identity proofs are made non-interactive for transport in a presentation. The construction must still bind the verifier’s challenge, audience, domain, and transaction where replay or forwarding matters. A proof that is valid in isolation may be unsafe in the wrong protocol context.

Terms commonly grouped under “zero knowledge” describe different properties:

Property What it provides Important boundary
Selective disclosure Reveals chosen attributes while hiding others Can be implemented without a ZKP, as in hash-based disclosure schemes.
Predicate proof Establishes a condition such as age above a threshold Reveals the predicate result and any public bounds or context.
Unlinkable presentation Prevents presentations from carrying a stable cryptographic correlation handle Requires analysis of the complete system, not only the proof bytes.
Blind issuance Hides selected values from the issuer during issuance Does not by itself hide later presentation metadata.
Private non-revocation Proves current validity without a correlating status query or identifier Depends on the revocation construction, update process, and timing data.
Scope-exclusive pseudonym Produces a stable identifier within one verifier or domain It is intentionally linkable within that scope.
Composite proof Relates hidden claims across credentials Requires compatible statements and sound binding between credentials.
Issuer hiding Proves membership in an accepted issuer set without naming the issuer The set, key distribution, and trust policy remain public or otherwise managed.

Selective disclosure is not synonymous with zero knowledge. For example, RFC 9901 SD-JWT selectively discloses salted claims and reveals the selected claim values; it does not use a ZKP to prove arbitrary predicates over hidden values. Conversely, a ZKP can prove a predicate without disclosing the source attribute at all.

Zero knowledge is not synonymous with unlinkability. A proof may be zero knowledge while the surrounding presentation exposes a stable public key, credential identifier, issuer-specific value, network identifier, or unique combination of attributes. Unlinkability is an end-to-end system property under an explicit collusion and side-channel model.

Digital identity use cases

Minimal attribute disclosure

A holder can prove possession of a valid credential while revealing only the attributes needed for a transaction. The statement may also cover issuer signature validity, credential type, validity period, status, and holder binding without exposing their hidden values.

Derived predicates

Range, set-membership, equality, and inequality proofs can answer questions such as whether a holder is over an age threshold, resides in an eligible region, or holds a qualification from an accepted set. The verifier must define the predicate precisely: “over 18” depends on time, time zone, date semantics, and the trusted source of the underlying attribute.

Unlinkable credential presentations

Anonymous-credential systems can randomize presentations so repeated uses do not carry the same cryptographic signature or holder identifier. This can reduce correlation between relying parties, but disclosed attributes, issuer choices, status mechanisms, wallet telemetry, and network metadata can still link users.

Privacy-preserving holder and device binding

A proof can demonstrate knowledge of a holder or device secret bound into a credential without revealing a stable public key. This addresses one source of correlation, provided that user authentication, secure hardware, backup, and recovery preserve the required assurance.

Private status and revocation

Accumulator and related constructions can prove that a credential has not been revoked without sending a unique credential identifier to a status service. Freshness, witness updates, issuer availability, and revocation-list size can still affect privacy and availability.

Cross-credential proofs

A composite proof can establish that hidden values in independently issued credentials agree, such as linking a professional licence to the same subject as a person-identification credential. Preventing credential lending or unintended subject substitution requires a well-defined common binding, not merely equal text fields.

Credential approaches

Identity systems use several different routes to privacy-preserving proofs. They are not interchangeable and may provide different issuance, revocation, predicate, device-binding, and unlinkability properties.

Multi-message signatures and derived proofs

A multi-message signature signs a vector of messages. A holder can derive a proof of knowledge of a valid signature while disclosing only selected messages, and some constructions support additional predicates or pseudonyms.

  • IRTF CFRG BBS Signatures — the developing BBS signature specification; cite a specific draft revision because it is not an RFC.
  • W3C BBS Cryptosuite v2023 — a W3C work item applying BBS proofs to Data Integrity secured Verifiable Credentials; check its current publication status before claiming standards maturity.
  • W3C Data Integrity 1.0 — the common securing model used by W3C credential cryptosuites.

BBS proof support does not follow from ordinary JSON-LD, CBOR, JWT, or VC support. Canonicalization, message mapping, cryptosuite version, proof options, and verifier behavior are part of the security boundary.

Anonymous credential systems

  • Hyperledger AnonCreds specification — issuance and presentation formats using CL-signature-based ZKPs, selective disclosure, predicates, holder binding, and privacy-preserving revocation.
  • AnonCreds project — specifications, Rust implementation, wrappers, test vectors, and project governance.
  • IBM Idemix implementation — an open-source anonymous identity stack implementing Idemix mechanisms for blockchain systems.
  • U-Prove — specifications and implementations for minimally disclosed, unlinkable credential tokens, standardized in part by ISO/IEC 18370-2.
  • ISO/IEC 18370-2 — blind digital signatures using discrete-logarithm mechanisms, associated with U-Prove.

These systems make different tradeoffs. For example, one-show or pre-generated tokens, multi-show credentials, supported predicates, issuer-holder unlinkability, and revocation behavior must be compared directly rather than grouped under a generic “anonymous credentials” label.

General-purpose proofs

Programmable systems such as zk-SNARKs can prove arbitrary computations over a credential represented as a private witness. This may permit proofs over existing signature formats, complex predicates, or multiple credentials without changing the original issuer’s signature algorithm.

  • ZKProof Community Reference — proof-system concepts, terminology, security, and implementation considerations.
  • zk-creds — research on flexible anonymous credentials built with zk-SNARKs and existing identity infrastructure.
  • Crescent — research on deriving privacy-preserving proofs from existing credentials.
  • Anonymous Credentials from ECDSA — research on privacy-preserving presentations compatible with existing ECDSA credentials.

Programmability introduces its own trust and engineering questions: circuit correctness, trusted or transparent setup, parameter distribution, proof-system assumptions, prover cost, verifier cost, proof size, implementation side channels, and long-term cryptographic agility.

EUDI Wallet work

The European Digital Identity Regulation calls for privacy-preserving technologies such as ZKPs and requires unlinkability where an attestation does not require user identification. The implementation details remain an actively evolving part of the EUDI architecture and standards work.

The EUDI materials distinguish multi-message-signature approaches from programmable arithmetic-circuit approaches. Their presence in ARF technical work does not alone mean that every wallet must support them, that all details are stable, or that an implementation is conformant. Use a versioned ARF release and the applicable implementing regulations for normative analysis.

What a verifier must still evaluate

Validating a ZKP establishes only the statement encoded by that proof under its cryptographic assumptions and public inputs. A digital identity verifier may still need to establish:

  • the proof system, parameters, curve, and transcript construction are approved and correctly implemented;
  • the statement faithfully represents the intended credential semantics and policy;
  • the hidden credential was authentically issued under the expected profile;
  • the issuer was authorized and trusted for the hidden claim;
  • validity time and status were checked with adequate freshness;
  • the presenter is bound to the credential, device, and current transaction as required;
  • disclosed values, public inputs, errors, timing, and network behavior do not defeat the claimed privacy property;
  • the proof is bound to the intended verifier, nonce, domain, and purpose; and
  • the result satisfies an explicit relying-party policy.

Even a perfectly valid proof can attest to a false real-world claim if a trusted issuer enrolled bad data, issued fraudulently, or was trusted for the wrong claim. Zero knowledge minimizes disclosure during verification; it does not create truth or authority.

Security and privacy review

ZKP deployments warrant specialized cryptographic and protocol review. At minimum, record:

  1. the precise relation being proved, including all public inputs and witnesses;
  2. the claimed security properties and adversary or collusion model;
  3. proof-system and primitive versions, parameters, and security levels;
  4. setup assumptions, parameter provenance, and update procedures;
  5. nonce, audience, domain, and transaction binding;
  6. issuer, holder, device, status, and revocation bindings;
  7. disclosed and inferable information, including failed-proof behavior;
  8. correlation surfaces outside the proof, including metadata and network traffic;
  9. implementation provenance, test vectors, audits, and side-channel analysis; and
  10. performance across target devices and remote, QR, NFC, or BLE transports.

Do not design a new proof system or compose primitives without expert review. Small changes to transcript construction, serialization, domain separation, randomness, or subgroup checks can invalidate the intended guarantees.

Reading ZKPs with Proofet Atlas

Proofet Atlas 0.1.0 keeps the observable mechanism separate from evaluated assurance. A credential or presentation can declare a ZKP-based selective-disclosure mechanism under B2, while C4 records whether the proof was cryptographically verified and C8 records the scope and limitations of privacy analysis.

Neither a zkp label nor successful cryptographic verification establishes unlinkability, minimal disclosure, issuer authority, status, holder binding, or fitness for purpose. Those conclusions belong to separate evaluated dimensions with explicit evidence.

For the surrounding credential concepts, see Digital Identity Credentials. For the European regulatory and implementation context, see EUDI Digital Identity Wallet.

Maintenance note

ZKP standards and identity integrations are developing quickly. Links and source status were checked on 25 August 2026. For implementation or assurance work, record the exact specification, draft revision, cryptosuite, proof system, parameters, credential profile, implementation version, and date consulted.