diff --git a/CHANGELOG.md b/CHANGELOG.md index 6975733..adb4191 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,10 @@ All notable changes to the IPTF Map are documented here. ## [Unreleased] +### Changed +- feat(use-case): Broadened [Private Authentication](use-cases/private-auth.md) beyond institutional KYC to cover governance and national identity use cases +- feat(approach): Restructured [Private Authentication Approach](approaches/approach-private-auth.md) with credential-source taxonomy and validated deployment references + ### Added - feat(pattern): [EY: Starlight](vendors/ey.md#starlight) - Solidity transpiler for private on-chain state. Consolidated EY products into a single vendor file. - feat(pattern): [Network-Level Anonymity](patterns/pattern-network-anonymity.md) - Umbrella pattern for transport-layer sender anonymity (Tor, mixnets, private RPC, TEE-assisted, VPN) diff --git a/GLOSSARY.md b/GLOSSARY.md index 7673bdf..54b2f6e 100644 --- a/GLOSSARY.md +++ b/GLOSSARY.md @@ -107,6 +107,12 @@ A dedicated network or service that publishes and stores the data required for D ### Identity & Compliance +**PCD (Proof-Carrying Data)**: Data bundled with a cryptographic proof of its own correctness, enabling portable and composable verifiable credentials. + +**Sybil Resistance**: Preventing a single actor from creating multiple fake identities to gain disproportionate influence in systems that distribute value, votes, or access. + +**DKIM (DomainKeys Identified Mail)**: Email authentication standard where mail servers sign outgoing messages. + **ONCHAINID**: Decentralized identity system used by ERC-3643 for KYC/eligibility verification **KYC/AML**: Know Your Customer/Anti-Money Laundering regulatory compliance requirements diff --git a/approaches/approach-private-auth.md b/approaches/approach-private-auth.md index 88fea61..5bb3393 100644 --- a/approaches/approach-private-auth.md +++ b/approaches/approach-private-auth.md @@ -1,169 +1,227 @@ # Approach: Private Authentication & Identity Verification -**Use Case Link:** [Private Authentication & Interaction of Client EOAs](../use-cases/private-auth.md) +**Use Case Link:** [Private Authentication & Identity Verification](../use-cases/private-auth.md) -**High-level goal:** Enable institutions to verify valid client identity and EOA ownership while protecting client privacy, preventing address linkability, and maintaining regulatory compliance. +**High-level goal:** Enable any party (institutions, governments, DAOs) to verify identity claims on Ethereum without exposing the underlying identity, using verification logic that is publicly auditable and cryptographically enforced. ## Overview ### Problem Interaction -Private authentication addresses three interconnected challenges: +Private authentication addresses four interconnected challenges: -1. **Regulatory Compliance**: Institutions must verify valid client KYC/AML status and address ownership for regulatory requirements -2. **Privacy Protection**: Clients need to protect their identity and prevent linkability between their various addresses and institutional relationships +1. **Identity Verification Without Disclosure**: The fundamental problem across all domains. Proving "I am eligible" without revealing "I am Alice." Traditional authentication (message signatures) satisfies verifiers but exposes identities and creates trackable on-chain patterns. +2. **Credential Source Heterogeneity**: No universal identity system exists. Passports, KYC registries, biometric enrollment, email ownership, event attendance, and on-chain history are all valid credential sources, each with different trust assumptions, coverage, and proof costs. +3. **Sybil Resistance**: Systems that distribute value (votes, tokens) need "one per person" guarantees without building identity databases. Requires deterministic, scope-bound nullifiers. +4. **Regulatory & Audit Compliance**: Financial use cases require selective disclosure and audit trails. All domains need scoped visibility without full identity exposure. -These problems interact because traditional authentication methods (message signatures, satoshi test) satisfy compliance but expose sensitive client information and create trackable on-chain patterns. The solution requires cryptographic techniques that enable verifiable compliance without identity disclosure. +These problems interact because the same cryptographic primitives (membership proofs, nullifiers, selective disclosure) serve all four challenges across different domains. ### Key Constraints +**Universal:** + +- **Unlinkability:** presentations must not be correlatable across verifiers or sessions +- **Openness:** proof systems and verification logic must be open source and auditable +- **Interoperability:** must work across credential formats, chains, and verifier implementations +- **Decentralization:** must not require a single canonical identity provider or central registry +- Must support credential revocation without re-identifying holders +- Proof generation must be practical on consumer hardware + +**Financial (additional):** + - Must satisfy institutional KYC/AML compliance requirements -- Must support and check identity revocation -- Prevent linking multiple addresses belonging to the same client -- Support self-custody while enabling institutional verification -- Provide regulatory audit capabilities without compromising privacy -- Scale to handle frequent authentication across multiple institutions +- Must provide regulatory audit trails with selective disclosure + +**Governance (additional):** + +- Must resist coercion +- Must scale to large anonymity sets without centralized bottlenecks ### TLDR for Different Personas -- **Business:** Verify client compliance and address ownership without exposing client identities or creating trackable patterns -- **Technical:** Use ZK proofs and Merkle tree membership to prove inclusion in KYC registries and exclusoion from revoked list without revealing which specific client -- **Legal:** Maintain regulatory compliance through verifiable proofs while protecting client privacy rights +- **Business:** Verify eligibility claims (KYC status, citizenship, community membership) without exposing personal data. The same primitives serve financial compliance and governance. +- **Technical:** Organize by credential source: Merkle tree membership for registries, document ZK for government IDs, DKIM for email, TLS proofs for web2 data. Each has different trust assumptions and proof costs. +- **Legal:** Achieve regulatory compliance through verifiable proofs rather than data collection. Selective disclosure provides cryptographically scoped visibility. ## Architecture and Design Choices -### Recommended Architecture: ZK-Based Registry Membership +### Approaches by Credential Source + +| Approach | Credential Source | Trust Assumption | Proof Cost | Maturity | Key Deployment | +| --- | --- | --- | --- | --- | --- | +| [Merkle tree membership](#a-registry-based-membership-proofs) | Institutional registry | Registry operator | Low | Pilot | Semaphore, ERC-3643 | +| [Document ZK](#b-document-zk-proofs) | Government ID (NFC/signature) | Document issuer | Medium | Pilot | ZKPassport, Anon Aadhaar | +| [zk-TLS](#c-tls-transcript-proofs) | Web2 data source | Notary + TLS server | Medium | PoC | TLSNotary | +| [On-chain attestation](#d-on-chain-attestation) | Trusted issuer | Issuer signing key | Low | Production | EAS, ONCHAINID | +| [POD2](#e-pod2) | Event/community | Attestation issuer | Low | Pilot | [POD2](https://github.com/0xPARC/pod2) (0xPARC) | +| DKIM proofs (email) | Email provider | Email provider DKIM key | Low | Pilot | zkEmail / Arbitrum | +| Biometric enrollment | Enrollment operator | Enrollment device | High (enrollment) | Pilot | World ID (25M users) | + +--- + +### A. Registry-Based Membership Proofs **Primary Pattern:** [Private MTP Authentication](../patterns/pattern-private-mtp-auth.md) -**Supporting Patterns:** +**Supporting Patterns:** [ZK-KYC/ML + ONCHAINID](../patterns/pattern-zk-kyc-ml-id-erc734-735.md), [Selective Disclosure](../patterns/pattern-regulatory-disclosure-keys-proofs.md), [vOPRF Nullifiers](../patterns/pattern-voprf-nullifiers.md) -- [ZK-KYC/ML + ONCHAINID](../patterns/pattern-zk-kyc-ml-id-erc734-735.md) -- [zk-TLS](../patterns/pattern-zk-tls.md) -- [Selective Disclosure](../patterns/pattern-regulatory-disclosure-keys-proofs.md) -- [Co-SNARK](../patterns/pattern-co-snark.md) +A registry operator (institution, DAO) maintains a Merkle tree of approved members. Provers generate ZK membership proofs demonstrating inclusion in the tree and exclusion from a revocation tree, without revealing which leaf they correspond to. [Semaphore](https://semaphore.pse.dev/) is the most established implementation, using identity commitments as leaves and nullifiers to prevent proof reuse. -#### Core Components: +**Operator trust assumptions:** The registry operator controls membership (who is added/removed) and can censor by omission (refusing to add legitimate members) or by selective revocation. The operator sees the identity of each member at enrollment time, though not at proof-presentation time. Multi-operator or federated registries can mitigate single-operator risk. -1. **KYC Registry Infrastructure** +**Core components:** - - Off-chain KYC verification and client onboarding - - Merkle tree construction with approved client addresses - - Lean Incremental Merkle tree for revoked client addresses - - On-chain root commitment with regular updates - - Multi-institutional registry coordination +1. **Registry infrastructure:** Off-chain onboarding, Merkle tree construction with approved addresses, Lean Incremental Merkle tree for revocations, on-chain root commitment with regular updates +2. **ZK proof system:** Membership proofs for inclusion, nullifier system to prevent replay, private key ownership verification within the proof +3. **Integration layer:** Contract hooks for proof verification, ERC-3643 integration for permissioned tokens, [attestation logging](../patterns/pattern-verifiable-attestation.md) for compliance trails, cross-chain registry sync +4. **Audit infrastructure:** Audit trails of registry updates and proof verifications, selective disclosure for regulatory investigations, threshold-based access controls -2. **ZK Proof System** +**When to use:** Institutional KYC/AML compliance, permissioned token transfers, any scenario with a defined membership set managed by a known operator. +**Deployment:** Semaphore +**Limitations:** Requires a trusted registry operator; registry updates introduce latency; Semaphore is one implementation of the Merkle membership pattern, not the only one. - - [Semaphore](https://semaphore.pse.dev/)-style membership proofs for registry inclusion - - Nullifier system or verifier challenge system to prevent proof reuse and replay attacks - - Private key ownership verification within the proof - - Support for multi-address ownership proofs (same seed, different EOAs) +### B. Document ZK Proofs -3. **Institution Integration Layer** +Document-based ZK proofs read cryptographic data from government-issued identity documents and generate ZK proofs of specific attributes without revealing the full document. - - Contract hooks for proof verification before transactions - - ERC-3643 integration for permissioned token transfers - - [Attestation logging](../patterns/pattern-verifiable-attestation.md) for compliance trails - - Cross-chain registry synchronization +**ZKPassport** reads the NFC chip embedded in biometric passports (120+ countries supported), extracts signed attributes, and uses [Noir](https://docs.aztec.network/) circuits with the Barretenberg (UltraHonk) prover to generate proofs natively on mobile devices. Provers can demonstrate nationality, age, or sanctions-list non-membership without revealing name, passport number, or other fields. -4. **Regulatory Compliance Infrastructure** - - Audit trails of registry updates and proof verifications - - Selective disclosure for regulatory investigations - - Threshold-based access controls for compliance officers - - Standardized reporting formats across jurisdictions +**Validated deployment:** The Aztec token sale (December 2025) used ZKPassport for privacy-preserving sanctions screening. Participants proved their passport data did not match OFAC, Swiss, EU, or UK sanctions lists without revealing any passport details to Aztec or anyone else. Approximately 50% of committed capital came from community participants using this flow. -### Vendor Recommendations +**Anon Aadhaar** generates ZK proofs of Indian national ID (Aadhaar) attributes. It verifies UIDAI's DKIM signature client-side without sending data to any server. EVM-verifiable on-chain. + +**When to use:** Sanctions compliance without full KYC, age verification, nationality proofs, any scenario where a government-issued document is the credential source. +**Limitations:** Requires NFC-capable device (ZKPassport) or specific national ID format; limited to countries with supported document cryptography. + +### C. TLS Transcript Proofs + +**Primary Pattern:** [zk-TLS](../patterns/pattern-zk-tls.md) + +[TLSNotary](https://tlsnotary.org/) enables provers to generate ZK proofs over TLS session transcripts, verifying data received from any web2 source (bank portals, government websites, social media) without revealing the full session content. A Notary co-signs the TLS session, and the prover selectively discloses specific fields via ZK proofs. + +**When to use:** Porting identity or financial data from web2 into on-chain claims; compliance data export from banking portals; any web2 data that cannot be accessed via API. +**Limitations:** Requires a trusted Notary (trust assumption is an [open question](#open-questions)); session freshness guarantees depend on Notary behavior; selective disclosure granularity depends on TLS record structure. + +### D. On-Chain Attestation + +**Primary Pattern:** [Verifiable Attestation](../patterns/pattern-verifiable-attestation.md) + +On-chain attestation systems ([EAS](https://attest.org/), [ONCHAINID](https://www.erc3643.org/) (ERC-734/735), W3C Verifiable Credentials) allow trusted issuers to publish signed claims about subjects. These claims can be verified on-chain with minimal gas cost. When combined with ZK wrappers, attestations support selective disclosure: prove you hold a valid attestation of type X from issuer Y without revealing the specific attestation content. + +[OpenAC](https://eprint.iacr.org/2026/251) adds unlinkable presentations over existing VCs (SD-JWT, mDL) using transparent ZK proofs, no issuer changes or trusted setup. PoC with mobile benchmarks; EUDI ARF compatible; moving to pilot. + +**When to use:** Permissioned token compliance (ERC-3643), cross-institutional credential sharing, regulatory registry mirroring (e.g., [eWpG bridge](../patterns/pattern-crypto-registry-bridge-ewpg-eas.md)). Add OpenAC when cross-verifier unlinkability is required. +**Deployment:** EAS is production-grade across multiple chains. OpenAC is PoC (moving to pilot). +**Limitations:** Without a ZK presentation layer, issuer linkage remains: the issuer knows which attestations they signed, creating a linkability vector. -**Primary Infrastructure:** +### E. POD2 -- **ZK Frameworks:** Semaphore for membership proofs and exclusion proofs, Aztec Noir for custom circuits -- **Registry Management:** [Attestation infrastructure](../patterns/pattern-verifiable-attestation.md) (EAS, W3C VC, ONCHAINID), custom Merkle tree contracts -- **Identity Standards:** ERC-3643 for permissioned tokens, ERC-734/735 for identity claims +[POD2](https://github.com/0xPARC/pod2) (0xPARC) implements Provable Object Data: any piece of data bundled with a cryptographic proof of its correctness. PODs are composable: event tickets, community badges, poll responses, and access tokens follow the same format, enabling credential-source-agnostic identity. -**Alternative Approaches:** +**When to use:** Event gating, community membership, anonymous polls, composable credential ecosystems, sybil-resistant access control. +**Limitations:** Community-driven tooling; less mature than institutional-grade systems. -- **ZK TLS:** [zk-TLS](../patterns/pattern-zk-tls.md) for KYC data portability from web2 -- **MPC-based:** [Co-SNARK](../patterns/pattern-co-snark.md) for multi-party KYC verification -- **FHE Integration:** [Zama](../vendors/zama.md) for homomorphic identity verification -- **Privacy L2:** Aztec Network for native privacy-preserving authentication +--- + +### Vendor Recommendations + +| Category | Vendors / Frameworks | Status | +| --- | --- | --- | +| Merkle membership | [Semaphore](https://semaphore.pse.dev/) (PSE), [Iden3](https://github.com/iden3) | Pilot | +| Document ZK | [ZKPassport](https://zkpassport.id/) (Noir/Barretenberg), [Anon Aadhaar](https://github.com/anon-aadhaar) (Circom), [Self](https://self.xyz/), [Rarimo](https://rarimo.com/) | Pilot/PoC | +| TLS proofs | [TLSNotary](https://tlsnotary.org/) | PoC | +| On-chain attestation | [EAS](https://attest.org/), [ONCHAINID](https://www.erc3643.org/) (Tokeny), W3C VC | Production | +| Anonymous credentials | [OpenAC](https://eprint.iacr.org/2026/251) (EF/PSE) | PoC | +| POD2 | [POD2](https://github.com/0xPARC/pod2) (0xPARC) | Pilot | +| Email ZK | [zkEmail](https://prove.email/) | Pilot | ### Implementation Strategy -**Phase 1: Basic ZK Authentication** +**Phase 1: Single-Domain Pilot** -- Deploy Merkle tree registry contracts on Ethereum L1/L2 -- Implement zk-TLS for data portability or Semaphore-style membership and LeanIMT exclusion proofs -- Basic wallet integration for proof generation -- Single-institution pilot deployment +- Choose one credential source and use case (e.g., institutional KYC with Merkle membership, or governance voting with MACI) +- Deploy registry or attestation contracts +- Basic wallet/mobile integration for proof generation +- Single-organization deployment -**Phase 2: Multi-Institution & Compliance** +**Phase 2: Multi-Credential & Cross-Domain** -- Cross-institutional registry coordination -- EAS integration for compliance logging -- Regulatory audit trail infrastructure -- Multi-address ownership proof support +- Support multiple credential sources in one system (e.g., KYC attestation + passport proof) +- Cross-institutional or cross-organization registry coordination +- EAS-based audit trail infrastructure +- Mobile proof generation for governance use cases -**Phase 3: Advanced Features & Scaling** +**Phase 3: Ecosystem Integration** - Cross-chain authentication support -- Machine learning-based KYC proof integration -- Full ecosystem integration +- Credential composability (combine proofs from different sources in a single verification) +- Standardized credential formats across domains ## More Details ### Trade-offs +**Credential Source Comparison:** + +| Source | Privacy Strength | Trust Assumption | UX Burden | Coverage | +| --- | --- | --- | --- | --- | +| Merkle membership | Dependent on k-anonymity | Registry operator | Low (wallet plugin) | Limited to registered users | +| Passport NFC | High (attribute-selective) | Passport issuing country | Medium (NFC reader) | 120+ countries | +| Email DKIM | Medium (email provider sees) | Email provider | Low | Universal (email users) | +| zk-TLS | Medium (notary sees session) | Notary | Medium | Any web2 source | +| Biometric | High (one-per-person) | Enrollment operator | High (enrollment) | Limited enrollment locations | +| On-chain attestation | Low-medium (issuer linkage) | Issuer | Low | Depends on issuer network | +| POD2 | High | Attestation issuer | Low | Community adoption | + **ZK Membership vs Traditional Whitelists:** -- **ZK Benefits:** Complete privacy preservation, no address linkability, regulatory compliance -- **Traditional Benefits:** Simpler implementation, lower computational costs +- **ZK Benefits:** Complete privacy preservation, no address linkability, censorship-resistant verification +- **Traditional Benefits:** Simpler implementation, lower computational costs, no proof generation UX - **Recommendation:** ZK for privacy-critical applications, traditional for internal operations **On-Chain vs Off-Chain Verification:** - **On-Chain:** Immediate verification, composability with smart contracts, higher costs -- **Off-Chain:** Lower costs, more flexible verification logic, requires trusted verification +- **Off-Chain:** Lower costs, more flexible verification logic, requires trusted verifier - **Hybrid:** Off-chain proof generation, on-chain verification for critical operations **Single vs Multi-Address Proofs:** -- **Single Address:** Simpler proofs, established Semaphore patterns -- **Multi-Address:** Complex proof construction, proof cost high, better privacy for portfolio management +- **Single Address:** Simpler proofs, established patterns +- **Multi-Address:** Complex proof construction, higher proof cost, better privacy for portfolio management - **Progressive:** Start with single, upgrade to multi-address as technology matures ### Open Questions 1. **Multi-Address Efficiency:** How to efficiently prove ownership of multiple EOAs derived from the same seed without revealing derivation patterns? - 2. **Cross-Institution Standards:** Standardization of KYC registry formats and proof verification across different institutions? - 3. **Regulatory Recognition:** Legal recognition of ZK proofs as sufficient evidence for compliance purposes? - 4. **Scalability:** Handling frequent registry updates and proof verification at institutional scale? - -5. **Key Recovery:** Institutional-grade key management for clients while maintaining self-custody principles? - -6. **Trust assumption on Notary** How to guarantee Notary trustworthiness? +5. **Key Recovery:** Institutional-grade key management while maintaining self-custody principles? +6. **Trust Assumption on Notary:** How to guarantee Notary trustworthiness in zk-TLS deployments? +7. **Cross-Credential Composability:** How to combine proofs from heterogeneous credential sources (e.g., passport + KYC attestation + community membership) in a single verification? +8. **Mobile Proof Generation:** What is the minimum hardware requirement for client-side proof generation on mobile devices? +9. **Credential Revocation:** How to handle revocation across heterogeneous issuers without a central revocation authority? ### Alternative Approaches Considered - - **TEE-Based Authentication** - Use case: Hardware-backed identity verification -- Trade-off: Hardware dependencies vs simplified proof generation -- Pattern: Secure enclave verification with attestation +- Trade-off: Hardware dependencies and vendor trust vs simplified proof generation +- Pattern: [TEE-Based Privacy](../patterns/pattern-tee-based-privacy.md) with remote attestation **Federated Identity Systems** -- Use case: Cross-institutional identity sharing -- Trade-off: Operational simplicity vs privacy leakage -- Status: Legacy approach being superseded by ZK methods +- Use case: Cross-institutional identity sharing (OAuth/OIDC-style) +- Trade-off: Operational simplicity vs privacy leakage and centralized dependency +- Status: Legacy approach; does not achieve censorship-resistant or privacy-preserving authentication + +**Self-Sovereign Identity (DID/VC without ZK)** + +- Use case: W3C DID + Verifiable Credentials presented directly +- Trade-off: Simpler UX but reveals credential content to verifier +- Status: Production (Microsoft ION, Spruce); limited privacy without ZK wrappers ## Example Scenarios @@ -171,7 +229,7 @@ These problems interact because traditional authentication methods (message sign - Client wants to purchase institutional bond tokens - Institution requires KYC verification without learning client identity -- Client generates Semaphore proof of registry membership +- Client generates Semaphore proof of registry membership - Contract verifies proof and allows token transfer - Observer sees transaction but cannot link to specific client @@ -180,9 +238,28 @@ These problems interact because traditional authentication methods (message sign - Client maintains accounts with multiple banks and asset managers - Each institution has separate KYC registry - Client proves compliance to each without revealing cross-institutional relationships -- Regulators can audit each registry independently +- Regulators can audit each registry independently via selective disclosure + +### Scenario 3: Anonymous Governance Vote + +- DAO conducts binding vote on treasury allocation +- Members prove token-holder status via Merkle membership proof +- MACI-style encrypted vote submission prevents vote buying +- ZK tallying reveals result without revealing individual votes +- Election observer can verify the tally is correct without accessing individual ballots + +### Scenario 4: Sanctions Compliance Without Full KYC + +- Protocol token sale requires participants to be non-sanctioned but does not require full KYC +- Participants use ZKPassport to prove: (a) passport is valid, (b) holder is not on OFAC/EU/UK sanctions lists, without revealing name, passport number, or nationality +- Proof verified on-chain; token purchase proceeds +- No personal data is collected or stored by the protocol ## Links and Notes -- **Standards:** [ERC-3643](https://eips.ethereum.org/EIPS/eip-3643), [ERC-734/735](https://eips.ethereum.org/EIPS/eip-734), [EAS](https://attest.org/) -- **ZK Infrastructure:** [Aztec Noir](https://docs.aztec.network/), [Sempahore ZK Protocol](https://github.com/semaphore-protocol), [Iden3](https://github.com/iden3) +- **Standards:** [ERC-3643](https://eips.ethereum.org/EIPS/eip-3643), [ERC-734/735](https://eips.ethereum.org/EIPS/eip-734), [EAS](https://attest.org/), W3C Verifiable Credentials, [EIP-5564](https://eips.ethereum.org/EIPS/eip-5564) +- **ZK Frameworks:** [Semaphore](https://github.com/semaphore-protocol), [Noir/Barretenberg](https://docs.aztec.network/), [Circom/Groth16](https://docs.circom.io/), [Iden3](https://github.com/iden3) +- **Credential Systems:** [ZKPassport](https://zkpassport.id/), [Self](https://self.xyz/), [Rarimo](https://rarimo.com/), [Anon Aadhaar](https://github.com/anon-aadhaar), [zkEmail](https://prove.email/), [TLSNotary](https://tlsnotary.org/), [POD2](https://github.com/0xPARC/pod2), [OpenAC](https://eprint.iacr.org/2026/251) +- **Validated Deployments:** ZKPassport Aztec sale (120+ countries), Anon Aadhaar, World ID (25M registrations), [OpenCerts](https://www.opencerts.io/) (2M+ certs) +- **Related Patterns:** [Private MTP Auth](../patterns/pattern-private-mtp-auth.md), [ZK-KYC/ML + ONCHAINID](../patterns/pattern-zk-kyc-ml-id-erc734-735.md), [zk-TLS](../patterns/pattern-zk-tls.md), [Selective Disclosure](../patterns/pattern-regulatory-disclosure-keys-proofs.md), [co-SNARK](../patterns/pattern-co-snark.md), [Verifiable Attestation](../patterns/pattern-verifiable-attestation.md), [vOPRF Nullifiers](../patterns/pattern-voprf-nullifiers.md), [Stealth Addresses](../patterns/pattern-stealth-addresses.md), [ERC-3643 RWA](../patterns/pattern-erc3643-rwa.md), [Compliance Monitoring](../patterns/pattern-compliance-monitoring.md), [Network Anonymity](../patterns/pattern-network-anonymity.md), [Noir Private Contracts](../patterns/pattern-noir-private-contracts.md), [Privacy L2s](../patterns/pattern-privacy-l2s.md) +- **Vendors:** [Aztec](../vendors/aztec.md), [Miden](../vendors/miden.md), [Zama](../vendors/zama.md), [Fhenix](../vendors/fhenix.md), [TACEO](../vendors/taceo-merces.md), [Privacy Pools](../vendors/privacypools.md), [Chainlink ACE](../vendors/chainlink-ace.md), [EY](../vendors/ey.md) diff --git a/domains/identity-compliance.md b/domains/identity-compliance.md index 4a5f0b1..7635c8b 100644 --- a/domains/identity-compliance.md +++ b/domains/identity-compliance.md @@ -8,11 +8,18 @@ status: draft - Public verification without publishing PII; scoped disclosure for regulators. ## Primary use cases +- [Private Authentication & Identity Verification](../use-cases/private-auth.md) - (Cross-cut; applied in all domains as a prerequisite) +## Approaches +- [Approach: Private Authentication & Identity Verification](../approaches/approach-private-auth.md) + ## Shortest-path patterns +- [Private MTP Authentication](../patterns/pattern-private-mtp-auth.md) - [zk-KYC/ML + ONCHAINID (ERC-734-735)](../patterns/pattern-zk-kyc-ml-id-erc734-735.md) - [Selective disclosure (view keys + proofs)](../patterns/pattern-regulatory-disclosure-keys-proofs.md) +- [Verifiable Attestation](../patterns/pattern-verifiable-attestation.md) +- [vOPRF Nullifiers](../patterns/pattern-voprf-nullifiers.md) - [Crypto-registry bridge (eWpG) + EAS](../patterns/pattern-crypto-registry-bridge-ewpg-eas.md) ## Adjacent vendors diff --git a/patterns/pattern-private-mtp-auth.md b/patterns/pattern-private-mtp-auth.md index c23a486..cf2dc90 100644 --- a/patterns/pattern-private-mtp-auth.md +++ b/patterns/pattern-private-mtp-auth.md @@ -58,3 +58,10 @@ Enable institutions to authenticate client EOAs in a way that satisfies regulato - Regulator can later audit the registry root and inclusion proof. ## See also + +- [Approach: Private Authentication & Identity Verification](../approaches/approach-private-auth.md) +- [Verifiable Attestation](pattern-verifiable-attestation.md) +- [vOPRF Nullifiers](pattern-voprf-nullifiers.md) +- [Selective Disclosure](pattern-regulatory-disclosure-keys-proofs.md) +- [ZK-KYC/ML + ONCHAINID](pattern-zk-kyc-ml-id-erc734-735.md) +- [zk-TLS](pattern-zk-tls.md) diff --git a/use-cases/private-auth.md b/use-cases/private-auth.md index c74bc35..54fd86b 100644 --- a/use-cases/private-auth.md +++ b/use-cases/private-auth.md @@ -1,47 +1,95 @@ --- -title: "Private Authentication & Interaction of Client EOAs" +title: "Private Authentication & Identity Verification" primary_domain: Identity & Compliance -secondary_domain: +secondary_domain: Governance --- ## 1) Use Case -Institutions that interact with client EOAs must verify identity and key control while protecting client privacy. The solution enables proving KYC compliance and address ownership without exposing personal information or linking multiple addresses belonging to the same client. +Prove membership, eligibility, or attribute possession on-chain without revealing identity or creating linkable activity. Applies to financial compliance (KYC registry membership), governance (anonymous voting), national identity (selective disclosure from government documents), and community membership (sybil-resistant access). ## 2) Additional Business Context **Confidential context:** Available in private IPTF repo +**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](https://github.com/0xPARC/pod2) (0xPARC); World ID (25M+ registrations) +- **Email identity:** zkEmail (DKIM proofs, email wallets on Arbitrum) + ## 3) Actors -Issuer (bank/institution) · Clients (EOA owners, investors) · Regulator (audit body) · Wallet (proof generation frontend) +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) ## 4) Problems ### Problem 1: Authentication Without Identity Leakage -Current authentication methods (e.g., message signatures) prove key control but expose addresses and create linkability between clients and institutions. Two distinct but related needs emerge: +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**: user proves they are a client of an institution (on- or off-chain) without revealing identity. -2. **Interaction privacy**: prevent onchain linkability between client addresses and institutional contracts. +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:** client identities, links between institutions and users, links between user EOAs -- **Public OK:** registry root, institutional contract addresses, [compliance attestations](../patterns/pattern-verifiable-attestation.md) -- **Regulator access:** scoped access to Merkle inclusion proofs, registry updates, or decryption keys where required +- **Must hide:** prover identities, links between verifiers and provers, links between prover EOAs +- **Public OK:** registry roots, verifier contract addresses, [compliance attestations](../patterns/pattern-verifiable-attestation.md) +- **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 +- **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](../patterns/pattern-voprf-nullifiers.md) for nullifier generation primitives ## 5) Recommended Approaches -See detailed solution architecture and trade-offs in [**Approach: Private Authentication**](../approaches/approach-private-auth.md). +| 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](https://github.com/0xPARC/pod2) (0xPARC) | +| Multi-party private inputs | Collaborative proving (co-SNARK) | TACEO | +| On-chain attestation | EAS / ONCHAINID / W3C VC | Tokeny, EAS | + +See detailed architecture and trade-offs in [**Approach: Private Authentication**](../approaches/approach-private-auth.md). ## 6) Open Questions -- How practical is it to prove ownership of multiple EOAs derived from the same seed? -- Should multi-ownership proofs be handled at the wallet layer (BIP-32 style derivations) or at the protocol layer (aggregated ZK proofs)? +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) Notes And Links -- **Standards:** [ERC-3643 ONCHAINID](https://www.erc3643.org/) +- **Standards:** [ERC-3643 ONCHAINID](https://www.erc3643.org/), [EAS](https://attest.org/), W3C Verifiable Credentials, [EIP-5564](https://eips.ethereum.org/EIPS/eip-5564) +- **ZK Frameworks:** [Semaphore](https://semaphore.pse.dev/), [Noir/Barretenberg](https://docs.aztec.network/), [Circom/Groth16](https://docs.circom.io/) +- **Credential Systems:** [ZKPassport](https://zkpassport.id/), [Self](https://self.xyz/), [Rarimo](https://rarimo.com/), [Anon Aadhaar](https://github.com/anon-aadhaar), [zkEmail](https://prove.email/), [TLSNotary](https://tlsnotary.org/), [POD2](https://github.com/0xPARC/pod2), [OpenAC](https://eprint.iacr.org/2026/251) +- **Validated Deployments:** [WFP Building Blocks](https://www.wfp.org/building-blocks), [OpenCerts](https://www.opencerts.io/) +- **Related Patterns:** [Private MTP Auth](../patterns/pattern-private-mtp-auth.md), [zk-TLS](../patterns/pattern-zk-tls.md), [Verifiable Attestation](../patterns/pattern-verifiable-attestation.md), [vOPRF Nullifiers](../patterns/pattern-voprf-nullifiers.md), [Selective Disclosure](../patterns/pattern-regulatory-disclosure-keys-proofs.md), [co-SNARK](../patterns/pattern-co-snark.md)