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.