Re: Security and Privacy Considerations

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

+1

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.

+1

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

I disagree. The message to the market should be: "We are not trying to
define an API for processing payments. We are standardizing a mechanism for
initiating a payment and therefor explicitly put payment method specific
security considerations out of scope.

The expectation being that different payment methods will have different
security needs and will therefor deal with those in a payment method
specific way.

On 9 July 2016 at 05:34, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

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