W3C

Web Payments Working Group

22 June 2023

Attendees

Present
Amine Khalfaoui (Worldline), Anne Pouillard (Worldline), Arman Aygen (EMVCo), Arnaud Crouzet (FIME), Bastien Latge (EMVCo), Clinton Allen (American Express), David Benoit, Doug Fisher (Visa), Franck Delache (Shopify), Gerhard Oosthuizen (Entersekt), Ian Jacobs (W3C), Jean-Luc di Manno (FIME), Jeff Owenson (Discover), Joel di Manno (FIME), John Bradley (Yubico), Jorge Vargas (Discover), Michael Horne (American Express), Nick Telford-Reed, Praveena Subrahmanyam (Airbnb), Rolf Lindemann (Nok Nok), Rouslan Solomakhin (Google), Sameer Tare (Mastercard), Stephen McGruer (Google), Suzie Annezo-Sébire
Regrets
-
Chair
Nick
Scribe
Ian, nicktr

Meeting minutes

TPAC Planning

Registration is open.

Status of SPC CR

* CR Published. Many thanks to the editors and also to the Members who providedtestimonials for the press release.

ian: Last week we published a CR "snapshot" - a version in a moment of time. But we have already started to fold in pull requests. These pull requests do not yet reflect the consensus of the WG and they have not undergone horizontal review. The published version of the specification now bears the label "Candidate Recommendation Draft." In order for us to move through the rest of the W3C process, we will need to get review of the delta since the most recent snapshot.

ian: We folded in a pull request for the previously discussed API "isSPCAvailable?"

ian: at some point, we will go back through CR to achieve horizontal review and CFC
… and then when we have a second implementation, we will be in a position to advance to REC

<Ian> Ian: We merged w3c/secure-payment-confirmation#233

<Ian> Stephen: We expect to ship isSecurePaymentAvailable in Chrome 117

<Ian> ...stable in early September

ian: any questions on the status ?

ian: as an aside, the W3C adopted its new process last week

<Ian> https://www.w3.org/2023/Process-20230612/

ian: this is first version of process without roles for the Director (Tim Berners-Lee), including the role of deciding formal objections.

ian: we have been through the formal objection process handled by a council (which was a "beta") and it is now the norm

Status of Charter review

ian: Shortly before the end of the charter review period, we got a formal objection
… we can continue to work (our charter is good through Dec 24)
… staff must now initiate the process to review the formal objection
… it was not made public so only members can see the objection in the AC review results.

ian: we will create a team report, which the council will review (ian shares an example of a previous report)

ian: councils have been working to improve their efficiency.

clinton: could you say more about the objections?

ian: First let me say that there were also some editorial suggestions from other Members.

ian: FIME suggested it would be helpful for the group to work on UI requirements

ian: Jean-Luc and I chatted. I have prepared a response.

ian: I will write up the history of the objections for the council

ian: if anyone wants more detail - please contact Ian

ian: the big q: how long will this take to resolve? a: we hope well before TPAC

Payment Request pull requests

User activation

smcgruer_[EST]: Recall that Payment request requires a "user activation".
… the user needs to have interacted with the page recently
… we've heard that this restriction can be problematic, notably in redirect flows
… imagine a site that aggregates merchants
… the aggregator might redirect the user to a specific merchant, and the merchant doesn't want to force the user to interact with the site again
… we spoke a lot with our security/privacy team internally and our conclusion in Chrome is that the use cases are worth the (small) risk
… pull request 1009 changes PR API to not require user activation (though user agent MAY require a user activation)

Ian: How will SPC change?

smcgruer_[EST]: We eventually will change the spec, but no behavioral change

<SameerT> +1

nicktr: Can you speak a bit to the risks?

smcgruer_[EST]: We have, in general, been looking at what user activation protects against. My understanding is that it doesn't protect against much, in part because it's trivial to get a user to interact with your page in some capacity.
… but user activation protects against two things (1) spam
… for example, we saw good results from making popups subject to user activation
… we have mitigations around Payment Request to not allow repeated calls to the API. You get "one for free" and afterwards require user activations
… (2) the second big risk is phishing
… we have a standard anti-clickjacking mechanism to prevent against this

nickTR: From a user activation perspective...the user activaltion in PR API is in the modal. Is user activation within the modal, or anywhere on the site?

smcgruer_[EST]: The user activation is pre-modal

Ian: Can you do user activation through Web Driver?

smcgruer_[EST]: Web driver not active for users. And it cannot be activated within a page; it is triggered externally.

Proposal: Update Payment Request API to allow but not require user activation prior to show().

<nicktr> +1

<Anne> +1

[Versioning and other pull requests]

https://www.w3.org/TR/payment-request-1.1/

https://w3c.github.io/payment-request/

ian: options: mark as non-normative, put in V1.1, <did I miss one>

ian: we know Marcos would prefer the former

ian: I am scheduling a meeting with the spec editors and then we will revert to the group

ian: questions?

rouslan: In Chrome, we also prefer unversioned specs

smcgruer_[EST]: We generally care about the Editor's draft most

ian: we will have to address both the privacy and 118n implications if we reintroduce addresses

Mozilla Developer Network

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

ACTION: Nick to work with Ian and editors on MDN data related to SPC

Next meeting

20 July

Summary of action items

  1. Nick to work with Ian and editors on MDN data related to SPC
Minutes manually created (not a transcript), formatted by scribe.perl version 210 (Wed Jan 11 19:21:32 2023 UTC).