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

Mountie,

I think we want to support wallets in any form (native app, hosted on the
Web, or built into the browser or OS) but we want to standardise the
messages that wallets will receive to initiate and confirm/complete a
payment and the responses they are expected to send back.

Then we can define the delivery mechanism for each scenario.

If the payment is initiated from within a Website via a browser API then we
would want the browser to simply proxy that message to the wallet and proxy
the response back to the Website via an API response (likely a Javascript
promise).

In this first version we just want to standardise how the payment
initiation message looks (price, currency, recurrence etc) and how that
message lists the available payment options.

On 8 July 2015 at 03:38, Mountie Lee <mountie@paygate.net> wrote:

> The Wallet is one of unclear part of this IG
>
> If the Wallet is implemented at a kind of web application helped with
> browser features, it will have browser dependency.
> if the wallet is installable webapp, then it will not dependent on
> browsers but give bad user experience.
> if the wallet is native app (or using any part of vendor technologies ),
> it will not be standard.
>
> for standardization view, we don't need to talk about vendor technologies
> like Siri which is not yet available on common browsers.
>
> normally "wallet" give image of Native Mobile App and I think this is not
> our goal.
>
> the important thing I think is "web is better neutral place and open to
> big/small institutions, corporate/private "
>
> regards
> mountie
>
> On Wed, Jul 8, 2015 at 10:01 AM, 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.
>>
>> > 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.
>>
>> > 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.
>>
>> > 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.
>>
>> A wallet does not help you perform:
>>
>> 1. Negotiation of Terms, or
>> 2. Payment Processing
>>
>> 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.
>>
>> -- 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/
>>
>>
>>
>
>
> --
> Mountie Lee
>
> PayGate
> CTO, CISSP
> Tel : +82 2 2140 2700
> E-Mail : mountie@paygate.net
>
>