Updates on work items formulated in October 2019

Dear Web Payments Working Group,

The Chairs and I had planned to discuss Working Group objectives during the virtual meeting two weeks ago, but in the end favored other topics. We plan now to discuss objectives at our 16 April call:
 https://github.com/w3c/webpayments/wiki/Agenda-20200416

As part of the discussion I'd like to give updates on the work plan [1] that we discussed in October 2019 [2]. Note: I have omitted from the updates below the work item about rechartering the Working Group, which we did in December 2019.

Questions for Working Group Participants:

 a) Do you have any relevant updates to share?
 b) What other work items should we now be pursuing?
 c) Are you available to help work on some of these?

Thank you,

Ian

[1] https://github.com/w3c/webpayments/wiki/WPWG-Plan-2019
[2] https://www.w3.org/2019/10/17-wpwg-minutes#item03

========================
Interoperability objectives

1. Specifications

  a) Payment Request 1.0 advances to Proposed Recommendation

     Payment Request 1.0 is stable and our implementation report shows strong interoperability between the Chromium browsers and Webkit. As we discussed in September [3] we are awaiting more adoption before requesting to advance PR API along the Recommendation track.

  b) SRC payment method advances to FPWD

     The Card Payment Security Task Force has made good progress on an architecture for SRC through PR API [4]. The next steps involve assessing whether there is consensus among the card networks [5] for this approach. If so, development of a Proof of Concept would then validate the approach, after which we would begin work on a payment method specification.

2. Payment Handlers

  a) All major browsers add support for payment handlers (through PH API or other proprietary API)

     Right now Chromium browsers support Payment Handler API. We discussed a variety of proposals [6] for improvements to the API (and implementations) at our recent virtual meeting. Discussions continue with Mozilla regarding support for payment handlers.

     Last November we reviewed a proposal for a "modal window" [7] approach that was more general than Payment Handler API. At this time, however, there does not seem to be broad support for adopting that more general approach.

     Many of the recent proposals to improve payment handlers (and thus increase their value and drive support by browsers) were the result of a Chrome-led privacy analysis [8]. We also expect to benefit from a master's thesis security analysis [9].

3. Security 

  a) Web Authentication works for payments use cases

     We formed the joint task force of the Web Authentication WG and the Web Payments Working Group [10] to meet this objective. The task force discusses payments use cases to inform the work of the Web Authentication WG. We have also discussed publishing educational materials to help the payments industry with adoption of Web Authentication.

     The Web Authentication WG recently made a decision to allow get() of Web Authentication credentials from a cross-origin iframe, which is one of the use cases that the WPWG had expressed.  This decision for Web Authentication Level 2 should improve the user experience in scenarios such as 3-D Secure where an issuing bank wishes to FIDO authenticate a user without requiring a full-page redirect to the issuing bank's Web site.

     In addition, we launched the Web Payment Security Interest Group with FIDO and EMVCo, which also holds higher level discussions about the interoperability of relevant specifications.

========================
Adoption Objectives

1. Payment handlers

  a) Major payment service providers experiment with a Payment Handler

     We are aware of a number of experiments from payment service providers with payment handlers. Some of these experiments have led to changes in the Chrome implementation and Payment Handler API.

  b) Organize code-a-thons in the Bay Area and Europe.

     For timing reasons chose to organize our first code-a-thon in Dublin, but it was canceled due to COVID-19. We expect to reschedule it as a virtual event, but have not yet planned it.

  c) Publicize payment handler benefits

     We have progressed on this through two blog posts: "Payment Handler Value Proposition" [11] and "Working with canMakePayment and hasEnrolledInstrument" [12].

2. Platforms

  a) Gain support by two more PSP platforms for Payment Request API natively.

     W3C staff has organized several discussions with platform providers. Although there is interest, at this time there are no public experiments to report.

3. Merchants

  a) Publish adoption trend data

     We requested adoption data from Stripe and Google. No update so far.

  b) Launch a Merchant Business Group

     W3C staff has developed a charter for a Merchant Business Group that we anticipate will launch by mid-2020.

  c) Compile a list of features required for a MVP (POC)

     No progress.

  d) Create resources for merchants to easily create superior checkout
     experiences

     No progress. We had anticipated that the code-a-thon might help us develop some of this material.

  e) Socialize these resources and the technology with more merchants

     No progress.

4. Users

  a) Reduce user surprise in the UX

     The Shopify study [13] indicated that the browser sheet surprised some users. The Chrome team in particular has been investigating how to move away from the sheet and increase the number of scenarios where the browser can "skip-the-sheet". This effort has resulted in changes to Chrome to support delegation of collection of shiopping address and other user data to payment handlers [14]. It has also led to proposals [6] to clarify, harmonize, and increase skip-the-sheet behavior.

     Thus, the primary actions being taken to reduce surprise involve deprioritizing the sheet.

     The Chrome team continues to do research to improve the Payment Request UX.


[3] https://www.w3.org/2019/09/05-wpwg-minutes#item02
[4] https://github.com/w3c/src/wiki/ProposedArchitecture
[5] https://lists.w3.org/Archives/Public/public-payments-wg/2020Apr/0009.html
[6] https://github.com/w3c/payment-handler/wiki/2020-Mar-proposed-changes
[7] https://github.com/adrianhopebailie/modal-window/blob/master/explainer.md
[8] https://w3c.github.io/webpayments/proposals/privacy-threat-model.html
[9] https://lists.w3.org/Archives/Public/public-payments-wg/2020Apr/0000.html
[10] https://github.com/w3c/webauthn-pay/wiki
[11] https://www.w3.org/blog/wpwg/2019/10/29/payment-handler-value-proposition/
[12] https://www.w3.org/blog/wpwg/2020/01/17/working-with-canmakepayment-and-hasenrolledinstrument/
[13] https://engineering.shopify.com/blogs/engineering/shaping-the-future-of-payments-in-the-browser
[14] https://github.com/w3c/payment-handler/issues/337

--
Ian Jacobs <ij@w3.org>
https://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447

Received on Wednesday, 15 April 2020 17:23:16 UTC