Designing Digital Wallets for Reality: Where Selective Disclosure and ZKPs Fit
“This post is about design decisions and tradeoffs in digital identity wallets. I was at an event recently (TIIME, in case you’re curious) where wallets were a hot topic, and the ZKP session was fascinating.”
So, time to write about what I learned from that and the research it inspired.
I wrote about zero-knowledge proofs last year from a higher-level perspective, focusing on their promise and some of the practical concerns around cost and accessibility. What’s become clearer since then, especially as wallet deployments move closer to production, is that the more interesting questions are increasingly architectural. Where the complexity lives, how correlation risk is managed, and how these systems behave at scale are starting to matter just as much as the underlying math.
First off, let’s remember that digital identity wallets aren’t always distinct from digital payment wallets. Several platforms are already combining the two. But they can be separate, and in many deployments, they are. Regardless of whether payment data is involved, the important point is this: digital identity wallets are becoming real infrastructure.
You can tell because they are being written into regulation (I’m looking at you, EU and your eIDAS 2.0 regulation). They are showing up in national programs. And they are increasingly being used by real people in everyday scenarios. Even enterprises—especially in finance and other regulated sectors—are starting to treat wallets as something they will need to support, not just monitor from a distance.
That shift changes the design conversation. It means designing for operational reality, not just a minimum viable product.
Which brings us to one of the many (many) architectural choices teams now face: when it comes to using the data held in a digital wallet, should systems rely on selective disclosure, zero-knowledge proofs, or some combination of both? This question is getting more attention because wallet deployments are moving out of pilot mode and into regulated, high-scale environments where privacy, performance, and operational cost all start to collide. The cryptography choices that felt interchangeable in early prototypes are beginning to have real architectural consequences.
You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.
And be sure to leave me a Rating and Review!
First, a quick reality check
Before going too far down the comparison path, it is worth understanding the distinction between the terms. These phrases describe different technical mechanisms, but they can be combined (or not), making clear distinctions a bit tricky. In other words, selective disclosure and ZKP are not mutually exclusive.
Selective disclosure refers to a credential holder’s ability to reveal only specific attributes from a credential rather than presenting the entire data set. A verifier might learn that someone is over 18, lives in a particular jurisdiction, or holds a given certification without receiving the rest of the credential contents. In many current deployments, this is achieved through cryptographic techniques that allow partial disclosure of signed data.
Zero-knowledge proofs (ZKPs) are a broader class of cryptographic protocols that allow one party to prove a statement is true without revealing the underlying data used to prove it. In wallet systems, this often means the holder can prove a predicate—such as “over 18”—without revealing the birthdate itself, and sometimes without exposing a stable identifier that could be correlated across transactions.
There is an important overlap between the two. In many modern credential architectures, selective disclosure is the goal, while zero-knowledge techniques are one — increasingly powerful — way to achieve it. Other implementations rely on more traditional signature schemes and structured credential design. And to round out the discussion, many production architectures will use elements of both. So the real question is not which one “wins.” It’s more a question of: where does the complexity live, and how does the system behave at scale?
Why selective disclosure became the early favorite
Selective disclosure has gained traction for good reasons. Conceptually, it is easy to explain and aligns well with existing credential models.
Instead of presenting a full credential, the holder reveals only what is needed for a given transaction. Proof of age instead of full birthdate. Proof of employment status instead of a full personnel record.
From a data minimization standpoint, this is clearly better than the “hand over everything” patterns that dominated earlier identity systems. In many controlled deployments, it works quite well. But the implementation details matter more than the headline capability.
In many current ecosystems, selective disclosure is often implemented through structured issuance models, though certainly not all selective disclosure schemes require this kind of credential structuring. Issuers anticipate future presentation needs and produce credentials, or credential variants, accordingly. This structured selective disclosure approach can work effectively at modest scale.
At national or cross-border scale, however, it begins to introduce operational weight. More credential variants can mean more issuance overhead, more revocation complexity, and more lifecycle management to keep everything synchronized across the ecosystem.
There is also a quieter privacy consideration. Structured selective disclosure reduces what is visible in a single transaction. But depending on how identifiers and cryptographic material are handled, it does not always eliminate the possibility of correlation across transactions.
This becomes particularly relevant in scenarios where the issuer and verifier may collude or, in some government and enterprise deployments, are effectively the same entity. In those environments, linkability can emerge even when individual disclosures appear minimal.
For some deployments, that is an acceptable risk.
For others—particularly those operating under strict data protection expectations—it becomes a more significant design concern.
What changes with zero-knowledge proofs
Zero-knowledge proof techniques approach the problem from a different angle.
Instead of relying on multiple pre-segmented credential variants, the issuer signs a credential once. The wallet then derives proofs dynamically, demonstrating only what is required for a given interaction. In some cases, this reduces disclosure all the way down to a predicate such as “over 18.”
In non-interactive models, this can happen in a single exchange, which is appealing for web-scale and cross-border environments. But the most important architectural shift is not just about what gets disclosed. It is about where the system complexity moves.
Structured selective disclosure models often concentrate complexity in the issuer and ecosystem governance layer. ZKP-enabled approaches tend to push more responsibility into the wallet and the user’s device, allowing selective disclosure to be computed dynamically rather than pre-packaged at issuance time.
That shift is not trivial. Efficient proof generation on constrained devices is still a real engineering challenge. Holder binding, pseudonym strategies, hardware support, and cryptographic agility all require careful design. Understanding how confidently the ecosystem can determine whether the entity presenting the credential is the legitimate holder is both difficult and critical.
But it also distributes computational effort across millions of devices instead of concentrating it in national backend systems. At very large scale, that distribution is not just a technical preference — it becomes a sustainability decision.
One additional caution is worth keeping in mind (the folks over at Brave wrote about this recently). Zero-knowledge proofs faithfully amplify the semantics of the underlying data. If the input credential, token structure, or claim canonicalization is poorly defined, the proof will still verify as valid; it will simply be proving something less meaningful than intended. In other words, ZKP strengthens well-designed systems, but it does not rescue weak ones.
It’s also worth noting that revocation and status checking are still active areas of engineering work for privacy-preserving credential systems. That’s a long way of saying the industry is still working through how to handle revocation cleanly at very large scale.
Correlation is the long game
One of the more subtle issues in wallet design is verifier-verifier correlation. Even when individual transactions are well minimized, linkability can emerge over time if the same identifiers or cryptographic material appear repeatedly across contexts.
Some structured selective disclosure deployments attempt to mitigate this through credential segmentation or batching strategies. That can help, but often at the cost of additional operational overhead.
ZKP-enabled selective disclosure offers a more structural response. Properly designed systems can derive per-verifier pseudonyms or unlinkable presentations from a single underlying credential.
For regulators and ecosystem designers thinking about privacy-by-design, this is often where the conversation becomes more concrete. It is less about any single transaction and more about what can be inferred over months or years of system use.
Reducing attributes is good. Reducing structural linkability is better.
Of course, cryptography is only part of the correlation story. Business logic, verifier behavior, network metadata, and user patterns can all reintroduce linkability if the broader system is not designed with equal care.
None of this is free
It would be a mistake to present ZKP approaches as a frictionless upgrade path. They are not.
Different constructions come with different tradeoffs. Some are efficient but raise longer-term cryptographic questions. Others are more future-resilient but computationally heavier. Hardware support is uneven. Secure element compatibility is still evolving.
Selective disclosure, for its part, benefits from being closer to many existing credential and signature models and from having more deployment experience today.
In other words, both paths involve real engineering and real tradeoffs. Which is exactly why wallet architects need to think beyond the minimum viable deployment.
Designing for the systems we are actually building
Wallet deployments are moving quickly, especially in Europe. Certification regimes are forming, mostly because they legally have to, but without guidance on what that means. Browser behavior continues to shift. Enterprises are starting to run real risk analyses instead of pilot experiments. There are a lot of ideas being thrown at a wall to see what will stick.
In that environment, it is tempting to choose whatever works today and defer the harder architectural questions. Tempting, but probably unwise. Digital wallets are not a short-lived feature. They are becoming part of the identity substrate of the internet and regulated digital services.
Most mature ecosystems will likely use both selective disclosure and zero-knowledge techniques over time. The goal is not purity. The goal is systems that behave well under real-world pressure.
The real design challenge is making sure the architecture can evolve without creating unsustainable operational or privacy debt. Because once these systems reach national scale, changing direction becomes significantly harder.
And, as always in identity, your mileage may vary. Different sectors, regulatory environments, and risk tolerances will land in different places on this spectrum. But the sooner teams start evaluating where complexity, correlation risk, and long-term operational cost actually sit, the better positioned they will be when today’s pilot architectures become tomorrow’s infrastructure.
📩 If you’d rather track the blog than the podcast, I have an option for you! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here]
Transcript
Welcome to the Digital Identity Digest
[00:00:00] Welcome to the Digital Identity Digest, the audio companion to the blog at Spherical Cow Consulting. I’m Heather Flanagan, and every week I break down interesting topics in digital identity — from credentials and standards to browser behavior and policy twists.
[00:00:26] If you work in digital identity but don’t have time to follow every specification or hype cycle, you’re in the right place.
Digital Wallets Are Moving From Theory to Practice
[00:00:31] If you spend time in digital identity, payments, or policy conversations, you’ve probably noticed a shift. What used to live in future-looking architecture diagrams is now showing up in regulation, procurement plans, and real product roadmaps.
[00:00:54] That shift was especially visible at Trust in Internet Identity Middleware Europe (TIME), where digital wallets were a major topic for the research and education community.
Why Zero Knowledge Proofs Are Back in Focus
[00:01:11] One session in particular focused on zero knowledge proofs — and importantly, it wasn’t designed for cryptographers.
[00:01:21] Instead, it explored deployment questions that are becoming very real, very quickly as wallet systems move toward production.
From Cryptographic Promise to Architectural Reality
[00:01:32] This conversation is less about cryptographic magic and more about design decisions teams are now being forced to make.
[00:01:53] As wallet deployments approach real-world scale, the most pressing questions are architectural:
- Where does system complexity live?
- How is correlation risk managed?
- How do these systems behave at scale?
Digital Identity Wallets as Real Infrastructure
[00:02:18] Digital identity wallets aren’t always separate from payment wallets. Some platforms are already combining the two, while others keep them distinct.
[00:02:51] Regardless, identity wallets are clearly becoming infrastructure. They’re written into regulation, embedded in national programs, and used by real people in everyday scenarios. Enterprises — especially in regulated sectors — are starting to plan for wallet support, not just observe from a distance.
Designing for Operations, Not Just MVPs
[00:03:03] This shift changes the design conversation. Teams now have to design for operational reality, not just minimal viable products meant to prove feasibility.
[00:03:12] One of the most significant architectural choices involves how data is disclosed from wallets:
- Selective disclosure
- Zero knowledge proofs
- Or a combination of both
Getting the Terminology Straight
[00:03:56] These terms are often used interchangeably, but they describe different technical mechanisms.
Selective disclosure allows a credential holder to reveal only specific attributes instead of the entire credential.
[00:04:19] For example, a verifier may learn that someone is over 18 or holds a certification without receiving their name or full data set.
Zero knowledge proofs (ZKPs) allow one party to prove a statement is true without revealing the underlying data.
[00:04:34] In wallet systems, this often means proving a predicate — like being over 18 — without revealing a birthdate or stable identifier.
Not Either–Or, But Architectural Trade-Offs
[00:05:11] In many modern credential architectures, selective disclosure is the goal, and zero knowledge proofs are one increasingly powerful way to achieve it.
[00:05:37] These approaches are not mutually exclusive. Many production systems will use elements of both.
[00:05:44] The real question is where complexity lives and how systems behave at national or cross-border scale.
Why Selective Disclosure Gained Early Momentum
[00:05:54] Selective disclosure became popular for good reasons. It’s easy to explain, aligns well with existing credential models, and clearly improves data minimization.
[00:06:34] However, many deployments rely on structured issuance models, where issuers anticipate future use cases and pre-structure credentials accordingly.
At scale, this introduces:
- Increased issuance overhead
- More complex revocation
- Greater lifecycle management burden
Correlation Risk in Structured Models
[00:07:32] Even when individual disclosures are minimized, correlation can still emerge across transactions.
[00:07:49] This is especially relevant when issuers and verifiers collude — or are the same entity. In those environments, linkability can persist despite selective disclosure.
How Zero Knowledge Proofs Change the Scaling Model
[00:08:21] Zero knowledge proof approaches invert this model. The issuer signs a credential once, and the wallet dynamically derives proofs locally.
[00:08:42] In some cases, disclosure can be reduced to a single predicate in a single exchange — an appealing model for web-scale and cross-border use.
Moving Complexity to the Edge
[00:09:26] This shift moves complexity away from centralized issuers and into wallets and user devices.
[00:09:41] That introduces real engineering challenges, including:
- Efficient proof generation on constrained devices
- Holder binding strategies
- Pseudonym management
- Hardware and cryptographic agility
At scale, distributing computation across millions of devices becomes a sustainability decision, not just a technical one.
A Critical Reality Check on ZKPs
[00:10:28] Zero knowledge proofs faithfully amplify whatever semantics exist in the underlying data.
[00:10:37] Well-designed systems become stronger, but poorly defined data is still poor — just cryptographically proven. ZKPs do not rescue weak system design.
Revocation and Status Remain Hard Problems
[00:11:01] Revocation and status checking remain active areas of engineering work, particularly for systems that require offline or low-latency verification. Progress is being made, but trade-offs remain unresolved.
Verifier Correlation Over Time
[00:11:17] Even well-minimized transactions can become linkable over time.
[00:11:52] Some selective disclosure systems mitigate this through credential segmentation or batching, but that comes with added operational overhead.
[00:12:06] Zero knowledge-enabled approaches can instead derive per-verifier pseudonyms, reducing long-term structural linkability.
Cryptography Isn’t the Whole Story
[00:12:27] Correlation risk doesn’t come solely from cryptography. Business logic, verifier behavior, network metadata, and usage patterns can all reintroduce linkability if the broader system isn’t designed carefully.
No Free Upgrades
[00:12:42] Zero knowledge proofs are not a frictionless upgrade path. Different constructions involve trade-offs in performance, hardware support, and long-term cryptographic resilience.
[00:13:16] Selective disclosure benefits from greater deployment experience today, but it also carries structural limitations at scale.
Designing Beyond the Pilot Phase
[00:13:38] Wallet deployments are accelerating, especially in Europe. Certification regimes are forming, browsers are changing, and enterprises are conducting real risk analysis.
[00:14:01] Digital wallets are not short-lived features — they are becoming part of the identity substrate of the internet.
Final Thoughts
[00:14:22] Most mature ecosystems will eventually use both selective disclosure and zero knowledge techniques. The goal isn’t purity — it’s resilience under real-world pressure.
[00:14:46] The sooner teams evaluate where complexity, correlation risk, and long-term operational costs live, the better prepared they’ll be when today’s pilots become tomorrow’s infrastructure.
One thought on “Designing Digital Wallets for Reality: Where Selective Disclosure and ZKPs Fit”
I once thought digital wallets would eventually become as omnipresent as web browsers are today. That’s why reading, “Digital wallets are not a short-lived feature. They are becoming part of the identity substrate of the internet and regulated digital services,” feels especially validating.