Re: [w3ctag/design-reviews] Secure Payment Confirmation (#544)

Hi all,
We are approaching FPWD of SPC. Stay tuned for more about that soon.

Since this TAG review request a year ago, the Working Group has made progress on use cases, requirements, and the specification itself. The Explainer is currently being revised to align with the latest impelmentation. For more information about these resources, please see our repo:
 https://github.com/w3c/secure-payment-confirmation

I would like to reply to some of the comments above, starting with some general observations:

* SPC adds some features atop WebAuthn that are specific to payments use cases.
* We intend SPC to be useful with a wide variety of payment methods, including card payments, open banking, real-time payments, proprietary payment methods, and more. 
 
Thus, SPC is not specific to card payments. By extension there are no requirements related to "providing card numbers in the clear." Nothing precludes people from using SPC with vanilla form fill use cases, but that is not part of SPC.

Like WebAuthn, SPC involves an enrollment phase and an authentication phase. During the enrollment phase, the relying party (which might be a bank, for example, or a payment service provider) associates a WebAuthn credential with a payment instrument (e.g., credit card or bank account). Then, at authentication time we envision this sort of flow:

* The user selects an instrument to make a payment.
* The merchant (or their payment service provider) reaches out to the relying party to ask "Do you have any SPC credentials for this instrument?"
* The relying party returns any credentials and other relevant information (e.g., nonce for the Webauthn call).
* The merchant calls SPC and receives an assertion that includes signed transaction information (by the authenticator).
* The mechant then communicates the assertion to the relying party for verification.

SPC thus relies on "backend rails" for communications with the relying party (to get credentials and to share the resulting assertion). By design, SPC is independent of these backend rails. Our primary conversations with industry participants at this time have been about using SPC with EMVCo's 3-D Secure. EMVCo has indicated publicly that they anticipate support for SPC to be part of 3DS version 2.3 (this year). As soon as EMVCo releases a public version of 3DS with SPC support, we will discuss it in the Web Payment Security Interest Group and Web Payments Working Group.

We have also had discussion about other underlying rails, including EMVCo's Secure Remote Commerce, open banking APIs, and some proprietary solutions as well. Our goal is to ensure the design scales across payment methods.

Thus, to the comment above "The specification does not elaborate on backend requirements" I reply "That is correct, but not a problem."

Regarding industry interest and engagement, a you may know, Stripe experimented with an early implementation of SPC in late 2020 / early 2021 and reported their encouraging findings in March 2021:
 https://www.w3.org/2021/Talks/spc-pilot-202103.pdf
 
Planning is underway for two additional experiments (using new capabilities driven by the first experiment): a second experiment by Stripe, and an experiment by Adyen and Airbnb.

I look forward to discussing the TAG's feedback on SPC.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/544#issuecomment-902093067