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

[rsheasby]

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 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 proceed 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, for various reasons.

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. Especially in our use-case, 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. User training at enrollment can help improve this, but it still isn't quite as seamless as we'd like it to be.

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

[MasterKale]

This almost seems like an ask for clients to support combining the "webauthn" token in the autocomplete attribute with more payment-related tokens like these:

• "cc-name"
• "cc-given-name"
• "cc-additional-name"
• "cc-family-name"
• "cc-number"
• "cc-exp"
• "cc-exp-month"
• "cc-exp-year"
• "cc-csc"
• "cc-type"

Is there an implicit assumption that SPC is being leveraged in payment flows like the ones identified in the OP? Or do we not need to consider that in here?

[rsheasby]

Not quite. In our case the credit card entry field is quite a bit later in the UX flow than where we'd like to invoke the conditional mediation.

So firstly, the user lands on a welcome splash screen. Then after clicking next, they are presented with a multiple selection of all the available payment methods:

• Credit Card
• Bank Credentials (instant EFT)
• QR Code
• etc

Some of these also have further nested selections, like bank credentials allows you to pick which bank you want to pay with.

We want to invoke webauthn right at the splash screen, before the user has even selected one of those payment methods and selected a text box. Otherwise it's a sub-optimal UX if the user has a credit card saved for example, but they forgot about it, and so they return, select "Bank Credentials", then select their bank, then select the username field to provide their bank credentials, and only then do they get the suggestion to auth with webauthn, which then redirects them back to the method selection, except this time with their saved credit card listed.

[rsheasby]

However, I will add that user agents supporting webauthn autofill in CC fields and similar also definitely would be helpful and is a good idea in its own right.

Also to answer your other question, in our case we are not looking to use Secure Payment Confirmation, no, as device support is not yet there, and we want the portability and usability of passkeys (which AFAIK are not usable with the payment extension, although I certainly could be wrong?)

[timcappalli]

The challenge with this is that it may prevent users from using a passkey from another device (security key or phone), and while that may not be important for your payments use case, it would impact traditional sign in flows.

I think the idea is worth exploring, but I think we should defer discussions to L4 based on existing work items and priorities.

/cc @nadalin