W3C home > Mailing lists > Public > public-payments-wg@w3.org > September 2019

Unexpected uses of W3C's PaymentRequest API

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Sun, 1 Sep 2019 07:07:56 +0200
To: Web Payments Working Group <public-payments-wg@w3.org>
Message-ID: <9ab254c7-c350-d43c-42e3-2c6d8b974854@gmail.com>
Hi List,

As some of you know I'm an advocate for mixing Web and Native mode applications.
The reason is simple: Advanced schemes like Saturn and Google Pay cannot really function without native code but still have to work on the Web.
PaymentRequest for Android addressed that need in an almost perfect way.

However, there was still a problem with Saturn because it more or less presumes Web enrollment of TEE-based keys [1] since it doesn't build on a central provider [2].
Fortunately my hunch that PaymentRequest probably could support other things as well turned out to be correct.

For those who have interests in "bleeding edge" Web2App tech, here is a one page document outlining the rationale behind this research:
https://cyberphone.github.io/doc/web/calling-apps-from-the-web.pdf

If you have a phone with Android version 7 or better and 5 minutes to spend you may test a SEPA SCT enabled payment authorization scheme PoC:
https://test.webpki.org/webpay-merchant/home

The Web (browser) code for the key enrollment application is anything but complex:
https://github.com/cyberphone/saturn/blob/fc1d55109c86f4d28aa59d9d7e1bad5d728ee43c/keyprovider/src/org/webpki/saturn/keyprovider/KeyProviderInitServlet.java#L233

-- Anders

1] https://cyberphone.github.io/doc/saturn/personal-payment-terminal.pdf
2] https://cyberphone.github.io/doc/saturn/enhanced-four-corner-model.pdf
Received on Sunday, 1 September 2019 05:08:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:33 UTC