Digital Identity Wallet Standards, the DC API, and Politics
“Digital identity wallet standards are having a moment. In certain circles, they’re the topic.”
The European Union is driving much of the global conversation through eIDAS2, which requires every member state to deploy digital wallets and verifiable credentials that work across borders. In the United States, things look very different: deployment is happening state by state as DMVs explore mobile driver’s licenses (mDLs) and experiment with how these new credential formats fit into existing identity systems.
For most people, this shows up as “more stuff on my phone,” though desktops matter, too. Regulators and lawmakers see more areas where they need to set rules regarding security, privacy, and usability. Developers and standards architects see something else: a complex web of digital identity wallet standards that include the layers of browsers, OS platforms, protocols, and wallets that must interoperate cleanly for anything to work at all.
We saw a version of this during the October AWS outage, where headlines immediately blamed “the DNS.” But the DNS protocol behaved exactly as it should. What failed was the implementation layer: AWS’s tooling that feeds DNS, not DNS itself.
A similar pattern is emerging around digital wallets and verifiable credentials. At last week’s W3C TPAC meeting, I lost count of how many times I heard a version of:
“It’s the Digital Credential API’s fault/responsibility.”
Just as “it’s the DNS” became shorthand for an entire problem space, “it’s the DC API” is now becoming shorthand for an entire stack of browser, OS, and wallet behavior. And that shorthand is obscuring real issues.
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!
Why the web has layers in the first place
Before diving into the DC API, it’s worth remembering why the ecosystem is structured this way. The web is layered by design, and when it comes to digital wallets, that layer looks like this:
- Browsers enforce security boundaries between websites and users.
- Operating systems manage device trust, hardware access, and application permissions.
- Wallets specialize in credential storage, presentation, and user experience.
- Protocols define how information moves across these components in interoperable ways.
No single layer can—or should—control the entire flow. The fragmentation is intentional. But when political or regulatory urgency collides with this architectural reality, confusion is almost guaranteed.
If you want a broader overview of the standards bodies and protocols that shape digital identity wallets, I wrote about that landscape in a post last year: “The Importance of Digital Identity Wallet Standards.” It provides helpful context for how these layers evolved and why they interact the way they do.
What the Digital Credential API actually is
The DC API is a protocol under development at the W3C. It isn’t a standard yet, it isn’t a wallet, and it isn’t an OS-level API. It’s one layer in a larger system.
What it actually does:
- The browser receives a request to present a credential.
- That request uses a specific presentation protocol, such as:
- ISO/IEC 18013-7 Annex C (from the mDL ecosystem)
- OpenID for Veriable Presentations (OpenID4VP, developed in the OpenID Foundation)
- The DC API passes that request to the device’s platform-specific APIs.
- The OS hands the request to the wallet(s) installed on the device.
- If the credential needs to move between devices, the DC API relies on the Client to Authenticator Protocol (CTAP, developed in the FIDO Alliance) for secure cross-device interactions.
That’s it. The DC API connects a request from the browser to a wallet. Everything else happens above or below it. Tim Cappalli is doing amazing work documenting this on the Digital Credentials Developers website.
A similar dynamic showed up years ago with Identity Provider Discovery, where some stakeholders wanted a trusted, independent way to verify that the user was being shown the correct identity providers. Some would like the DC API to offer similar guarantees for wallets and credentials. But that kind of oversight is not in scope for this layer. The DC API doesn’t govern UX, verify correctness, or audit the platform; it only bridges protocols to the OS.
Two important clarifications
As one of the co-chairs of the W3C group working on the DC API, I spend a lot of time keeping the specification tightly scoped to the layer it actually controls. Outside the working group, though, “the DC API” often becomes shorthand for every layer in the wallet stack, which results in unfortunate (at least from my perspective) confusion.
The DC API supports multiple presentation protocols, but browsers, OSs, and wallets don’t have to.
The DC API can transport both Annex C and OpenID4VP. But support across layers varies:
- Google supports both protocols.
- Apple supports Annex C only.
- Third-party wallets choose based on product goals.
- Government-built wallets align protocol choices with policy, privacy, and interoperability requirements.
So while the DC API can support multiple protocols, the ecosystem around it is not uniform. That’s a separate but very relevant problem. At this time, this critical standard is only fully supported by one vendor, and yet, the option is this or the less-than-secure option that is custom URL schemes.
The DC API allows multiple wallets on one device, but the ecosystem isn’t ready.
In theory, multiple wallets are fine. In practice, this raises unresolved questions:
- How should a device present wallet choices?
- How does a wallet advertise which credentials it holds?
- What happens when wallets support different protocols?
These aren’t DC API issues, but misunderstandings about them often land at the DC API’s feet. So why not make it the DC API’s responsibility? There are reasons.
Why pressure lands on the DC API
Some requirements emerging from the European Commission would require changes in how the OS platform layer behaves; that’s the layer that controls platform APIs, secure storage, inter-app communication, and hardware-backed protections.
But the OS platform layer is proprietary. No external standards body governs it, and regulators cannot directly influence it.
The EC can influence some other layers. For example, they engage actively with the OpenID Foundation’s OpenID4VP work. But OpenID4VP has already been released as a final specification. The EC can request clarifications or plan for future revisions, but they cannot reshape the protocol on the timeline required for deployment.
That leaves the DC API.
Because the DC API is still in draft, it is one of the few open, standards-based venues where the EC can place requirements for transparency, security controls, and protocol interoperability. It is, quite literally, the only part of this stack where immediate governance pressure is possible.
When pressure lands on the wrong layer
The problem arises when that pressure is directed at a layer that does not control the behaviors in question. Some EC requirements cannot be met without OS-level changes, and those changes are outside the influence of a W3C specification. The deeper issue is that governments need predictable, enforceable behavior from digital wallets—behavior that works the same way across browsers, devices, and vendors. But if support for key standards like Annex C or OpenID4VP varies by platform, and wallet behavior differs across OS ecosystems, governments are left with only two real levers: regulate platforms directly, or mandate interoperability requirements that implementations must meet. Neither of those levers sits at the DC API layer. That layer can expose capabilities, but it cannot enforce consistency across implementations.
Regulators aren’t wrong to feel frustrated. They want outcomes—stronger security, clearer transparency, and technical mechanisms supporting regulatory oversight, and better privacy protections—that would require deeper hooks into the platform. But today, the only open venue available to them is the DC API, not the proprietary OS layers below it, and not a recently finalized protocol like OpenID4VP. By pressuring the DC API, there is hope that this might encourage OS vendors to change their ways.
The missing layer: the W3C TAG’s concerns about credential abuse
Another factor complicating the landscape is that each layer is thinking about the “big picture.” The W3C Technical Architecture Group (TAG) recently published a statement, Preventing Digital Credential Abuse, outlining the risks associated with the abuse of digital credentials, highlighting how easily these technologies can be misused for tracking, surveillance, exclusion, and other harms if guardrails aren’t in place.
Their guidance is deliberately broad. They are looking across browsers, wallets, protocols, and policy environments, and raising concerns that span multiple layers. That kind of review is their mandate: they examine the technical architecture (as implied by the name of the group) and provide guidance to ensure that protocols developed for the web are as safe and useful as possible.
Unfortunately, the TAG is similar to the EC in that it can only influence so much when it comes to standards. Critical decisions about privacy and security often occur outside the remit of any single specification or standards organization. A browser can mitigate some risks. An OS can mitigate others. Wallets can add protections. Protocols can limit what they expose. But no single layer can fix everything. That said, the EC (unlike the TAG) can regulate the issue and force platforms to specific implementations, which is its own political challenge.
The missing governance layer
This is part of why there is so much political, architectural, and cultural pressure around digital credentials. Everyone is trying to look after the whole system, even though no layer actually controls it. This is why some stakeholders argue that a new layer—one explicitly designed for governance—may be required. A layer where wallet- and platform-facing behaviors are standardized in a way regulators can rely on, rather than inferred from proprietary implementation details. If governments want consistent privacy controls, consistent credential-selection behavior, or consistent transparency requirements, they will eventually have to either regulate platform behavior directly or create a standards-based layer that makes such oversight possible.
When political pressure meets technical layering
Digital wallets and verifiable credentials are being deployed globally, but the gravitational center of policy influence remains Brussels. The “Brussels Effect” is real. Discussions in the W3C Federated Identity WG, the OpenID Foundation’s DCP WG, and other standards groups frequently reference the EUDI ARF and eIDAS2 timelines.
Political pressure isn’t inherently bad. Sometimes it’s the only reason standards work moves at all. But when pressure targets the wrong layer, we get:
- misaligned expectations
- rushed architectural decisions
- poorly targeted requirements
- and the temptation to fall back to less secure approaches (such as custom URL schemes)
Some EC expectations cannot be met without changes to the layering of the current technical solutions. Achieving the desired outcomes for privacy and transparency would require OS vendors to publicly disclose platform behaviors or implement new layers that afford regulatory oversight, standardized controls, or support additional protocol features.
Closing: shorthand is helpful… until it isn’t
“The DC API” is increasingly used as shorthand for the entire credential-presentation ecosystem. It’s understandable and perhaps unavoidable. But it isn’t accurate.
When inconsistencies show up across implementations, it’s tempting to assume the DC API should be redesigned to become a more prescriptive or “smarter” layer. That is technically possible, but it has little support within the working group—and for good reason. A protocol-agnostic DC API preserves permissionless innovation and prevents any one protocol or architecture from dominating the ecosystem. It is meant to expose capabilities, not dictate which protocols must be used or how wallets should behave.
If governments need consistent, enforceable behavior across platforms—and many do—those guarantees must come from a different part of the stack or through regulation. The DC API simply does not have the authority to enforce the kinds of requirements that regulators are pointing toward, nor should it be transformed into that kind of enforcement mechanism.
If we want secure, interoperable digital wallets, we need to name the right problems and assign them to the right layers. Expecting the DC API to control behaviors outside its remit won’t get us the outcomes we want.
The real work starts with a better question: “Which layer is responsible for this?” Only then can we move on to the most important question: “How do we manage these layers to best support and protect the people using the technology?”
Everything else follows from that.
📩 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 back. Today, we’re talking about digital identity wallets because they are definitely having a moment right now—at least among the people who spend their days thinking about standards, protocols, governance, and all the delightful complexity of making digital identity work at scale.
In many circles, digital wallets aren’t just one topic among many. Instead, they have become the topic.
Furthermore, much of this momentum is coming from the European Union. Under eIDAS 2, every EU member state must deploy digital wallets and verifiable credentials that work across borders. That’s a massive mandate, and it’s shaping the conversation far beyond Europe.
Meanwhile, in the U.S., the topic looks a bit different. Deployment is happening primarily state by state, as DMVs explore mobile driver’s licenses (MDLs). The results include:
- Fragmented implementation
- A lack of harmonization
- State-driven experimentation
Yet this patchwork now coexists with the EU’s broad alignment efforts, while other regions adapt approaches that suit their needs.
More Wallets, More Icons, More Complexity
For most everyday users, this simply shows up as more stuff on their phones—an airline ticket here, a government wallet there, and possibly more icons appearing in the future as deployments expand.
Even though phones dominate the conversation, desktops continue to matter. Different stakeholders view the shift through different lenses:
- Regulators identify more areas where intervention may be required.
- Architects see a complex interplay between browsers, operating systems, protocols, and wallet design.
- Product teams wrestle with the UX and expectations users bring.
- Lawmakers try to understand the implications and risks.
And unsurprisingly, interoperability sometimes breaks.
A great example comes from the AWS outage back in October. Headlines blamed DNS—but DNS worked exactly as designed. The failure stemmed from the implementation layer that feeds DNS, not DNS itself.
This is important, because a similar pattern is emerging in the conversations around digital wallets and the Digital Credentials API (DC API).
The DC API Becomes a Scapegoat
At last week’s W3C TPAC meeting, “It’s the DC API’s fault” became a common refrain.
However, just as with DNS, “the DC API” has become shorthand for an entire stack—browser behavior, OS behavior, application logic, protocol integration, and wallet decisions. And that shorthand obscures real issues.
So let’s step back and revisit the basics.
Why We Have Layers
The web is layered, intentionally. Fragmentation is a feature, not a bug.
Each layer plays a different role:
- Browsers enforce security boundaries and mediate how websites interact with users.
- Operating systems manage device trust, hardware access, and permissions for inter-app communication.
- Wallets store credentials and manage the user experience around presentation.
- Protocols govern how data moves between each layer in interoperable ways.
No single layer can—or should—control the entire ecosystem.
However, political urgency tends to collide with this distributed design, creating confusion.
If you want a broader primer, check out the earlier piece The Importance of Digital Identity Wallet Standards, which explains how these layers historically evolved.
But today, our focus is the DC API.
What the DC API Actually Does
The Digital Credentials API is a protocol under development at the W3C. It is:
- Not a standard yet
- Not a wallet
- Not an OS-level API
- Just one layer with a narrow scope
Here’s the actual flow:
- The browser receives a request to present a credential.
- That request uses a presentation protocol—typically:
- ISO 18013-7 (Annex C) from the MDL ecosystem, or
- OpenID for Verifiable Presentations (OID4VP).
- The DC API passes the request to the operating system.
- The OS hands it to whichever wallet(s) are installed.
- If the credential needs to be presented across devices (e.g., from phone to desktop), the DC API uses CTAP from the FIDO Alliance.
As you can already see, this brings in several standards bodies:
- ISO
- OpenID Foundation
- W3C
- FIDO Alliance
The DC API simply bridges browser protocol traffic to the OS. Everything else happens above or below it.
Tim Cappalli has a great visual diagram of this—linked from the written blog post.
Echoes of Old Identity Problems
This is not the first time these issues have come up. Years ago, during the identity provider discovery debates, some parties wanted browsers to verify the “correct” identity provider.
Now, we’re hearing similar suggestions: that the DC API should verify whether the “correct” wallet is being used.
However, this is out of scope. The DC API does not:
- Govern UX
- Verify correctness
- Audit platform behavior
It only bridges protocols.
As one of the W3C co-chairs working on the DC API, I spend a great deal of time keeping the specification tightly scoped, while the world often uses “DC API” as a catch-all term for problems elsewhere.
Clarification #1: Protocol Support Varies
The DC API supports multiple presentation protocols, but vendors do not have to.
For example:
- Google supports both Annex C and OpenID4VP.
- Apple supports only Annex C.
- Third-party wallets choose based on their own goals.
- Government wallets choose based on policy and privacy requirements.
So while the DC API is protocol-agnostic, the surrounding ecosystem is not uniform.
Without the DC API, implementers would rely on custom URI schemes, which are problematic for security and privacy.
Clarification #2: Multiple Wallets on One Device
The DC API technically allows multiple wallets on the same device, but the ecosystem is not yet ready.
Key unanswered questions include:
- How should devices present wallet choices?
- Should wallets advertise which credentials they hold?
- What if different wallets prefer different protocols?
These are important questions—but not questions for the DC API.
So Why the Pressure on the DC API?
Much of it comes from regulatory pressure, especially from the European Commission.
Some EC requirements require OS-level changes, but OS behavior is proprietary and not governed by standards bodies—so regulators cannot influence it directly.
Protocols such as OID4VP and Annex C are already nearly finalized, leaving little wiggle room.
Therefore, regulators turn to the one venue still open: the DC API Working Group.
Unfortunately, some expectations require changes outside what the DC API controls.
Governments need:
- Consistent behavior across devices
- Transparent selection mechanisms
- Predictable privacy protections
If platform support varies, governments must either:
- Regulate platforms directly, or
- Mandate compliance through policy
In practice, the choice increasingly becomes regulation.
The W3C TAG Weighs In
The W3C Technical Architecture Group (TAG) recently published Preventing Digital Credential Abuse, which outlines risks including:
- Tracking and surveillance
- User exclusion
- Privacy harms
The TAG offers broad guidance across layers. However, the TAG cannot enforce behavior.
Browsers can mitigate some risks.
OS platforms can mitigate others.
Wallets can add protections.
Protocols can define boundaries.
But no single layer can solve them all.
The European Commission can regulate, though doing so creates additional complexities.
A Possible New Governance Layer?
Because of the competing pressures—political, architectural, and cultural—some stakeholders now wonder if the ecosystem may eventually require a new governance layer.
Such a layer could standardize:
- Wallet-facing behaviors
- Platform-facing behaviors
- Privacy controls
- Transparency requirements
This would give regulators a consistent target, rather than relying on inferred or proprietary platform behavior.
The Brussels Effect
Digital wallets and verifiable credentials are being deployed globally, but Brussels still exerts immense policy influence.
You can feel it in:
- W3C Working Groups
- OpenID Foundation discussions
- Broader standards ecosystem conversations
Political pressure isn’t inherently bad—it often accelerates progress. But when the pressure is misaligned with where change must occur, the results are predictable:
- Misaligned expectations
- Rushed architecture decisions
- Poorly targeted requirements
- A retreat to less secure options (like custom URI schemes)
The DC API Is Not the Entire Ecosystem
The DC API often becomes shorthand for the entire credential presentation ecosystem—but that’s inaccurate.
- Protocols live in different standards bodies.
- Implementations live in different layers.
- Governments and companies make different choices.
When inconsistencies appear, some suggest making the DC API more prescriptive. While technically possible, it has little support—for good reason.
A protocol-agnostic DC API:
- Preserves permissionless innovation
- Prevents one protocol from dominating
- Exposes capabilities
- Avoids dictating wallet behavior
If governments need enforceable consistency, it must come from either:
- Regulation, or
- A new standards-based governance layer
It won’t come from the DC API.
Closing Thoughts
If we want secure, interoperable digital wallets, we must name the right problems and assign them to the right layers.
The key question is:
Which layer is responsible for this component?
Once we answer that, we can address how to manage the layers to best support and protect users.
Everything else follows from that.
Outro
And that wraps up this week’s episode of the Digital Identity Digest.
If this helped clarify a complex topic, please share it with a colleague and connect with me on LinkedIn @hlflanagan.
Subscribe, leave a rating or review, and check out the full written post at sphericalcowconsulting.com.
Stay curious, stay engaged, and let’s keep these conversations going.
