The Ethereum Foundation (EF), through its Privacy Stewards of Ethereum (PSE) team, is rolling out a strategic initiative to integrate Zero-Knowledge Proof (ZKP) standards into the global digital identity landscape.
This isn't an academic exercise. It's a response to direct institutional demand—specifically from the European Union (eIDAS) and Taiwan's Ministry of Digital Affairs (MODA)—to solve the privacy crises inherent in current digital wallets.
In this deep dive, we unpack the PSE's playbook, the technical constraints they are navigating, and the cryptographic evolution from SD-JWTs to Generic SNARKs.
New to the concepts of DID, VC, and BBS+? Start with our foundational guide: From SSI to zkID – The Evolution of Digital Identity.
1. The Core Strategy: "Proliferation, Not Competition"
The PSE's goal is not to build another Identity Provider (IdP) or compete with existing SSI protocols. Instead, the strategy is infrastructure proliferation.
- Modular Architecture: Building reusable components that any project (e.g., Anon Aadhaar, Proof of Passport) can plug in.
- Gap Filling: Targeting infrastructure-lacking regions by providing the "crypto-plumbing" needed to unlock on-chain use cases for existing credentials.
- Standardization: Addressing the fragmentation (100+ DID methods) by pushing for common ZK specifications.
2. Technical Constraints (The "Hard" Requirements)
To build a privacy-preserving identity layer that scales to millions of users, the architecture must satisfy four non-negotiable constraints:
- Unlinkability: Preventing Verifier A and Verifier B from colluding to track a user. (This is where most current standards fail).
- Client-Side Proving: Proofs must be generated on the user's mobile device.
- Target: < 2 seconds on low-end mobile.
- Post-Quantum Security: We are building for the next decade, not just today.
- No Trusted Setup: Eliminating "ceremonies" that introduce centralization risks.
3. The Protocol Roadmap: Evaluating the Options
The industry is currently transitioning through three stages of cryptographic maturity.
Phase 1: SD-JWT (Selective Disclosure JWT)
The Status Quo
- How it works: Uses salted hashes to hide specific fields in a JSON Web Token.
- The Problem: It fails the Unlinkability test. The issuer signature is static. If you present the same credential twice, you can be tracked.
- Verdict: ❌ Not recommended for high-privacy use cases.
Phase 2: BBS+ Signatures
The Intermediate Solution
- How it works: Multi-message digital signatures that allow generating unique ZKP proofs for each presentation.
- The Good: Provides strong Unlinkability.
- The Bad:
- Relies on pairing-friendly curves not yet certified by EU regulators (BSI/ANSSI).
- Not post-quantum secure.
- Verdict: ⚠️ Good for now, but not the endgame.
Phase 3: Generic zk-SNARKs
The Endgame
- How it works: Decouples the signed data from the verification logic entirely.
- Example: Google's Longfellow-ZK (verifies ECDSA/SHA-256 legacy credentials in a ZK circuit).
- Benchmark: ~816ms prover time on mobile.
- Verdict: ✅ The long-term winner. Enables arbitrary logic ("Age is prime") without re-issuance.
4. The "Vitalik Critique": Why Tech Isn't Enough
Vitalik Buterin's recent analysis ("Does digital ID have risks even if it's ZK-wrapped?") adds a critical layer of social engineering to this technical discussion.
Even with perfect ZK, two risks remain:
- The "One-Identity" Trap: If we force a single "real-name" identity for everything, we kill pseudonymity. We must encourage contextual identities (e.g., a "Gamer ID" separate from a "Gov ID").
- The Master Key Problem: ZK protects against snooping, but not coercion. If a government demands your private key, the game is over.
Conclusion
The shift from SD-JWT to zk-SNARKs effectively moves identity from "Digitized Paper" to "Programmable Privacy."
By solving the hard engineering problems of Client-Side Proving and Unlinkability, the PSE team is laying the groundwork for an identity layer that is not just secure, but physically impossible to surveil.