Storing card information

[adrianhopebailie]

Migrated from w3c/payment-request#199 by @adamroach

The flow in the current "Basic Card" spec has an annotation to the effect of "Merchant can store card details for future use (aka 'card on file')." I think this is actually behavior we want to discourage very strongly, rather than encourage.

The current web environment -- absent webpayments -- does lead to a situation where it is very much in merchants' interests to store credit card information, as the only other alternative is requiring customers to re-enter the information for each purchase. With the API that we're designing, this rationale goes away completely: since the user agent will store credit card information, the merchant site only needs to call the API to retrieve the card information whenever it is needed.

This provides a number of benefits.

First, it removes persistently stored credit card information from the middle of the network, where is it demonstrably vulnerable to capture by hostile parties. There have been a large number of high-profile cases recently that arise only because of the tendency to store card information. We can help the web move away from that.

Second, it provides users the convenience of only needing to update changed credit card information once -- in their user agent -- rather than once per merchant. Since the merchant can interact with the UA to retrieve completely up-to-date information, we can eliminate the friction of web sites having to request updated expiration dates, and eliminate the hassle of updating myriad web sites when assigned a new credit card number (e.g., due to a lost card).

Finally, this approach provides the user additional information, agency, and control over their information, as they can be presented with indicia and/or controls any time payment details are accessed.

I would propose (a) removing the suggestion of storing credit card information from the flow, and (b) adding text strongly discouraging sites from storing credit card numbers, in favor of querying the user agent each time.

[adamroach]

This is a recommendation from the Security and Privacy Checklist review. See https://docs.google.com/document/d/1w7ginyzNg-xZUmITK4vzcGUKB4gbMOAvlkWWaRtX14k/edit?usp=sharing for additional detail

We suggest that the Basic Card Payment specification strongly discourage web sites from storing credit card information for future use, except in the case of future or recurring payments. We suggest including explicit guidance that in such cases, Web site owners should take careful action to prevent disclosure. The sequence diagram in the document should similarly be updated so as not to encourage server-side credit card information storage.

Because of the potential for such storage by web sites, and because of the potential for web browser state synchronization (usually assisted by a synchronization server), we also tentatively recommend that the Basic Card Payment specification make some level of mention of PCI DSS compliance. We propose that the group seek input from major credit card processing companies -- such as Visa and American Express -- regarding what language about PCI DSS compliance (if any) is appropriate for the specification. Here is the sort of statement we have in mind: “The privacy and security sections in this document do not replace conformance with PCI DSS or any other regulations. Implementors and users of the payment APIs should determine whether they are also subject to PCI DSS and/or other legal regulations.”

If we elect not to discuss PCI DSS compliance in the Basic Card Payment specification, we strongly recommend mentioning the topic by name and explicitly indicating that it will not be discussed.

[zkoch]

I don't think we should take any stance on if/how/when credit cards are stored. That's a business decision. It's also by itself insufficient, as PCI governs the transmission of cards as well on the server, even if they're not stored.

I do support saying something to the effect of: "The use of PaymentRequest and the Basic Card specification does not necessarily absolve a site owner of PCI compliance." Or similar (and better worded).

[ianbjacobs]

@zkoch,

We currently have this text: "

Note: Implementers and users of this specification may be subject to PCI DSS or other regulations, but discussion of those considerations lies outside the scope of this document.

"

Does that work for you?

Ian

[zkoch]

Ah, forgot about that, so yep!

[adrianba]

Fixed by #7.