[webauthn] Allow conditional mediation flow without username or password field, I.E. from button press (#2084)

rsheasby has just created a new issue for https://github.com/w3c/webauthn:

== Allow conditional mediation flow without username or password field, I.E. from button press ==
## Description

The current conditional UI is a huge step in the right direction for seamlessly logging users in when they have stored a passkey previously, but is still dependent on having a username and/or password field with the autofill="webauthn". This covers many use-cases, but not all.

### Explanation of our use-case
Our desired use-case at Stitch is that we are a payments provider, and we support various different payment methods. When a user first lands on our payment page, they first see a splash screen, then after clicking next, they select the payment method they want to use, and then process to fill out the relevant details for that payment method.

Currently we remember users by using localstorage, so if they have paid with Stitch before on a device, when they return to make a payment a second time we offer them the ability to pay using a payment method they previously saved. But we want to replace localstorage with webauthn.

Note Stitch is usernameless and passwordless, with the exception of any required details for the payment methods themselves. We aim to have the most minimal, simple payment experience possible.

### Potential webauthn solutions for use-case

#### Explicit "Use Passkey" button
One possible implementation might require a user to explicitly click a "Use Passkey" button. However, this is likely to lead to low user adoption among laypersons, who may not know what a passkey is. Furthermore, the UX if a user mistakenly clicks "Use Passkey" and they don't have one saved is not very pretty, with the QR popup and such. Finally, there's risk that the user confuses a passkey with a payment method, and mistakenly believes they can't use a passkey, as they don't have (or have not even heard of) that payment method.

#### Always try getting credential when the user clicks through the splashscreen, without conditional mediation
We could of course call the modal UX pop-up on the splash screen as soon as the user clicks next, but that results in a very ugly and confusing UX for the vast majority of users who do not have a passkey already stored.

#### Conditional mediation (current day)
Conditional mediation is almost perfect for what we need. The only real disadvantage is that it requires the user to click on a username or password text field before we can upgrade them to the passkey flow if they have one stored. For many sites this is fine, but in our instance, this would require the user to click through the splash screen, select a payment method, and then start to enter payment details, and only at that point can we offer them the use of webauthn credentials which they previously enrolled, and then present them with their list of saved credentials. This is a confusing UX.

#### Conditional mediation from button press (Desired feature)
If conditional mediation could be triggered from a button press, this would be ideal. It would mean that users who have a credential stored don't necessarily need to remember that they already have a profile with us, as we can conditionally access it as soon as they click on the "next" button on the splashscreen. For users who do have a profile, they seamlessly log in, and are presented with their previously saved payment methods. For users without a profile, nothing changes.

### Password Managers
For what it's worth, it seems that passkeys via password managers (1Password is the one I've tested, I'm unsure if this is the case with all of them) do in fact work using conditional mediation in the way I desire. If I have the 1Password browser extension, and I call a conditional mediation `get`, the 1 password prompt appears immediately to tell me if I have a passkey stored, and lets me log in without needing to ever select a input field. If I don't have a passkey stored, it just has a small toast saying "no passkeys found for this site".

However, native browser passkey management works according to the spec, in which it requires the user select a text field with the relevant autofill property before it will offer the stored passkey.

## Related Links

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2084 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 13 June 2024 15:11:04 UTC