[w3c/payment-request] Third-party payment handlers (#640)

I think that making a list of supported payment methods an implementation detail of a browser is a very bad idea. It creates entry barriers to payment systems, gives browser's developers too much power and makes them targets for legal actions (I'm not aware about the laws allowing prosecuting webbrowsers makers (non-merchants) for non-supporting national payment system, but it is obvious that it is possible to pass them) by some shitty jurisdictions promoting own payment systems.

So IMHO
1 Browser must not have a list of payment handlers shipped with it at all. Payment handlers should be discovered by user's request.
2 A set of API to create a payment handler should be moved into the scope of the web standard.


1 Website declares its supported payment requests in JSON in special ```<paymentinfo>``` HTML tag. There must be only one such a tag on the page, otherwise the api must be disabled.
2 ```paymentinfo``` must contain ```paymentmethod``` tags
3 ```paymentmethod``` must contain an ```a``` tag, providing the readable name and a link to the official site of payment system, having inside an ```img``` or a ```picture``` tag providing an icon. ```a``` tag must be followed by an ```article``` tag providing the description in a safe (non-active) subset of html. This can give fallback for the browsers not supporting this API and a better machine-readability for machine-to-machine apps like web crawlers. ```paymentmethod``` tag must have ```name``` attribute giving payment method identifier,  and ```data-``` attributes giving  additional information.
```data-group``` must give arbitrary type of the payment handler, for example (but not limited to) ```e-money```, ```NFC```, ```cryptocurrency```, ```basic-card```. This is used to group similar methods together in the UI.
4 This is all the description of payment handlers provided by the website.

When a user wants to pay, it selects the payment method he wants. If a browser doesn't have a payment handler for that method installed, it opens the official website mentioned in the link. To address fishing the links can be checked against a whitelist of websites of well-known payment systems like ```visa``` or ```bitcoin```, if the website is not in whitelist a warning message must be shown saying that the browser's vendors don't know that payment system website, so user must be careful and triple check, because it may be fraud. 
If it has, it opens payment handler-provided GUI.

Payment handler is a WebExtension with a very limited set of permissions (an empty set for now) with the only application in ```applications``` called ```w3c-paymentRequestAPI```. It is strictly sandboxed and disallowed to use any API which can execute the remote code or modify the UI with remote content like adding a ```script``` tag or ```eval```ing a remote string, or loading a remote image or a css. It is also disallowed to create network requests to the domain other than it was installed from. Addons interacting with localhost must be installed from localhost. State of the art encryption must be used, no RSA 2048, no SHA1, no TLS 1.0, ephemerial key exchange. For the case of localhost a handler must have an embeded certificate.

The addon must register some callback functions getting and returning the info defined in the standard.

-- 
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/640