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/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=51770 >>>>> 75746734080 >>>>> >>>>> *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/CANh-dXnemkS5VgCGe0AuqfnSh3Hh-a9BFM9VEV7Km_OS2NM%2BeQ%40mail.gmail.com.
