- From: Anders Rundgren via GitHub <sysbot+gh@w3.org>
- Date: Sat, 04 Sep 2021 04:03:23 +0000
- To: public-webauthn@w3.org
@stephenmcgruer wrote: > SPC's current model should (I believe) work with any payment protocol where the merchant and the bank talk on some form of backend protocol - which is most of them. This is not entirely correct, in most cases there is a third party in the middle. For EMV which is the most widely used payment authorization system there is no direct communication between the merchant and the customer's bank; it is a pure store-and-forward system depending on trusted intermediaries for the communication with banks (which BTW often is bank specific). 3DS (and SPC) introduces a new requirement: retrieving the URL to the bank's (ACS) Access Control Server using the card number as key. According to the 3DS specification this operation requires certified merchant software and an X.509 certificate for authentication which is why 3DS more or less presume outsourced operation. That is, merchants will _in general_ not be able invoking SPC themselves. How does this relate to this issue you may [rightfully] wonder? Well, by rather building on EMV you get away from just about all _privacy_, _UI_, _credential discovery_, and _scalability_ issues mentioned here, as well as in the SPC draft. An EMV variant would preferably not be built on top of the WebAuthn API, it would rather use CTAP2 and funnel hashed transaction requests through `clientDataHash` (and thus eliminating `clientDataJSON`). Backing authenticators would still be 100% compatible with WebAuthn in case RPs would like to use them for login as well. -- GitHub Notification of comment by cyberphone Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1667#issuecomment-912902742 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 4 September 2021 04:03:24 UTC