Re: Encrypting basic card data

Just for the sake of discussion: I find it interesting that we are willing to attempt to address security issues, but are reluctant to address common failure modes (referring to payment request api issue 224). Using the same arguments that I have heard on that topic, why would we not just say that all implementers need to solve these problems themselves? It’s probably not worth derailing this thread to respond to my question, but I would very interested to hear some thoughts in issue 224.

From: Adam Roach <abr@mozilla.com>
Date: Monday, July 11, 2016 at 9:07 AM
To: Erik Anderson <eanders@pobox.com>, "public-payments-wg@w3.org" <public-payments-wg@w3.org>
Subject: Re: Encrypting basic card data
Resent-From: <public-payments-wg@w3.org>
Resent-Date: Monday, July 11, 2016 at 9:09 AM

Erik --

You're off in the weeds here. The work proposed for Payments v1 is no worse -- and is, in many ways, better -- that the current situation, security-wise. For this kind of work, improvement is a process, not an event.

So, we can spend years overengineering something that would likely become theoretical, cumbersome, perfect, and undeployable -- which is what you're proposing -- while the security situation on the deployed web remains the same as it is today. Or we can embark on a series of incremental improvements, bringing the existing ecosystem along with us while we do, so that we eventually reach a much more secure situation.

One path leads to irrelevance, defeat, and stagnation. The other is deliberate, steady progress. It's basically the XHTML 4.01 versus HTML 5 story all over again. I'd like to think we learned that lesson.

/a

On 7/11/16 10:24 AM, Erik Anderson wrote:
>  How is the current Basic Card mechanism any less secure than what is done today using web forms to capture card details?

Adrian, time.... Time changes everything, Chip-n-pin is causing fraud to move away from the Merchant terminal to online. Laws are changing quickly to adjust.

Paypal was successful because they wrote a secure application in an unsecure environment. They worked around all of the issues.

Paypal follows the best practices, assumes liability for fraud transactions, and required financial standards.

If all you want to achieve with v1 is social payments (not financial payments) or optimize checkout then do whatever.

However, credit cards, checks, and consumer data is closely regulated and consumers have legal protection.

I am not sure why payment security topics are such an anti-pattern topic at W3C.

Erik Anderson
Bloomberg



--
Adam Roach
Principal Platform Engineer
abr@mozilla.com<mailto:abr@mozilla.com>
+1 650 903 0800 x863