Re: The case for registration as a technical specification

On 07/09/2015 08:11 AM, L. David Baron wrote:
> 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.

+1 to "registration" as you've described. As you mention, we don't want 
to get into the details of how registration would occur here (as it is 
up to the WG), but I do think it's worth mentioning that we want 
registration to work for more than just browsers. That, in my view, 
means we want to avoid restricting registration so that it depends on 
sites executing JavaScript. That, I believe, should certainly be one way 
to do registration, but a declarative mechanism (ie: machine-readable 
registration data), should also be a requirement to support non-browsers.

>
>
> 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.

+1 -- and, in my view, the best way to make a site "connected" to paypal 
in that way would be through machine readable data (ie: Linked Data). 
That will be up to the WG to decide, but I believe that course of action 
will require us to invent the least number of new/special things.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Received on Thursday, 9 July 2015 14:37:39 UTC