Re: The case for registration as a technical specification

There's a lot happening in this thread, so I apologize in advance for
cherry picking out quotes and responding, but it seems like the cleanest
way to do it.

As a general comment, the concept of a "wallet" and a "payment instrument"
is becoming more and more muddled. I think this is worrisome, which I
comment on more below. I thought of a wallet as something much dumber (i.e.
just an aggregator of payment instruments).

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.


I agree with David. PayPal is best thought of as a (set of) payment
instrument(s). This notion of Visa, MC, PayPal etc all being wallets does
not, IMO, lead to a good user experience. You're asking users to think
about and understand the difference between Wallets and the various payment
instruments they support.

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.


Maybe, but I'm not sure PayPal would agree with you.

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.


This is a big red flag to me and worries me that what you'll end up with is
a muddled and confusing user experience. We need to draw a clear line
between a "wallet" and a payment instrument.

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.


I'm not clear on why this has to be the case.  Couldn't you have Coinbase,
for example, as the payment instrument and the Coinbase payment instrument
knows how to send a bitcoin transaction? Why does the Wallet need to know
about this? I think we're overcomplicating the Wallet here.

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.


It seems as if you're making Wallets the key place where innovation happens
here. I don't think that's the right place. I understand the goal of
driving openness, but I'm not sure this standard is the place to push this.
I think first we should focus on users and creating an easy and compelling
user experience (i.e. easy selection of payment instruments from the
intersection of payment instruments they've added to their wallet and
payment schemes the merchant supports). Then we should focus on merchants
and ensuring that the payment schemes they accept are available in this new
experience we're standardizing. We shouldn't be trying to force PayPal, for
example, to support credit card transactions for non PayPal merchants. I
fear that will not end in success.



On Mon, Jul 13, 2015 at 3:53 PM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

>
>
> On 13 July 2015 at 11:31, Brett Wilson <brettw@google.com> wrote:
>
>> 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?
>>
>
> Yes.
>
> As I said to David, wallets need to know how to use a payment instrument
> according to the rules of the scheme for which the instrument is issued.
>
>
>> I would expect the system to have a list of payment instruments provided
>> via a system-specific API.
>>
>
> Why system specific? The standard is aiming to define a set of standard
> messages that the wallet must process and a set of standard responses the
> wallet must return. The actual delivery mechanism may differ but the
> messages and flow will be standardized.
>
>
>
>> Likewise, the browser might maintain some web payment instruments in its
>> own database that it merges with system instruments to display to the user.
>>
>
> Why would the browser display the list of instruments to the user? The
> intention is for the browser to simply be a proxy of messages between the
> wallet and the calling application.
>
> If the wallet is built into the browser then it may be the component that
> prompts the user but if it is not then I'd expect the wallet service itself
> to display this UI.
>
> The "merging" you describe is what we have called an aggregation service
> but I'd recommend that the browser doesn't attempt to do this but rather
> allow user's to configure the browser with their preferred wallet.
>
> 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.
>
>
>> How these are stored or retrieved in any particular situation isn't
>> something that can or should be standardized.
>>
>>
> Correct. Wallets are free to store and retrieve instruments and the
> meta-data they require as they wish. Some schemes will define how this must
> be done if the data is sensitive.
>
> Alternatively the mechanism that is used may be a competitive
> differentiator for a wallet. Example: a wallet that supports Bitcoin may
> support a sophisticated multi-sig or hardware-based mechanism for executing
> transaction.
>
>
>>
>>
>>
> 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.
>>
>>
> The wallet is a thing that people WILL point their browser to that does
> have specific properties. The most important will be that it supports the
> APIs we are defining. It is NOT just a list of instruments. It maintains a
> list of instruments that the user has registered but also has knowledge
> about how to use those instruments.
>
>
>> Brett
>>
>
>