[webpayments] Splitting registration from payment (#26)

The [Payment Request Architecture diagram](http://wicg.github.io/paymentrequest/specs/architecture.html#architecture) suggests that we split registration from payment. While I agree that the separation of concerns is good and helps both progress independently, I'm concerned that it also creates a very easy excuse for us to ignore the registration problem and may accidentally create an oligopoly in which the browsers and OS vendors control who can and can't register.

While I don't think any one of us wants to create an oligopoly, ignoring the registration problem is something that has a moderate chance of creating such an oligopoly. For example: "BigCorp requires all registering payment instruments to pass our payment instrument criteria (which, by the way, requires your payment instrument to have a total transaction volume of X, for you to pay us registration fees, and for your company to have existed for 10 years and have at least a millions of dollars in recurring revenue)".

So, if we split these specs, I'd only be okay if we commit to similar time frames.

To be clear, the registration process has several good technical approaches we could utilize:

1. Shared, centralized corporate community run registry.
2. Decentralized WebDHT-based mechanism.
3. Decentralized payment instruments as credentials.
4. Password-manager as registration vehicle (LastPass, etc.)

... and you can't do a payment until there is some registration process available (and polyfill-able).


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