Intent to Ship: Digital Credentials API I (presentation support)

Chromestatus

unread,

Aug 11, 2025, 2:26:35 PM Aug 11

to blin...@chromium.org, ashim...@google.com, go...@chromium.org, ma...@chromium.org, rby...@chromium.org

Summary

Websites can and do get credentials from mobile wallet apps through a variety of mechanisms today (custom URL handlers, QR code scanning, etc.). This Web Platform feature would allow sites to request identity information from wallets via Android's IdentityCredential CredMan system. It is extensible to support multiple credential formats (eg. ISO mDoc and W3C verifiable credential) and allows multiple wallet apps to be used. Mechanisms are being added to help reduce the risk of ecosystem-scale abuse of real-world identity (see https://docs.google.com/document/u/1/d/1L68tmNXCQXucsCV8eS8CBd_F9FZ6TNwKNOaFkA8RfwI/edit ).

Blink component

Blink>Identity>DigitalCredentials

TAG review

Mozilla feedback from Martin (also on the TAG) suggests we need to invest more in the threat model for the larger space and clarify specific privacy mitigations before shipping or requesting TAG review.

TAG review status

Issues open

Origin Trial Name

Digital Credentials API

Chromium Trial Name

WebIdentityDigitalCredentials

Origin Trial documentation link

https://wicg.github.io/digital-credentials

WebFeature UseCounter name

kIdentityDigitalCredentials

Risks

Interoperability and Compatibility

There are multiple standards efforts involved here. We have been working with WebKit and Mozilla in the WICG on defining this specific API. But the greater interoperability risk will come from the data that is sent and returned via this API. Details of that are still in discussions but mostly driven outside the web browser community in the OpenID Foundation (eg. OpenID4VP: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html ) and ISO (18013-7 "mdoc": https://www.iso.org/standard/82772.html )

Gecko : Negative ( https://github.com/mozilla/standards-positions/issues/1003 ) We share most of Mozilla's concerns and continue to work with them (and the broader community) on mitigations. I believe we feel greater risk for the established practice of custom schemes becoming prevalent than Mozilla does (eg. due to Google being mandated by eIDAS regulation to accept EUDI credentials).

WebKit : In development ( https://github.com/WebKit/standards-positions/issues/332 ) WebKit implementation progress: https://bugs.webkit.org/show_bug.cgi?id=268516

Web developers : No signals

Other signals : This work in the W3C PING is relevant: https://github.com/w3cping/credential-considerations/

Ergonomics

There's a possibility that these credentials will be used alongside other types of credentials in the future - such as optionally minting a passkey when a digital credential is used to sign up for a site, or by allowing sign-up with either a digital credential or a federated credential via FedCM. As such we argued it was best to put this work in the context of the Credential Management API, and hence the support is added in 'navigator.identity.get() API .

Activation

The primary activation concern is enabling existing deployments using technology like OpenID4VP to be able to also support this API. As such we have left the request protocol unspecified at this layer, to be specified along with existing request protocols to maximize activation opportunity.

Security

See https://github.com/WICG/digital-credentials/blob/main/horizontal-reviews/security-privacy.md and https://github.com/w3c-fedid/digital-credentials/issues/115

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

This feature does not deprecate or change the behavior of existing APIs. This feature adds a new feature via extending the existing navigator.credentials.get() with a new type.

Debuggability

None necessary - just new JS API. For testing we may want to add a developer option to provide a fake wallet (as for the devtools fake authenticator for WebAuthn), but this is not urgent.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Android and Desktop Only

Is this feature fully tested by web-platform-tests ?

Yes

https://wpt.fyi/results/digital-credentials?label=master&label=experimental&aligned

DevTrial instructions

https://digitalcredentials.dev/docs/requirements

Flag name on about://flags

web-identity-digital-credentials

Finch feature name

WebIdentityDigitalCredentials

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

True

Tracking bug

https://issues.chromium.org/issues/40257092

Launch bug

https://launch.corp.google.com/launch/4268575

Availability expectation

- Feature is in Chromium browsers for the foreseeable future. - Feature is available in Webkit (Safari) starting version 26

Adoption expectation

Feature is used by specific partner(s) to provide functionality within 12 months of launch in Chrome.

Adoption plan

- Many partnership are being driven by the Android and the Google Wallet teams. - Regulations in the EU may recommend incorporating the API in Digital Wallets in the EU and hence there is a very chance that website will start adopting this API.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

This API passes the request from the verifier website to the underlying operating system. Therefore on Android, it replies on the Credential Manager API. This is widely deployed via GMSCore though.

Sample links

https://digitalcredentials.dev/docs/requirements

Estimated milestones

Shipping on desktop	141
Origin trial desktop first	134
Origin trial desktop last	140
Origin trial extension 1 end milestone	140
Origin trial extension 2 end milestone	139
Origin trial extension 3 end milestone	136
DevTrial on desktop	133
Shipping on Android	141
Origin trial Android first	128
Origin trial Android last	140
DevTrial on Android	119

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5166035265650688?gate=5070577134469120

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL9PXLx3sHWmdE-ikAEDay_S3ijf0%2BfxB_LbsuOx8YJx%2BZA7%2Bg%40mail.gmail.com
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-421uDmu2WNDBG5bYRSWAhfmahsHPVjDwN5NLkUdCkvw%40mail.gmail.com
Intent to Extend Experiment 1: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6876938b.2b0a0220.377b9f.0109.GAE%40google.com
Intent to Extend Experiment 2: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67f3fe84.170a0220.25676e.143e.GAE%40google.com
Intent to Extend Experiment 3: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6786814c.2b0a0220.1b83ac.051d.GAE%40google.com

This intent message was generated by Chrome Platform Status .

Rick Byers

unread,

Aug 11, 2025, 5:32:19 PM Aug 11

to Chromestatus, blin...@chromium.org, ashim...@google.com, go...@chromium.org, ma...@chromium.org

[API owner hat off since I work on this API]

On Mon, Aug 11, 2025 at 2:26 PM Chromestatus < ad...@cr-status.appspotmail.com > wrote:

Contact emails
rby...@chromium.org , go...@chromium.org , ma...@chromium.org , ashim...@google.com

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

Specification
https://w3c-fedid.github.io/digital-credentials

Summary

Websites can and do get credentials from mobile wallet apps through a variety of mechanisms today (custom URL handlers, QR code scanning, etc.). This Web Platform feature would allow sites to request identity information from wallets via Android's IdentityCredential CredMan system. It is extensible to support multiple credential formats (eg. ISO mDoc and W3C verifiable credential) and allows multiple wallet apps to be used. Mechanisms are being added to help reduce the risk of ecosystem-scale abuse of real-world identity (see https://docs.google.com/document/u/1/d/1L68tmNXCQXucsCV8eS8CBd_F9FZ6TNwKNOaFkA8RfwI/edit ).

Blink component
Blink>Identity>DigitalCredentials

TAG review
Mozilla feedback from Martin (also on the TAG) suggests we need to invest more in the threat model for the larger space and clarify specific privacy mitigations before shipping or requesting TAG review.

Sorry, I forgot to update this (now fixed). The FedID WG filed for TAG review a month ago now but no comment yet.

Related, TAG has published Preventing Abuse of Digital Credentials which is related (and covers many of the issues I listed when we decided to start going down this path), but doesn't explicitly weigh in on whether and how the Digital Credentials API makes these problems better or worse.

FWIW I personally think the time has come to ship out of OT and continue iterating on this as a launched API. Most of the important debate at this stage is about things we're going to have to keep iterating on like how the browser UI and presentation metadata should best promote privacy and transparency and control for the user (not the API shape). I anticipate much iterating on this in Chrome over the coming years as government identity systems are adopted more widely. For now the risks are relatively low because so few people have these credentials installed in a wallet that supports using the API.

See also this discussion from our last OT extension.

TAG review status
Issues open

Origin Trial Name
Digital Credentials API

Chromium Trial Name
WebIdentityDigitalCredentials

Origin Trial documentation link
https://wicg.github.io/digital-credentials

WebFeature UseCounter name
kIdentityDigitalCredentials

Risks

Interoperability and Compatibility

There are multiple standards efforts involved here. We have been working with WebKit and Mozilla in the WICG on defining this specific API. But the greater interoperability risk will come from the data that is sent and returned via this API. Details of that are still in discussions but mostly driven outside the web browser community in the OpenID Foundation (eg. OpenID4VP: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html ) and ISO (18013-7 "mdoc": https://www.iso.org/standard/82772.html )

Gecko : Negative ( https://github.com/mozilla/standards-positions/issues/1003 ) We share most of Mozilla's concerns and continue to work with them (and the broader community) on mitigations. I believe we feel greater risk for the established practice of custom schemes becoming prevalent than Mozilla does (eg. due to Google being mandated by eIDAS regulation to accept EUDI credentials).

WebKit : In development ( https://github.com/WebKit/standards-positions/issues/332 ) WebKit implementation progress: https://bugs.webkit.org/show_bug.cgi?id=268516

Apple has now announced shipping in iOS 26 (September). Though it's worth noting that Apple's initial implementation is only partially interoperable with Chrome in that it supports only the ISO 18013-7 Annex C protocol while Chromium is largely protocol agnostic.

Dan Clark

unread,

Aug 13, 2025, 12:59:48 PM Aug 13

to blink-dev, rby...@chromium.org, blin...@chromium.org, ashim...@google.com, Sam Goto, ma...@chromium.org, Chromestatus

The parenthetical in the Intent title "(presentation support)" seems to imply that this intent covers only part of Digital Credentials API, and maybe more of it will ship at another time. Is that right, or am I reading too much into it?

Per the comment here the explainer at https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md is outdated and reflects an earlier proposal. So should we be disregarding that explainer and just looking at the introductory sections of the spec instead, or is there a list somewhere of what's changed?

Thanks,

Dan

Mohamed Amir Yosef

unread,

Aug 14, 2025, 4:29:18 PM Aug 14

to blink-dev, dan...@microsoft.com, Rick Byers, blin...@chromium.org, ashim...@google.com, Sam Goto, Mohamed Amir Yosef, Chromestatus

Thanks a lot Dan for your questions!
Replies are inline

On Wednesday, August 13, 2025 at 7:59:48 PM UTC+3 dan...@microsoft.com wrote:

The parenthetical in the Intent title "(presentation support)" seems to imply that this intent covers only part of Digital Credentials API, and maybe more of it will ship at another time. Is that right, or am I reading too much into it?

Yes, this Intent is for digital credentials presentation via navigator.credentials.get() API

digital credentials issuance via navigator.credentials.create() API will come separately at a later point of time.

Per the comment here the explainer at https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md is outdated and reflects an earlier proposal. So should we be disregarding that explainer and just looking at the introductory sections of the spec instead, or is there a list somewhere of what's changed?

Thank you for spotting that!

Yes please, disregard the explainer. The the introductory sections of the spec should be sufficient and up-to-date!

Alex Russell

unread,

Aug 18, 2025, 2:16:38 PM Aug 18

to blink-dev, Mohamed Amir Yosef, dan...@microsoft.com, Rick Byers, blin...@chromium.org, ashim...@google.com, Sam Goto, Chromestatus

Hey Mohamed,

We generally expect explainers to be updated throughout the life of a feature. LGTM1, conditional on the explainer being updated with up-to-date example code for both the problem and proposed solution.

Best,

Alex

Jeffrey Yasskin

unread,

Aug 20, 2025, 11:21:01 AM Aug 20

to Rick Byers, Chromestatus, blin...@chromium.org, ashim...@google.com, go...@chromium.org, ma...@chromium.org

I see that "Mechanisms are being added to help reduce the risk of ecosystem-scale abuse of real-world identity (see https://docs.google.com/document/u/1/d/1L68tmNXCQXucsCV8eS8CBd_F9FZ6TNwKNOaFkA8RfwI/edit) ." Are those mitigations implemented in the version you're planning to ship? If not, what's the timeline for implementing those, and how do you expect to prevent abuse until then?

Thanks,

Jeffrey

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org .
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-8oB2_WO5RFF0gkG-sOcz_DsvuR6L0QJ_yREGg2bN2MQ%40mail.gmail.com .

Jeffrey Yasskin

unread,

Aug 20, 2025, 8:24:48 PM Aug 20

to Alex Russell, blink-dev, Mohamed Amir Yosef, dan...@microsoft.com, Rick Byers, ashim...@google.com, Sam Goto, Chromestatus

On Mon, Aug 18, 2025 at 11:16 AM Alex Russell < sligh...@chromium.org > wrote:

Hey Mohamed,

We generally expect explainers to be updated throughout the life of a feature. LGTM1, conditional on the explainer being updated with up-to-date example code for both the problem and proposed solution.

Also, FWIW, the TAG has loosened this expectation a bit. Obviously that doesn't require the Blink API owners to loosen it in the same way, but https://www.w3.org/TR/explainer-explainer/#introduction now says :

"You can move or copy sections of your explainer directly into your specification.... Make sure that the explainer remains useful and accurate over time. If you move sections out of it, replace them with links to the relevant part of the spec. If you keep redundant text in the explainer, remember to update it as the specification changes."

I think the explainer is missing example code for the problem (and/or screenshots if the custom-scheme practice involves user interaction?), but https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md#what links to https://w3c-fedid.github.io/digital-credentials/#example-requesting-a-digital-credential , which I think covers the example code for the solution.

Jeffrey

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org .

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7b83a6c1-53ae-4dd4-8eb4-549daf8126a1n%40chromium.org .

Dan Clark

unread,

Aug 25, 2025, 2:13:54 PM (14 days ago) Aug 25

to blink-dev, jyas...@chromium.org, blink-dev, ma...@chromium.org, Dan Clark, rby...@chromium.org, ashim...@google.com, Sam Goto, Chromestatus, sligh...@chromium.org

LGTM2

Alex Russell

unread,

Aug 25, 2025, 2:15:41 PM (14 days ago) Aug 25

to blink-dev, Jeffrey Yasskin, blink-dev, Mohamed Amir Yosef, dan...@microsoft.com, Rick Byers, ashim...@google.com, Sam Goto, Chromestatus, Alex Russell

It's good practice for explainers to remain up-to-date for a lot of reasons, not least of which is that they are the easiest way "in" to a feature for developers until full documentaiton is available (and sometimes well after). It's concerning the TAG has changed its advice, but I don't believe we have, but I would argue that we should not.

Best,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org .

Mohamed Amir Yosef

unread,

Aug 26, 2025, 3:02:10 PM (13 days ago) Aug 26

to Alex Russell, blink-dev, Jeffrey Yasskin, dan...@microsoft.com, Rick Byers, ashim...@google.com, Sam Goto, Chromestatus

I am very sorry for the late reply here!

@Alex Russell the explainer should be up-to-date now in the sense the it links to the spec for the relevant section, do you think this is good enough or you would require the examples to be duplicated in the explainer as well?

@Jeffrey Yasskin ""Mechanisms are being added to help reduce the risk of ecosystem-scale abuse of real-world identity", in the version we are shipping, Chrome displays an interstitial similar to https://photos.app.goo.gl/7wSmXoWVZ5mBtQbr5 for any request asking for PII. For requests that don't ask for PII (e.g. Age over 18 proof), Chrome doesn't show any interstitial. Those are the mechanisms we are shipping to help reduce the risk or abuse.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org .

Yoav Weiss (@Shopify)

unread,

Aug 27, 2025, 9:11:52 AM (12 days ago) Aug 27

to blink-dev, Mohamed Amir Yosef, blink-dev, Jeffrey Yasskin, dan...@microsoft.com, Rick Byers, ashim...@google.com, Sam Goto, Chromestatus, Alex Russell

LGTM3

FWIW, I found the explainer to be light on details. I'm fine with it just pointing to example sections in the spec, but I think it'd be good to beef up these sections and explain what parts are handled by this API, what parts are delegated to the Credential Management API, what information is exposed to servers and what UI can we expect be shown to users.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org .

Reply all

Reply to author

Forward