LGTM1 to deprecate and remove On Tuesday, June 16, 2026 at 2:31:17 AM UTC+2 Rick Byers wrote:
> 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 <[email protected]> > 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 [email protected] wrote: >> >>> *> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>> >>> *> Yes> Covered >>> by https://wpt.fyi/results/digital-credentials/get.https.html >>> <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 >>> <https://wpt.fyi/results/digital-credentials/get.https.html?label=master&product=chrome%5Bexperimental%5D&product=chrome%5Bstable%5D&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned> >>> >>> 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 <https://github.com/web-platform-tests/wpt/pull/60542> > complicating things (I was also confused). If you remove Firefox (which I > guess hasn't run in a while) to get current test results > <https://wpt.fyi/results/digital-credentials/get.https.html?label=master&product=chrome%5Bexperimental%5D&product=chrome%5Bstable%5D&product=safari%5Bexperimental%5D&aligned> > you > see that Chrome Experimental (which has DigitalCredentialsProtocolFilter > enabled > <https://chromium-review.git.corp.google.com/c/chromium/src/+/7905644>) > 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 > <[email protected]> do you know? > > >> -- Dan >>> >>> On Wednesday, June 10, 2026 at 1:56:24 PM UTC-7 Chromestatus wrote: >>> >>>> *Contact emails* >>>> [email protected], [email protected] >>> >>> >>>> >>>> *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 >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EIdentity%3EDigitalCredentials%22> >>>> >>>> *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 >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>> 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 >>>> <https://chromestatus.com>. >>>> >>> -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/06b1b964-ccca-493b-987f-df64616557e5n%40chromium.org.
