- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 27 Jan 2021 16:46:52 -0600
- To: Tom Jones <thomasclinganjones@gmail.com>
- Cc: Web Payments Working Group <public-payments-wg@w3.org>
Hi Tom, We will carry forward your objection to the Director. I have included some comments inline. Ian > On Jan 27, 2021, at 3:24 PM, Tom Jones <thomasclinganjones@gmail.com> wrote: > > I would like to raise a formal objection to the Payment Request API. > > I Thoroughness. The current standard only enables payment from companies that are able to create a browser from the blink core. I’m not sure to understand the comment. Anyone can distribute payment apps that respond to Payment Requests, notably via the Payment Handler API. > Two implementations do exist from web kit and chromium, but these only serve the purposes of the duopoly of Apple and Chromium. Adrian has commented that "Web-based payment handler using open interfaces that can be implemented by anyone else." Which is technically true, but meaningless given the control of the two implementations on the marketplace. I have been informed by members of the WG that implementations for Apple and Google have been accepted as two distinct implementations. I believe that today the Webkit project and the Blink project are independent, both in code base and governance: https://webkit.org/ https://www.chromium.org/blink I welcome input from others on this point. Ultimately the Director makes the decision about implementation experience. As an aside, the Firefox Platform Status [1] lists Payment Request as “in development” although I don’t believe much new development is happening at this time (but I haven’t verified lately). If you are saying that you would like to see more independent browser engine development, I would like to see that as well. [1] https://platform-status.mozilla.org/ > II Fairness: I have been denied access to the group to make my opinions known. Although you are not a formal participant in the group, as this email shows (as well as our commitment to carry it forward to the Director), you have not been denied access to the group. > It has been reported in the press that Apple and Google have conspired to limit competition in advertising with formal, legal agreements, and so should be considered as a single monopoly created specifically in restraint of trade. The current document reinforces this monopoly and must be changed to allow more competition. One goal of Payment Request API (and its companion Payment Handler API) is to enhance the Web to more easily and securely support a wide variety of payment methods. In section 1.1 (Goals and Scope) of the specification we cite as one goal to “[e]nable a payment method provider to bring more secure payment transactions to the web.” As Adrian Hope-Bailie pointed out separately, for the full duration of this project we have engaged with and sought to support a variety of payment method. > The wallet monopoly will extend to other domains as well, that the payment team needs to consider. For example Marshall University basically chose to enforce it on their students as seen in this site. https://www.marshall.edu/it/mobile-id/ > > I propose two changes which are directed at the process, which does not seem to be working for the good of the larger community: > 1. that implementations that go through blink (in particular Webkit and Chrome) only count as a single implementation. The Director will assess the implementation experience we convey in our transition request. > II. that no payment API be approved by W3C that is not implemented in a payment handler that can be accepted by a user without involvement of the browser manufacturers. A few comments here: * Payment Request API is not implemented in a payment handler. * We expect most Payment Handler API implementations to be in browsers. Thus, browser vendors are “involved” in the implementation of that API. * Anyone can create a payment handler that leverages the Payment Handler API. That doesn’t mean that any payment handler can claim to support any payment method, but people can bring payment handlers to the Web for their own payment methods. Thus, companies other than browser vendors can create payment handlers. In addition, in the Android environment, people (who are not browser vendors) can use an Android-specific API to create Android payment apps that respond to Payment Request. I do not know the full set of terms for creating an Android-based payment app, but the goal is certainly to create a vibrant ecosystem. I wish we also had analogous support for both Payment Handler API and an iOS specific API on iOS devices, but we don’t yet have that. Ian [1] https://web.dev/android-payment-apps-developers-guide/ -- Ian Jacobs <ij@w3.org> https://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447
Received on Wednesday, 27 January 2021 22:46:58 UTC