Secure Payment Confirmation - Part 2

[plinss]

(Just realized that the OP is now out of date too and I don't have edit rights, so posting a new version here. Please feel free to request that I open a new issue if that's easier!)

I'm requesting a TAG review of Secure Payment Confirmaton.

Secure Payment Confirmation (SPC) is a proposed Web API to support streamlined authentication during a payment transaction. It is designed to scale authentication across merchants, to be used within a wide range of authentication protocols, and to produce cryptographic evidence that the user has confirmed transaction details.

SPC adds payment-specific capabilities atop WebAuthn and is designed with stronger privacy protections than risk analysis approaches that rely on data collection.

• Explainer¹: https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md
• Security and Privacy self-review²: https://github.com/w3c/secure-payment-confirmation/blob/main/security-privacy-questionnaire.md
• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/secure-payment-confirmation/
• Primary contacts (and their relationship to the specification):
  • Stephen McGruer (stephenmcgruer), Google Chrome
  • Rouslan Solomakhin (rsolomakhin), Google Chrome
  • Ian Jacobs (ianbjacobs), W3C
• Organization/project driving the design:
  • Web Payments WG
  • Google
  • Stripe
• External status/issue trackers for this feature: https://chromestatus.com/feature/5702310124584960

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): Joint Task Force of Web Authentication and Web Payments Working Groups (no longer current)
• The group where standardization of this work is intended to be done ("unknown" if not known):
  • Web Payments Working Group
  • WebAuthn Working Group (advisory)
• Existing major pieces of multi-stakeholder review or discussion of this design:
• Major unresolved issues with or opposition to this design: N/A
• This work is being funded by: N/A

You should also know that... N/A

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Originally posted by @stephenmcgruer in #544 (comment)

[webpki]

Editor’s Draft, 9 September 2021:

An additional benefit of this feature to Relying Parties is that they no longer need to build their own front-end experiences for authentication. Instead, payment service providers are likely to build them on behalf of merchants.

The latter has a technical explanation: due to its architectural origins (3DS and WebAuthn), SPC does in practice rather mandate outsourcing, except for a limited set of big merchants.

The root of this requirement is that SPC by design leaves everything related to payment instrument (e.g. card) discovery and selection as well as locating issuing bank, to the market to figure out, and in a provider specific way, as outlined in the draft's sample session:

The merchant communicates out-of-band with the issuing bank of the payment instrument (e.g., using another protocol).

This differs from native mode mobile "wallets", which by design usually have quite modest (and unlike SPC, documented) requirements for merchant integration. This is due to the fact that these applications build on a uniform and integrated payment experience which also makes "backend" support straightforward. That is, these systems do not depend on OOB communication using another protocol. In fact, there is no interaction whatsoever with issuing banks during the user's part of a payment authorization process.

That Relying Parties (banks) are eager outsourcing the "front-end experiences" to third parties, is not a universal truth. Current offerings as well as high profile projects like the European Payments Initiative rather point in the opposite direction.

According to the draft, SPC is

...to be used within a wide range of authentication protocols

which does not easily translate into real-world terms, since no examples have been provided. Given that current systems are all over the map, it seems like a pretty bold statement as well.