#1119: Digital Credentials API

Visit on Github.

Opened Jul 11, 2025

こんにちは TAG-さん!

The Federated Identity on the Web WG is requesting a TAG review of the Digital Credentials API.

This document specifies an API to enable user agents to mediate presentation and issuance of digital credentials such as a driver's license, government-issued identification card, and/or other types of digital credential . The API builds on Credential Management Level 1 as a means by which to request or issue a digital credential from a user agent or underlying platform.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Previous early design review, if any: N/A
  • Relevant time constraints or deadlines: Apple has announced the API will ship in iOS 26 in September and Chrome is aiming to ship in version 140 in September, but both implementers have indicated flexibility in evolving with the specification where possible.

The FedID WG is tracking this horizontal review https://github.com/w3c-fedid/digital-credentials/issues/230

Thank you!

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1119

Discussions

Log in to see TAG-private discussions.

Discussed Jul 21, 2025 (See Github)

Matthew: Can we bump this to next week?

Lola: Yes.

Discussed Jul 28, 2025 (See Github)

Lola: Looked at that this week...

Martin: My view is unsatisfied, simply because there is no spec. There might be other reasons for that, but I can't tell.

Marcos: Coincidentally, I have the spec text now on a branch. That fills in most of the blanks. There is no consensus yet on some of these parts, so these haven't landed in the spec yet.

(Marcos walks through things for https://github.com/w3c-fedid/digital-credentials/pull/306) That shows a picture of the architecture and the new "coordinator" role within the user agent, which manages access to the wallet. Then there is the whole formats side of the protocol. These are somewhat out of scope for the API; these dictate how you interact with different credential formats (mDoc, openID, whatever). The reason that isn't there is that we are working through the details and the algorithms and trying to reconcile that with implementations. Lots of reasons for not being satisfied.

Lola: We should hold off until everything is added. Also, the explainer is not an explainer: that links to the intro section, but the explainer doesn't cover some of things.

Marcos: Alternatives were custom URLs, which is in another document.

Lola: It's not clear. The explainer is not in our design-review issue.

Marcos: https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md should cover most of the explainer topics. ... we've been moving stuff from the explainer to the spec as the spec is filled out. So that things don't get out of date.

Lola: Should we wait?

Martin: I'm still concerned about the formats question, which is far from being resolved.

Matthew: Can wait.

Ehsan: I have an issue related to the no papers document with respect to how the API operates.

Marcos: It would be good to have something about formats to take to the working group. Even if the API shape is there, the formats would be good to take there. There is also privacy/security and the working group put in a lot of work recently on that. Would be good to see if there are things missing and set expectations.

Comment by @lolaodelola Jul 31, 2025 (See Github)

Explainer: https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md

Comment by @wseltzer Aug 11, 2025 (See Github)

The Working Group chose not to include the explainer @lolaodelola linked above because it is outdated (it reflects an early proposal, before WG adoption). We're discussing retiring the explainer and keeping updates in the non-normative introduction to the spec itself.

Comment by @marcoscaceres Aug 14, 2025 (See Github)

Apologies, TAG! The working group is currently blocked getting consensus on this PR: https://github.com/w3c-fedid/digital-credentials/pull/306

Which, once it lands, will allow us to actually add the algorithms. The algorithm are more or less written (I have them locally), but we can't send them as they depend on the Coordinator and Client model.

I expect to land that in the next few days... just waiting on confirmation that other implementers do the same thing. It should be easily demonstrable with a couple of tests.