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 On Thursday, August 14, 2025 at 1:29:18 PM UTC-7 Mohamed Amir Yosef wrote: > 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 > <https://github.com/w3ctag/design-reviews/issues/1119#issuecomment-3176058950> > 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! > > > > Thanks, > Dan > On Monday, August 11, 2025 at 2:32:19 PM UTC-7 rby...@chromium.org wrote: > > [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 > <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. > > Sorry, I forgot to update this (now fixed). The FedID WG filed for TAG > review <https://github.com/w3ctag/design-reviews/issues/1119> a month ago > now but no comment yet. > > Related, TAG has published Preventing Abuse of Digital Credentials > <https://w3ctag.github.io/web-no-papers/> which is related (and covers > many of the issues I listed > <https://github.com/w3c/credential-considerations/blob/main/credentials-considerations.md> > 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 > <https://groups.google.com/a/chromium.org/g/blink-dev/c/Vj2tr_cAClk/m/ztVMpBYSAgAJ> > > 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 > <https://developer.apple.com/videos/play/wwdc2025/232/> 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. > > > *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 > <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 > > 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-421uDmu2WNDBG5bYRSWAhfmahsHPVj > DwN5NLkUdCkvw%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 > <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/7b83a6c1-53ae-4dd4-8eb4-549daf8126a1n%40chromium.org.
