[w3c/payment-request] Adding support for "encrypted basic card" (#572)

This issue is related to
https://github.com/w3c/payment-request/issues/566

Supporting external payment providers offering "secure payment pages" where the user fill-in card details etc. has the advantage that is relieves the merchant from PCI certification as well as dealing with payment networks.  _This is a very common arrangement_.

Although https://w3c.github.io/webpayments-methods-tokenization/index.html could address this problem, there is a (for this purpose NB), much simpler solution needing the following additional properties
- public encryption key
- key encryption algorithm
- content encryption algorithm

which if defined would return exactly the same data as "basic card" _but encrypted by the outsourced payments provider's public key_.  The data would preferably be encrypted using JOSE JWE.  The resulting Base64Url encoded "blob" could then be supplied as an argument to the redirect which currently usually happens after the customer have selected "card payment" relieving the end-user from filling in card data.

Only the targeted service provider would be able to decrypt such elements.

Outsourced payment services could make this new element _optional_ so that existing merchant solutions would continue exactly as today.

Security wise it is important nothing that plain-text card data would only be processed by trusted (built-in) browser software and the end-user. 

Note that this arrangement only requires the browser to encrypt data and that _no additional external service providers are introduced either._

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/572