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 On Wednesday, August 20, 2025 at 5:24:48 PM UTC-7 Jeffrey Yasskin wrote: > On Mon, Aug 18, 2025 at 11:16 AM Alex Russell <slightly...@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 > <https://github.com/w3ctag/explainer-explainer/pull/25>: > > "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 > > 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7b83a6c1-53ae-4dd4-8eb4-549daf8126a1n%40chromium.org?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/af51d426-71f3-4dbd-bad4-797f826fa74fn%40chromium.org.
