Re: Wallets (was: Re: Web Payments Working Group Charter review (Manu))

On 8 July 2015 at 03:01, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 07/07/2015 06:03 AM, Adrian Hope-Bailie wrote:
> >> Wallets
> >
> > I really don't like the wallet skeumorphism. When we're done, I
> > don't expect that what we will have will resemble a wallet at all.
> > For those that have worked on these systems, a wallet is a really
> > poor metaphor that helps us align with the current industry language,
> > but that's about it.
> >
> > I strongly disagree. We will not have a wallet when we are done but
> > we will have an interoperable way for browsers to interface with
> > wallets (both native and cloud-based).
>
> In the end (version 2+), we'll have an interoperable way for /user
> agents/ (browsers aren't the only important thing on the Web) to
> interface with /payment services/ (aka payment agents).
>
> Some of these payment services will have functionality that looks like a
> digital wallet (but that's a very limited way of looking at what we're
> trying to do here). Other payment services will have functionality that
> looks far more like Siri for commerce than a wallet.
>
> I get that we may have to "market the message" a bit to communicate this
> to the general public. A charter, however, isn't intended for the
> general public, it's intended for W3C Advisory Committee
> representatives. W3C AC reps tend to be highly educated, technically
> minded people. Sure, we may need to market a bit to them as well, but
> "wallet" may be misleading (at least, that's the point I'm trying to make).
>
> I don't think this is a make or break thing, just that we should be very
> careful NOT to buy into our own marketing message. If folks think that
> all we are doing is creating an interface to a digital wallet, you're
> missing the point of what this work is capable of accomplishing.
>
>
This is not just marketing. The scope we have given the group for THIS
charter is nothing but payment initiation, execution and confirmation, all
functions of a "digital wallet".

I am concerned that we continue to colour this WG charter with our wishes
for the future. The future vision is the domain of the IG and it is the
IG's job to ensure that loyalty, credentials and any other functions that
will ultimately be provided by the service we are calling a wallet today
are not forgotten for good.


> > The linked data, fuzzy, user space concept where a payment request
> > is "resolved" through some process that crawls the payer's possible
> > payment instruments stored in a myriad inter-linked private places on
> > the Web is too abstract for what we are trying to solve today. We
> > should be standardising the interface from the Web to this wallet
> > service in a way that allows this service to evolve into something
> > that can do search and discovery one day.
>
> My warning is that we should be standardizing the interface to this
> payment service in a way that doesn't prevent the future that we want,
> which is far more broad than wallets containing things that we provide
> to websites.
>

+1. That is why I am trying to push us in the direction of a browser API
that is simply a proxy between the web application and the wallet. If this
is an open pipe that simply passes standardised JSON objects back and forth
then once the pipe is open (the WebIDL API is implemented in the browsers)
the format of that JSON object can evolve quickly.

An ecosystem of competitive wallet vendors will drive innovation around the
data that will be passed back and forth in that JSON object (hopefully
guided by work in the IG and new WGs) but for now we just want what is in
the charter, payment terms and a set of instruments supported by the payee.


>
> > Finally, the concept of a digital wallet is well understood and is
> > even being adopted by those who avoided the terminology in the past
> > like Apple [1]. For us to pro-actively avoid the terminology used by
> >  the industry is a recipe for confusion and apathy toward our work.
> > The standardization process starts to appear like a well meaning
> > academic exercise with no pragmatic purpose or understanding of
> > reality.
> >
> > TL;DR: The rest of the world are using wallets but they don't have
> > an interoperable way to make them work with the Web. We should be
> > fixing that problem not trying to persuade everyone that we know
> > better.
>
> My point was that giving "wallets" special attention in the charter
> could turn out to send the wrong message. I think we're doing that
> primarily for marketing/messaging purposes, and maybe that's the
> trade-off we need to make.
>
> The downside here is that people will think that we're primarily
> interested in creating a standard API for wallets, and they expect
> wallets to do everything their current physical wallet does. This
> functionality includes holding receipts, coupons, and identity
> information - all of which were specifically placed out of scope for
> version 1 with no concrete plan to do anything about it for version 2.
> So, doing that may cause confusion as well.
>

I disagree here. I think wallet is the right way to describe this service
for exactly these reasons. It easy to explain that we are standardising an
API between web applications and wallets and that v1 of that standard is
focused on a specific set of functions focused on payments. This opens the
door for those interested in the other functions to work in parallel so
that v2 of the API follows soon after.

The McKinsey report from Arie (shared this week) is almost entirely focused
on digital wallets and the fact that they are going to be a very important
part of payments (and other services) in the near future.

The missing piece of the puzzle today (preventing wallets from being
completely ubiquitous, which they should have been for years) is a standard
inter-operabiity scheme between them and payee applications (Web and
native).

You may be right that what we call wallets today may be services doing
things we can't even dream of right now but I don't think that is relevant
for a charter for a WG that is supposed to finish it's work in the next
year or two.


> > We should put some time aside on the Thursday call to discuss a
> > different way of describing what we're creating. It's more akin to a
> > "payment service discovery" mechanism than a "wallet".
> >
> > I disagree. I don't think we are creating a wallet or a payment
> > service discovery mechanism. We are standardising the mechanism for a
> > payer and payee to exchange payment terms so that wallet providers
> > can build great wallets that simply plug into the Web ecosystem and
> > payee's can offer user's a better payment experience (if they are
> > using a wallet that implements this standard).
>
> I think that we are standardizing a mechanism for a payer and payee to
> transact over the Web so that payment service providers can build great
> experiences that simply plug into the Web ecosystem. Wallets are a part
> of that, but they are not central.
>

That is the focus of the IG. This WG has a much more limited scope
(intentionally) which is entirely focused on interoperability between Web
applications, wallet services and payee payment service providers
specifically for the very basci functions required to process a payment
(and acknowledges that user agents are an immovable proxy between all 3
right now).


> A wallet does not help you perform:
>
> 1. Negotiation of Terms, or
>

That depends on how you define "negotiation" and "terms". I think that the
wallet, by processing a set of available instruments and terms (cost,
currency, recurrence etc) from a machine readable payment initiation
request and then present the user with options (or make selections based on
user-defined rules and defaults) is doing some basic negotiation. Anything
more than that (like rules for determining the price based on currency
selection or an FX index and time constraint etc) could be included in
future versions of the spec.


> 2. Payment Processing
>

Depending on the scheme I think wallets will do some level of processing.
If the scheme is debit pull then the wallet will need to package the
response to the payee in a way that is defined by the scheme (note on a
standard card scheme below). This means wallets need some knowledge of the
payment schemes they support. It follows then that a good wallet will also
support credit push schemes AND be able to execute a push payment or hand
this off to another service.


> We should mention wallets, but in a way that does not make it seem like
> the concept is central to the work we're doing. The current charter
> makes it seem like wallets are central to the work we're doing.
>

I think wallets are central to the work of this WG. I hear you that we need
to ensure we don't take design decisions that neglect the other stuff that
is important to the wider IG but let's just say that in the charter and not
pretend that this WG is less focused than it really is.


>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Web Payments: The Architect, the Sage, and the Moral Voice
> https://manu.sporny.org/2015/payments-collaboration/
>
>
>