The case for registration as a technical specification

I'd like to make a slightly more detailed case for registration as
being technical work in the charter.  (I think "registration" is a
sensible term coming at this from a browser background; I'm not sure
if it is from a payment industry background.)

This is because I worry about whether we're building enough of the
system to make it open.  I'm concerned about:

1. the ability to make a Web browser without either running a payment
   system or making business deals with somebody who does

2. the ability of payment providers to compete in the market, given the
   incentives in (1) to tie browsers to payment systems


What I mean by registration as a technical specification is this: it
should be possible for a website (e.g., a bank's site, a payment
network's site, or any sort of payment scheme's site) to, with the
user's permission, add to the list of payment instruments or types
of payment instrument that can be used in the browser when making a
payment somewhere else.  When I say that, I'm trying to avoid
constraining the problem too much, e.g.:

 - I don't say whether the registration data is declarative, a blob
   of Javascript, something else, or a combination; the WG should
   solve that

 - I don't say how specific the registration is, e.g.,
   how much information about the user's payment instrument (if any)
   gets stored as part of that registration and how much is entered
   at the time of payment; that should be a question for the WG (and
   probably with different options for those registering)

Without something like this, I don't see how we can end up with
anything other than a fragmented ecosystem where each browser has
(if it can) its own payment system.  I'm certainly open to hearing
other ways of getting to the same outcome, though.

In the browser space we've used the word "register" for this sort of
thing (e.g., registerProtocolHandler, registerContentHandler); that
might not be the right term in the payment space.


A related technical piece, which seems useful at least in the case
of the user having no registered payment instruments (which may well
happen the first time they use the technology that the group
develops), is that there should be a way to get from the way a
payment method is described in a site's list of accepted payment
schemes to a URL where the user could register a payment instrument
for that scheme.  For example, a site that accepts paypal could be
connected to a signup/login page on paypal's site that would
register paypal (as described above); there could be similar things
for other payment schemes that are currently less Web-centric.  This
might be extremely simple, depending on how the API works.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)