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/
<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]
<mailto:[email protected]>
*Explainer*
https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation
<https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation>
*Specification*
https://github.com/w3c/webauthn/pull/2291
<https://github.com/w3c/webauthn/pull/2291>
*Design docs*
https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation
<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
<https://github.com/w3c/webauthn/issues/2228>
*TAG review*
https://github.com/w3ctag/design-reviews/issues/1092
<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
<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
<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
<https://github.com/mozilla/standards-positions/issues/1239>)
/WebKit/:
Negative (https://github.com/WebKit/standards-positions/issues/504
<https://github.com/WebKit/standards-positions/issues/504>) Feedback
is on the WG issue:
https://github.com/w3c/webauthn/issues/2228#issuecomment-3443764943
<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/w3c/webauthn/issues/2228#issuecomment-3999513181
<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
<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
<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
<https://issues.chromium.org/issues/408002783>
*Launch bug*
https://launch.corp.google.com/launch/4394539
<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
<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
<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
<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
<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
<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/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.
