Re: The case for registration as a technical specification

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.

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

 * 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)

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

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