Allow immediate mediation

[deephand]

Proposed Change

I added an explainer in the wiki that suggests to return a NotFoundError when there are no locally available credentials and otherwise show the modal UI. This should allow RPs to go formless and skip the hybrid flow, which is time consuming and not always applicable.

I would like to hear your opinions about it, thanks in advance!

[kopy]

In B2B, workspace, and smaller deployments, this functionality can be helpful.

For larger consumer deployments with a lot of existing accounts (1 million+), removing the familiar username field (email/phone) and only showing a sign-in button at first would be confusing for users. This is also why many large-scale websites haven’t elevated a “Use Passkey” button yet to the same level as the username field. Instead, they attempt to start a passkey ceremony automatically after the username is entered, even if it comes with complications like user enumeration and false positives (e.g., QR codes). In those cases, conditional mediation still works well because the user has not yet entered their username, but with this approach it would not work due to the AllowList limitation.

[Firstyear]

You assume everyone will have access to passkeys to support this. The reality is not all users will be able to access passkeys (android famously errors to create passkeys without a full device reset), and some users may choose not to use them (due to not having a pw manager, unable due to rk limits on security keys, or distrust of apple/google). So you need to keep your username field for the foreseeable future.

[kenrb]

FYI: @deephand has updated the explainer with some clarifications. In particular:

1. It makes it clearer that the expectation is not for sites to be able to remove other sign-in options. The idea is that users with immediately-available passkeys can be shown the passkey UI directly without having to interact with a sign-in form, while users without those would see the same sign-in options that they do without this.
2. The privacy section now provides better detail on the compromise that we are proposing. The earlier version of the explainer was not explicit on this point. This would make a change to the privacy guarantees that the WebAuthn API currently provides, and the explainer offers mitigations intended to prevent any potential abuse of that change.

[kopy]

@kenrb @deephand: Have you considered a user consent-driven approach on the web?

Instead of requiring a user gesture for immediate mediation (which has proven to be a bad idea), an automatic flow could leverage explicit, browser-level consent (e.g. after credential creation or use). Users could opt (after an RP requests that) in to allow the RP to initiate a WebAuthn ceremony automatically (with user verification) when visiting a page, clicking a login button, or navigating to a login page. This consent would allow the RP to infer credential availability without breaking privacy guarantees, as the browser would manage storage, control, and permission. It also enables the use of AllowCredentials after identifier-first flows, aligning with natural login flows users already expect. As there is user consent using AllowCredentials becomes and option.

[ricea]

Sites can use that extra bit of information to lock out users who have credentials for the site but don't want to log in for whatever reason. A few sites like Twitter and Instagram show some content to logged-out users but aggressively try to coerce them to log in. With this feature they could be even more obnoxious.

Requiring user interaction seems worthless as a hurdle in an age where every site has cookie banners.

If there was a way to restrict this only to scenarios where the user was going to have to log in anyway, the privacy concerns would be lessened.

I can also see a usability problem when the account I want to log in to Twitter with is a different one from the one that my browser knows about.

[kenrb]

Sites can use that extra bit of information to lock out users who have credentials for the site but don't want to log in for whatever reason. A few sites like Twitter and Instagram show some content to logged-out users but aggressively try to coerce them to log in. With this feature they could be even more obnoxious.

I agree this is a concern. Sites do this now using cookies, but this would make that problem somewhat worse because users who have manually cleared their cookies might still have the existence of a sign-in credential apparent to the site through this mechanism. This is part of the reasoning why this feature would not work in private browsing modes such as incognito. It provides a way for users to hide the existence of credentials.

I can also see a usability problem when the account I want to log in to Twitter with is a different one from the one that my browser knows about.

Yes. If you have two accounts, and one has a credential that will appear in this UI and one does not, then this adds friction signing in with the second account. That's a trade-off.

[ricea]

Sites do this now using cookies, but this would make that problem somewhat worse because users who have manually cleared their cookies might still have the existence of a sign-in credential apparent to the site through this mechanism.

It's also an issue because of sync. I sync my personal browser profile between home and work, so they have access to the same credentials, but there are some sites I only log into at home. If I happen to access the same site at work, I don't particularly want it knowing that it knows me.

This could maybe be addressed by having some record of sites I have logged into that is intentionally not synced between machines. This would be consistent with how cookies work now, so maybe not too surprising?

[timcappalli]

WebAuthn hybrid meeting on 2025-04-11: there is multi-implementer interest in exploring this feature for L4.