Private Identity

Prove identity claims, membership, eligibility, or attribute possession on-chain without revealing the underlying identity or creating linkable activity. Authentication is one key application — others include credential portability, sybil resistance, and selective disclosure. Applies to financial compliance (KYC registry membership), governance (anonymous voting), national identity (selective disclosure from government documents), and community membership (sybil-resistant access).

Additional Context

Validated deployments:

  • National identity: ZKPassport used in Aztec token sale (120+ country passports, NFC + Noir circuits); Anon Aadhaar
  • Governance: NounsDAO Private Voting (Aztec + Noir storage proofs); MACI deployed at ETHDam, ETHMexico, ETH Tegucigalpa (anti-collusion)
  • Community/sybil: POD2 (0xPARC); World ID (25M+ registrations)
  • Email identity: zkEmail (DKIM proofs, email wallets on Arbitrum)

Actors

Credential Issuer (bank, government, DAO, university) · Prover / Subject (investor, citizen, voter, community member) · Verifier (smart contract, institution, election system) · Registry Operator (maintains on-chain commitment: Merkle root, attestation registry, membership set) · Auditor / Regulator (entity with scoped disclosure rights: financial regulator, election observer) · Wallet / Proof Agent (client-side proof generation: mobile wallet, browser extension, NFC reader)

Problems

Problem 1: Authentication Without Identity Leakage

Current authentication methods (e.g., message signatures) prove key control but expose addresses and create linkability between provers and verifiers. Two distinct but related needs emerge:

  1. Authentication: prover demonstrates membership or attribute possession without revealing identity.
  2. Interaction privacy: prevent on-chain linkability between prover addresses and verifier contracts.

Requirements:

  • Must hide: prover identities, links between verifiers and provers, links between prover EOAs
  • Public OK: registry roots, verifier contract addresses, compliance attestations
  • Auditor access: scoped access to Merkle inclusion proofs, registry updates, or decryption keys where required
  • Settlement: proof verification + transaction execution
  • Ops: resilience against replay attacks; low-cost proof generation; interop across rollups; proof generation on consumer hardware

Problem 2: Credential Source Diversity

Different domains require different credential sources: government-issued IDs (passports, national IDs), institutional attestations (KYC providers), biometric enrollment, email ownership (DKIM), event attendance, and on-chain history. No single canonical identity system covers all use cases.

Requirements:

  • Must support: document-based (passport NFC), attestation-based (EAS/VC), biometric-enrollment-based, email-based (DKIM), membership-based (Merkle tree), TLS-based (web2 data export)
  • Must not require: a single canonical identity system or global registry
  • Interop: credentials from different sources should be composable (e.g., prove KYC + jurisdiction + accreditation from different issuers in one proof)

Problem 3: Sybil Resistance Without Surveillance

Systems that distribute value (governance votes, token distributions) must prevent double-claiming without building a surveillance database. This requires deterministic, scope-bound nullifiers that prevent repeat actions without linking to the underlying identity.

Requirements:

  • Must prevent: double-claiming, double-voting, distribution farming
  • Must preserve: unlinkability across different scopes/services
  • Must handle: revocation of compromised credentials without re-identifying holders
  • Reference: vOPRF Nullifiers pattern for nullifier generation primitives

Problem 4: Credential Portability & Reuse

Institutions repeatedly collect the same credentials (KYC/KYB) from counterparties during onboarding. Reusable, privacy-preserving credentials that work across institutional contexts reduce onboarding cost and friction. Key challenges include cross-border recognition (a credential issued in one jurisdiction accepted in another), revocation propagation without de-anonymization (revoking a compromised credential without revealing which holder was affected), and credential freshness guarantees (proving a credential is still valid, not just that it was once issued).

Requirements:

  • Must support: reuse of a single credential across multiple relying parties without re-disclosure of underlying data
  • Must not require: a centralized credential database or single point of trust
  • Must handle: cross-border credential recognition (e.g., eIDAS mutual recognition), revocation propagation, and credential expiry/refresh
  • Reference: Verifiable Attestation pattern for attestation lifecycle primitives; OpenAC for privacy-preserving access control across relying parties

Recommended Approaches

Credential Source Primary Approach Example Deployments
Institutional KYC registry Merkle tree membership proofs ERC-3643 issuances, Semaphore
Government ID (passport) Document ZK proofs (NFC + Noir) ZKPassport / Aztec token sale
Government ID (national) Document DKIM/signature + ZK Anon Aadhaar / ETHIndia
Email DKIM signature proofs zkEmail / Arbitrum wallets
Web2 data source TLS transcript proofs TLSNotary
Biometric enrollment Iris/face hash + membership proof World ID
Event/community POD2 POD2 (0xPARC)
Multi-party private inputs Collaborative proving (co-SNARK) TACEO
On-chain attestation EAS / ONCHAINID / W3C VC Tokeny, EAS
Civil registry / vital records Government registry attestation + ZK eIDAS 2.0, EUDI pilots
Professional license / certificate Issuer attestation + revocation registry EBSI, national licensing boards

See detailed architecture and trade-offs in Approach: Private Identity.

Open Questions

  1. How practical is it to prove ownership of multiple EOAs derived from the same seed without revealing derivation patterns?
  2. Should multi-ownership proofs be handled at the wallet layer (BIP-32 style derivations) or at the protocol layer (aggregated ZK proofs)?
  3. How to establish cross-credential interoperability, e.g., combine a ZKPassport proof with an institutional attestation in a single transaction?
  4. What trust models are acceptable for biometric enrollment systems in different regulatory contexts?
  5. How to handle credential revocation across heterogeneous issuers without a central revocation authority?
  6. How do these building blocks map onto existing and emerging compliance frameworks (EUDI ARF, eIDAS 2.0, MiCA) across jurisdictions?
  7. How do government-issued verifiable credentials (eIDAS 2.0, EUDI Wallet) integrate with on-chain attestation registries for institutional KYC?
  8. What models enable credential reuse across institutions without creating a centralized identity database?

Notes And Links