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.

[torgo]

@ianbjacobs @stephenmcgruer can you give us some info on implementations? Chrome status says no signals from Firefox or Webkit?

[ianbjacobs]

@torgo, I don't have any public signals yet from Webkit or Firefox. Still working on that and encouraged by recent TPAC discussions.

[cyberphone]

 
https://www.apple.com/apple-pay/
"And when you pay, your card numbers are never shared by Apple with merchants"

https://www.w3.org/TR/2021/WD-secure-payment-confirmation-20210831/
"However in order to obtain them from the Relying Party, the merchant already needs an as-strong identifier to give to the Relying Party (e.g., the credit card number)"

[cyberphone]

Chrome status says no signals from Firefox or Webkit?

The crucial part is rather getting banks involved since SPC depends on their cooperation. However, supporting SPC is likely to be a board level question since most banks already have deployed solutions for the only readily available use case, 3DS.

[ianbjacobs]

To correct a comment above, SPC does not depend on bank cooperation. SPC would most certainly benefit from bank cooperation, but SPC can be deployed in a variety of ways with a variety of benefits.
In a given payment system there may be an "optimal" relying party (e.g., the bank for 3DS, or the card network for SRC). But there may be other relying parties (e.g., PSPs) given other rules and practices (e.g., delgation) in the ecosytem.

[stephenmcgruer]

@stephenmcgruer can you give us some info on implementations? Chrome status says no signals from Firefox or Webkit?

@torgo - As Ian noted, we have no public signals currently. You may already have seen this from Chromestatus, but here are the relevant request-for-comments:

• Mozilla
• WebKit

Neither have replies. An engineer from Apple did attend the WPWG TPAC sessions and stated that SPC is interesting but that Apple has no opinion on it yet. (I can provide links to the minutes if you want.)

[hadleybeeman]

Hi, @ianbjacobs and @stephenmcgruer. We (@rhiaro, @kenchris and I) are looking at this in our W3CTAG face-to-face. We are scrambling to follow the information flows in the explainer (perhaps a diagram would be a clear way to communicate this?), and to see how this works from a user's perspective (especially the registration process). Would it be possible to address those in the explainer?

Also, it seems like the explainer assumes a strong familiarity with webauthn, which seems complicated in light of the ongoing work with them. It would help us a lot if you explain in plain English how you see those working together, again especially from the user's perspective.

And finally, for our notes: we are reassured to see how much you're focused on privacy, based on the issues in your repo and the thorough Security and Privacy questionnaire responses. That's important in this area and we're pleased to see how much emphasis you are giving to it.

[ianbjacobs]

Hi @hadleybeeman,

Seeking clarification: does the current diagram [1] need improvement?

The following videos from Adyen may also help illustrate user experiences:
Registration: https://www.w3.org/2021/10/adyen-spc-reg.mov
Authentication: https://www.w3.org/2021/10/adyen-spc-auth

(For more context on those videos and links to accessible descriptions, see [2].)

Regarding the relationship between SPC and Web Authentication, there are three main differences:

• With Web Authentication, only the RP can use their own credentials. With SPC, other parties can initiate authentication ceremonies with those credentials as well, but with accompanying UX. This difference from Web Authentication is mentioned here in the spec: https://w3c.github.io/secure-payment-confirmation/#sctn-authentication
• With Web Authentication, one can ask an authenticator to sign client data. With SPC, there is built-in support for signing transaction specific data, which is displayed by the native user experience. This is described here in the spec: https://w3c.github.io/secure-payment-confirmation/#sctn-collectedclientadditionalpaymentdata-dictionary
• Finally, with Web Authentication Level 2 it is not possible for an RP to create a credential in a cross-origin iframe. With SPC it is possible. We are in ongoing discussions with Web Authentication folks about whether that capability should be available generally within Web Authentication. Indeed, Web Authentication Level 2 allows create() in a cross-origin iframe following discussions about payments use cases.

From a user experience perspective, the authentication ceremony is the same (I believe) between Web Authentication and SPC. With SPC, there is a payment confirmation dialog that precedes the platform's authentication dialog.

I hope this helps; happy to join a call if that would be useful.

[1] https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md#proposed-solution-secure-payment-confirmation
[2] https://www.w3.org/blog/wpwg/2021/11/08/tpac-recap-2021-edition/

[cyberphone]

@hadleybeeman

And finally, for our notes: we are reassured to see how much you're focused on privacy, based on the issues in your repo and the thorough Security and Privacy questionnaire responses. That's important in this area and we're pleased to see how much emphasis you are giving to it.

It is worth noting that the most obvious privacy object related to payments (card numbers), haven't been dealt with:
#675 (comment)
@wseltzer

Apple Pay and other state-of-the-art solutions which effectively are competing with SPC, do not have this problem since they build on another concept, that also brings many other improvements to the table including greatly reduced complexity. There are no technical hurdles adopting this time-proven concept by SPC.

Another side effect of not handling payment instrument data, is that SPC users must usually still carry their physical payment cards. For A2A payments which is what the banks in the EU target, this becomes a veritable showstopper since these systems doesn't come with cards.

[torgo]

Hi @ianbjacobs – it's not clear to me if the web site (or another party) would, in the context of this transaction, be privy to information about the authentication mechanisms on the client which might give them more info about the end user than the user would expect to be sharing? For example - would the web site know that a biometric dialog had been shown to the user? What if the user chose to dismiss that dialog and opt for another authentication mechanism? In other words - they click "cancel" on the dialog box below? Would the web site be able to detect that?

[ianbjacobs]

Hi @torgo,

The specification speaks to this:
https://w3c.github.io/secure-payment-confirmation/#sctn-privacy-probing-credential-ids

Specifically:

"Implementors of Secure Payment Confirmation must make sure not to enable malicious callers (who now may not even be the Relying Party) to distinguish between these cases: (1) A credential is not available. (2) A credential is available, but the user does not consent to use it."

I think that speaks to your question about detectable "cancel." Let me know if I have not. Thanks!

Ian

[plinss]

I expect this is likely covered somewhere, but I'm missing it. The spec/explainer talks mostly about the merchant, customer, and account provider, and only briefly mentions payment processors.

When I've built e-commerce sites, I've always interfaced directly with a single payment processor, and never directly with an account provider. I believe this approach to be very common (at least in the US) and want to make sure that this has little friction both for the user and developer.

As a customer, I'm fine with registering an authentication mechanism with my account provider (either the bank directly or the credit card company). If the site I'm trying to make a purchase at is using a payment processor, will the payment processor be able to contact the account provider to authenticate me (I accept the back-channel communication is likely outside the scope of the spec) or will the site need to talk directly to the account provider? or will I as a customer need to re-register my authentication mechanism with the payment provider? (and presumable every new payment processor I encounter?)

[ianbjacobs]

Hi @plinss,

I talked about this topic a bit in a blog post:
https://www.w3.org/blog/wpwg/2021/10/06/spc-design-choices-for-flexibility-and-scale/

In short:

• In practice we are likely to see a variety of solutions with different relying parties.
• Solutions where the account provider is the relying party are likely to most closely approach "register once, reuse credentials easily everywhere." We certainly hope to support that model but it might require time for service providers to integrate SPC into their solutions.
• In the Stripe and Adyen pilots, on the other hand, the PSP is the relying party. The user registers credentials with the PSP and the PSP uses SPC at transaction time. How the PSP then works with the account provider regarding risk assessment is outside the scope of SPC. EMVCo and FIDO have published, for example, a paper on leveraging FIDO authentication in a delegated model: https://fidoalliance.org/technical-note-fido-authentication-and-emv-3-d-secure-using-fido-for-payment-authentication/

Thus:

• In the "issuing bank is the relying party" model there should be one registration and lots of reuse.
• In the "delegated to the PSP model" there should be one registration per PSP, and the PSP would communicate with account provider.

I hope that helps,

Ian

[cyberphone]

It is worth pointing out that the model (apparently) used in the Stripe and Adyen pilots effectively make them issuers of cloned payment credentials. It would be interesting to know how this cloning is performed in order to achieve the necessary binding between the payer and his/her bank account. AFAIK, delegated authentication requires a contractual arrangement as well.

As a (European) user of 3D Secure since more 10 years back, I have yet to encounter an e-commerce site where the bank has been taken out of the equation. My current banks (one in France and one Sweden), use their respectively mobile banking app for the authentication/authorization step. According to the European banking regulator, over 90% of the banks have deployed SCA (Strong Customer Authentication).

There is also a bunch of systems out there including Apple Pay, which build on concepts that have virtually nothing in common with 3D Secure and SPC. The differences affect core issues including UX, privacy, and last but not least, backend integration.

[ianbjacobs]

@cyberphone,

• I don't know what "cloned" means. The Adyen experiment involves a delegation agreement. SPC can (presumably) be used in that scenario. SPC can also be used in non-delegation ceremonies.
• I don't know what you mean when you say "the bank is taken out of the equation." The delegation agreements that I understand to be part of the Adyen experiment presumably involved all the parties that need to be part of the process.

Your discussion of "a bunch of systems" does not seem directly relevant to SPC.

[torgo]

Hi @ianbjacobs - thanks for all the great responses and engagement. The TAG is happy to close this review positively. I hope our feedback has been useful. I hope that further conversation on the additional issues raised here can be carried on in the appropriate working group forum.

[ianbjacobs]

Hi @torgo,

Many thanks to all of the TAG for the thoughtful review. We will continue to work through issues, horizontal review, and cross-browser support.

Ian

[cyberphone]

@ianbjacobs

• Delegated authentication probably requires having a copy of card data. Copying and "cloning" are often used interchangeably.
• With "taking the bank out of the equation" I simply meant that the bank is not directly involved in the authentication process.
  https://www.w3.org/2022/02/16-wpwg-minutes
  Herve: In some cases, people already have 2-factor mechanisms and don't want to implement a new architecture

It is a pity that nobody have bothered describing the delegation concept in more detail.