Re: Progressing "PaymentRequest" to TR

Hi Tom,
Chrome's and Safari's (and Mozilla's) implementations are all open source. 

Apple's Implementation:
https://github.com/WebKit/webkit/tree/master/Source/WebCore/Modules/paymentrequest

Including the ApplePay Payment Handler:
https://github.com/WebKit/webkit/tree/master/Source/WebCore/Modules/applepay/paymentrequest
 
Chrome:
https://chromium.googlesource.com/chromium/src/+/ffe65028319b24fe413809cdf6048d7936e252c3/third_party/blink/renderer/modules/payments/

Mozilla:
https://github.com/mozilla/gecko-dev/tree/master/dom/payments

To reiterate what Ian stated, there is no requirement in the W3C Process that the implementations be open source (though thankfully they all are!). The requirement is that they be interoperable by virtue that they pass the official test suite, which again all implementations do - except for a tiny handful of tests, which we are working on fixing.  

Kind regards,
Marcos 


> On 17 Nov 2020, at 9:49 am, Tom Jones <thomasclinganjones@gmail.com> wrote:
> 
> Well then I would like to make it clear that I consider that step to be in restraint of trade. If the W3C does that for the web payments, I intend to report that action to the FTC as monopolistic.
> Peace ..tom
> 
> 
> On Mon, Nov 16, 2020 at 11:24 AM Ian Jacobs <ij@w3.org> wrote:
> Tom,
> 
> W3C commonly considers Chromium and WebKit implementations in its process evaluations. 
> 
> For more information on the process requirements see:
>  https://www.w3.org/2020/Process-20200915/#adequate-implementation
> 
> Ian
> 
>> On Nov 16, 2020, at 12:20 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:
>> 
>> 
>> Adrian: I was under the impression that to become a TR there needed to be two implementations. I suspect that people are saying that Apple and Google allow that criteria to be fulfilled, but I suggest that since these are closed code, that they should not count. Are there two implementations that you can point out that meet the criteria that are open?
>> Peace ..tom
>> 
>> 
>> On Mon, Nov 16, 2020 at 8:09 AM Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>> On 2020-11-16 10:06, Adrian Hope-Bailie wrote:
>> > Hi Anders,
>> 
>> Hi Adrian,
>> 
>> This how it looks from my horizon:
>> - The payment industry put their money on omnichannel
>> - The payment industry put their money on mobile "Apps" which to date is the only reasonable way supporting omnichannel
>> - The payment industry put their money on various solutions for bridging the Mobile/Desktop gap
>> 
>>  From earlier discussions I understand that the You consider most of this to be out of scope.  This is a valid but unusual value proposition.
>> 
>> Since nobody but the WPWG chairs have ever aired (dismissed rather) these rather fundamental, almost existential issues there is really nothing to discuss.
>> 
>> Regarding the validity of my comments: Apple Pay is a bit more than a "pretty UX".  It is a "wallet", it is omnichannel, and it has state-of-the art security.  It is the "gold standard" which all other solutions will be measured against.  Apple achieved this by an intelligent blend of Web, App, OS, and HW technologies.
>> 
>> Anders
>> > 
>> > Thanks for your input. I find it curious that you consider an interface that depends on concrete implementations to have "no value".
>> > That is, by definition, every standard API defined by W3C and any other standards body.
>> > 
>> > Some corrections to a few of your statements which are not correct:
>> > 
>> > - The Basic Card Payment Method spec is here: https://www.w3.org/TR/payment-method-basic-card/ <https://www.w3.org/TR/payment-method-basic-card/> and the WG has resolved to publish this as a Note.
>> > The purpose of this payment method was to bootstrap the PR API and provide a use case for websites to use it, test it and provide feedback.
>> > In that regard it has served its purpose well.
>> > With the introduction of newer more secure payment methods basic-card is becoming less useful and will likely be deprecated in favour of these other payment methods in future.
>> > 
>> > - "there have been no reports on any major (or even minor) uptake of this technology."
>> > This is completely untrue. As I've pointed out to you numerous times, Google Pay is built using this technology (whether you consider that major or minor is a matter of opinion).
>> > We have also done extensive testing with this API at Coil and plan to roll out our own product features soon using this API.
>> > A number of other WG members have demonstrated use of the API and my assumption is that we'll see some of these in the market in due time.
>> > 
>> > - "this is also pretty much the antithesis of the open Web."
>> > Again, I'm curious as to how you come to this conclusion?
>> > SPC is a mechanism of combining payment initiation with secure authentication (WebAuthn) facilitated by the browser and platform all using open APIs and technologies.
>> > What is it about this that is antithetical to the "Open Web"?
>> > 
>> > - "Apple have more or less set the standard for mobile payment systems in the western hemisphere."
>> > I'm sure my Apple colleagues will be delighted that you think so and I would agree that the UX they have put together is excellent and something to aspire to with open technologies
>> > 
>> > - "To put things in a slightly simpler wording: it appears to be infeasible building something along the lines of Apple Pay using PaymentHandler."
>> >  From what I've seen of experiments within the WG there are a number of solutions offering a very similar UX in development and now with integrated biometric auth thanks to SPC the gap is closing to almost zero between what is possible with open Web standards and closed vendor specific solutions.
>> > Obviously making all this work using open technology and standards is harder and is taking some time to get right but I'm personally very optimistic about the progress.
>> > 
>> > What I think you are missing in your analysis of the WG's work is the difficult tension between the competing priorities of privacy, security and user experience.
>> > Finding solutions that balance all three and are not dependent on a closed ecosystem is difficult, but not impossible.
>> > 
>> > In my opinion we're making good progress. While you may be ready to give up on the Web, I'm not.
>> > 
>> > If you have practical suggestions for our new charter feel please do share them but also consider that a lot of what you've said here has been clearly false so please try to accompany your proposals with some justifications that are founded on facts.
>> > 
>> > Thanks,
>> > Adrian
>> > 
>> > 
>> > On Sun, 15 Nov 2020 at 09:05, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>> > 
>> >     The Payment WG is in the process making the PaymentRequest API a TR.
>> > 
>> >     That's fine.  What's maybe somewhat less obvious is that PaymentRequest in itself has no value since it is just an interface that depends on concrete implementations, aka "payment handlers".
>> > 
>> >     For the latter the WG started with browser-based (built in) "basic-cards".  This has subsequently been deprecated and is not a part of any standard.
>> > 
>> >     After that the ServiceWorker-based PaymentHandler project was launched with the goal making it possible to write payment handlers using "pure" Web technology.  Although this mission has been running for several years, there have been no reports on any major (or even minor) uptake of this technology.
>> > 
>> >     In fact, it appears that the to date only "substantial" use of PaymentRequest is through the proprietary OS/App-level interfaces to iOS and Android provided by Apple/Safari and Google/Chrome respectively.
>> > 
>> >     Recently a new effort called Secure Payment Confirmation (SPC) using FIDO2/WebAuthn was launched.  Unlike PaymentHandler, it is based on browser-based (built-in) support for parts of a payment authorization including the UI.  However, this is also pretty much the antithesis of the open Web.
>> > 
>> >     The only reasonable conclusion from all of this is that supporting advanced payment systems through "pure" Web technology is not going anywhere.  To put things in a slightly simpler wording: it appears to be infeasible building something along the lines of Apple Pay using PaymentHandler.  Apple have more or less set the standard for mobile payment systems in the western hemisphere.
>> > 
>> >     The anticipated charter update ought to take the above in consideration.
>> > 
>> >     Sincerely,
>> >     Anders Rundgren
>> > 
>> 
>>

Received on Monday, 16 November 2020 23:10:16 UTC