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

@burdges,

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

I think we're talking about multiple layers of digital signatures. What you're describing would probably be a payment-method-specific digital signature. Which should be just fine (I believe we want to be able to include any arbitrary, necessary payment-method-specific data in the payment request). What I'm talking about is a higher-level digital signature on the payment request itself, such that when the request is forwarded to a Payment App, that app, if it so chooses, can verify that the payment request was not modified. However, depending on the format we settle on for these messages, that may not end up being a requirement.

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

One approach would be to tokenize or encrypt this kind of information.

> 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'm not so sure we can easily protect against that (or it's our place to) -- and that sounds like an anti-compete lawsuit waiting to happen.

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