Re: Scalability of PaymentHandler-based Systems

On 2020-04-29 10:58, Adrian Hope-Bailie wrote:
> Be that as it may, the scope of the Payments WG is not to create a generic Web to native bridge.
> For a variety of security and privacy reasons I don't expect that will ever materialize but who knows.

The Payment WG is already standing at that cross road:
- ModalWindow:  Universal versus PaymentRequest-only
- PaymentHandler: Powerful versus Constrained

>     while this one (with respect to PaymentRequest NB), is a blocker: https://github.com/w3c/payment-request/issues/865
> 
> In your opinion, yes. If you read the thread both Marcos and I have suggested a way in which you could achieve what you want using the existing technology available.

The suggested solution has severe downsides.  Dropping PaymentRequest for a specific QR alternative is a way better and fully established solution.


> What you are asking for is to abandon the Payment Handler API (the interface between the browser and issuer domains) in favour of an API that goes directly to the mobile device.

No, I'm actually suggesting deprecating PaymentRequest after finishing 1.0.

The proposed replacement is a Universal Web Channel concept which should work for ModalWindow/ServiceWorker, Web2Native, Web2BLE, and Web2USB. PaymentRequest should be able to thrive on top of this platform.

The security and privacy issues should as far as I can tell be no worse than they currently are; a malicious application can do as much harm as the platform and user permits.  The PaymentRequest API can as proven by Saturn [*] anyway run another API "behind the curtain".  Only hard-coded payment handlers like "basic-card" can enforce strict API usage.

A fundamental difference to current Web security models would be that in the Web2* schemes, possible security questions would be delegated to the connected device which thus is assumed to be "intelligent".

Anders

*] https://cyberphone.github.io/doc/web/calling-apps-from-the-web.pdf

Received on Thursday, 30 April 2020 06:15:15 UTC