Re: Progressing "PaymentRequest" to TR

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
>> >
>>
>>
>>