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. As I understand your API, an explicit form treatment is still possible in any UI that prefers that. Is that wrong? 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/5c88d756-f0d4-46a6-8543-a5f9138b9a82n%40chromium.org.
