privacy review for Web Payments standard

W3C Web Payments Use Cases 1.0 Privacy Review
By Greg Norcie and Joe Hall
Center for Democracy & Technology

[Aside: Maybe you should break out payment and refund into two separate
phases for easier readability/organization in 3.0 ?]


3.3 Payment Processing:


* Completion of Transfer: Is it within scope to notify users of which
regulatory bodies will receive their information prior to making a payment?
Not necessarily making such notice mandatory, but it would nice to support
such a notice mechanism so that transaction parties could use it to provide
transparency about flows of financial transaction information.

4. A Simple Example of the Payment Phases

4.1 Negotiation of Purchase Terms
* Discovery of Offer / Agreement on terms: Will the site know Jill looked
at the item in the store or on her mobile device previously and if so will
that alter the price of an item?

* Application of Marketing elements: will the application of marketing
elements always DECREASE price? For example, might a site see Jill has
repeatedly looked at airline prices for flights from DC to SF, and raise
the price?

4.2 Negotiation of Payment Instruments

* Selection of payment instruments: Is this a _loyalty_ card or a store
branded credit card? One provides a unique ID used to get a discount, the
other is a form of payment preferred by the merchant. There are privacy
implications of each that may not be immediately apparent to the payer.
This seems like the payments-equivalent of collapsing web cookies from
multiple origins into a single common origin. It’s unclear what to
recommend here other than allowing methods – e.g., a “private payment mode”
akin to private browsing modes in UAs – that would allow the payer to
divorce a transaction or series of transaction from past and future payment
history.

* Authentication to access instruments: What if Jill doesn't own a
smartphone, or is in an area with no signal? There should be a fallback
(such as one time codes, or a PIN) that does not require said smartphone.


4.3 Payment Processing

* Verification of available funds: The payment processor should simply be
told there are sufficient funds, not the amount in the account / remaining
credit balance

6 Negotiation of Payment terms

6.1.1.1 No Essential Use Cases

* Email: Why does anything need to happen in the email client? We agree
that there is huge phishing/fraud risk here. Why can't this include a link
and use the website use case? (Eg: Display an ad, click "redeem offer",
browser opens, safebrowsing, etc..)

* Hold funds: Again, should not leak more than whether there are sufficient
funds for the hold + purchase price value. Do NOT respond with remaining
credit limit / funds in account, unless the there is some contextually
expected reason to transmit this information (e.g., a “Display
Balance/Credit Limit?” prompt.).

* Pre-authorization: Why is privacy only a concern for small fuel
purchases? All purchases leak location information since it is known where
the business you bought the item from is located. Privacy should be the
default unless there is a compelling or contextual reason to reveal
individual details. We recommend s/small fuel purchases/small purchases/
here.

6.1.2 Agreement on Terms


* Credentials: Is it really necessary to transmit this information in all
cases? Why not, where possible and supported by client infrastructure,
simply calculate if a user meets the check, rather than pass their
credentials to the retailer? (This is akin to zero-knowledge credential
verification, and we’d like to see the eventual spec support that
functionality.)
   - Ex: Greg verifies he is >21 and a token is sent to the server
confirming this, rather than sending say, a DL scan and exposing swathes of
personal info.




6.1.2.1 Agreement on Terms - Non Essential Use Cases


* Full disclosure: The privacy and security section could use more detail.
Example: Require data to be encrypted at rest and in transit. It seems
unclear how we can reduce phishing attacks via this work and eventual specs
in these cases.


6.1.3 Application of Marketing Elements


* Coupons: This use case seems to be overly general about  how coupons
work. Coupons are often limited to a small number of people (as wide as a
city / state, or as narrow as an individual). So if the system simply
reduces the price and says to the merchant "1 person claimed at X price
point", it might reduce utility of coupons. (OTOH it would _increase_
privacy) It would be great if individualized coupons would indicate that
using the coupon may reveal an individual’s purchase information to the
coupon issuer, regardless of any other transfer of personal information
(this may be out of scope for this IG and the eventual WG)

* Loyalty cards: Again, the uses cases should distinguish between a loyalty
card and a store branded credit card and a credit card that gives rewards
in certain categories, simply because there are distinct privacy
implications of each of those cases.


6.2 Negotiation of Payment Instruments
6.2.2 Selection of Payment Instruments

* Discovery: Site should list what payment instruments it takes, and the
user's client should  display the options user can employ. To protect
privacy, the use case should be designed to not leak what payment accounts
the payer has to merchant.

* Manual selection: A loyalty card can be a credential, a payment
instrument, or both!
* Payer privacy: Why isn't the default that info about payment instruments
is not shared unless user opts in? Is there a use case that makes it clear
in what circumstances a user agent/client would need to be more promiscuous
about transmitting information about the payer’s payment instruments?


6.2.3 Authentication to Access Instruments

* Biometrics: there should always be a method to authenticate to an access
instrument that is not biometric. Systems should fall back to two factor,
preferably supporting a mode that those w/o a smartphone can use such as a
PIN or a card with one time codes. There are a number of instances of the
specific word “fingerprint” in this use case that should be “biometric” to
be more general.

* Regulatory Blocks: Only check identity against a blacklist when the
transaction amount or category of goods legally requires such verification.


6.2.3.1:
* Accessibility: "Improve" is mispelled


6.3.2 Verification of Available Funds:
* Hold verification: Only tell merchant that hold can be sustained, not how
much funds exist in the account or the size of the instrument’s credit
limit.

* Hold verification: Is it feasible to let user acknowledge / authorize the
hold? It seems problematic if a malicious attacker with your financial
account details can put in a large hold that locks your account. (This can
be especially disastrous for debit card users)


6.4.2 Delivery of Receipt

* Electronic Receipts: Receipts should minimize data just like with
physical receipts (see below)

* Physical Receipts: We need to define "private information". ex: Full
credit card numbers would be one type of info that should not be included.


6.4.3 Refunds
* Common refunds: To guard against fraud and/or money laundering, refunds
should be in the tender the purchase was made in. (Malicious actor could
use a stolen CC, then get refund in cash, or launder BTC into $$$ otherwise)


7.2 Tokenized Payments
* Application of Marketing elements: Why is it n/a?

7.4 Cryptocurrency Payment
* Delivery of receipt: At CDT we are not necessarily familiar w/ BTC - why
are there "six verifications" in this use case before the transaction is
considered sealed? Why not four? Or seven? Or one?

* Authentication to access instruments: Why is it only mentioned here that
<$50 purchases don't require 2FA? Is this a standard value of a small
monetary transactions that shouldn’t require 2FA? If this value is codified
into an eventual specification, it will go stale in time with inflation, so
it would be best to couch this in non-monetary terms.

General thoughts:
* Idea: all transactions anonymous unless loyalty card used
* We need to specify if using a loyalty card just means you get a certain
price, or if it will leak a unique ID. The way the spec is written, this is
unclear

* Terminology suggestion:
      - Loyalty card: A card that provides a unique ID used to deliver
special prices (and provide retailers insight into purchases
      - Branded Charge Card: A credit card that a retailer offers, which
provides special discounts / privileges.
      - Rewards Card: A credit card which gives rewards at specific
merchants and/or classes of merchants
-- 
/***********************************/

*Greg Norcie (norcie@cdt.org <norcie@cdt.org>)*

*Staff Technologist*
*Center for Democracy & Technology*
1634 Eye St NW Suite 1100
Washington DC 20006
(p) 202-637-9800
PGP: http://norcie.com/pgp.txt

Fingerprint:
73DF-6710-520F-83FE-03B5
8407-2D0E-ABC3-E1AE-21F1

/***********************************/