Re: Progressing "PaymentRequest" to TR

Anders,

You seem determined to persuade everyone in this group that we are wasting
our time and yet when we challenge
your assertions, you shut down the conversation.

Based on what I have read of Saturn and related ideas of yours, I can infer
that you are clearly a knowledgeable
member of the payments community. However, you refuse to acknowledge the
constraints under which Web standards
are developed or the privacy and security differences between Web and
native platforms. The W3C does not develop
products or have the ability to influence any browsers to deploy its
standards. We try to find consensus among existing
ecosystem participants around APIs to improve interoperability.

Did you know that invoking Apple Pay from the browser is done using one of
those standard APIs (i.e. the same API
that can be used to invoke Google Pay)?

My suspicion is that if you were proposing solutions that were in scope of
our group (i.e. built on the Web platform)
then the group would engage you more readily. As long as you continue to
post disparaging remarks and
unsubstantiated theories I think it's fair to expect only the chairs to
respond in an effort to spare the rest of the
group's time and energy.

Adrian



On Mon, 16 Nov 2020 at 18:08, 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
> >
>
>