Do API owners have any other questions or concerns about this? This launch is targeting Chrome 148 which branched on Monday.
On Thu, Apr 2, 2026 at 3:45 PM Ken Buchanan <[email protected]> wrote: > > We've decided to accept that change. The spec PR and explainer have been > updated, and there is a change to the Chrome implementation in code review. > > The Chrome privacy team asked us to tighten the rate limiter to compensate > for not consuming the transient user gesture. Requests are rejected if more > than two are made within a five-second window on a single page. > > > On Wed, Apr 1, 2026 at 2:58 PM Ken Buchanan <[email protected]> wrote: > >> Yoav, we are still investigating on our side but here's an update. >> >> We had not considered the possibility of requiring a user gesture without >> consuming it until some of your organization's people raised the >> possibility last month. The use case is that this API could be called, and >> then a popup would be triggered in the case where no credentials are >> available. Consuming the transient activation would prevent the popup from >> working. >> >> If we change that, it should be done before initial launch. Relaxing the >> restriction later would make it difficult for a site to know in advance >> whether the popup will work. >> >> We have an ongoing internal discussion about the question and I will >> update this thread when we reach a conclusion. >> >> On Wed, Mar 25, 2026 at 11:32 AM Yoav Weiss (@Shopify) < >> [email protected]> wrote: >> >>> One point that came up last week (and apparently also as part of the TAG >>> review) is that because this consumes user activation, developers may have >>> a hard time integrating this feature into auth flows, that often involve >>> popups. >>> >>> Is this something you considered? If this turns out to be an issue with >>> developers, can this change without breakage? >>> >>> On Wednesday, March 25, 2026 at 2:40:23 PM UTC+1 Ken Buchanan wrote: >>> >>>> 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#issuecomm >>>>>>>>>> ent-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/CALjHGKqq%3DfM%2BYc%2BQeQDfPviifs%2BEcUwyw_Q3UKDgmKNF0NxR1A%40mail.gmail.com.
