Fwd: privacy review for Web Payments standard

Hi PING, here are some comments we just sent to the web-payments IG on
their Use Cases document. (Apologies, we will in the future share them
here at PING so PING can better coordinate feedback to other WGs/IGs.)

best, Joe


---------- Forwarded message ----------
From: Greg Norcie <gnorcie@cdt.org>
Date: Thu, May 14, 2015 at 11:37 AM
Subject: privacy review for Web Payments standard
To: public-webpayments-comments@w3.org
Cc: Joe Hall <joe@cdt.org>


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)
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

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


-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
joe@cdt.org
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

Received on Thursday, 14 May 2015 15:43:02 UTC