Re: Scalability of PaymentHandler-based Systems

Dear Adrian,

I'm not interested in a debate per se, I just want to properly analyze the pros and cons of different alternatives. Each of the topics below is BTW worthy its own thread.  Since it is obvious that nobody else have such interests, it seems rather pointless to continue.

I prefer spending my precious cycles on the additional Open Banking security mode proposal since it has received interest from quite different "camps", ranging from the ECB to card vendors.

Regards
Anders

On 2020-04-30 15:50, Adrian Hope-Bailie wrote:
> 
> 
> On Thu, 30 Apr 2020 at 08:15, Anders Rundgren <anders.rundgren.net@gmail.com <mailto: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
>

Received on Thursday, 30 April 2020 15:16:52 UTC