Friendly ping on this intent. It currently has two approvals from API owners.
On Wed, Mar 18, 2026 at 5:57 PM Jeffrey Yasskin <[email protected]> wrote: > On Wed, Mar 18, 2026 at 1:53 PM Ken Buchanan <[email protected]> wrote: > >> >> >> On Wed, Mar 18, 2026 at 11:59 AM Jeffrey Yasskin <[email protected]> >> wrote: >> >>> On Wed, Mar 18, 2026 at 8:32 AM Ken Buchanan <[email protected]> wrote: >>> >>>> >>>> >>>> On Wed, Mar 18, 2026 at 10: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? >>>>> >>>> >>>> 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! > > >> >>> But I'll re-iterate the TAG's >>> <https://github.com/w3ctag/design-reviews/issues/1092#issuecomment-3630215411> >>> feedback >>> <https://github.com/w3ctag/design-reviews/issues/1092#issuecomment-3630215411> >>> 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 >>> <https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation#contextual-sign-in-moments> >>> 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. >> >> >>> >>> 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 >>> >>> 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. >>>> >>>> >>>>> /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/moz >>>>>> illa/standards-positions/issues/1239) >>>>>> >>>>>> *WebKit*: Negative (https://github.com/W >>>>>> ebKit/standards-positions/issues/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=51770 >>>>>> 75746734080 >>>>>> >>>>>> *Links to previous Intent discussions* >>>>>> Intent to Prototype: https://groups.goog >>>>>> le.com/a/chromium.org/d/msgid/blink-dev/CALjHGKrQEs4TDzuzb%3 >>>>>> D0B00S4OmkE4a1NbZGi19sCueTKvN_m9w%40mail.gmail.com >>>>>> Ready for Trial: https://groups.google.c >>>>>> om/a/chromium.org/g/blink-dev/c/zC13ioLIZ_E/m/P-P6B6gNCQAJ >>>>>> Intent to Experiment: https://groups.goo >>>>>> gle.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/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/CALjHGKogbYYwkiNSR_Pakc6jqp1cXKBaRS9E_uHrUdbr0t2RQA%40mail.gmail.com.
