Re: Encrypting basic card data

> Let's not do this in v1, it may imply more security than is actually
> being provided and we haven't actually identified the threat >
> properly to evaluate it's value.
> Rather, let's work out a comprehensive solution for v2 that fully
> mitigates a MiM threat
 
Adrian,
 
This is a well documented topic in financial standards.
Specifically the data elements required to be secured are
Cardholder Data
- Primary Account Number (PAN)
- Cardholder Name
- Service Code
- Expiration Date
Sensitive Authentication Data
- Full Magnetic Stripe Data
- CAV2/CVC2/CVV2/CID
- PIN
- Encrypted PIN Block

Once again read over https://www.w3.org/Payments/IG/wiki/Security_Issues

X9.119 covers this topic. Visa published best practices and PCI
   published many legal requirements.

I know that the issues will not be fixed by V1. Many of the browser
security issues are over 10 years old.

Fraud is must higher online and I feel W3C will be helping to
standardize fraud without any security efforts.
 
Wendy has published
https://github.com/w3c/websec/blob/gh-pages/security-roadmap.md
 
This is a good beginning.
 
To limit W3C liability in event of publishing a standard that leads to
fraud, I recommend W3C
1) publishing a payment security roadmap
1) Publish a best practices document to give users points how to work
   around the problems.
3) Place a disclaimer in v1 referencing the security roadmap and best
   practices.
 
If a v1 is published and W3C makes a call to implementer's without anti-
fraud/security/privacy measures and without a proper security roadmap to
address the issues then I am pretty sure the courts will find W3C
liable. IMO, the world is a big place and there is enough international
case law around control point & liabilities to make the law suits stick.
 
Once again, online security is a HUGE problem. No one is expecting it to
be fixed in the first pass.
 
Erik Anderson Bloomberg