Re: [w3c/webpayments-method-identifiers] Should a payment method identifier that is a URL bind that payment method to a single payment app or origin? (#12)

What the proposal says is that browsers should do two things with proprietary payment method identifiers:

1. By default, only allow payment apps from the same origin as the origin of the payment method
2. Get the manifest file that the URL points to and process this to decide what origins can publish payment apps supporting this payment method

**Issue 1**: If we do this we are overloading the payment method identifier. It is an identifier of the payment method, a pointer to the payment method manifest and it's used to decide what origin payment apps can come from. That's just bad design.

**Issue 2**: This default behavior is very dangerous, not least because the manifest based behaviour is still very hand-wavy, but by making this the default, and easier to do than publishing a manifest, we are pushing the market in this direction.

The separation between apps and methods has always been a key part of our architecture because it ensures fair competition between payment app publishers and this means better experiences for users.

By pushing the market toward closed systems for the sake of easier implementation by app publishers we are ignoring the Priority of Constituencies (user > author > implementor > spec).

Payment method owners that want to limit payment apps to only their origin should do so the same way as those that want to open their payment method up to others, put the limits in a manifest. 

Put differently, we shouldn't be proposing a design that makes it easier to create closed systems than open ones.


-- 
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/webpayments-method-identifiers/issues/12#issuecomment-240968744