W3C home > Mailing lists > Public > public-webpayments@w3.org > November 2015

Re: Google's Web Payment API

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Thu, 5 Nov 2015 09:26:49 +0100
To: Zach Koch <zkoch@google.com>
Cc: Web Payments CG <public-webpayments@w3.org>
Message-ID: <563B12C9.8090008@gmail.com>
On 2015-11-04 23:51, Zach Koch wrote:
> (Note: In the spirit of full disclosure, I am the author of Chrome's proposal)
Hi Zach,

I know.  Anyway, this is a very complex topic, which is one reason to why credit-card payments on the Web in reality have gone backwards the last 20 years.

> Hi Anders -
> I don't think that's true at all. We are in the (very) beginning stages of the WG, and I think there is still plenty of time for alternate proposals to emerge. Anyone is free to write a proposal and submit it to the Web Community Incubation Group [1] for feedback and discussion, just like we did [2].
> It is far from "game over."

Zack, your draft/write-up introduces massive dependency on the browser.  Due to security issues, I imagine that in the end the work will likely be in custody by the same same people who designed WebCrypto which is a rather different lot than the Web Payment WG.

IMO, the the space haven't (in general) been properly researched and now there's no time for that given the very aggressive time-line.

Personally, I don't consider "Browser Wallets" particularly interesting since the real action doesn't appear to be happening at that layer, it is either server-side a la PayPal (using existing Web-tech), or native-level "App" like Apple Pay.  Server-side solutions doesn't necessarily need any innovation beyond strengthening the authentication which is provided by FIDO alliance while standardizing an API to native wallets will most certainly go bust for the simple reason that these systems are proprietary and also mostly secret.

A highly related question that begs for an answer is who owns/controls the payment UI.

IMO, there's no immediate need for a universal payment instrument selector either, such a thingie will only complicate the design. Manual selection by the user works fine using standard Web-tech. Well, an optional filtering mechanism could possibly be useful.

FWIW, I did (early on), suggest an entirely different approach.  If I understand things correctly, this opportunity will also be available although I don't think the solution is ready for prime-time [1].  The core idea was not creating a payment standard but an improved Web platform that could be used to create new payment schemes but that this innovation would not be limited to W3C.


1] https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html

> Thanks,
> Zach
> [1] http://discourse.wicg.io/
> [2] http://discourse.wicg.io/t/rfc-proposal-for-new-web-payments-api/1100
> On Wed, Nov 4, 2015 at 2:26 PM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>     Since the big players in the Web Payment WG didn't assign any engineering resources during the startup phase (IG), they have no option but going with the undisputed leader in Web technology.
>     Since Google controls 80% of the mobile phone market and have Chrome running on all desktops, it essentially means that it is "game over" for other alternatives.
Received on Thursday, 5 November 2015 08:27:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:43 UTC