Secure Payment Confirmation (SPC)

[marcoscaceres]

Request for position on an emerging web specification

• WebKittens who can provide input: @dcrousso @marcoscaceres

Information about the spec

• Spec Title: Secure Payment Confirmation (SPC)
• Spec URL: https://w3c.github.io/secure-payment-confirmation/
• GitHub repository: https://github.com/w3c/secure-payment-confirmation/
• Issue Tracker (if not the repository's issue tracker):
• Explainer (if not README.md in the repository): https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md

Design reviews and vendor positions

• TAG Design Review: Secure Payment Confirmation w3ctag/design-reviews#544 (comment)
• Mozilla standards-positions issue: Secure Payment Confirmation mozilla/standards-positions#570

Bugs tracking this feature

• WebKit Bugzilla:
• Radar:

Anything else we need to know

Over on webkit-dev, @stephenmcgruer wrote:

I am seeking WebKit's position on the Secure Payment Confirmation Web API currently under development in the Web Payments Working Group.

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 current risk analysis approaches that rely on data collection.

[ianbjacobs]

Thanks @marcoscaceres!

[othermaciej]

This seems to have a some overlap in purpose with Payment Handler API. But it's not an extension of it. Why does the web platform need two different ways for payment providers to hook into PaymentRequest?

Separately, for Apple ports our policy has been to only support the ApplePay PaymentRequest method to minimize user confusion and make sure that PaymentRequest API payments always get the same level of security and privacy protection. We don't ship other PaymentRequest methods or PaymentHandler. We probably wouldn't ship this either for the same reason.

[stephenmcgruer]

Hi @othermaciej , thanks for the feedback!

This seems to have a some overlap in purpose with Payment Handler API. But it's not an extension of it. Why does the web platform need two different ways for payment providers to hook into PaymentRequest?

I'm curious as to what overlap in purpose you see; would you be willing to expand there?

From my point of view - Secure Payment Confirmation is a browser-provided tool for authentication in a payment context, addressing some needs that payment folks have been unable to get from pure WebAuthn (e.g., support for Dynamic Linking by including the provided transaction amount and other data in the signed assertion). It cannot, nor is it intended to, handle a 'full' payment.

Some confusion may come from the fact that Secure Payment Confirmation is (currently) implemented on top of the PaymentRequest API. There is nothing about Secure Payment Confirmation that intrinsically requires this, however, and the Web Payments Working Group has indeed previously discussed changing the API shape entirely, such as to use navigator.credentials.get() as the entry-point.

(So why is Secure Payment Confirmation currently based on PaymentRequest? I think the answer is "it was the tool we had at our disposal when the project started"!)

Separately, for Apple ports our policy has been to only support the ApplePay PaymentRequest method to minimize user confusion and make sure that PaymentRequest API payments always get the same level of security and privacy protection. We don't ship other PaymentRequest methods or PaymentHandler. We probably wouldn't ship this either for the same reason.

Again noting that Secure Payment Confirmation does not handle payment, and is only an authentication tool, would this concern be addressed by switching away from PaymentRequest as the underlying API basis? For example (and other API choices are definitely possible!), if the entrypoint was instead:

const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: ...,
    ...,
    extensions: {
      payment: {
        amount: { value: '15.00', currency: 'GBP' },
        instrument: { displayName: 'Stephens Card', icon: '...' },
        ..., // etc
      },
    },
  },
});

[ianbjacobs]

+1 to @stephenmcgruer's characterization.

• SPC is not a payment method.
• SPC provides authentication capabilities useful for payments on top of Web Authentication.
• SPC is currently implemented in Chrome as a payment method (for historical reasons) but does not have to be.

Ian

[gsnedders]

Am I right in understanding that the primary goal here is to replace 3-D Secure with something that's browser mediated?

[ianbjacobs]

Hi @gsnedders,

SPC is integrated into 3-D Secure [1]. It does not replace 3-D Secure. 3-D Secure implementations may make use of a variety of authentication methods (e.g., OTP, FIDO, SPC). A Stripe experiment showed that, compared to 3-D Secure using OTP, conversions increased by 8% when using 3-D Secure with SPC.

SPC could also at some point be integrated into other protocols (e.g., EMV Secure Remote Commerce, open banking protocols). Our conversations with those parties (e.g., the Berlin Group, STET, open banking UK) are ongoing.

The primary goal of SPC is to leverage WebAuthn/FIDO for payment authentication.
SPC enhancements intend to help developer satisfy some of the requirements of
the EU Payment Services Directive 2:

• Strong customer authentication (2-factor)
• Cryptographic evidence of user consent for a transaction ("dynamic linking").

For more information, see our explainer:
https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md

I hope that helps,

Ian

[1] https://www.emvco.com/emv_insights_post/what-is-new-with-emv-3ds-v2-3/

[stephenmcgruer]

SPC could also at some point be integrated into other protocols (e.g., EMV Secure Remote Commerce, open banking protocols). Our conversations with those parties (e.g., the Berlin Group, STET, open banking UK) are ongoing.

I would like to make it clear that SPC can, and is being, used outside of any of these protocols (including 3-D Secure) for authentication in the payment space. SPC is just a tool, it is not tied to nor requires any of these payment protocols.

[maceip]

This seems to have a some overlap in purpose with Payment Handler API. But it's not an extension of it. Why does the web platform need two different ways for payment providers to hook into PaymentRequest?

Separately, for Apple ports our policy has been to only support the ApplePay PaymentRequest method to minimize user confusion and make sure that PaymentRequest API payments always get the same level of security and privacy protection. We don't ship other PaymentRequest methods or PaymentHandler. We probably wouldn't ship this either for the same reason.

User confusion doesn't seem to be a problem when merchants switch providers via web iframes mediated by Stripe, Square, etc

Please let me know if there is a document that describes the security and privacy affordances provided by ApplePay, that way we can work together as community to provide innovative alternatives that meet those criteria.

As a global developer it's hard to prioritize iOS because it only supports one web engine (webkit), and only one Payment method (ApplePay), requiring me to spend time writing tests / logic per platform, making universal web development almost as complex as multiplatform native...