LGTM2 On Wed, Mar 18, 2026 at 7:16 AM Daniel Bratell <[email protected]> wrote:
> How obvious will the existence of browser stored credentials be to the web > site? > > What if I clear site data in the browser? > > /Daniel > On 2026-03-11 16:35, Ken Buchanan wrote: > > Hi Yoav, > > That's correct. Apple agrees with the use case but dislikes the > information leakage. The website can easily infer that browser UI is being > shown, which lets them know a passkey exists for this user even if the user > does not choose to sign in with one. > > We spent some time exploring their alternative proposal. It ends up being > something quite different, though, and we decided to continue with this > based on partner feedback. Since in their case the promise would not be > rejected if no passkeys are available, the website must offer an > alternative on the page before the method is called. Much of the current > design's value is that it allows the page to perform some action (such as a > navigation) only if this API does not succeed. > > The two proposals can co-exist in the specification, and we haven't ruled > out pursuing Apple's alternative also. They would be invoked in different > situations. > > > On Wed, Mar 11, 2026 at 11:21 AM Yoav Weiss (@Shopify) < > [email protected]> wrote: > >> >> >> On Monday, March 9, 2026 at 7:51:08 PM UTC+1 Alex Russell 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. 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/issue >> s/1239) >> >> *WebKit*: Negative (https://github.com/WebKit/standards-positions/issu >> es/504) Feedback is on the WG issue: https://github.com/w3c/ >> webauthn/issues/2228#issuecomment-3443764943 >> >> >> Naively reading through WebKit folks' feedback, they seem supportive of >> the use case, but interested in a different shape that won't expose the >> presence of the passkey to the site. >> Is there a chance to converge here? >> >> >> >> >> *Web developers*: Positive (https://github.com/w >> 3c/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/18iV5eUBM4NVoNx0gqPSxPyJA >> jPdrfIR75vcMDBewzZU/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 desktop147Origin trial desktop first139Origin trial desktop >> last141Origin trial extension 1 end milestone144DevTrial on >> desktop136Shipping >> on Android147DevTrial on Android142Shipping on WebView147 >> >> *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%3DgDNWeqTyH >> fv8sSg%40mail.gmail.com >> Intent to Extend Experiment 1: https://groups.google.com/a >> /chromium.org/d/msgid/blink-dev/CALjHGKpLbqYVnSMfNgxh45TSbP9 >> j6AU2JvLWow%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/CALjHGKoR0EskBNkLxcaRRO0wtfGe-0po0mxnFH_VhSnpFt49Zw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjHGKoR0EskBNkLxcaRRO0wtfGe-0po0mxnFH_VhSnpFt49Zw%40mail.gmail.com?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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/29362701-203d-4847-abc0-d0b47e65100d%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/29362701-203d-4847-abc0-d0b47e65100d%40gmail.com?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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_auuFo3gJUoV1qhwCrPTSkK-8HUyBMY5RTD7P%2BzccJLg%40mail.gmail.com.
