Web Payments Working Group

Doodle for FTF meeting planning

<Ian> Doodle

Pain Point Analysis

<Ian> Heat Map

<scribe> scribenick: nicktr

<Ian> Rough consensus:

ian: goal of the pdf was to show where there was consensus

<Ian> ====

<Ian> Speed up checkout

<Ian> Reduce auth friction

<Ian> Account-free payment

<Ian> Reduce sharing card numbers

<Ian> ====

<jv> having issues with webex

ian: I thought we could refine the view
... on the call

<Ian> IJ: Is there anyone who wants to strongly push for one quadrant or the other?

<Ian> Heat Map

<Ian> IJ: For "Pain point 5: Lower risk/cost of securing user data" everyone thought it was important

<Ian> ...should we add that to the list?

<Ian> Heat Map

<Ian> IJ: For "Pain point 8: Lower PCI burden of payment page"

<Ian> ...everyone thought it was important

<Ian> IJ: Next steps - evaluate consensus points wrt our existing work; add to work streams areas where we think there is importance but not yet doing anything.

<Ian> Ryan: Secure data keeps coming up for us; mentioning in charter would be great

<Ian> Original deck

<Ian> For "Pain point 5: Lower risk/cost of securing user data"...where is the biggest pain point?

<Ian> ..is it in storage?

<Ian> ...or just receiving data?

Work Plan

<Ian> Draft plan

ij: this is a sketch which we hope will become more concrete
... on the scope - three categories:
... 1) adoption
... 2) rechartering
... 3) interoperability
... I propose we wait until we have the draft charter in front of us before we discuss
... interop - we need to advance payment request and PMMs
... we should get the same for payment handler but the mechanism may not be advancing the spec
... delegation of security is an emerging important topic
... e.g. for SRC - both card data and instrument listing
... for adoption, it would be really great to have more access to more payment handlers. AirBnB suggested AliPay, WeChatPay and other and get more experimentation
... a hackathon (or similar) might help us forward
... to get handler developers talk directly to merchants
... potentially in the bay area in January

<Zakim> rouslan, you wanted to say adoption is important

Next FTF meeting

<Ian> Doodle

Review other actions

<Ian> https://www.w3.org/2019/10/03-wpwg-minutes

<Ian> https://github.com/w3c/webpayments/wiki/Agenda-20191003

<Ian> https://discourse.wicg.io/t/proposal-modal-window/3982

<Ian> IJ: Any feedback yet from the TAG?

<Ian> rouslan: Not yet from the TAG, but I did speak with the Portals engineers since there is some overlap in architecture;

<Ian> ...they gave some good feedback that I incorporated into the explainer

<Ian> ..they said don't make the modal window ONLY a popup enhancement

<Ian> ...there are a lot of legacy assumptions about popup behaviors related to what the parent window can do

<Ian> ...so we are taking the example of Portals and exposing only a thin interface to communicate between the modal window and the parent

<Ian> ...the functionality is still the same from our payment handler perspective

<Ian> IJ: Who is the parent window in the case of a parent window?

<Ian> Rouslan: There is none in the case of a payment handler

<Ian> ..only payment request event is means of communication between merchant and payment hadnler

<Ian> IJ: Why was legacy behavior relevant?

<Ian> Rouslan: We've written the explainer by taking popup examples and replace window.open with window.openModal

<Ian> ..which makes it look like we are exposing the same interface as window.open (that is, popups)

<Ian> ...we want to make clear that this is NOT window.open

<Ian> ...the parent window of a popup can navigate a popup...and if the popup is from the same origin as the parent then the parent has synchronous access to the DOM of the popup

<Ian> ...and the parent can modify the DOM and get objects and modify them

<Ian> ...whereas with modal we want to host the modal in another process, which is different from popup expectations

<Ian> Modal window explainer

<Ian> IJ: Would it make sense to have a table or FAQ of diffs between popups, portals, modal....?

<Ian> Rouslan: Might indeed benefit from more detailed analysis

<Ian> ----

<Ian> other actions to review...no progress

<Ian> (AdrianHB to propose alternatives to the payment sheet and evaluate the impact of these on different use cases)

<Ian> ----

<Ian> (Ian to work with Justin and Google on writing up payment handler benefits)

<Ian> IN PROGRESS

<Ian> ----

<Ian> (Jeremy to see whether Stripe could provide any data about PR API)

<Ian> [No news]

<Ian> ----

<Ian> (Justin to check internally at Google about what adoption data can be shared)

<Ian> [No news]

<Ian> ----

<Ian> (Tony Nadalin to convene a joint task force on payment use cases that involve Web Authentication)

<Ian> IN PROGRESS..expect more info at next meeting

<Ian> ----

<Ian> (Chairs and Team Contact to draft a new charter)

<Ian> IN PROGRESS...next meeting

Next meeting

<Ian> 31 October