Thanks so much for the clarifications, Ken. LGTM1
On Wednesday, March 11, 2026 at 8:21:44 AM UTC-7 Ken Buchanan wrote: > On Mon, Mar 9, 2026 at 2:51 PM Alex Russell <[email protected]> > wrote: > >> Hey Ken, >> >> It's disappointing to hear that the TAG was trying to litigate specific >> UI choices, rather than helping to guide the API's design. As a general >> matter, we should not be specifying *any* explicit UI: >> >> https://infrequently.org/2020/07/why-ui-isnt-specified/ >> >> > If we've made that mistake here, it's not too late to change course >> (although it's reasonable to leave non-normative "for instance" examples >> and Explainer illustrations). If we didn't, then I'm inclined to suggest >> that we have a conversation with our friends on the TAG about the >> opportunities for UI treatments that APIs provide vs. requirements. >> > > Thanks for the response, Alex. We are not specifying the UI, other than > that it must allow the user to select an existing passkey for sign-in. The > objection stems from this API's functional behaviour, which is intended to > enable sign-in via an in-context browser dialog rather than the site having > to show a login form. TAG "disagree[s] that a browser dialog is a better > user experience than an inline login form," but that is the goal of this > API, not the actual thing being specified. > > This feature allows developers to implement the following flow: > if (there is a passkey known by the UA to be available) then > the UA shows sign-in UI offering that passkey > else > reject the promise so the website can take some other action > > The question is about whether this actually enables better user > experiences, because in the current state the first part of that is > available via autofill, but the 'else' part is not possible. > > The discussion with TAG reached a point where they required a higher > standard of evidence for user benefit than we can provide. We are satisfied > with feedback from developers telling us how they intend to use this, and > that this enables a lower-friction sign-in flow that makes it worth > shipping. > > >> As I understand your API, an explicit form treatment is still possible in >> any UI that prefers that. Is that wrong? >> > > You are correct. This deliberately does not displace any existing WebAuthn > usage. Invoking `navigator.credentials.get()` in this mode is not > guaranteed to show any UI, so developers need to keep their existing > sign-in options available for the cases in which the promise is rejected. > > >> >> Best, >> >> Alex >> >> On Thursday, March 5, 2026 at 11:34:59 AM UTC-8 Ken Buchanan wrote: >> >>> *Contact emails* >>> [email protected], [email protected] >>> >>> *Explainer* >>> >>> https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation >>> >>> *Specification* >>> https://github.com/w3c/webauthn/pull/2291 >>> >>> *Design docs* >>> >>> >>> https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation >>> >>> *Summary* >>> A new mode for navigator.credentials.get() that causes browser sign-in >>> UI to be displayed to the user if there is a passkey or password for the >>> site that is immediately known to the browser, or else rejects the promise >>> with NotAllowedError if there is no such credential available. This allows >>> the site to avoid showing a sign-in page if the browser can offer a choice >>> of sign-in credentials that are likely to succeed, while still allowing a >>> traditional sign-in page flow for cases where there are no such credentials. >>> >>> *Blink component* >>> Blink>WebAuthentication >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebAuthentication%22> >>> >>> *Web Feature ID* >>> webauthn <https://webstatus.dev/features/webauthn> >>> >>> *Motivation* >>> Most sign-in experiences on the web use sign-in pages that offer >>> multiple options for accessing an account, such as username/password input >>> fields, federated sign-in buttons, and sometimes explicit WebAuthn or >>> passkey buttons. When the browser is aware of passkeys or passwords that >>> the user has for the site, this API mode makes the sign-in page unnecessary >>> by instead showing simple browser account selection UI when the user begins >>> a sign-in attempt. Signing in with this flow reduces friction and avoids >>> user confusion from having to remember which sign-in option they have used >>> previously on a given site. The main difference between this and current >>> modal WebAuthn sign-in UI is that for users without any such credentials, >>> no browser UI will be shown, and their sign-in experience will be unchanged >>> from what it is today (typically, a navigation to the site's sign-in page). >>> >>> *Initial public proposal* >>> https://github.com/w3c/webauthn/issues/2228 >>> >>> *TAG review* >>> https://github.com/w3ctag/design-reviews/issues/1092 >>> >>> TAG has closed its review with unsatisfied on the basis that they do not >>> believe a modal browser dialog is preferable to a form for user sign-in >>> experiences. There was extensive discussion of this topic on both the TAG >>> review issue and the WebAuthn WG issue. >>> >>> This conflicts with the feedback we have received from developers of >>> major relying parties who believe this enables them to build meaningfully >>> better user experiences. They believe that a modal dialog that appears only >>> when passkeys are available will be more successful for users attempting to >>> sign in. Additionally, achieving the goal of signing in a user while >>> keeping them in the current page context is very difficult with the current >>> API. >>> >>> Apple has stated that it supports the goals of this mode, but has >>> objected on a different basis from TAG. It favors an alternative API form >>> that it believes will have better privacy properties ( >>> https://github.com/w3c/webauthn/issues/2228#issuecomment-3443764943). >>> Notably, >>> Apple's proposal and Immediate mode would be invoked in different >>> situations, and are not mutually exclusive. >>> >>> Since Immediate mode does not guarantee that UI will be shown on >>> invocation, we maintain flexibility to tweak this later in ways that limit >>> its use. >>> >>> *TAG review status* >>> Issues addressed >>> >>> *Origin Trial Name* >>> Immediate Mediation for Passkeys and Passwords >>> >>> *Chromium Trial Name* >>> WebAuthenticationImmediateGet >>> >>> *Origin Trial documentation link* >>> >>> https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation >>> >>> *WebFeature UseCounter name* >>> kCredentialsGetImmediateMediationWithWebAuthnAndPasswords >>> >>> *Risks* >>> >>> >>> *Interoperability and Compatibility* >>> *Gecko*: No signal ( >>> https://github.com/mozilla/standards-positions/issues/1239) >>> >>> *WebKit*: Negative ( >>> https://github.com/WebKit/standards-positions/issues/504) Feedback is >>> on the WG issue: >>> https://github.com/w3c/webauthn/issues/2228#issuecomment-3443764943 >>> >>> *Web developers*: Positive ( >>> https://github.com/w3c/webauthn/issues/2228#issuecomment-3999513181) >>> >>> *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 >>> >>> https://wpt.fyi/results/webauthn/getcredential-ui-mode-immediate.https.html?label=master&label=experimental&aligned&q=getcredential-ui-mode-immediate.https.html >>> >>> *DevTrial instructions* >>> >>> https://docs.google.com/document/d/18iV5eUBM4NVoNx0gqPSxPyJAjPdrfIR75vcMDBewzZU/edit?tab=t.0#heading=h.uj0x12ysuohk >>> >>> *Flag name on about://flags* >>> web-authentication-immediate-get >>> >>> *Finch feature name* >>> WebAuthenticationImmediateGet >>> >>> *Rollout plan* >>> Will ship enabled for all users >>> >>> *Requires code in //chrome?* >>> True >>> >>> *Tracking bug* >>> https://issues.chromium.org/issues/408002783 >>> >>> *Launch bug* >>> https://launch.corp.google.com/launch/4394539 >>> >>> *Measurement* >>> Use counters: CredentialsGetImmediateMediationWithWebAuthnAndPasswords >>> CredentialsGetImmediateMediationWithWebAuthnOnly >>> CredentialsGetImmediateMediationWithPasswordsOnly We are also tracking user >>> interactions with the modal UI that will be shown when this is used. >>> >>> *Estimated milestones* >>> Shipping on desktop 147 >>> Origin trial desktop first 139 >>> Origin trial desktop last 141 >>> Origin trial extension 1 end milestone 144 >>> DevTrial on desktop 136 >>> Shipping on Android 147 >>> DevTrial on Android 142 >>> Shipping on WebView 147 >>> >>> *Link to entry on the Chrome Platform Status* >>> https://chromestatus.com/feature/5164322780872704?gate=5177075746734080 >>> >>> *Links to previous Intent discussions* >>> Intent to Prototype: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjHGKrQEs4TDzuzb%3D0B00S4OmkE4a1NbZGi19sCueTKvN_m9w%40mail.gmail.com >>> Ready for Trial: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/zC13ioLIZ_E/m/P-P6B6gNCQAJ >>> Intent to Experiment: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjHGKpJkA9G6De6D4%3DRNSbLMRdy8Yfa6B%3DgDNWeqTyHfv8sSg%40mail.gmail.com >>> Intent to Extend Experiment 1: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjHGKpLbqYVnSMfNgxh45TSbP9j6AU2JvLWow%3DH1ihr5v%2Bj0A%40mail.gmail.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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e120c308-e321-4cd6-a0f8-71fee454e8b0n%40chromium.org.
