Re: Encrypting basic card data

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
+1 650 903 0800 x863