What is the W3C WICG Digital Credentials API?

About a year ago, a new work item was formed under the W3C’s Web Incubator Community Group (the WICG). This work item, now called the Digital Credential API, looks at how a browser should behave when it comes to identity wallets and the credentials they hold. The scope for the work is described in GitHub. 

Why am I writing about it now? Because the W3C is thinking about whether the new working group I’m co-chairing in the W3C with Wendy Seltzer, the Federated Identity Working Group, should be the standardization home for this project. This is definitely a niche post, but IYKYK!

Background

Initially, conversations about browsers, wallets, and how individuals are expected to select their credential of choice started in a FIDO Alliance board task force. Given the number of overlapping participants, members of the Federated Identity Community Group (FedID CG) took up the question as to whether that work should be in scope for the CG. The FedID CG, however, came to the conclusion that they were focused on determining how a different identity architecture, one that covers more traditional federation models via OpenID Connect and SAML, should handle the deprecation of third-party cookies. So, while there was alignment on the problem of “how is an individual supposed to actively select their identity,” the fact that the deprecation of third-party cookies mattered to the federation architecture but not to the wallet architecture suggested a separate incubation effort was necessary. If you don’t have alignment on what problem you’re trying to solve, you’re probably not going to solve the problem.

A Different Set of Stakeholders

That wasn’t necessarily a bad thing, that rejection from the FedID CG. The work item there is relatively simple when compared to what needs to come into play for an entirely new identity architecture. There are fewer stakeholders involved in a ‘traditional’ federation architecture. When considering wallet interactions, the number of interested parties goes well beyond a SAML or OIDC federation’s Identity Providers and Relying Parties and the browser.

With a digital identity wallet, we see requirements coming in from operating system developers, browser developers, and privacy advocates, as well as wallet and credential issuers and verifiers. This diversity of needs results in some confusion as to what problem the group is trying to solve. There are several layers to making a digital wallet function in a secure, privacy-preserving fashion; the group is not, however, specifying for all layers.

The WICG’s Digital Credentials work may be a good fit for a more structured working group format than it was for a community group focused on incubation; that’s part of what has inspired this post.

Protocol Layers

The WICG Digital Credentials work item did not start with a single problem statement the way the FedID CG did. Instead, their mission is described in their charter “to specify an API for user agents that would mediate access to, and representation of, verifiably-issued digital identities.”

To understand the totality of the effort to bring digital wallets and credentials to the web, which is a broader scope than that of the Digital Credentials work item, you need to understand the many layers involved in enabling an identity transaction on the web and/or across apps. 

Our Layers

• Standardized API (W3C) = Digital Credentials Web Platform API (this is us)
• Standardized API (Other) = currently FIDO CTAP 2.2 (hybrid transport; a phishing-resistant, cross-device link is already in place for passkeys/WebAuthn)
• Platform-specific web translation API = platform abstraction of web platform APIs for verifiers*
• Platform-specific function API = independent platform native API*
• Protocol-specific = Protocol or deployment-specific request/response

Digital Credentials Web Platform API

The output of the WICG Digital Credentials work item is the Digital Credentials API from that first layer in the stack. In incubating that API, the specification editors are relying on the existence and behavior of other APIs either already in place or being developed by their respective platforms. Having the developers of those other APIs involved to make sure that the end-to-end flow of wallet and credential selection works as anticipated by the Digital Credentials Web Platform API is critical. Requiring change to those other APIs is out of scope for the Digital Credentials work item (though we can ask nicely). 

An FAQ

• Should the browser see the details of the request for what’s in a wallet?
  • That’s not in scope for the W3C (though the question still comes up when people join the group).
• Should the OS see the details of what’s in a wallet?
  • That’s not in scope for the W3C, either, so while of interest to many, it’s not something this group can or should resolve. 
• Should the API be protocol agnostic when it comes to verifiable credentials?
  • Some say yes, some say no. The more protocols you have to support, the more expensive maintenance gets. So, while on the one hand, being protocol-agnostic supports the largest number of use cases, it’s also the most expensive thing to do. 
• What does protocol-agnostic look like in practice when different credentials format similar information differently?
  • That’s one of the things we talk about. 
• At what point(s) does the individual consent to the information being requested from a wallet? being requested to be added to a wallet?
  • We’re still talking about that, too.
• Is the use case under consideration primarily remote presentation or in-person presentation?
  • The scope is online presentation, so the work is focused on the remote use case. 
• Is the payload of requests in scope for this group? Or is the group only concerned with communication channels (leaving payload handling up to the platforms)?
  • Here’s another area of contention. Of course, the browser wants to prevent bad traffic. But this stuff is encrypted for a reason, and making everything (most things? some things?) viewable to the browser isn’t necessarily the right answer either from a privacy and security perspective. 
• Is the question of what signal must exist (and who provides that signal) for a wallet to be trusted by the browser in scope for the group? If not, where can those discussions be directed?
  • This is not in scope as the web platform does not directly communicate with the wallet in this architecture.

Wrap Up

So what happens now? Conversations are happening at the OAuth Security Workshop, within the W3C Advisory Committee, and soon at the Internet Identity Workshop. After those wrap up, the FedID WG will start meeting and decide whether this work belongs in scope or not. If you’re interested in participating, there is a GitHub issue open where we are collecting input on the topic. You are welcome to chime in there, or just grab some popcorn and watch the story unfold!

I love to receive comments and suggestions on how to improve my posts! Feel free to comment here, on social media, or whatever platform you’re using to read my posts! And if you have questions, go check out Heatherbot and chat with AI-me