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/CALjHGKow5Ny2uqq%3DDCnNh6tZNkza8wLeDzNLzqK%3DOiPD84WHag%40mail.gmail.com.
