Re: The case for registration as a technical specification

On 9 July 2015 at 16:37, Dave Longley <dlongley@digitalbazaar.com> wrote:

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

+1 to adding registration BUT also consider the following.

The way a payment instrument is used to effect a payment is entirely
dependent on the scheme and therefor the definition of an instrument is
too. Consider the difference between registering a Bitcoin address vs a
VISA credit card as an example.

We need a machine readable registration message that can be passed to a
WebIDL API or delivered to the wallet service via some other delivery
mechanism as appropriate.

That message needs to identify the scheme it is used under and then the
remainder of the message is likely to be scheme specific.

The wallet service will either support instruments from that scheme (and do
what is required to store the instrument) or not and reject the
registration request.

Support may mean calling out to other wallets or services to try and store
the instrument there.


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

Would it not make sense for the wallet service to have knowledge of how to
do this? i.e. It get's a payment initiation request with a set of supported
payment schemes. If it doesn't have a supported instrument it might suggest
the user add one that it (the wallet) supports holding and is also
supported by the payee.


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