[browser-payment-api] Should the API support field-level encryption? (#55)

Migrated from https://github.com/w3c/webpayments/issues/78 via @adrianhopebailie:

Split out from #19 which is focused on the need (or not) for digital signatures as a way of validating that the payment request is received as intended by the payment app.

In that thread @mattsaxon raised a requirement for payment apps to be able to return data that is hidden from the payee themselves (perhaps for PCI scope reasons) as they will pass it on to their PSP who can then decrypt it and use it:

> Some elements in the payment response may need to be hidden from the merchant also (e.g. card number)

@cyv suggested SCAI as an option for standardisation of signing and encrypting data through a multi-party flow:
https://www.w3.org/Payments/IG/wiki/Main_Page/ProposalsQ42015/SCAI

So the question becomes; is field level encryption something that should be:
 1. standardised and the Web Payments specs define this standard
 1. defined as a best practice and the WG publishes this guidance
 1. left entirely to the payment app publishers and payment methods to define as they see fit

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/issues/55

Received on Monday, 14 March 2016 02:58:49 UTC