Re: [webauthn] Cross-origin credential creation (#1656)

Hi Adam (@agl ),

I concur with the use-case: that it is essential for Banks to receive digital signatures from Consumers directly when they're confirming a payment transaction at a Merchant site. But I humbly disagree with the premise that the optimal way to register Consumers is with cross-origin credential creation. I think Banks and browser companies are making a mistake and forcing the FIDO protocol/implementations to become a lot more complex than it need become - at least for this use-case.

Every Bank, IMO, is going to have to contend with FIDO sooner or later whether they like it or not. Windows 11 and Apple Passkey will ensure that. If they have to implement FIDO for their own users to interact with them directly, why would they not simply require that the Consumer register with them _first_ and associate all their registered Public Keys for whatever payment instruments they have acquired from the Bank?

By doing so, here are all the benefits that accrue to the ecosystem:

- Consumers only have to register with the Bank once (for each unique Authenticator they choose to register);
- Consumers do not have to be distracted with additional friction during the Checkout process (to register an Authenticator);
- Consumers do not have to be worried that they are being attacked by someone while shopping at a site ("What are these additional things the Merchant wants me to do?", "How do I know I can trust what I'm seeing here?", "Perhaps the Merchant has been compromised?");
- Merchants do NOT have to create complex Checkout workflows for registration of Authenticators. When the Consumer chooses a specific payment instrument during Checkout, and the Merchant sends that information to the Bank, the Bank recognizes the instrument, finds the associated Public Key(s) and a unique challenge comes back as a response for the Consumer to sign;
- Banks do not have to worry about whether the Consumer _may_ register their new payment instrument with them - they can mandate it as a prerequisite to using the instrument (they already require all kinds of user actions to enable the use of a payment card before first use currently);
- Banks can transition to digital payment instruments - instead of sending out cards - and register those instruments faster and more securely with FIDO, rather than:

     1. Wait for the Consumer to receive the card;
     2. Choose to go shopping on the internet;
     3. Choose to use a Merchant that might have implemented FIDO; and finally
     4. Choose to register at the Bank during Checkout.

- There are too many conditional probabilities that are likely to result in very low registrations with the Bank. When registered directly with the Bank, they will have 100% compliance and the potential to offer Merchants faster Checkouts (and more conversions) because of FIDO enabled payment instruments;
- Banks will reduce risk and costs while providing Consumers a better experience in interacting with the Bank when they use FIDO for **all** interactions with the Bank - not just for Merchant transactions (at sites that _might_ have FIDO enabled).

By not thinking of the bigger picture, Banks and browser manufacturers might unnecessarily complicate the protocol and the process. IMO, it will be more productive for Banks to register Consumers directly - and more securely - while eliminating the need for one more change to the protocol to carry new baggage.

-- 
GitHub Notification of comment by arshadnoor
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1656#issuecomment-887865084 using your GitHub account


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

Received on Tuesday, 27 July 2021 22:05:11 UTC