W3C home > Mailing lists > Public > public-payments-wg@w3.org > July 2016

Re: Security and Privacy Considerations

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Sat, 9 Jul 2016 06:34:47 +0200
To: Erik Anderson <eanders@pobox.com>, public-payments-wg@w3.org
Message-ID: <86139d6b-3121-a66e-e26d-2fe8f7a650cf@gmail.com>
On 2016-07-08 17:16, Erik Anderson wrote:
<snip>

https://www.w3.org/Payments/IG/wiki/Security_Issues

  "The browser does not prevent any of these, and web standards require these weaknesses.
   If your browser does not expose your site and your users to all of these problems, it
   is not standards compliant. There's something deeply wrong in the W3C standards.
   To make the browser secure means breaking those W3C standards and that's going against
   the 'standards politicians'"

I wouldn't necessary express it like this.  The "truth" FWIW is that there indeed is no such thing as a "Trusted Web App".  For payments there is (IMO) no need for that either since state-of-the-art schemes like Apple Pay provide trusted code which does not run in the browser.

In spite of this, I'm personally unconvinced that it is weaknesses in the browser model that has been the primary source of payment fraud.  Apart from poorly designed applications (there will always be such...), isn't it rather the lack of strong authentication and/or dependency on static card numbers that (still) is the #1 problem?

Anyway, the traditional financial industry have had ample of time (like 20 years...) coming up with a better system for card payments on the Web but opted for NOT doing that which means that security (particularly in the US) can hardly be top priority.


> As I have said before, standardizing a payments API with known
> vulnerabilities is the same as standardizing fraud. One API to exploit
> them all.

Since it is the "Schemes" that are supposed providing [scheme specific, usually SECRET] security solutions it seems pretty difficult performing any deeper analysis except (to some extent) for privacy.

In some cases the API is merely a dispatcher to the actual payment system, while in other cases (like CNP), it may do the whole thing client-wise.

A problem with this is that the "message to the market" by definition is unclear w.r.t. security, which is why I'm personally are more interested in specific payment systems than in frameworks.

Anders Rundgren
WebPKI.org
Received on Saturday, 9 July 2016 04:35:27 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 9 July 2016 04:35:28 UTC