Re: The case for registration as a technical specification

On Mon, Jul 13, 2015 at 4:25 AM, 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.
>

Need a "wallet" by anything more than a list of payment instruments?

I would expect the system to have a list of payment instruments provided
via a system-specific API. Likewise, the browser might maintain some web
payment instruments in its own database that it merges with system
instruments to display to the user. How these are stored or retrieved in
any particular situation isn't something that can or should be standardized.

I think the term "wallet" is confusing since it gives the impression that
there's a thing people can point to that has specific properties. I would
personally prefer if it was just replaced with "list of payment
instruments" every time it appears.

Brett