Request for position: Secure Payment Confirmation

[stephenmcgruer]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Secure Payment Confirmation
• Specification or proposal URL: https://w3c.github.io/secure-payment-confirmation/ (see also explainer)
• Caniuse.com URL (optional): N/A
• Bugzilla URL (optional): N/A
• Mozillians who can provide input (optional):

Other information

• The current API shape of Secure Payment Confirmation does require the Payment Request API, which has not shipped in Firefox I believe. We are considering an API shape change in the intermediate future (3-6 months) away from it, however (issue).

[annevk]

cc @stpeter

[cyberphone]

 
W3C Pay (w3c/secure-payment-confirmation#143 (comment)), combines W3C's previous payment efforts with SPC. Since Apple Pay is often held as the "Gold Standard" for payment apps, it seems valid to include it in a comparison chart as well:

	SPC	Apple Pay	W3C Pay	Comment
Integrated Payment UX	❌	✔	✔	Card Not Present (CNP) vs Wallet concept
Simple Merchant Integration	❌	✔	✔	Side effect of the previous feature
Privacy By Design	❌	✔	✔	Encrypted/tokenized authorization data including card numbers
Market Brand Name	❌	✔	✔	Framework solution vs Branded icon in checkout pages
Provider Neutral	❌	❌	✔	Core value for IT standards
Unified User Authorization	❌	❌	✔	Identical protocol and UX for on-line and physical world payments, irrespective of payment network
Account Type Agnostic	❌	❌	✔	Support for arbitrary account based payment networks
Physical World Payments	❌	✔ EMV	❕ [2, 3]	Standard feature in the "app" world
Open Specification	✔	❌	✔	Core value for IT standards
Platform Independent	✔	❌	✔	Core value for IT standards
Desktop Web/Mobile Wallet	❕ [1]	❕ MacOS Only	✔ QR Code	Major use case
WebAuthn/FIDO Updates	❕ Major	Not Applicable	None, [4]	Dependencies add cost, fuzz, and time

1. Through provider specific solutions.
2. Through QR code which is currently not generally available in payment terminals.
3. There are untapped possibilities here like combining NFC and BLE which would be interesting for many other payment applications as well.
4. After attestation an RP may return an object containing wallet data which is a browser extension like navigator.wallet.update(...).
5. Although Microsoft have not participated in these developments, they got it for free after their decision to build on the "Blink" core which is powering Chrome.

SPC primarily targets framework based systems like 3DS, SRC, and Open Banking which are agnostic to the underlying authentication method. That is, in these scenarios you don't select which method to use. W3C Pay represents a specific method which is incompatible with frameworks. This is the de-facto standard for most "app" based systems, including Apple Pay.

Card Not Present (CNP) solutions usually require that users also carry physical payment cards. Wallet solutions only depend on virtual payment cards selected via icons.

[cyberphone]

As described by the W3C chair, SPC more or less presumes that Stripe, MasterCard et al take over the issuance of payment credentials from banks: w3ctag/design-reviews#675 (comment)

Otherwise it would obviously not scale since there are so many banks and most of them already have implemented 3DS.

The remaining problem is the bootstrapping, binding the WebAuthn key to the account and user. PayPal once had a system where they sent a dummy transaction to your bank containing an OTP. That doesn't work today, everything must be done in seconds! How can you do that without having the banks onboard? This is effectively credential cloning.

A side effect of this arrangement is that you will need to get a new card clone for each payment provider you encounter.