Re: The case for registration as a technical specification

Hi David,

I agree and I think that the discussion re the charter to date suggests
others do too.

One thing I wanted to clarify is the role of the browser/UA in the
currently proposed flow. This is my understanding and I'm happy for anyone
to chime in with a different perspective.

As it stands, the proposal is to create a standard WebIDL API that allows
websites to initiate a payment by passing a standardised message to the
browser and for that API to respond with a standardised message back to the
website. This process will be repeated for a completion request and
response.

When the browser receives this message it should do one of two things:

   1. Pass it directly to a configured wallet, unmodified
   2. Decline the API request as there is no wallet configured

i.e. I'd like the browser's participation in the flow to simply be as a
proxy of messages between the website and the user's wallet.

We are proposing that there may be 3 types of wallet:

1. Cloud-based. In which case the browser passes the requests message via
HTTP (a REST API of sorts) to the wallet service and get's back a response.
(Details of how this would work, including hosting of the wallet UI in a
frame or new window will be left to the WG to decide).

2. Native. Meaning the user installed some wallet software (or app in the
case of a smartphone) and there is a mechanism for the browser to
communicate with that native wallet service. It will be for the browser
vendors to propose how this is done or if it should be standardised.
Perhaps it will be simplest to say that native wallets must host an HTTP
endpoint service so that the interface matches cloud-based wallets, or
maybe they will need to take the form of browser extensions.

3. Built-in to the browser or OS. In this case I think it's outside the W3C
WG's scope to define the delivery mechanism for messages between the UA and
the wallet service but the standard could still mandate that the messages
passed between the UA and wallet must follow the standard format.

So, I would imagine a user downloading a wallet application (or writing one
themselves) and installing it or signing up for a wallet service from a
thrid-party (like PayPal). Then they need to register payment instruments
with that wallet. They could do this directly through the wallet system
itself OR they could login to a website of a payment scheme or payment
instrument provider of theirs and the website could call a WebIDL API like
*registerPaymentInstrument* and they would be prompted to add this payment
instrument to their wallet.

I also proposed that we add a registerWallet call to allow cloud wallet's
to register themselves with the browser (i.e. ask the browser to make them
the user's default wallet) but not everyone has agreed with that idea.

On 9 July 2015 at 14:11, L. David Baron <dbaron@dbaron.org> 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.
>
>
> 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)
>