Intent to Ship: Web Authentication Immediate UI mode

[Ken Buchanan]

Contact emails

ke...@chromium.org, der...@google.com

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

Web Feature ID

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?

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.

[Alex Russell]

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

ke...@chromium.org, derinel@google.com

[Yoav Weiss (@Shopify)]

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?

[Ken Buchanan]

On Mon, Mar 9, 2026 at 2:51 PM Alex Russell <sligh...@chromium.org> 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

ke...@chromium.org, der...@google.com

[Ken Buchanan]

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.

[Alex Russell]

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 <sligh...@chromium.org> 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

ke...@chromium.org, derinel@google.com

[Daniel Bratell]

How obvious will the existence of browser stored credentials be to the web site?

What if I clear site data in the browser?

/Daniel

--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjHGKoR0EskBNkLxcaRRO0wtfGe-0po0mxnFH_VhSnpFt49Zw%40mail.gmail.com.

[Chris Harrelson]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/29362701-203d-4847-abc0-d0b47e65100d%40gmail.com.

[Ken Buchanan]

On Wed, Mar 18, 2026 at 10:16 AM Daniel Bratell <brat...@gmail.com> wrote:

How obvious will the existence of browser stored credentials be to the web site?

What if I clear site data in the browser?

Since the credentials come from the passkey provider/password manager, clearing site data has no effect.

In terms of obviousness, a site that wanted to know if UI was shown could fairly easily determine it by timing how long it takes before the promise is rejected (i.e., it can distinguish between no UI being shown, and UI being shown but the user dismissing it).

One limitation we've added is that in incognito mode this API behaves the same as when there are no credentials available, based on users having a higher expectation of privacy while using that mode.

[Jeffrey Yasskin]

On Wed, Mar 18, 2026 at 8:32 AM Ken Buchanan <ke...@chromium.org> wrote:

On Wed, Mar 18, 2026 at 10:16 AM Daniel Bratell <brat...@gmail.com> wrote:

How obvious will the existence of browser stored credentials be to the web site?

What if I clear site data in the browser?

Since the credentials come from the passkey provider/password manager, clearing site data has no effect.

In the TAG review, I thought everyone had agreed that if the user uses browser UI to sign out of a site (which is accomplished by clearing site data), the browser should hide the fact that the user has a passkey until the user next chooses to sign in with a passkey. I now see that you removed that section from the explainer after I last looked: https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation/_compare/cef140c78ffe6ea855eb3f8d3c56db7cb17596c8...874f2dcf4c3b831db8169a92ccf828a03ff6551e. At the very least, this should continue to live in the Alternatives Considered section, with the reason for choosing against it.

But I'll re-iterate the TAG's feedback that it's user-hostile to force someone to go over to Incognito in order to hide the fact that they have an account.  If I want to use the 'guest' flow on a site that I've previously logged into, the UI that you've mocked in the explainer forces me to 'close' my attempt to check out in order to get to the guest flow. This seems likely to coerce users to sign in, since they don't actually want to 'close' their attempt to check out. Browsers shouldn't facilitate that.

This touches on Alex's point about litigating specific UI choices: it's fine if there are some "good" UIs and some "bad" UIs for a proposed API shape. The problem with this one is that I haven't yet seen a UI design for it that gives the user a free choice between logging-in-with-their-passkey and using some other method to accomplish their goal. If no such UI exists, that's an issue with the API itself.

Jeffrey

[Ken Buchanan]

On Wed, Mar 18, 2026 at 11:59 AM Jeffrey Yasskin <jyas...@google.com> wrote:

On Wed, Mar 18, 2026 at 8:32 AM Ken Buchanan <ke...@chromium.org> wrote:

On Wed, Mar 18, 2026 at 10:16 AM Daniel Bratell <brat...@gmail.com> wrote:

How obvious will the existence of browser stored credentials be to the web site?

What if I clear site data in the browser?

Since the credentials come from the passkey provider/password manager, clearing site data has no effect.

In the TAG review, I thought everyone had agreed that if the user uses browser UI to sign out of a site (which is accomplished by clearing site data), the browser should hide the fact that the user has a passkey until the user next chooses to sign in with a passkey. I now see that you removed that section from the explainer after I last looked: https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation/_compare/cef140c78ffe6ea855eb3f8d3c56db7cb17596c8...874f2dcf4c3b831db8169a92ccf828a03ff6551e. At the very least, this should continue to live in the Alternatives Considered section, with the reason for choosing against it.

Thank you for the suggestion. I have added that to the explainer.

 

But I'll re-iterate the TAG's feedback that it's user-hostile to force someone to go over to Incognito in order to hide the fact that they have an account.  If I want to use the 'guest' flow on a site that I've previously logged into, the UI that you've mocked in the explainer forces me to 'close' my attempt to check out in order to get to the guest flow. This seems likely to coerce users to sign in, since they don't actually want to 'close' their attempt to check out. Browsers shouldn't facilitate that.

I share the view that in general we should minimize information leakage through side channels. However, it's far from certain that the API would be abused in this way, since the scenario where this is possible is rare in practice. One advantage of this API change is that the browser does not guarantee UI will be shown even if credentials are available. This allows for flexibility to add restrictions later if we observe the feature being used in user-hostile ways. Doing that would pose no risk of breakage.

[Jeffrey Yasskin]

On Wed, Mar 18, 2026 at 1:53 PM Ken Buchanan <ke...@chromium.org> wrote:

On Wed, Mar 18, 2026 at 11:59 AM Jeffrey Yasskin <jyas...@google.com> wrote:

On Wed, Mar 18, 2026 at 8:32 AM Ken Buchanan <ke...@chromium.org> wrote:

On Wed, Mar 18, 2026 at 10:16 AM Daniel Bratell <brat...@gmail.com> wrote:

How obvious will the existence of browser stored credentials be to the web site?

What if I clear site data in the browser?

Since the credentials come from the passkey provider/password manager, clearing site data has no effect.

In the TAG review, I thought everyone had agreed that if the user uses browser UI to sign out of a site (which is accomplished by clearing site data), the browser should hide the fact that the user has a passkey until the user next chooses to sign in with a passkey. I now see that you removed that section from the explainer after I last looked: https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation/_compare/cef140c78ffe6ea855eb3f8d3c56db7cb17596c8...874f2dcf4c3b831db8169a92ccf828a03ff6551e. At the very least, this should continue to live in the Alternatives Considered section, with the reason for choosing against it.

Thank you for the suggestion. I have added that to the explainer.

Thanks!