[API owner hat off since I'm personally working on this API] Yeah Alex we had the same debate on the team. We feel ready to ship but we understand there's a lot of concern around this API and that the spec is far from finished in terms of convincingly mitigating the privacy risks of this powerful feature. We are completely ready to ship in M140 if API owners felt that was best, but also the TAG review was just filed by the WG and it seems reasonable to me to give at least a few weeks for debate and discussion on the TAG review before asking API owners to make a call on the risk / benefit tradeoff to shipping at this time. Adoption of this API is going to be slow mainly because adoption by users of these forms of digital credentials is slow, but at the same time there is real urgency around directing adoption here vs. competing approaches like the use of custom schemes.
So all that said, personally I think aiming for M141 is a good balance, but if we happen to get a good TAG review without a lot of debate in time for M140 then I'd be happy to launch early. Rick On Wed, Jul 16, 2025 at 11:31 AM Mohamed Amir Yosef <ma...@chromium.org> wrote: > Thanks Alex! > Could you please clarify what you mean with "pivot this intent to a > gapless I2S"? (sorry but I am a bit confused) > I am requesting the extension to cover up to and including Chrome 140, and > we are optimistic that we will be able to send the I2S for 141. > > Doesn't this qualify as a gapless I2S? > > > On Wed, Jul 16, 2025 at 5:26 PM Alex Russell <slightly...@chromium.org> > wrote: > >> Thanks for all of this. Any reason not to pivot this intent to a gapless >> I2S? >> >> On Tuesday, July 15, 2025 at 11:02:05 AM UTC-7 Jeffrey Yasskin wrote: >> >>> On Tue, Jul 15, 2025 at 10:44 AM Chromestatus < >>> ad...@cr-status.appspotmail.com> wrote: >>> >>>> Contact emails rby...@chromium.org, g...@chromium.org, >>>> ma...@chromium.org, ashimaar...@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 >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EIdentity%3EDigitalCredentials%22> >>>> >>>> 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. >>> >>> >>> FWIW, Wendy Seltzer did send a TAG review for this, at >>> https://github.com/w3ctag/design-reviews/issues/1119. >>> >>> TAG review status Pending >>>> >>>> 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? >>>> >>>> >>>> >>>> Goals for experimentation >>>> >>>> >>>> >>>> Reason this experiment is being extended >>>> >>>> We have made significant progress on the spec (specifically the privacy >>>> and security sections), and the First Public Working Draft has been >>>> published on the 1st of July 2025. We are currently waiting for the TAG >>>> review and hence would like to extend this OT for one more milestone. We >>>> are optimistic that by the end of this time we will have received a >>>> positive TAG review, which will unblock shipping the API. >>>> >>>> >>>> Reason this experiment is being extended >>>> >>>> - W3C team report on Digital Credentials formal objection is now >>>> published with, as expected, a recommendation to overrule the objection: >>>> https://www.w3.org/2024/10/team-report-fedid-wg-fo.html - We have made >>>> progress with updating the spec and updated the implementation to match the >>>> latest spec (changing the request and response format, and support multiple >>>> requests) and we would like to test such implementation. - Google Birthday >>>> Correct Flow implementation is also being updated to support both legacy >>>> and modern format. - We have delayed announcing the cross-device OT because >>>> of issue with 3rd party camera apps, we have reached out to other OEMs to >>>> fix it. >>>> >>>> >>>> Reason this experiment is being extended >>>> >>>> I'd like to request permission to extend an OT for this API. The >>>> experiment has been running for Android only so far, but in the meanwhile: >>>> 1- There has been progress on the spec >>>> https://wicg.github.io/digital-credentials/ and it is expected to >>>> graduate to the FedID WG soon. 2- We have added Desktop cross-device >>>> support. Therefore, we are requesting the extension. >>>> >>>> >>>> Ongoing technical constraints >>>> >>>> None >>>> >>>> >>>> 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 >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? 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 >>>> >>>> Requires code in //chrome? True >>>> >>>> Tracking bug https://issues.chromium.org/issues/40257092 >>>> >>>> Launch bug https://launch.corp.google.com/launch/4268575 >>>> >>>> Estimated milestones >>>> Shipping on desktop 141 >>>> Origin trial desktop first 134 >>>> Origin trial desktop last 136 >>>> 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 133 >>>> DevTrial on Android 119 >>>> >>>> Link to entry on the Chrome Platform Status >>>> https://chromestatus.com/feature/5166035265650688?gate=5169620323139584 >>>> >>>> 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 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 >>>> <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 blink-dev+unsubscr...@chromium.org. >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6876938b.2b0a0220.377b9f.0109.GAE%40google.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6876938b.2b0a0220.377b9f.0109.GAE%40google.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8mEfkN3C2dygX0HAo-Q%3D_1YkeTC5cUz1ZZXj%2BvUyQm2A%40mail.gmail.com.
