Re: The case for registration as a technical specification

On 15 July 2015 at 23:36, L. David Baron <dbaron@dbaron.org> wrote:

> On Monday 2015-07-13 15:53 -0700, Adrian Hope-Bailie wrote:
> > Browser can take on this role if the user hasn't explicitly configured
> > another wallet and I'd recommend that the standard makes it mandatory to
> > allow users to pick a wallet other than the browser.
>
> That doesn't seem sufficient to cause wallet software to come in to
> existence, especially if most (but not all) of the browsers ship
> with built-in wallets tied to their own payment services.  If such a
> situation with no freestanding wallet products were to happen, what
> allows browser makers who don't have payment services to remain
> competitive in the browser market?
>
>
I don't think that will be the case but I'm not sure we have the ability
through this work to enforce what additional functionality a browser vendor
may or may not build into their browser?

Personally, I think the wallets that are available from existing browser
vendors will be tied to the OS (that is also produced by that same vendor)
rather than the browser (that is certainly the case today) and there is
sufficient mixing and matching of browser and OS to incentivize browser
vendors to keep things that way.

Example: Users will want to use Apple Wallet on their iPhone even if they
use Chrome browser. For Google to push for this they can't prevent wallet's
other than Android Pay being integrated into Chrome or try to force iPhone
users to use Android Pay.

I'd like the standard to explicitly describe how a user should be able to
configure their primary wallet and for the integration to be as simple as
the flow and messages as described in the charter. 2 request response pairs
which the browser must pass unchanged between the Website and wallet.

User's will have a variety of reasons to use different wallets be it
convenience (the wallets ships with their OS), features, support for
specific instruments they want to use etc.