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.