Re: [webpayments] What gets registered - apps, wallets, or payment instruments? (#28)

> Well, they'd probably need N signatures (one for each method)

I'd expect they'll need those anyways since the signature algorithms for different methods may differ, perhaps radically. 

> I'd rather see the threat model for exposing all of the payment request data to the user's payment app of choice. What are the real dangers/concerns as concrete examples?

At minimum it widens the attack surface for obtaining identifying information.  A wallet application is potentially designed, or even insured, with the idea that it typically protects around $1000 in token, not information that'd expose the user to identity theft. 

Aren't discount/loyalty programs being discussed for payment methods?  Those should be considered malicious adversaries whose interests are actively hostile to the user's interests, so they really should not learn anything not specifically meant for them. 

There are various new payment methods trying to support micro-payments by offering lower transaction costs.  And merchants might wish to promote these.  Yet, merchants doing so might face retaliation by legacy payment method providers. 

I'd expect different payment methods to impose different rules on what private user information is recorded in payment contracts and how it is recorded, so doing this sounds largely unavoidable anyways.  We encrypt many details of the contract so that only the user can prove things later, but we need the merchant's signature on that cypertext. 

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/28#issuecomment-164033128