Re: Scalability of PaymentHandler-based Systems

On Thu, 30 Apr 2020 at 08:15, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> 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
>
>
Modal Window was a proposal to provide something that could replace pop-ups
and be generally usable for cross-origin modal interactions.
The security model is still enforced by the browser so this is very
different to a generally usable tunnel to a mobile app.





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


Can you enumerate these? It's hard to address problems that we don't know
about.


> Dropping PaymentRequest for a specific QR alternative is a way better and
> fully established solution.
>

I'm not sure why PR and a QR-based solution are mutually exclusive.
Could you explain how this QR-based solution would address the goals of the
Payments WG, maybe it's something we should include?


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

As I said above, I don't think this is compatible with the origin security
model and is in any case outside the scope of the Payments WG.
If you have a proposal for how this would work I'd suggest taking it to the
TAG.

In my opinion this has been tried and failed. See Web Intents
<https://paul.kinlan.me/what-happened-to-web-intents/> and Ballista
<https://github.com/chromium/ballista>


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


That is not entirely true and has been the subject of extensive work
recently on defining a privacy and threat model for Payment Request and
Payment Handler.
Even as specialized APIs they have issues we are addressing, these would
only be worse (insurmountable) in a more general API.


> The PaymentRequest API can as proven by Saturn [*] anyway run another API
> "behind the curtain".


In theory yes but this will likely be harder as the APIs evolve. This also
takes advantage of non-standard capabilities such as JIT installation and
skip-the-sheet which are likely to change in nature.


> Only hard-coded payment handlers like "basic-card" can enforce strict API
> usage.
>

True, but even that is a model we are moving away from. The goal is that
when invoking PR API this is a very explicit change of context into a
"payment" and the security and privacy environment for any cross-origin
services (Payment Handlers) will reflect that.

Execution inside such a context will also require some more explicit
consent from users during installation/enrollment.

Finally, payment method owners will also have tighter controls over which
payment handlers can claim to support their payment method allowing them to
perform any level of "certification" they consider necessary.

The space is evolving.


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

What are security questions?
I think it is unlikely the browser (the user's agent) will ever delegate
security or privacy to an unknown external application whether on the same
device or not.


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