Re: Encrypting basic card data

You continue to think we should design an arbitrarily complex, perfect 
system at some point in time infinitely far in the future rather than 
making security better incrementally and as soon as possible?

I humbly disagree. Internet commerce isn't going away, and until we 
provide a better system, it's going to largely be PANs typed into HTML 
forms.  We can make that better *now*, or we can sit in an ivory tower, 
forever, making something ideal. Your call to make this undeployably 
complex, if heeded, harms users by leaving them with the status quo.


On 7/14/16 4:21 PM, Erik Anderson wrote:
> This topic is changing daily.
> 2 days ago EU just adopted some strong privacy issues around users 
> data and financial devices.
> The new European laws strictly call out European-style data 
> protection/encryption, data at rest, data in motion,  and tokenization.
> Throughout these laws and regulations they specifically call out 
> "public networks". Public networks is exactly where W3C Web Payments 
> falls.
> They are not saying to protect against this attack vector or that 
> attack vector. They are saying to secure the data before it leaves the 
> users control via encryption and tokenization.
> I am looking into a massive amount of incoming documentation from the 
> US Treasury, NIST, PCI compliance,  Federal Trade Commission (FTC).
> Between the US and EU they are essentially saying the same thing. 
> Protect the users data via point-to-point security (not channel based 
> security but encrypt  or tokenize that data directly).
> These W3C standards are international. I will update Manu page.
> Design the API up, not down.
> I would argue that the users data leaves their control once they enter 
> it in a web form. I will accept that the data is secured once it hits 
> our API (or before).
> The Payments API must be secure.
> Erik Anderson
> Bloomberg

Adam Roach
Principal Platform Engineer
+1 650 903 0800 x863

Received on Friday, 15 July 2016 04:22:59 UTC