Just want to provide an update. Chrome shipped this experimental API behind Origin Trial in M86 and is working with Stripe to run a production test. Here's a summary: https://www.w3.org/2020/Talks/danyao-spc-20201006.pdf

We would like to turn this into a more formal spec based on Stripe's implementation experience soon. So a TAG feedback of this proposal will be greatly appreciated!

Hi, @plinss, @kenchris, and I each looked at this during our vF2F this week, and I've got a couple basic questions:

1. Is this necessary? Existing payment methods (e.g. Apple Pay) already securely confirm payments. (If it is necessary, how does it interact with existing payment methods which already have secure confirmation built in?)
2. I realize that your explainer already states, in bold, that a fallback mechanism still needs to be designed. That said, it's hard to evaluate the proposal without one. Have you designed a fallback mechanism since filing this request? If so, could you update the explainer with details?

Thanks @hober for the feedback!

1. Is this necessary? Existing payment methods (e.g. Apple Pay) already securely confirm payments. (If it is necessary, how does it interact with existing payment methods which already have secure confirmation built in?)

Yes. Although existing payment methods such as Apple Pay has secure confirmation, form-based checkouts are still more common. This feature enables WebAuthn-based strong authentication for any form-based checkouts. Merchants usually have multiple business reasons to consider when switching from form-based checkouts to payment apps. So I believe it's valuable to add a small primitive to enhance the security of checkout forms in the meantime.

2. I realize that your explainer already states, in bold, that a fallback mechanism still needs to be designed. That said, it's hard to evaluate the proposal without one. Have you designed a fallback mechanism since filing this request? If so, could you update the explainer with details?

With the implementation experience from the pilot, I'm leaning towards leaving the fallback mechanism to the merchant (or PSP who is handing the checkout on behalf of the merchant). So the Secure Payment Confirmation request will simple reject with an error code. I will update the explainer soon, unless TAG sees a concern with this approach.

Just realized that I didn't fully answer the first question:

(If it is necessary, how does it interact with existing payment methods which already have secure confirmation built in?)

Currently Secure Payment Confirmation is designed as a payment method itself, so it does not interact with existing payment methods that have built-in secure confirmation.

Some developers requested that SPC be made into a capability that they can use when building web-based payment handlers using [Payment Handler API][ph] (see SPC & SRC discussion in https://www.w3.org/2020/10/20-wpwg-minutes.html). But this use case needs to be better understood before we can propose a design to incorporate it.

Hi TAG, I have performed an extensive review of SPC. It covers technical issues but also things that may affect adoption: https://github.com/cyberphone/doc/blob/gh-pages/payments/review-secure-payment-confirmation.md#external-review-googlew3c-secure-payment-confirmation-spc

On the technical side, the following may be particularly worth looking into:

• Forcing users giving card numbers in clear to untrusted third-parties like merchants (which for example Apple Pay do not), appears to be incompatible with modern standards.
• The specification does not elaborate on backend requirements, this is supposed to be catered for by the industry. However, AFAICT the SPC Web API which targets merchants, does in most real-world cases in practice require that the entire payment process is outsourced. That the underlying standard (3DS) is covered by a whopping 500 pages of documentation gives an indication of the complexity of this (not researched) part.

I hope that SPC gets a more professional analysis by TAG than its (now finally discontinued) predecessor, the PaymentHandler got: https://lists.w3.org/Archives/Public/www-tag/2017Aug/0001.html

It is important to realize that since the idea of providing an API enabling developers writing compelling payment applications using "pure" Web didn't pan out, we are now about to standardize the opposite, an "application". Unlike most other applications, SPC must (in order to work), be accepted by merchants, payment providers, banks, and last but not least by consumers. The W3C have never done anything comparable before. That banks rarely participate in any kind of open standardization, makes things even a bit more challenging!

@hober @kenchris

Another thing that may be non-obvious is that SPC signs payment request data. Unlike many other signature schemes the requester (merchant) and the consumer (bank) are different entities which adds an additional constraint: the data to be signed must be standardized. Note: this is NOT a problem, this is how payment systems work. What it does say though, is that there is not a lot of leeway here.

Other approaches were suggested early on, but were as can be seen never taken in consideration: https://github.com/w3c/secure-payment-confirmation/issues/32

Due to that I took the liberty creating an alternative where the "backend" architecture (not the exact messaging), is an integral part of the plot:

FIDO Web Pay is essentially a platform independent and open version of Apple Pay.

Yes, creating generally useful primitives like fetch() and creating a payment application for the Web are pretty different tasks. Reminds me a bit of https://www.w3.org/TR/encrypted-media/ 😁

When @danyao requested a review the concept was not described in such a way that people without extensive domain knowledge could possibly "decipher" it. Since the backend interactions and dependencies required by SPC still are not defined, a meaningful TAG review does not seem to be possible to carry out at this stage. CORS and WebAuthn are examples of Web standards that required well-defined service interaction models. @plinss

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 a registration phase and an authentication phase. During the registration 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., challenge for the Webauthn call).
• The merchant calls SPC.
• The user agent displays transaction information in native UX and invites the user to authenticate.
• The merchant 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.

Hi @ianbjacobs I'm sure that the SPC API is as good as it gets including its integration with WebAuthn. That is, TAG has no real work to do if their task is restricted to the draft to be published.

What I'm saying is that the thing you call "backend rails" introduces very strict requirements on merchants which make most of them depend on proprietary checkout solutions provided by Stripe et al. I.e. SPC would rather execute in an outsourced service.

The competitors that build on wallets (there are hundreds of such), do not have such requirements because they don't need direct interaction with banks or card number to bank URLs lookups; all data needed for authorization is in the local credential. 10 billion EMV cards builds on this idea as well.

The user selects an instrument to make a payment

What standard is this based on? I know that Chrome can hold card data.

The merchant (or their payment service provider) reaches out to the relying party to ask "Do you have any SPC credentials for this instrument?"

What is an "instrument" in the case of card payments, if not "a card number in clear"?

@cyberphone,

You wrote: What is an "instrument" in the case of card payments, if not "a card number in clear"?

A card may be represented in a variety of ways, including an opaque identifier provided by a payment service provider and used in card-on-file scenarios. I think the EMVCo PAR may be another option. The main point is that from an SPC perspective it doesn't matter.

In response to "The user selects an instrument to make a payment", you wrote: "What standard is this based on? I know that Chrome can hold card data."

Again, from an SPC perspective it doesn't matter. Some options might be:

• Card on file
• Instrument selection in a JavaScript popup (e.g., some SRC experiences)
• Instrument selection in the Sheet (Chrome implementation of Payment Request)
• Instrument selection in a payment app. (This probably won't work today with SPC, but it's part of the longer-term vision)
• Form-fill

Although instrument display and selection remains a topic of interest to the WPWG, it is not currently part of SPC.

@ianbjacobs I fully agree with this. However, my [essentially only] concern are the things happening before SPC finally is invoked. This part is at least as important as SPC since it is necessary in order to build a system. It also has huge impacts on the UX.

Since this part is (by design) undefined, Google will most likely find it quite challenging writing developer information of the kind they have done for other Web APIs. The only workable solution AFAICT, is referring to the proprietary checkout APIs provided by Stripe, Adyen, Wordline, etc.

It is obvious that Stripe & Co need this flexibility in order to lock-in merchants into their respective worlds. What is not equally clear is if this properly serves the market consisting of a gazillion of consumers, merchants, payment intermediaries, and banks.

It is a pity that none of the other browser vendors have expressed a single word on the WPWG mailing list regarding their support of this project. @wseltzer @sideshowbarker

Bonjour TAG!

I wanted to note that we have now updated our explainer to match the current proposed API shape and to better discuss security & privacy considerations.

As such, we would like to formally request that the TAG take another look at this request, as it looks like the initial review quietly dropped off around late January.

(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

@stephenmcgruer From an "external" perspective I find it strange that only one option was ever considered: Integrating everything related to the user's authorization in a single trusted application have a giant impact on just about every aspect imaginable.

For the W3C the issue is not really the SPC spec., but what the expectations are in terms of adoption. The SPC "predecessor" (PaymentHandler), died due to limited utility compared to native code.

Anyway, the W3C will most likely only get a single shot at this so it better be right! 😁

For the reviewers it might be useful knowing that SPC introduces lots of non-trivial issues like:

• Changes in the WebAuthn access model: https://w3c.github.io/secure-payment-confirmation/#sctn-payment-extension-registration
• https://w3c.github.io/secure-payment-confirmation/#sctn-privacy-probing-credential-ids

Anyway, the by far biggest (but not mentioned) issue, is the reliance on merchant access to bank-related security services which in practice makes SPC out of scope for the majority of merchants who are thus forced to use outsourced "checkout" services. That practically all WPWG members who have publicly given SPC their support are into this kind of business does not come as a surprise.

As a contrast, a properly designed "wallet" disables merchant code from accessing user specific data like card numbers and FIDO authenticators. Only the wallet has access to such data. In addition, a wallet does not need external access to perform user authorization, making a wallet API potentially usable by any merchant, regardless of size.

Don't get me wrong, SPC seems legit as a "vendor" standard/initiative. As an international standard from an organization like the W3C, maybe not.

@torgo @hober @kenchris @hadleybeeman

Fragmentation Issues

The payment market is currently highly fragmented. The "framework" approach will further increase fragmentation which is hardly in the interest of consumers, merchants, and banks. There are no technical reasons for supporting both 3DS and SRC since they in the end accomplish the same thing, albeit in a slightly different way, while security with respect to the user presumably is identical.

Although the opposite (a standardized system for user payment authorizations), would not automatically solve all fragmentation issues, it would be an important step in this direction, as well as clearly establishing W3C/FIDO alliance as a force in the payment space.

We have put it on the agenda for our "f2f" on the week of the 13th. Hope to be able to progress by then.

Thanx @torgo According to the draft: "Secure Payment Confirmation (SPC) is a Web API to support streamlined authentication during a payment transaction".

The competition in the form of mobile native-mode applications like Apple Pay, typically provide "An integrated and unified payment experience".

That is, SPC is underperforming already on the drawing board. That SPC due to its lack of integration also requires at least one magnitude higher complexity of the merchant SW than the competition, doesn't bode well for its adoption by the market.

In fact, the architectural concepts underpinning SPC predates the advent of ubiquitous security hardware and powerful browsers with built-in payment support (which when put together are true game changers).

Since the primary originators behind SPC (Google and Stripe), didn't bother responding to pretty fundamental GitHub issues like

• https://github.com/w3c/secure-payment-confirmation/issues/52
• https://github.com/w3c/secure-payment-confirmation/issues/33
• https://github.com/w3c/secure-payment-confirmation/issues/32
• https://github.com/w3c/secure-payment-confirmation/issues/41

I couldn't resist creating a "challenger" specification and associated PoC to verify that my claims were not pure BS.

Objectives: After more than 25 years with the Web, we still lack an on-line payment authorization system that is:

• Standardized
• Convenient
• Universal
• Platform independent
• Provider neutral
• Secure
• GDPR and PCI compliant
• Optionally also usable at the PoS terminal

The ”humble” goal with FIDO Web Pay is transforming this elusive dream into a reality 😇

@slightlyoff @marcoscaceres @mikewest @domenic @kenchris Since native mobile apps (as I predicted https://lists.w3.org/Archives/Public/www-tag/2017Aug/0003.html) have taken over the payment space while Web (browser) payment technology haven't progressed a single millimeter, this issue is more fundamental than just another API. Maybe the answer is that nobody really cares?

If somebody do care, the combination of FIDO and pre-built payment support in browsers is effectively a new platform. IMO a new platform motivates some kind of research to figure out its true potential, particularly in the light of previous attempts.

Google rather applied this brand new platform to legacy payment architectures that were explicitly designed to not require security HW and/or built-in browser support. It also means that SPC will be competing with existing systems that (once again!) typically are relying on mobile native applications. I recently donated $10 to Wikipedia and they used 3DS (outsourced, of course). My bank's mobile banking app received a notification and I finished the payment with a fingerprint. That is, neither Wikipedia nor my bank have any reasons to be interested in SPC since it doesn't offer anything but additional costs and customer hassles.

Anyway, whatever Web payment solution W3C comes up with, there are no guarantees for success and the need for marketing must not be underestimated. For SPC which is a "framework", this becomes unusually tricky: Who is going to market What and to Whom?

Please don't mention me further; I am not involved in this work.

Additionally, please consider editing your older posts instead of sending a new email to all thread subscribers; so far this thread is mostly consecutive posts from you.

@domenic I mentioned you because you were one of the editors of the previous (now discontinued) effort creating a Web payment API: https://www.w3.org/TR/payment-method-manifest/ BTW, I don't have anything to add for now, all is available in my review :)

@cyberphone, please stop mentioning/emailing me also. We’ve already warned you of your behaviour and we will be left with no choice but to ban you from the W3C community entirely. Please consider this your final warning.

Cc @ianbjacobs

Hello Ian and Marcos, Before you cast me off from the W3C in its entirety, may I finish by briefly describing how SPC works from a User and Merchant perspective, here in a 3DS setting?

User Enrollment

• The User authenticates to their Bank using a bank-specific verification method
• The enrollment process creates a FIDO authenticator and associates that with a card number, credentialId, logotype, etc.
• 👁 After this process the only remaining item on the client side is the FIDO authenticator, the rest is stored on the Bank-server only.

Payment Authorization

• 👁 Through pretty complex communication with external systems, as well as typically also requiring typing card numbers (the key to an account), the Merchant retrieves the previously created Bank-server data.
• SPC is invoked.
• 👁 After the result has been returned to the Merchant, the assertion must be authenticated through a call to a server discovered in the initial step.

Concrete payment methods like Apple Pay and hundreds of lesser-known brands, do not need the steps marked with 👁 since the required data associated with a payment key (authenticator) is stored locally. In addition, authorization data is only signed. Although this may look like a "detail", the consequences of this design choice are HUGE. However, since most of this happens outside of the SPC API, it is probably not an item for TAG. Unfortunately, Users, Merchants, and Banks do not enjoy the same luxury.

Cheers, Anders / leaving this thread 😺

@stephenmcgruer

Thank you for pointing that out, @cyberphone. The suggestion to store the payment account information locally sounds consistent with your comments in W3C channels from the beginning of the SPC project about a year ago, if I recall correctly. Sorry if we have not made it clear that we understood your ideas. They do make sense. However, it's out of scope of SPC as it is defined today.

For process reasons, I'm closing this issue and transferring over to #675.

There is no need to re-post existing comments in the new issue.