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

[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