Intent to Ship: Deprecate and Remove Digital Credential API support for unspecified exchange protocols

[Chromestatus]

Contact emails

rby...@chromium.org, ma...@chromium.org

Explainer

https://github.com/w3c-fedid/digital-credentials/issues/396

Specification

https://w3c-fedid.github.io/digital-credentials/#protocols

Summary

The Digital Credentials API was originally designed to be an opaque pipeline for arbitrary exchange protocols. In November the FedID WG resolved to change this (https://github.com/w3c-fedid/digital-credentials/issues/396) so that the spec normatively referenced only a specific set of exchange protocols. This feature tracks changing Chromium's implementation of the DC API to match such that requests for unspecified presentation and issuance protocols will fail vs. being passed through to Android.

Blink component

Blink>Identity>DigitalCredentials

Web Feature ID

No information provided

Motivation

To align with a change to the spec which enables more credible privacy and security analysis of the API.

Initial public proposal

No information provided

TAG review

No information provided

TAG review status

Not applicable

Goals for experimentation

None

Risks

Interoperability and Compatibility

A UseCounter was added for unknown protocols in the DC API, it has fallen to essentially zero starting in April 2026: https://chromestatus.com/metrics/feature/timeline/popularity/5770 Looking at more detailed internal metrics, the exact value is not exactly zero and amounts to about 3% of all DC API calls (itself very rare). We believe this represents some limited testing by developers considering migrating from custom schemes to the DC API, no real deployments. But in order to avoid negatively impacting those developers we want to hold actual removal until the start of 2027. In order to reduce the risk of surprises we want to add a deprecation warning / report now.

Gecko: No signal (https://mozilla.github.io/standards-positions/#digital-credentials) Mozilla is officially negative on the DC API itself. In the FedID WG meeting for restricting the API to specified protocols only, Mozilla representatives argued in favor of the change.

WebKit: Shipped/Shipping (https://webkit.org/blog/17431/online-identity-verification-with-the-digital-credentials-api) Supports only the org-iso-mdoc protocol already

Web developers: No signals

Other signals:

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?

No information provided

Debuggability

No information provided

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

Yes

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

Yes
Covered by https://wpt.fyi/results/digital-credentials/get.https.html

Flag name on about://flags

#enable-experimental-web-platform-features

Finch feature name

DigitalCredentialsProtocolFilter

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://crbug.com/465006289

Estimated milestones

Shipping on desktop	160
DevTrial on desktop	151
Shipping on Android	160
DevTrial on Android	151
Shipping on WebView	160

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).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6492906882990080?gate=5229137305403392

This intent message was generated by Chrome Platform Status.

[Dan Clark]

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

> Yes
> Covered by https://wpt.fyi/results/digital-credentials/get.https.html

Do any of these tests cover the specific thing that's being changed here? It looks like the current results for Chrome already match Safari, except for the "navigator.credentials.get() API rejects if there are no credential request for same-origin iframe" testcase which doesn't sound related.

-- Dan

[Alex Russell]

Hey Mohamed,

Can you maybe outline the motivation for this deprecation, other than low use? Would be useful in terms of judging the risk.

Best,

Alex

[Rick Byers]

Sorry this was me that wrote this, not Mohamed (though we're both owners).  Inline.

On Mon, Jun 15, 2026 at 2:40 PM Alex Russell <sligh...@chromium.org> wrote:

Hey Mohamed,

Can you maybe outline the motivation for this deprecation, other than low use? Would be useful in terms of judging the risk.

Huh weird - I swear I put something in the motivation section in chromestatus but it's not there now. Thanks for catching that. I just added this:

When arbitrary protocols were supported in the spec it made security and privacy analyses less precise since there was more ambiguity about how the API could be used in practice. In order to get more broad browser industry alignment on the privacy and security properties of the API, the specification was changed to normatively reference specific exchange protocols (which themselves have privacy and security threat models associated with them).

Chromium is updating to reflect this specification change because of the reduction in potential for confusion and compatibility issues by matching other browser engines, and because (contrary to original expectations) this extra flexibility was not actually being used by anyone in production.

 

Best,

Alex

On Monday, June 15, 2026 at 9:34:28 AM UTC-7 dan...@microsoft.com wrote:

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

> Yes
> Covered by https://wpt.fyi/results/digital-credentials/get.https.html

Do any of these tests cover the specific thing that's being changed here? It looks like the current results for Chrome already match Safari, except for the "navigator.credentials.get() API rejects if there are no credential request for same-origin iframe" testcase which doesn't sound related.

Yes it's the last 4 subtests that cover this together with a few additional details. Unfortunately there was a bug in the test which was fixed a few days ago complicating things (I was also confused). If you remove Firefox (which I guess hasn't run in a while) to get current test results you see that Chrome Experimental (which has DigitalCredentialsProtocolFilter enabled) now passes all 4 of the last subtests while stable fails three of them. I'm not sure why Safari is still failing those three, @Mohamed Amir Yosef do you know?

[Alex Russell]

Thanks, Rick.

LGTM1

[Yoav Weiss (@Shopify)]

LGTM1 to deprecate and remove

[Daniel Bratell]

LGTM3 (there were two LGTM1).

I think it would be fine to remove quicker but this is fine.

/Daniel

--
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/06b1b964-ccca-493b-987f-df64616557e5n%40chromium.org.