Collect Privacy and Security considerations

[marcoscaceres]

Discussed some with @pauljt... would be great to collect more here... please suggest more:

• Protecting the wallet - making sure "data at rest" can't be easily attacked by, for example, other applications.
• Don't store CVV

Payment sheet considerations:

• what numbers to show from stored credit cards (i.e., maybe first 4 and last 4).
• how to deal with too many Display Items in the sheet.
• how to deal with unicode strings and log URLs or origins (specially ones that try to flip the text display).
• Require user interaction bring up payment sheet (e.g., activate a button)
• Maybe delay activation of the "Pay" button in the sheet - so to give more time for the user to understand what is being asked of them.

[ianbjacobs]

Hi @marcoscaceres,

I believe that previously we have wanted to avoid listing payment method -specific security considerations such as "don't store CVV." That is how we ended up with this text in the Basic
Card specification: "Note: Implementers may be subject to PCI DSS or other regulations, but discussion of those considerations lies outside the scope of this document."

See also discussion about user consent text:
#229

Of the things you listed above, I support (in addition to our consent discussion of issue 229):

• Adding to payment app good practice documentation sensitivity to displaying account information (but without specific guidance for credit card PANs)

I don't understand:

• the Unicode strings / URLs bullet

I do not support the addition of general user interface considerations such as:

• General security topics like how apps protect data
• How to deal with too many items on a screen
• Consideration for the time required for a user to take action

Thanks!

Ian

[marcoscaceres]

Closing, as there is nothing actionable here.