diff --git a/CHANGELOG.md b/CHANGELOG.md index 6cb4374..ef5a0ac 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,8 @@ All notable changes to the EthSystems Map are documented here. ## [Unreleased] +- fix: factual audit of the [Private Identity](use-cases/private-identity.md) entry and the cards one hop out. + - fix: factual audit of the [Private Bonds](use-cases/private-bonds.md) entry and the cards one hop out. In [Private Bonds](use-cases/private-bonds.md) set Trading as secondary domain, add the FHE PoC and the Atomic DvP Settlement approach, correct the PoC RFQ scope, mark ERC-6123 and ERC-7573 Draft and describe ERC-7573 as oracle-conditional settlement that hides no amounts, replace the unsourced HTLC-replacement forecast with the PoCs' actual DvP scope, and link the DvP, crypto-registry and ICMA BDT patterns, the eWpG jurisdiction and sibling bond use cases; in [Private Bonds](approaches/approach-private-bonds.md) refresh the Railgun figure to the project Dune dashboard (~USD 5.7b, Oct 2026), source the Aztec V5 vulnerability to its 2026-08-07 post, describe the PoC whitelist as its compliance hook, set FHE gas to the PoC measurement (~330K per transfer), scope the PoC disclosure claim to what each PoC exercises, and link eWpG, MiCA, the crypto-registry bridge and ERC-7573; in [Verifiable Attestation](patterns/pattern-verifiable-attestation.md) name the EIP-712 vs EIP-191 signing paths, add EAS (MIT) and ONCHAINID (GPL-3.0) licenses, cite ML-DSA (FIPS 204) and EIP-8051 for PQ migration, and note VC Data Model 2.0 Recommendation status; in [ICMA BDT](patterns/pattern-icma-bdt-data-model.md) scope the taxonomy to term-sheet data (no lifecycle event messages), state the royalty-free licence with ICMA-retained IP and replace the 2023 factsheet with the April 2026 FAQ; in [Crypto-registry bridge](patterns/pattern-crypto-registry-bridge-ewpg-eas.md) describe the eWpG register as a decentralised recording system (§4(11), §16) rather than an off-chain notarial store, scope attestation verification to existence, signer and time, replace dead BaFin links with the statute and the current BaFin licensing page and move EAS docs to docs.attest.org; in [DvP via ERC-7573](patterns/pattern-dvp-erc7573.md) state Draft status and that amounts and parties are observable in calls and events; mark ERC-6123 and ERC-7573 Draft and describe ERC-7573 as oracle-conditional settlement in [Private Corporate Bonds](use-cases/private-corporate-bonds.md); move the EAS docs link to docs.attest.org in [Selective Disclosure](patterns/pattern-regulatory-disclosure-keys-proofs.md); link these cards back to Private Bonds - fix: factual audit of the [Private Treasuries](use-cases/private-treasuries.md) entry and the cards one hop out. Fill the empty context section with sourced cash-pooling, transfer-pricing (OECD Chapter X, BEPS Action 13) and Kinexys/JPMD bullets and scope regulatory capital and liquidity reporting to regulated group entities in [Private Treasuries](use-cases/private-treasuries.md); in [Private Payments](approaches/approach-private-payments.md) add the deposit verification cost, note Aztec Alpha and the July 2026 V5 proving-system disclosure, replace the exit-game description of Stateless Plasma with proof-based exits, mark Plasma user proofs as server-side, note that MPC configurations can hide addresses, correct relay-set floors to the PoC spec and state the Resilient Disbursement Rails PoC scope; add FATF R.16 Travel Rule access, the Swift shared-ledger plan and a Resilient Disbursement Rails link in [Private Payments](use-cases/private-payments.md); state GENIUS Act effective date and ERC-7573 Draft status and oracle dependence, and move the Zama link to zama.org, in [Private Stablecoins](use-cases/private-stablecoins.md); date and source the tokenized Treasury market figure (rwa.xyz, 5 Oct 2026) in [Private Money Market Funds](use-cases/private-money-market-funds.md); replace the unsourced Asia municipal-debt line with Hong Kong digital green bonds and Japan's 2026 Local Finance Act amendment in [Private Government Debt](use-cases/private-government-debt.md) - fix(approach): [Private Money Market Funds](approaches/approach-private-money-market-funds.md): Phase 1 review for the MMF approach cycle. Stable- vs floating-NAV yield, aggregates at the fund's cadence, disclosure-key custody instead of threshold NAV opening, investor-side vs portfolio compliance, maturity corrected to `documented`, three new comparison rows, a conditional recommendation, and new open questions (collateral as a future extension). Links: `private-vaults` removed; `erc3643-rwa` and `private-mtp-auth` added. diff --git a/approaches/approach-private-identity.md b/approaches/approach-private-identity.md index 465c5e7..09f06d7 100644 --- a/approaches/approach-private-identity.md +++ b/approaches/approach-private-identity.md @@ -1,7 +1,7 @@ --- title: "Approach: Private Identity" status: ready -last_reviewed: 2026-06-24 +last_reviewed: 2026-10-21 use_case: private-identity related_use_cases: [resilient-identity-continuity] @@ -35,7 +35,7 @@ open_source_implementations: description: "Anon Aadhaar (Indian national ID, RSA in ZK)" language: TypeScript / Circom - url: https://github.com/0xPARC/pod2 - description: "POD2 (composable provable object data)" + description: "POD2 (composable Provable Object Datatypes, Plonky2 backend)" language: Rust - url: https://github.com/tlsnotary description: "TLSNotary (zk-TLS transcript proofs)" @@ -125,7 +125,7 @@ example_vendors: [] **Summary:** zero-knowledge proofs over cryptographic data from government-issued identity documents (passport NFC, national ID signatures); selectively disclose attributes without revealing the document. -**How it works:** ZKPassport reads passport NFC chips (120+ countries) and proves attributes (age, nationality, sanctions-list non-membership) under Noir / UltraHonk on mobile. Anon Aadhaar verifies UIDAI's RSA signature client-side and emits EVM-verifiable proofs over Indian national ID attributes. The verifier checks the SNARK; no identity data is collected. +**How it works:** ZKPassport reads the NFC chips of passports, national ID cards, and residence permits (130+ countries per [zkpassport.id](https://zkpassport.id/), October 2026) and proves attributes (age, nationality, sanctions-list non-membership) under Noir / UltraHonk on mobile. Anon Aadhaar verifies UIDAI's RSA signature client-side and emits EVM-verifiable proofs over Indian national ID attributes. The verifier checks the SNARK; no identity data is collected. **Trust assumptions:** - Document-issuing authority signature integrity @@ -134,7 +134,7 @@ example_vendors: [] **Threat model:** - Document issuer compromise propagates to all proofs -- Cloned passports / NFC replay; mitigated by document-side anti-cloning +- Cloned passports / NFC replay; passive authentication alone does not detect a cloned chip, and the anti-cloning checks (Active or Chip Authentication) are optional for issuing states - Mobile platform compromise reveals derivation material **Works best when:** @@ -156,9 +156,9 @@ uses_patterns: [pattern-zk-tls] example_vendors: [] ``` -**Summary:** TLSNotary generates zero-knowledge proofs over TLS session transcripts from any web2 source (bank portals, government sites, social media); selectively discloses specific fields. +**Summary:** TLSNotary proves the authenticity of TLS session transcript data from any web2 source (bank portals, government sites, social media); selectively discloses specific fields. -**How it works:** A Notary co-signs the TLS session; the prover holds the session transcript and generates a zero-knowledge proof attesting to specific fields (account balance, government registry record, social signal). The verifier checks the proof against the Notary's signature and the TLS session metadata. +**How it works:** The verifier joins the TLS session with the prover under MPC-TLS, or delegates that role to a Notary that signs commitments to the transcript for reuse with other verifiers. The prover holds the session transcript and discloses selected ranges, optionally with a zero-knowledge proof over redacted data, to attest to specific fields (account balance, government registry record, social signal). The verifier checks the disclosure against the MPC-TLS commitments, or against the Notary's signature in Notary mode. **Trust assumptions:** - Notary honesty and availability during the session @@ -168,7 +168,7 @@ example_vendors: [] **Threat model:** - Notary compromise corrupts the witnessing function - TLS server-side data manipulation between sessions -- Disclosure granularity limited by TLS record structure +- Disclosure is limited to the transcript ranges the prover committed to ([commit strategy](https://tlsnotary.org/docs/protocol/commit_strategy)) **Works best when:** - Web2 data source has no API for direct attestation @@ -177,7 +177,7 @@ example_vendors: [] **Avoid when:** - Trusted Notary is incompatible with the threat model -- Required disclosure granularity is below TLS record boundaries +- Many different disclosure patterns are needed and artifact size matters (finer-grained commitments grow storage linearly) ### On-Chain Attestation @@ -222,7 +222,7 @@ uses_patterns: [pattern-private-mtp-auth] example_vendors: [] ``` -**Summary:** POD2 (Provable Object Data) bundles any data with a cryptographic proof of correctness; event tickets, community badges, poll responses, and access tokens share a composable format. +**Summary:** POD2 (Provable Object Datatype) bundles any data with a cryptographic proof of correctness; event tickets, community badges, poll responses, and access tokens share a composable format. **How it works:** Each POD is a typed record signed by the issuer; verifiers check the signature and the typed schema. PODs compose: a holder can prove statements over multiple PODs in a single zero-knowledge proof (e.g., "I hold an event POD and a community POD without revealing which event or community"). @@ -259,7 +259,7 @@ example_vendors: [] **How it works:** Any of these credential sources can enroll (passport, national ID, email DKIM, TLS notary, biometric, community vouch). The holder runs RFC 9497 + Jarecki threshold OPRF against the network (TACEO operates a threshold OPRF network, live in production). Output: a deterministic enrollment nullifier and a leaf added to the on-chain LeanIMT. Verification at any verifier checks a zero-knowledge proof against the on-chain root with public inputs (root, scope-bound nullifier, predicate parameters). Sybil resistance is layered: cryptographic (one enrollment per source credential), economic (refundable stake, default 0.1 ETH), social (web-of-trust vouching, future). Recovery via Shamir threshold splitting and guardian-based social recovery. **Trust assumptions:** -- Threshold OPRF network availability (t-of-n liveness) +- Threshold OPRF network availability (t-of-n liveness) and fewer than t colluding operators (t colluding operators can bypass the sybil gate and enumerate enrollments) - Source credential cryptography for enrollment - On-chain LeanIMT integrity - Recovery custodian / guardian set independence @@ -288,8 +288,8 @@ example_vendors: [] | **Maturity** | prototyped | prototyped | prototyped | production | prototyped | prototyped | | **Context** | i2i | both | both | both | both | both | | **CROPS** | CR:med O:y P:full S:hi | CR:med O:y P:full S:hi | CR:med O:y P:part S:med | CR:med O:y P:part S:med | CR:hi O:y P:full S:med | CR:hi O:y P:full S:hi | -| **Trust model** | Registry operator | Document issuer | Notary + TLS server | Issuer signing key | POD issuer keys | Threshold OPRF + on-chain root | -| **Privacy scope** | k-anonymity in the tree | Attribute-selective | Field-selective from TLS record | Issuer linkage unless ZK-wrapped | Composable, attestation-based | Multi-source, issuer-independent | +| **Trust model** | Registry operator | Document issuer | Verifier or Notary + TLS server | Issuer signing key | POD issuer keys | Threshold OPRF + on-chain root | +| **Privacy scope** | k-anonymity in the tree | Attribute-selective | Field-selective within committed transcript ranges | Issuer linkage unless ZK-wrapped | Composable, attestation-based | Multi-source, issuer-independent | | **Performance** | Low proof cost | Medium (mobile NFC + Noir) | Medium (TLS + ZK) | Low (signature check) | Low | Medium (OPRF + ZK) | | **Operator req.** | Yes (registry) | No (issuer cooperation only at refresh) | Yes (Notary) | Yes (issuer) | Yes (POD issuer) | Yes (OPRF threshold network) | | **Cost class** | Low | Medium | Medium | Low | Low | Medium | @@ -304,7 +304,7 @@ For institutional KYC, sanctions compliance, and ERC-3643 permissioned token tra ### Technical perspective -Engineering effort scales by approach. Registry Membership reuses Semaphore-class infrastructure with the lowest proof cost. Document ZK requires mobile NFC integration plus Noir or Circom circuits per document type. TLS Transcript Proofs add the Notary infrastructure and TLS-record introspection. On-Chain Attestation is the simplest verification surface (signature check) but requires registry hygiene at the issuer. POD2 is composable across heterogeneous attestations but the tooling is community-driven. Issuer-Independent OPRF is the heaviest engineering surface (threshold network, on-chain LeanIMT, recovery infrastructure) but is the only category designed to survive single-issuer failure. +Engineering effort scales by approach. Registry Membership reuses Semaphore-class infrastructure with the lowest proof cost. Document ZK requires mobile NFC integration plus Noir or Circom circuits per document type. TLS Transcript Proofs add MPC-TLS verifier or Notary infrastructure and transcript commitment handling. On-Chain Attestation is the simplest verification surface (signature check) but requires registry hygiene at the issuer. POD2 is composable across heterogeneous attestations but the tooling is community-driven. Issuer-Independent OPRF is the heaviest engineering surface (threshold network, on-chain LeanIMT, recovery infrastructure) but is the only category designed to survive single-issuer failure. ### Legal & risk perspective @@ -339,4 +339,3 @@ Run On-Chain Attestation as the default for production permissioned flows; layer 5. **Credential Revocation.** Revocation across heterogeneous issuers without a central authority. 6. **Guardian Recovery Design.** Minimum guardian set for anti-coercion; acceptable coordination overhead for quorum recovery. 7. **Attribute Freshness.** Without an issuer to refresh, how stale attributes (expired passports, changed nationality) are handled in OPRF-anchored enrollment. - diff --git a/patterns/pattern-co-snark.md b/patterns/pattern-co-snark.md index 6d40c7d..3377cce 100644 --- a/patterns/pattern-co-snark.md +++ b/patterns/pattern-co-snark.md @@ -4,7 +4,7 @@ status: ready maturity: testnet type: standard layer: hybrid -last_reviewed: 2026-09-29 +last_reviewed: 2026-10-21 works-best-when: - A user or institution lacks the compute, memory, or battery to generate a zero-knowledge proof client-side and wants to offload the work without disclosing the witness. @@ -32,7 +32,7 @@ crops_context: post_quantum: risk: high - vector: "Pairing-based SNARKs (Groth16, PLONK/KZG) broken by CRQC. MPC communication inherits the underlying key-exchange assumptions." + vector: "Pairing-based SNARKs (Groth16, PLONK/KZG, UltraHonk) broken by CRQC. MPC communication inherits the underlying key-exchange assumptions: secret sharing itself is information-theoretic, but recorded channel traffic carrying witness shares is exposed to HNDL." mitigation: "Collaborative versions of hash-based proof systems exist only as research (Ozdemir & Boneh adapt Fractal, at N-times proof size and verification cost). See [Post-Quantum Threats](../domains/post-quantum.md)." standards: [] diff --git a/patterns/pattern-private-mtp-auth.md b/patterns/pattern-private-mtp-auth.md index a2cf78b..f4064f9 100644 --- a/patterns/pattern-private-mtp-auth.md +++ b/patterns/pattern-private-mtp-auth.md @@ -4,7 +4,7 @@ status: ready maturity: testnet type: standard layer: hybrid -last_reviewed: 2026-09-30 +last_reviewed: 2026-10-21 works-best-when: - Institutions must comply with KYC/AML but want to protect client privacy on-chain. @@ -33,8 +33,8 @@ crops_context: post_quantum: risk: high - vector: "Pairing-based and elliptic-curve proof systems (Groth16, PLONK/KZG) are broken by a CRQC, letting an attacker forge membership proofs. HNDL risk is bounded because the Merkle tree itself uses hash-based commitments." - mitigation: "Migrate to STARK-based membership circuits with hash-based commitments. See [Post-Quantum Threats](../domains/post-quantum.md)." + vector: "Pairing-based and elliptic-curve proof systems (Groth16, PLONK/KZG) are broken by a CRQC, letting an attacker forge membership proofs. An ECDSA key-control check is also forgeable once the EOA public key is exposed. HNDL does not apply: nothing is encrypted, the zero-knowledge property does not rest on the broken assumptions, and the Merkle tree and nullifiers are hash-based." + mitigation: "Migrate to STARK-based membership circuits with hash-based commitments and a post-quantum signature for the key-control step. See [Post-Quantum Threats](../domains/post-quantum.md)." standards: [ERC-3643, ERC-735] @@ -45,8 +45,8 @@ related_patterns: open_source_implementations: - url: https://github.com/semaphore-protocol/semaphore description: "Semaphore: zero-knowledge signaling with Merkle membership and nullifiers" - language: "Circom, Solidity" - - url: https://github.com/privacy-scaling-explorations/zk-kit + language: "Circom, Solidity, TypeScript" + - url: https://github.com/zk-kit/zk-kit description: "PSE zk-kit: Merkle tree libraries used by Semaphore and similar membership-proof systems" language: "TypeScript" --- diff --git a/patterns/pattern-regulatory-disclosure-keys-proofs.md b/patterns/pattern-regulatory-disclosure-keys-proofs.md index fbe2afd..701ccc3 100644 --- a/patterns/pattern-regulatory-disclosure-keys-proofs.md +++ b/patterns/pattern-regulatory-disclosure-keys-proofs.md @@ -4,7 +4,7 @@ status: ready maturity: testnet type: standard layer: hybrid -last_reviewed: 2026-09-29 +last_reviewed: 2026-10-21 works-best-when: - A regulator needs targeted visibility into specific trades or accounts without blanket transparency. @@ -34,8 +34,8 @@ crops_context: post_quantum: risk: high - vector: "Viewing keys typically derive from EC-based key exchange and are stored as long-lived secrets; HNDL risk is high since ciphertexts and proofs can be archived now and broken later. Predicate circuits built on pairing-based proof systems are also affected." - mitigation: "Migrate key-encapsulation to post-quantum KEMs (for example, ML-KEM) and move predicate circuits to STARK-based systems with hash commitments. See [Post-Quantum Threats](../domains/post-quantum.md)." + vector: "Viewing keys typically derive from EC-based key exchange and are stored as long-lived secrets; HNDL risk is high since ciphertexts encrypted under them, including the on-chain standing register feed, can be archived now and decrypted later. Predicate circuits built on pairing-based proof systems face forgery risk instead: a CRQC could produce a false compliance proof." + mitigation: "Migrate key-encapsulation to post-quantum KEMs (for example, ML-KEM, FIPS 203) before ciphertexts are published, since migration does not protect ciphertexts harvested earlier, and move predicate circuits to STARK-based systems with hash commitments. See [Post-Quantum Threats](../domains/post-quantum.md)." standards: [] @@ -89,14 +89,14 @@ Standing register disclosure: Guarantees: -- Least-privilege, revocable access: viewing keys are time-boxed; predicate proofs leak no raw data. +- Least-privilege access: viewing keys are scoped to a time window; predicate proofs leak no raw data. A disclosed key cannot be withdrawn, so revocation stops further grants but not the regulator's access to data already in scope. - Full audit trail: every grant is recorded, signed, and anchored. - Predicate proofs can answer common compliance questions without exposing transaction content. - Standing register disclosure: the register of record can rebuild beneficial ownership for any point in time without holder cooperation, provided the circuit constrains the ciphertext. Threat model: -- Threshold key custody integrity. A coalition of operators above the threshold can forge responses or leak keys. +- Threshold key custody integrity. A coalition of operators that meet the threshold can forge responses or leak keys. - Mandate parsing correctness. A bug in the policy engine can widen scope beyond what the mandate authorises. - Attestation log availability. If the log is rewritable or unobserved, disclosures can be retroactively denied. - Predicate circuit soundness and input binding. A misbound predicate may answer a different question than the one logged. @@ -114,7 +114,7 @@ Threat model: ## Example -A supervisory authority asks for trades on a given date in a specific instrument. The policy engine matches the request against the institution's active mandate, an approval record is logged, and a 24-hour viewing key reconstituted from threshold shares is issued. The regulator reviews the trades during the window; at expiry the key is revoked automatically, and the attestation log retains a hashed record for future audit. +A supervisory authority asks for trades on a given date in a specific instrument. The policy engine matches the request against the institution's active mandate, an approval record is logged, and a 24-hour viewing key reconstituted from threshold shares is issued. The key decrypts only that day's trades, so nothing outside the window is exposed, but the regulator keeps access to those trades after the review ends; the attestation log retains a hashed record for future audit. The transfer agent of a tokenized security holds the register key. Each issuance, transfer and redemption publishes position data encrypted to that key, bound to the proof by the circuit, so the register can reproduce holder records, eligibility status and tax reports for any date without asking holders. diff --git a/patterns/pattern-verifiable-attestation.md b/patterns/pattern-verifiable-attestation.md index 2cf3b9b..5649b7b 100644 --- a/patterns/pattern-verifiable-attestation.md +++ b/patterns/pattern-verifiable-attestation.md @@ -4,7 +4,7 @@ status: ready maturity: production type: standard layer: hybrid -last_reviewed: 2026-10-13 +last_reviewed: 2026-10-21 works-best-when: - Smart-contract logic must gate on off-chain attested facts (KYC status, accreditation, membership). diff --git a/patterns/pattern-voprf-nullifiers.md b/patterns/pattern-voprf-nullifiers.md index 9598109..e3ecdb7 100644 --- a/patterns/pattern-voprf-nullifiers.md +++ b/patterns/pattern-voprf-nullifiers.md @@ -4,7 +4,7 @@ status: ready maturity: testnet type: standard layer: hybrid -last_reviewed: 2026-06-17 +last_reviewed: 2026-10-21 works-best-when: - You need deterministic per-scope nullifiers or pseudonyms for credentials and signals without revealing the underlying identifier. @@ -28,14 +28,14 @@ crops_profile: crops_context: cr: "Reaches `high` when the committee is permissionless and bond-backed with slashing. Drops to `low` when a single operator controls the evaluation pipeline or the rate-limit gate." - o: "The vOPRF construction itself is specified in open IETF standards; threshold implementations vary in licensing. Production deployments may bundle proprietary orchestration and rate-limit logic." + o: "The base vOPRF construction is specified openly in [RFC 9497](https://www.rfc-editor.org/info/rfc9497/); threshold variants are outside it, and implementations vary in licensing. Production deployments may bundle proprietary orchestration and rate-limit logic." p: "Input privacy holds against the committee in the vOPRF model. Metadata about when and how often a user requests an evaluation remains visible to the committee and can leak usage patterns." s: "Security rides on the OPRF scheme soundness, the threshold key-generation ceremony, and the honest-threshold assumption (fewer than t colluding nodes)." post_quantum: risk: high - vector: "Current OPRF constructions rely on the DDH assumption in a prime-order elliptic-curve group, which is broken by a CRQC. HNDL risk applies to any recorded blinded request, since a future adversary with quantum capability plus the committee key could de-blind and reconstruct nullifiers." - mitigation: "Post-quantum OPRF constructions (lattice-based, VDF-based) are in research. Migration requires re-keying the committee, versioning scopes with a key identifier, and accepting larger message sizes. See [Post-Quantum Threats](../domains/post-quantum.md)." + vector: "[RFC 9497](https://www.rfc-editor.org/info/rfc9497/) OPRF and VOPRF security rests on the One-More Gap Computational Diffie-Hellman assumption in a prime-order elliptic-curve group, which a CRQC breaks. A quantum adversary can recover the committee key from its public key, evaluate the PRF offline to link nullifiers to known or enumerable identifiers, and forge VOPRF proofs. Blinding hides the client input even from an unbounded server, so recorded blinded requests carry no HNDL exposure." + mitigation: "Post-quantum OPRF constructions (lattice-based, isogeny-based, MPC- or garbled-circuit-based) are in research. Migration requires re-keying the committee, versioning scopes with a key identifier, and accepting larger message sizes. See [Post-Quantum Threats](../domains/post-quantum.md)." standards: [RFC-9497, RFC-9576] @@ -45,8 +45,8 @@ related_patterns: see_also: [pattern-zk-promises, pattern-compliance-monitoring] open_source_implementations: - - url: https://core.taceo.io/articles/taceo-oprf/ - description: "TACEO threshold vOPRF writeup with reference implementation (research)" + - url: https://github.com/TaceoLabs/oprf-service + description: "TACEO:OPRF threshold vOPRF service" language: "Rust" --- diff --git a/patterns/pattern-zk-tls.md b/patterns/pattern-zk-tls.md index 66c9eac..4f093ab 100644 --- a/patterns/pattern-zk-tls.md +++ b/patterns/pattern-zk-tls.md @@ -4,7 +4,7 @@ status: ready maturity: testnet type: standard layer: offchain -last_reviewed: 2026-06-18 +last_reviewed: 2026-10-21 works-best-when: - Data required on-chain only lives behind a TLS-protected website with no usable API. @@ -33,8 +33,8 @@ crops_context: post_quantum: risk: high - vector: "Current notarized-TLS constructions use elliptic-curve Diffie-Hellman for the TLS handshake inside an MPC or 2PC protocol. Both the handshake and the MPC channels are broken by a CRQC. HNDL risk applies to any recorded notarized session whose contents must remain confidential or verifiable post-CRQC." - mitigation: "PQ-safe TLS handshakes require ML-KEM inside the MPC layer, which is an unsolved problem in current notarized-TLS designs. Track the RFC-9497 and MPC-TLS working groups; plan for re-notarization of long-lived data. See [Post-Quantum Threats](../domains/post-quantum.md)." + vector: "Current notarized-TLS constructions use elliptic-curve Diffie-Hellman for the TLS handshake inside an MPC or 2PC protocol, and notaries sign with ECDSA (secp256k1 or P-256 in TLSNotary). Both the handshake and the MPC channels are broken by a CRQC, so HNDL applies to any recorded session whose redacted contents must stay confidential. Notary signatures face forgery risk, so attestations stop being verifiable evidence once a CRQC exists." + mitigation: "PQ-safe TLS handshakes require ML-KEM inside the MPC layer, which is an unsolved problem in current notarized-TLS designs. The hybrid ML-KEM key agreement groups are defined only for TLS 1.3, which TLSNotary does not yet support; plan for re-notarization of long-lived data. See [Post-Quantum Threats](../domains/post-quantum.md)." standards: [] @@ -44,7 +44,7 @@ related_patterns: open_source_implementations: - url: https://github.com/tlsnotary/tlsn - description: "TLSNotary reference implementation of notarized TLS with MPC prover (research)" + description: "TLSNotary Rust implementation: MPC-TLS and proxy mode, TLS 1.2 only; alpha, README says not for production; notary server removed in alpha.13" language: "Rust" --- @@ -55,7 +55,7 @@ Export verifiable data or identity attributes from a TLS-protected website into ## Components - Origin server hosts the TLS-protected website holding the data of interest (account balance, identity attribute, certification). -- Notary participates in the TLS session alongside the user under an MPC or 2PC protocol, so that neither party alone can forge the transcript. The notary signs the transcript output. +- Notary participates in the TLS session alongside the user under an MPC or 2PC protocol, so that neither party alone can forge the transcript. The notary signs commitments to the transcript and the server identity without seeing the plaintext. - User client drives the session, produces the zero-knowledge proof over the signed transcript, and redacts the fields that should not be disclosed. - Proof backend (a zero-knowledge proof system) compiles the transcript predicate into a circuit and produces a proof a verifier can check. - On-chain verifier contract or counterparty verifier checks the notary signature on the transcript and the zero-knowledge proof that the disclosed fields follow from the signed content. @@ -63,9 +63,9 @@ Export verifiable data or identity attributes from a TLS-protected website into ## Protocol 1. [user] Initiate a TLS session to the origin server with the notary participating in the handshake under the MPC or 2PC protocol. -2. [notary] Participate in the session so that the session key is shared; neither party learns the full plaintext alone. +2. [notary] Participate in the session so that the session key is shared; neither party holds the full key, and only the user sees the plaintext. 3. [user] Request the target data from the origin within the session; receive the encrypted response. -4. [notary] Produce a signed transcript that binds the handshake and the response ciphertext to the notary identity. +4. [notary] Sign an attestation over the user's commitments to the transcript and the server identity, bound to the notary key. 5. [user] Generate a zero-knowledge proof that the disclosed fields (predicate over account balance, identity attribute) follow from the signed transcript, while redacting everything else. 6. [verifier] Check the notary signature and the zero-knowledge proof against the public statement; accept or reject on that basis. @@ -89,7 +89,7 @@ Threat model: - The notary is a trust and liveness dependency. Multi-notary or threshold-notary designs reduce collusion risk at the cost of protocol complexity. - MPC-TLS session bandwidth and latency are an order of magnitude above a direct TLS session; large transcripts require careful redaction to keep proof cost reasonable. - Origin-side changes (HTML structure, API response format) break the downstream parser; deployments need a versioning plan for predicates. -- Current MPC-TLS stacks support only TLS 1.2 or a limited subset of TLS 1.3 ciphers; adoption is bounded by that compatibility. +- TLSNotary supports only TLS 1.2, with TLS 1.3 on its roadmap; origins that accept only TLS 1.3 are out of reach, and adoption is bounded by that compatibility. ## Example @@ -98,5 +98,5 @@ A custodian needs to verify that an investor holds a minimum balance at a regula ## See also - [TLSNotary documentation](https://tlsnotary.org/) -- [Notary as a service, TLSNotary docs](https://docs.tlsnotary.org/) -- [Notarizing TLS, IEEE 2023 paper](https://eprint.iacr.org/2023/964) +- [Notarization, TLSNotary docs](https://tlsnotary.org/docs/protocol/notarization) +- [Lightweight Authentication of Web Data via Garble-Then-Prove (Xie et al., USENIX Security 2024)](https://eprint.iacr.org/2023/964) diff --git a/use-cases/private-identity.md b/use-cases/private-identity.md index de44f87..e87d745 100644 --- a/use-cases/private-identity.md +++ b/use-cases/private-identity.md @@ -78,8 +78,8 @@ Institutions repeatedly collect the same credentials (KYC/KYB) from counterparti | --- | --- | --- | | 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 | +| Government ID (national) | Document RSA signature + ZK | Anon Aadhaar / ETHIndia 2024 voting | +| Email | DKIM signature proofs | zkEmail email wallet (Arbitrum trial, now Base Sepolia) | | 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) | @@ -103,9 +103,9 @@ See detailed architecture and trade-offs in [**Approach: Private Identity**](../ ## 7) Notes And Links -- **Standards:** [ERC-3643 ONCHAINID](https://www.erc3643.org/), [EAS](https://attest.org/), W3C Verifiable Credentials, [EIP-5564](https://eips.ethereum.org/EIPS/eip-5564) +- **Standards:** [ERC-3643 ONCHAINID](https://www.erc3643.org/), [EAS](https://attest.org/), [W3C Verifiable Credentials 2.0](https://www.w3.org/TR/vc-data-model-2.0/), [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) +- **Credential Systems:** [ZKPassport](https://zkpassport.id/), [Self](https://self.xyz/), [Rarimo](https://rarimo.com/), [Anon Aadhaar](https://github.com/anon-aadhaar), [zkEmail](https://zk.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/) - See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team, demo data): verifiable credentials, KYC/KYB, licensing, selective disclosure - **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)