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: https://github.com/w3ctag/design-reviews/issues/544#issuecomment-904606925
• Mozilla standards-positions issue: https://github.com/mozilla/standards-positions/issues/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.

[mtom55]

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.

The EU Digital Markets Act states:

(Article 5.7) The gatekeeper shall not require end users to use, or business users to use, to offer, or to interoperate with, an identification service, a web browser engine or a payment service, or technical services that support the provision of payment services, such as payment systems for in-app purchases, of that gatekeeper in the context of services provided by the business users using that gatekeeper’s core platform services.

(Article 43) Gatekeepers should therefore not use their position to require their dependent business users to use any of the services provided together with, or in support of, core platform services by the gatekeeper itself as part of the provision of services or products by those business users. In order to avoid a situation in which gatekeepers indirectly impose on business users their own services provided together with, or in support of, core platform services, gatekeepers should also be prohibited from requiring end users to use such services, when that requirement would be imposed in the context of the service provided to end users by the business user using the core platform service of the gatekeeper. That prohibition aims to protect the freedom of the business user to choose alternative services to the ones of the gatekeeper, but should not be construed as obliging the business user to offer such alternatives to its end users.

(57) The gatekeepers should, therefore, be required to ensure, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same operating system, hardware or software features that are available or used in the provision of its own complementary and supporting services and hardware. Such access can equally be required by software applications related to the relevant services provided together with, or in support of, the core platform service in order to effectively develop and provide functionalities interoperable with those provided by gatekeepers. The aim of the obligations is to allow competing third parties to interconnect through interfaces or similar solutions to the respective features as effectively as the gatekeeper’s own services or hardware.

Under this law and similar laws/regulations that will likely be adopted worldwide forcing users to use ApplePay won't be legal (including by not providing APIs needed to interact with other payment systems).

The key takeaways are:

1. Apple should collaborate to provide support for third-party payment systems via the Web
2. Other browser vendors can lodge complaints via their legal teams to the EC once the enforcement date has passed if this doesn't happen

[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...