“When I first wrote about the W3C’s Digital Credentials API (DC API) in April 2024, one of the questions that interested me most was how the various layers of the digital credential ecosystem would work together.”

Browsers, operating systems, wallets, credential formats, and presentation protocols all have different responsibilities. Getting those responsibilities sorted out was going to be an interesting challenge.

More than two years later, that question is still very much with us.

Last week, the W3C held its annual Technical Plenary and Advisory Committee (TPAC) meetings in Dublin, Ireland. I wore enough hats at TPAC this year that I probably should have brought a hat rack. Between my roles on the W3C Technical Architecture Group (TAG), the Exploration Interest Group, and the Federated Identity Working Group (FedID WG) and Community Group (FedID CG), I found myself moving between conversations about the Web’s architecture, emerging areas of standardization, and the practical challenges of getting specifications across the finish line. One discussion that is staying top of mind is the Digital Credentials API (DC API) and its path toward becoming a W3C Recommendation.

The FedID WG made some meaningful progress. The working group agreed on an approach to narrowing the scope of the initial specification and reached a better understanding of the architectural boundaries between the API and the ecosystem around it. That’s a seriously big deal.

But some of the hardest questions remain, particularly around privacy. And those questions are a useful illustration of what happens when multiple standards and technologies must work together to deliver an experience that users can understand and trust.

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!

Getting the Scope Under Control

First, some good news: The working group agreed to take a page from the Web Authentication (WebAuthn) specification and organize the DC API into levels.

The idea is pretty straightforward; it’s another form of versioning. Rather than trying to resolve every feature request and architectural question before the API can advance, the group will identify the functionality essential to Level 1 and defer other features to Level 2.

The most consequential decision was to move credential issuance into Level 2.

The DC API was originally designed to support both the presentation of digital credentials (showing a credential to a website) and issuance (receiving a new credential into a wallet). Both are important, but they are at different stages of implementation maturity, which means we agreed to shift them to different levels.

Keeping issuance in Level 1 would make it significantly harder to advance the specification, particularly because a second browser implementation of that functionality has no committed timeline. Other capabilities, including conditional invocation and a broader mechanism for providing invocation context, will also move to Level 2.

This doesn’t mean the group is abandoning those features. It means recognizing that a useful, interoperable first version does not have to solve every problem the ecosystem will eventually encounter.

There’s still work to do before Candidate Recommendation (CR), including sorting through the remaining issues and pull requests to determine which genuinely block Level 1. But we now have a more manageable way to approach that work.

Where Does the API End?

The other important discussion concerned architectural boundaries.

In November 2025, I wrote about the politics of digital identity wallet standards, particularly the tendency to hold the DC API responsible for things happening elsewhere in the digital credential ecosystem. That tendency hasn’t disappeared. I understand why, but still. Grr.

The DC API provides a way for websites to interact with digital credentials through a browser-mediated interface. It is designed to accommodate different credential formats and protocols rather than dictate which ones the ecosystem must use. But making a digital credential transaction work involves considerably more than passing a request from a website to a wallet and returning a response.

The browser has responsibilities. So does the operating system, the wallet, the credential protocol, and the website requesting the information. Each component sees a different part of the transaction, and each has different capabilities for evaluating what is happening.

At TPAC, the group agreed to use the architectural model described at digitalcredentials.dev to help clarify those responsibilities.

That is useful progress. It gives us a common model for identifying whether a particular requirement belongs in the browser API, the underlying protocols, or another part of the ecosystem.

Unfortunately, identifying where a responsibility belongs doesn’t necessarily guarantee that someone will fulfill it. And that’s where things get interesting.

The Problem with Assuming Someone Else Will Handle It

Consider a website requesting information from someone’s digital identity wallet. The browser knows which website is making the request and can enforce rules about how the API is invoked. It may not, however, understand the contents of the credential being requested. Depending on the protocol and architecture, that information may be available only to the wallet.

The wallet, meanwhile, may understand exactly what information the user is being asked to disclose. But it may not have all the contextual information available to the browser about the website making the request.

Both components have important information. Neither necessarily has the complete picture.

Suppose the browser assumes that the wallet will explain what information is being shared and obtain appropriate user consent. That may be a reasonable division of responsibilities, provided the wallet actually does so.

But what happens if it doesn’t?

Perhaps the wallet displays a poorly designed consent interface. Perhaps its implementation doesn’t provide the protections the browser assumes are present. Or perhaps the protocol itself doesn’t convey enough information for the wallet to make an informed decision. From an architectural perspective, the browser may have done everything its specification requires. From the user’s perspective, the transaction may still have exposed information they never intended to share. This is why simply declaring something out of scope can be unsatisfying when discussing privacy and security.

It may be entirely correct that the DC API cannot solve a particular problem. That does not make the problem disappear.

The Problem with Everyone Trying to Handle It

There’s another side to this, though, and it is equally important. Suppose every component in the transaction decides it cannot trust the others to protect the user adequately.

The browser asks whether the user wants to proceed. The operating system asks whether the user wants to allow access to the wallet. The wallet asks which credential the user wants to share. The credential protocol or wallet interface introduces another confirmation about the information being disclosed.

Each of these interactions may have a defensible rationale. After all, each component has some responsibility for protecting the user. But imagine being the poor soul trying to accomplish a relatively ordinary task, such as proving your age to access a service.

How many times should you have to confirm that you want to do the thing you started doing?

We’ve seen the consequences of excessive permission and consent requests elsewhere on the web. Research into privacy notices and permission prompts has explored how the number, presentation, and repetition of these requests influence user behavior.

For example, research presented at CHI 2024 examined user behavior across more than 100 million Chrome installations and found that ignoring or dismissing certain browser permission prompts was common. Other research on privacy fatigue and tracking consent has examined how fatigue influences the decisions people make when presented with consent notices. The evidence is not that every additional prompt necessarily makes consent worse. Context, presentation, and the nature of the decision all matter.

But the risk is real: repeatedly asking people for permission can turn a meaningful security or privacy decision into another obstacle between them and whatever they were trying to accomplish. Eventually, people may stop evaluating what they’re being asked and start looking for the button that makes the interruption go away. In that situation, additional consent interfaces may create the appearance of stronger user protection while undermining the effectiveness of consent itself. That’s quite a problem for an ecosystem that places so much importance on user control.

Shared Responsibility Requires More Than Architectural Boundaries

I don’t think there’s a simple answer here.

It’s perfectly reasonable for the DC API to avoid defining the behavior of every wallet and credential protocol. Attempting to do so would make the specification considerably more complex, create dependencies on technologies outside the working group’s control, and potentially undermine the protocol neutrality that makes the API useful. At the same time, the API cannot assume that privacy protections exist elsewhere without understanding the consequences if those assumptions are wrong.

One approach is to distinguish between the responsibilities a component can directly enforce and the guarantees it depends on other components to provide. Where the browser can enforce a protection, the specification should be clear about what is required. Where protection depends on wallet or protocol behavior, those dependencies should be explicit. Ideally, they should also be testable or otherwise supported by concrete requirements in the relevant standards. And where a risk cannot be adequately addressed by the API, the specification needs to acknowledge that limitation.

This doesn’t eliminate the difficult coordination work so much as it makes it easier to see where that work is needed.

It also raises a question that deserves more attention: can the ecosystem coordinate consent and user interaction across these layers so that people receive the information they need at the moment it matters, without encountering a separate permission dialogue from every participating component?

That question extends beyond the scope of any one specification. But it is critical to whether the overall system will work well for users.

Privacy Is Still the Hard Part

The TPAC discussions confirmed that privacy remains one of the most significant obstacles to advancing the DC API to CR.

Several outstanding issues concern protections that depend, at least in part, on behavior outside the API itself.

Selective disclosure is one example. The ability to share only the information necessary for a transaction is an important privacy property of many credential systems. But the browser cannot necessarily determine which attributes a credential contains or which information will ultimately be disclosed. Other unresolved questions concern user-initiated credential presentation, purpose limitation, and responses to abusive credential requests.

These are not minor editorial matters. They involve decisions about what protections the API can realistically provide, what assumptions it makes about other components, and what risks remain.

The working group plans to bring editors and privacy experts together for more focused discussions to work through these questions. I expect those conversations to be challenging. Privacy requirements often expose assumptions about architecture that are easy to overlook when discussing functionality alone. They’re conversations we need to have if the API is going to provide a trustworthy foundation for digital credentials on the web.

What Happens Next?

The DC API is in a better position after TPAC than it was before. The decision to create specification levels provides a practical approach to delivering an interoperable first version. The agreement on architectural layering gives the group a better way to distinguish between the responsibilities of the browser API and the wider credential ecosystem. That said, neither decision, by itself, resolves the outstanding privacy issues.

The next stage will involve turning those agreements into concrete specification changes, completing the Level 1 issue triage, and working through the privacy questions that remain. I expect the most interesting discussions will continue to concern responsibilities that span multiple layers.

There is a temptation in standards development to believe that a well-defined architectural boundary means the responsibilities on either side have been adequately addressed. Sometimes they have. Sometimes that boundary is exactly where important assumptions become invisible.

For digital credentials, the user doesn’t experience a browser API, an operating system interface, a wallet, and a presentation protocol as separate architectural components. They experience a request to share information about themselves. That experience needs to be understandable, trustworthy, and reasonably straightforward, regardless of how many standards and technologies are involved in making it happen.

Figuring out how to deliver that experience without either neglecting essential protections or burying the user under permission requests remains one of the more interesting challenges ahead.

And yes, we’re still talking about it.

📩 If you’d like to be notified of new posts rather than hoping you catch it on social media, I have an option for you! Subscribe to get a notification when new posts go live. No spam, just announcements of new posts. [Subscribe here]

Transcript

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 the field of digital identity, from credentials and standards to browser weirdness and policy twists.

If you work with digital identity but don’t have time to follow every specification or hype cycle, you’re in the right place.

Let’s get into it.

When I first heard about the W3C’s Digital Credentials API back in April 2024, one of the questions that interested me most was how all the different pieces of the digital credential ecosystem would work together.

You have browsers and operating systems, things commonly referred to as digital wallets (although they should more properly be called credential managers), credential formats, and presentation protocols. Each has different responsibilities.

Figuring out how those responsibilities fit together was always going to be an interesting challenge. More than two years later, we’re still working on it.

Last week, I attended the W3C’s annual Technical Plenary and Advisory Committee Meetings, better known as TPAC, in Dublin, Ireland.

I wore enough hats this year that I probably should have brought a hat rack. Between my work with the Technical Architecture Group, the Exploration Interest Group, the Federated Identity Working Group, and the associated Community Group, I moved between conversations about the Web’s architecture, emerging standards, and the practical challenges of getting specifications finished.

One discussion that really stayed with me concerned the Digital Credentials API, or DC API, and its progress toward becoming a W3C Recommendation.

The working group made meaningful progress. We agreed on a way to narrow the initial specification and developed a clearer understanding of its architectural boundaries.

However, some difficult privacy questions remain. They illustrate a challenge that extends well beyond digital credentials: when multiple technologies work together, how do we make sure the user is adequately protected?

But first, let’s start with the good news.

---

Making Progress by Organizing the DC API Into Levels

At TPAC, the Federated Identity Working Group agreed to organize the DC API into levels, following the approach used by a protocol called WebAuthn.

The idea is straightforward. Essentially, this is a form of versioning that avoids requiring every requested feature to be resolved before publishing the standard.

We identified the functionality needed for an initial interoperable version. That becomes Level 1.

Other capabilities can move into Level 2, Level 3, or Level 4 as the specification evolves.

The most significant decision was to move much of credential issuance into Level 2.

The DC API supports two broad activities:

• Presenting a credential to a website.
• Receiving a new credential into a wallet or credential manager.

Both are important, but they are at different stages of implementation maturity. In particular, there is no committed timeline for a second browser implementation of credential issuance.

Keeping issuance in Level 1 would make advancing the specification considerably harder.

Other features, including conditional invocation and more general ways of providing invocation context, will also move to Level 2.

That doesn’t mean we’re abandoning those capabilities. Instead, we’re recognizing that a useful, interoperable first version doesn’t have to solve every problem the ecosystem might eventually encounter.

There’s still work to do before Candidate Recommendation, of course. However, we now have a more manageable path forward.

---

Understanding the Architectural Boundaries

The second important discussion concerned architectural boundaries.

I’ve written before about the tendency to hold the DC API responsible for problems elsewhere in the digital credential ecosystem. It kind of drives me crazy, although I understand why it happens.

The API is the effective control point where websites interact with digital credentials through the browser. When something about that experience seems problematic, it’s natural to ask the API to fix it.

However, a digital credential transaction involves considerably more than a browser passing a request to a wallet or credential manager.

Consider the different components involved:

• The website initiates the request.
• The browser mediates the interaction.
• The operating system may help connect the browser to a wallet.
• The wallet or credential manager processes the request using an underlying credential protocol.

Each component has different information and different capabilities.

At TPAC, the working group agreed to use the architectural model described at digitalcredentials.dev to help clarify those responsibilities.

That’s useful progress because it gives us a common framework for deciding whether a particular requirement belongs in the browser API, the underlying protocols, or another part of the ecosystem.

But there’s a complication.

Identifying where a responsibility belongs doesn’t necessarily guarantee that someone will actually fulfill it.

---

When No Single Component Has the Complete Picture

Let’s walk through an example.

Imagine you’re visiting a website that asks you to prove you’re over 18. This is a fairly common use case these days, and you have a digital credential in your wallet that can provide that information.

The browser knows which website is making the request and can enforce rules about how the API is invoked.

However, depending on the credential format and protocol, the browser may not know exactly what information the wallet will disclose.

The wallet may understand the contents of the credential, including whether the request involves a simple assertion that you’re over 18 or your full date of birth. However, it may lack some of the context the browser has about the requesting website.

Neither component necessarily has the complete picture.

Now, suppose the browser assumes that the wallet will explain what’s being shared and obtain the appropriate consent.

That may be a perfectly reasonable division of responsibilities, provided the wallet actually does it.

But what if the wallet presents a confusing consent interface? What if it doesn’t enforce the protections the browser assumes are present? Or what if the protocol doesn’t convey enough information for the wallet to make an informed decision?

The browser may have fulfilled every requirement in its specification, yet the user could still disclose information they never intended to share.

This is why simply declaring something out of scope can be unsatisfying when discussing privacy and security.

Sometimes a problem genuinely belongs elsewhere. However, declaring that the API isn’t responsible doesn’t make the risk disappear.

---

The Problem With Too Many Consent Prompts

Let’s consider the opposite approach.

Suppose every component decides it can’t rely on the others to protect the user. The browser asks whether you want to proceed. The operating system asks whether you want to allow access to your wallet. The wallet asks you to select a credential and then confirm which information you want to disclose.

Each interaction might have a perfectly defensible rationale.

But remember, all you wanted to do was prove you were 18.

How many times should you have to confirm that you’re trying to do the thing you originally set out to do?

We’ve already seen what happens when people encounter too many permission prompts and privacy notices.

Research presented at CHI 2024 examined user behavior across more than 100 million Chrome installations and found that ignoring or dismissing certain browser permission prompts was common.

Other research into privacy fatigue has explored how repeated consent requests influence people’s decisions about tracking and information sharing.

That doesn’t mean every additional prompt makes consent worse. Context, presentation, and the nature of the decision all matter.

However, repeatedly asking people for permission can turn a meaningful privacy decision into just another obstacle between them and whatever they were trying to accomplish.

Eventually, users may stop evaluating what they’re being asked and start looking for the button that makes the interruption go away.

We could end up creating more consent interfaces while making consent itself far less meaningful.

That’s quite a problem for an ecosystem that places so much emphasis on user control.

---

Finding the Right Balance Between Responsibilities

I don’t think there’s a simple answer here.

It’s reasonable for the DC API to avoid defining the internal behavior of every wallet or credential manager and credential protocol. Doing otherwise would make the specification considerably more complex and could potentially undermine the protocol design that makes it useful.

At the same time, the API shouldn’t assume that protections exist elsewhere without understanding the consequences if those assumptions are wrong.

One approach is to distinguish between the protections a component can enforce directly and the guarantees it depends on other components to provide.

For example:

• Where the browser can enforce a protection, the specifications should say so clearly.
• Where protection depends on wallet or protocol behavior, those dependencies should be made explicit and ideally supported by testable requirements in the relevant standards.
• Where the DC API cannot adequately address a risk, the specification should acknowledge that limitation and identify where coordination is needed across the ecosystem.

This also raises another question worth exploring.

Can we coordinate consent and user interaction across these different layers so that people receive the information they need when they need it, without facing a separate permission dialogue from every component?

That’s a bigger question than any one specification, but it’s central to making the overall system work.

---

Privacy Questions Still Blocking Progress

At TPAC, we confirmed that privacy remains one of the most significant obstacles to advancing the DC API to Candidate Recommendation.

Several outstanding issues involve protections that depend, at least partly, on behavior outside the browser.

Selective disclosure is one example.

Many credential systems allow users to share only the information necessary for a transaction. You might prove you’re over 18 without disclosing your full date of birth.

That’s an important privacy property.

However, the browser may not understand which attributes a credential contains or what information will ultimately be disclosed.

So, what can the DC API realistically guarantee about selective disclosure? What must it rely on the wallet and credential protocol to provide?

I don’t know.

Similar questions arise around:

• User-initiated credential presentation.
• Purpose limitation.
• Abusive credential requests.

These aren’t minor editorial details. They involve decisions about what protections the browser can provide, what assumptions it makes about other components, and what risks remain for the user.

The working group plans to bring the editors and privacy experts together for focused discussions of these issues. I expect those conversations to be challenging.

Privacy requirements have a way of exposing architectural assumptions that are easy to overlook when everyone is concentrating on making functionality work.

At the same time, those requirements can sometimes demand things that aren’t technically possible.

Either way, they’re essential if the API is going to provide a trustworthy foundation for digital credentials on the Web.

---

What Happens Next for the DC API?

The DC API is in a better position after TPAC than it was before.

Organizing the specification into levels gives us a practical approach to delivering an interoperable first version.

The agreement on architectural layering also gives us a clearer way to identify responsibilities across the ecosystem.

Now we need to:

• Translate the agreed requirements into specification changes.
• Complete the Level 1 issue triage.
• Work through the outstanding privacy questions.

I suspect some of the most interesting discussions will continue to happen at the boundaries between all these different technologies.

There is a temptation in standards development to believe that defining an architectural boundary means the responsibilities on either side have been adequately addressed.

Sometimes they have.

And sometimes that boundary is exactly where important assumptions become invisible.

For digital credentials, the user doesn’t experience a browser API, an operating system interface, a wallet or credential manager, and a presentation protocol as separate architectural components.

They experience a website asking them to share information about themselves.

That experience needs to be understandable, trustworthy, and reasonably straightforward, regardless of how many technologies and standards are involved behind the scenes.

Figuring out how to deliver that experience without neglecting essential protections or burying users under permission requests remains one of the more interesting challenges ahead.

And yes, we’re still talking about it.

---

Final Thoughts

That’s all for this week. As always, you’ll find links to the specifications, research, and other resources I’ve mentioned in the written version of this post.

Thank you for listening.

And that’s it for this week’s episode. If it helps make things a little clearer, or at least a little more interesting, share it with a friend or colleague and connect with me on LinkedIn at @hlflanagan.

If you enjoyed the show, be sure to subscribe and leave me a rating and review on Apple Podcasts or wherever you listen to podcasts.

You can also find the full written post at sphericalcowconsulting.com.

Stay curious, stay engaged, and let’s get these conversations going.