Secure Payment Confirmation (heading to Candidate Recommendation)

[ianbjacobs]

Wotcher TAG!

I'm requesting a TAG review of Secure Payment Confirmation, which is heading soon to Candidate Recommendation.

Specification:
https://w3c.github.io/secure-payment-confirmation/

Explainer:
https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md

Updated security/privacy questionnaire:
https://github.com/w3c/secure-payment-confirmation/blob/main/security-privacy-questionnaire.md

The TAG's previous positive review was recorded on 14 February 2022:
#675 (comment)

We are now preparing to advance the document to CR (mid-September 2022).

Here are the diffs to the document since your February 2022 results:
https://github.com/w3c/secure-payment-confirmation/compare/8c18586..ac828cb2#diff-6f5a1d8263b0b0c42e2716ba5750e3652e359532647ac934c1c70086ae3cedda

(Sorry, the diff includes multiple files; please see the diffs at the end for spec.bs)

Further details:

• Relevant time constraints or deadlines: We would like review comments by 16 September 2022.
• The group where the work on this specification is currently being done: Web Payments Working Group
• Major unresolved issues with or opposition to this specification: None at this time

We will be at TPAC 2022 and welcome discussion then of any new substantive issues you uncover.

We'd prefer the TAG provide feedback as (please delete all but the desired option):
☂️ open a single issue in our GitHub repo for the entire review

[torgo]

Thank you for this review request and for the comprehensive information you've put together in the explainer. As we've previously positively reviewed Payment Request and Web Authentication we're happy to see these being brought together to make the web payment user flow easier. The use cases and user needs are well documented. It's also great to see the results of the experiment written up here.

Regarding the design choices you've made to implement this as a payment method: we're concerned that this may be confusing to developers. Would the alternative approach (navigator.credentials.get()) be better from a developer ergonomics PoV? If so, it may be worth the effort to coordinate with the webauthn working group.

Regarding the privacy risks enumerated at the end of the explainer, can you include more specific mitigation advice for implementers on how to mitigate against these potential attacks?

[ianbjacobs]

Hi @torgo,

Thank you and the TAG for the additional review/questions.

I take your first point (on navigator.credentials.get()) to mean "Does SPC have to be based on Payment Request API?" The Working Group has an open issue on that topic [1]. Organizations conducting pilots or building demos (e.g., that integrate with 3-D Secure) have not indicated that the current API shape poses challenges. We have also heard from two browser vendors that there are advantages to leveraging Payment Request API. Having said that, there are also advantages to moving away from Payment Request, such as the ability to use SPC within a payment handler. Having discussed these considerations (including timeliness) the current Working Group consensus is that for version 1 we prefer to stick with the Payment Request API approach.

Thank you for the review of the explainer. As a result of PING review of SPC earlier this year we made some changes to the specification (including being more specific about mitigations) but we did not update the explainer at the same time. Your comment today prompted the Editors to update the explainer with the same improvements found in the specification; see this pull merged request:
w3c/secure-payment-confirmation#213

And the updated explainer privacy considerations:
https://github.com/w3c/secure-payment-confirmation/blob/main/explainer.md#privacy-considerations

Please let me know if these improvements satisfy your concerns, or if you have other suggestions. Thanks again!

Ian

[1] w3c/secure-payment-confirmation#56

[torgo]

Hi Ian - This looks great. Thanks for taking our feedback on board. We're happy with the trajectory this is on so we're going to close on that basis.