How to Build
Privacy-Preserving Identity

Privacy-preserving identity is not a feature. It is an architectural property. You cannot bolt privacy onto an identity system after the fact — it must be designed in from the first line of code. Six principles govern privacy-preserving identity engineering: 1. Data minimization: collect only what you need. If your identity system stores birth dates "just in case," you have already failed. Every stored attribute is a liability. 2. Selective disclosure: the user decides what to reveal. A verifier asking "are you over 18?" does not need your birth date. Your identity system must support partial revelation — preferably via zero-knowledge proofs. 3. User-held credentials: the credential lives in the user's wallet, not your database. Your system should never be a honeypot of user identity data. Verifiable Credentials (W3C VC 2.0) make this possible. 4. Ephemeral identifiers: no long-lived global identifiers. Every interaction uses a pairwise DID. No cross-site tracking. No correlation without user consent. 5. Consent-driven: every data share requires explicit, informed consent. Not a checkbox buried in a 40-page terms document. Real, granular, per-attribute consent. 6. Auditability without surveillance: the system must be provably correct — verifiable by third parties — without logging every user action. Zero-knowledge proofs and verifiable data registries make this possible.

A privacy-preserving identity system has four layers. Each layer requires specific technology choices: Layer 1 — Identifiers: DIDs (Decentralized Identifiers). Use did:key for simple cases, did:web for organizational identity, did:ethr for Ethereum anchoring. Never use email addresses or phone numbers as primary identifiers — they are global correlators. Layer 2 — Credentials: W3C Verifiable Credentials with BBS+ or CL signatures. These support zero-knowledge selective disclosure — the holder can prove "age > 18" without revealing the birth date. Standard ECDSA VCs do NOT support this; choose the signature scheme deliberately. Layer 3 — Presentation: Verifiable Presentations with ZK proofs. The holder aggregates multiple VCs into a single presentation and reveals only the minimum necessary attributes. Use the W3C Verifiable Presentation data model. Layer 4 — Verification: The verifier checks the presentation against the issuer's DID, validates the ZK proof, and confirms the attributes satisfy their policy. No call to the issuer. No central database query. The math is the authority. Critical implementation detail: never store raw VCs on a server. The holder's wallet is the only place VCs live. Your system issues them and forgets them. This eliminates the "database breach → all credentials leaked" failure mode.

Zero-knowledge proofs are the cryptographic primitive that makes privacy-preserving identity possible. A ZK proof allows a prover to convince a verifier that a statement is true without revealing why it is true. For identity, this means: - "I am over 21" — without revealing age - "I am a citizen of this country" — without revealing which country - "I have not been blacklisted" — without revealing transaction history Three ZK proof systems matter for identity in 2026: 1. BBS+ Signatures: The W3C standard for ZK-friendly VCs. Allows the holder to derive a new signature that reveals only a subset of the originally signed attributes. Mature, standardized, production-deployed. 2. Circom + Groth16: For custom ZK circuits. Maximum flexibility, maximum performance. Used when you need to prove arbitrary statements about identity attributes. Requires circuit design expertise. 3. Noir: A Rust-like DSL for writing ZK circuits. Emerging standard supported by Aztec. Lower barrier to entry than Circom. Compiles to multiple proving backends. The key insight: ZK moves identity verification from "trust me, here's all my data" to "verify this proof — I reveal nothing else." That is the architectural shift that privacy-preserving identity demands.