Re: The case for registration as a technical specification

On 13 July 2015 at 04:25, L. David Baron <dbaron@dbaron.org> wrote:

> On Thursday 2015-07-09 17:34 +0200, Adrian Hope-Bailie wrote:
> > 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.
>
> Saying that there can be three different types of wallet and not
> defining how they really work seems dangerous to me.  It makes the
> wallet concept like a black box, which means an essential part of
> the system is not defined by the standard, and thus unlikely to be
> sufficiently open.
>

The intention is to standardise the messages that a wallet must be capable
of accepting and the responses it is expected to return. That feels like
enough stnadardization to me.

If we standardize too much of the wallet functionality then where is the
incentive for wallet vendors to innovate? We will have constrained what
they can do and our standard becomes a gatekeeper to further innovation.

Wallet vendors like VISA, MasterCard, PayPal are unlikely to support a
standard that prevents them from differentiating themselves from their
competition.

On the other hand, if they all have to expose the same interface to the Web
then it's easy for users to switch between wallets and easy for wallet
vendors to offer great value add features without being non-compliant.

It feels like you're talking about the wallet being something like a
> plugin to the browser -- more limited than an NPAPI plugin, but
> still a plugin.


That's one option. Wallet's could also be a cloud-hosted service accessed
via REST or stand-alone native applications that integrate with the browser
via some mechanism that the browser vendors define or even a REST API
exposed on a local URL as is the case with native applications like Dropbox.

These possibilities are explicitly listed in the charter so that when we
publish a standard we define the ways that browsers should interface with
them. The work to define what that is is still left to the WG.


> I think browser developers today are unlikely to
> leave essential parts of the browser to plugins based on
> unstandardized or platform-specific APIs.


What makes you say that the APIs will be unstandardized or platform
specific?


> Doing this in the past
> has caused:
>
>  * vulnerability of our users to security holes (see the multiple
>    Flash 0-day vulnerabilities today, with users being stuck with
>    the choice between being open to attack or being unable to access
>    content that was designed for Flash)
>
>  * constraints on the operating systems on which browsers can
>    operate, and thus which operating systems it's possible to use
>    the Web from (which in turn has been a significant constraint on
>    viability of operating systems)
>
>    (Consider, for example, the long history of Flash on Linux, and
>    especially 64-bit Linux, lagging behind other platforms, and the
>    effect that had on the usability of the Web on Linux.)
>
>
> I'm worried about what competition in the Web browser market looks
> like.  Any of the following could be major constraints to entry (or
> continued participation) in the Web browser market:
>
>  * needing to make deals with people who do payment processing or be
>    a large enough company to already have such deals for another
>    part of your business
>

If a browser vendor implements the WebIDL API and is capable of calling on
the REST APIs we define then most of the work is done. No special deals are
required.


>
>  * needing to make deals with people who make wallet software
>    in order to interface with your browser, across all operating
>    systems on which you'd like to release that browser (which may
>    include minor ones and which may change over time)
>

I would expect the browser vendors to allow this to be done in a
standardised way. The messages and flow will be standardised so it's a
matter of defining a delivery mechanism between browser and wallet.

If the wallet is cloud-based then that's just the browser calling out to
the wallet's REST API. If it's native then I'm not sure we have a place
defining how this must work beyond the message format and flow of messages?

Personally I'm a fan of a native wallet listening on a specific port and
exposing the standardised REST API. So the browser is configured to connect
to the wallet at https://localhost:9000/wallet or similar.

I'd expect the browser vendors participating in the group to have good
ideas about the right way to do this.


>
> > 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).
>
> I would see parties like PayPal (at least for what PayPal does
> today) fitting into this ecosystem as payment instruments rather
> than wallet providers.  (From a single credit card on file with
> PayPal, PayPal might be able to register multiple payment
> instruments, one to make a PayPal payment and one to make a credit
> card payment.)
>

I don't agree. PayPal hold a number of sources of funding (PayPal balance,
credit cards etc) which are each payment instruments. I can see the
argument that your PayPal account could advertise itself as a payment
instrument but that takes away the ability of the payer to choose which
instrument to use each time they pay out of their PayPal wallet.

It also means that the merchant has to explicitly support PayPal as a
payment instrument. If the merchant supports VISA cards as payment
instruments and you have a VISA card in your PayPal wallet then you should
be able to complete the payment.

We are explicitly aiming to create a standard that allows some kind of
aggregation so the line between wallets (which are effectively aggregators
of instruments) and instruments does become a bit of a grey area.

The major difference between a wallet and simple list of instruments is
that wallets have knowledge about how to use the instruments they support
storing.

A wallet that supports Bitcoin knows how to send a Bitcoin transaction for
example. If the wallet is provided by a company like Coinbase then it will
use their API but it would be possible for someone to write their own
wallet that takes our standardised messages as input and executes the
Bitcoin transaction directly.

If the wallet supported a "debit-pull" instrument like a payment card it
would know what the card scheme expects in the payment initiation response
to be able to execute the payment. It's possible that the scheme even
defines out of band communications that the wallet must perform. This is up
to each scheme.

If schemes define rules that close out wallets then the market will push
back by tending toward more open schemes. A standard like this enables this
market driven openness because it becomes trivial for merchants and users
to support and use new payment instruments.

>
>
> -David
>
> [ Sorry for the delay replying; was on vacation Friday and today. ]
>
> --
> 𝄞   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)
>