Re: Web Payments Working Group Charter review (Manu)

On 7 July 2015 at 05:13, Manu Sporny <msporny@digitalbazaar.com> wrote:

On 06/30/2015 02:52 PM, Ian Jacobs wrote:
> > Web Payments Architecture Working Group Charter
> > http://www.w3.org/2015/06/payments-wg-charter.html
>
> Here's my review of the Web Payments WG Charter...
>
> > Web Payments Architecture Working Group Charter
>
> Change to "Web Payments Working Group Charter". "Architecture" is
> something the IG produces.
>

+1 - As discussed on the call yesterday


>
> > see the Web Payments Interest Group's glossary.
>
> The glossary should be in a document by itself and referenced
> accordingly (to the TR page). Shane has done much of this work over the
> last weekend, we should use it.
>
> I'm also a bit uneasy about a charter that requires a glossary to
> understand what it's saying, but have no alternative proposal other than
> trying to stick to purely English terms and standard dictionary
> definitions.
>

I agree that we don't want the charter to be littered with jargon but the
reality is we are attempting to solve problems in a domain that has a long
history and a lot of domain specific language that we can't get away from.

Also, we will struggle to avoid some level of explanation around words or
phrases we use that can be interpreted differently by different people in
different context. The glossary is not always used to educate the reader
about a word/phrase they don't know but also provide the specific
definition that is appropriate for it's use in this context.

As an example, I believe the phrase "payment scheme" is well understood by
the majority of the group but as has been illustrated in the review of the
use cases not everyone outside the group agrees on the use of the phrase or
it's accepted definition. In my opinion, trying to avoid this phrase will
make the charter less readable so we need a mechanism to explain these
domain specific words/phrases.


> > passes through the Web context
>
> Strike "context", it's not necessary to be overly pedantic about "the
> Web" in this particular paragraph.
>

+1 - doesn't change the meaning


> > At that point much
>
> Missing comma?
>

+1 - will change to "At that point, much"


>
> > typically outside of the "Web context."
>
> We shouldn't invent new terminology for this. Just use "Web". It's not
> entirely accurate, but I don't think it needs to be to get the point
> across.
>
>
+1 - doesn't change the meaning


> > Unfortunately these efforts
>
> Missing comma, the rest of the sentence feels awkward.
>

+1 - Will change to "Unfortunately, these efforts"

> 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).


> A similar analogy was one that I heard of for search engines back in the
> day: the card catalog. You see, a search engine is like a card catalog
> in a library. It organizes information so when you start typing, the
> drawers of the catalog automatically fly open and the cards of
> importance fly out of the drawers and arrange themselves in front of you
> in order of importance. We don't explain search to people like this
> today, and most youngsters have never used a card catalog in their life
> (why would they, when there are search engines!).
>

I disagree that "wallet" it is a bad metaphor or that search/discovery are
better.

If I make a payment today, I take out my wallet, select a payment
instrument (or use a stored value token - cash) and make the payment. If
the payee needs some info like my identity, then I take my driver's license
out of my wallet and share the information on there with them. If we get
this standard right the process online will be identical (albeit the
additional data piece may only be standardized in later versions). The
payee site will request a payment, I will select a payment instrument from
my wallet (which has intelligently narrowed down the list of options to
suit the context) and make the payment. The advantage of a digital wallet
is it can accommodate all sorts of new payment schemes like credit-push
based systems and seamlessly handle hundreds of payment options without
ruining the user experience.

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. In time it may be that the best wallets are capable of
doing this but I don't see this as a requirement for standardization.

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.


> We're moving toward "personal data spaces"... bits of the Web that you
> own, contain your information, and belong to you. Unfortunately, no one
> knows what those are, so we're in this weird spot describing this
> skeumorph (the wallet) that will hopefully be outmoded by much of the
> work we'll be doing over the next couple of years.
>

I believe that we will ultimately define a Web payment scheme that will
resemble what you are describing. This is certainly the intention of the
IoV CG. However, I expect this scheme to co-exist with the schemes that are
around today. User's will proactively choose to use a wallet that supports
the "Web payment scheme" and this wallet will discover the best pay to make
a payment based on the available instruments the payer has and the terms
offered by the payee.

I don't think that is in scope for this WG yet.


>
> 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).


> > Though not a requirement for this charter, the group may define APIs
> >  that may also be used outside of a browser context
>
> -1, the group has to define REST APIs that can be used outside of a
> browser context.
>
> If we don't do that, the new gatekeeper are the browsers and that's not
> good for anyone (even the browser vendors).
>
>
I don't understand where these REST API's would be. Between which two
entities? The only scenario I can think of is between the browser and a
cloud-wallet but that interaction doesn't necessarily have to be
implemented through a REST API.

Let's assume a I have a cloud-based wallet at http://wallet.com/ahopebailie
and I have configured my browser to use this as my wallet. The browser
get's a payment request via the new browser API we have defined containing
the terms of a payment and a large set of supported payment schemes.

How do you imagine the browser passing this request to the wallet? I would
say a simple POST to that URL in a new Window is sufficient and the return
from the cloud-wallet will be another call to the browser API (from within
the wallet window).

We could come up with a more complex set of interactions but I don't think
we should assume that will be the case by mandating that we'll define REST
APIs. I'm not sure of a precedent where a W3C WG has defined REST APIs and
I think that's because when you do you start to step outside the scope of
what we should be standardizing in this group.


> > where a wallet serves as an aggregator of other wallets
>
> I kind of understand where this is going, but it doesn't really make a
> whole lot of sense. Thinking of the piece of software we're defining as,
> to borrow some networking lingo, a "wallet switch" is a better way to
> think about it, IMHO.
>
> In fact, we might want to put a bit more thinking into describing part
> of what we're doing as specifying a "payment service discovery"
> mechanism for people.
>

This is a user choice issue. Many users will simply use the wallet they are
comfortable with (provided by their bank, ships with their OS, built into
their browser). We can't try to define a standard that explicitly takes
away the market positions of the companies that own the majority of
browsers and OS's but we can make sure that there is a standard for
interoperability and so there is a level playing field for competition.

As you say, we don't want the browser vendors to have to implement a
payment discovery mechanism putting them in the critical path. However,
they are an inalienable proxy for the communications so the easiest model
is to say a browser must allow a user to define where to proxy these
payment requests (a single wallet) and then ensure that the interface we
standardise can be aggregated so that the user can configure the browser to
send requests to a wallet aggregator service (that looks to the browser
like a wallet) and then that aggregator service does the discovery work.

If the standard is well designed there will be an opportunity for vendors
to provide wallets that can do all sorts of great things, aggregating other
wallets being one of them. Our job is not to innovate but to allow the
market to do so freely.


>
> > confirmation of the terms and sending of any requested
>
> Use an oxford comma, please.
>

+1 - Will change to "confirmation of the terms, and sending of any
requested"


>
> > Recommendation-track deliverables Web Transactions 1.0
>
> -1, we need at least three Rec-track deliverables related to API. The
> first one needs to cover message formats and protocols (these use the
> vocabularies work). The second one needs to cover REST APIs that are
> exposed at payment service providers and websites. The third one needs
> to define what the WebIDL interface is for the browser.
>
> We need these three so that the REC-track deliverables match what the
> rest of the document is saying we're going to do. Having built a few of
> these systems, you can't accomplish what we're trying to accomplish with
> just a WebIDL interface and a few vocabularies.
>
>
As discussed, I don't think it's appropriate to list a REST API deliverable
if we aren't certain one will be required. I'm not convinced that we do
need one but let's discuss on Thursday.

The API's at payment service providers exist today. They are not
standardised because they don't need to be. They are specific to each
payment scheme they implement. The API's used by Websites will be the
WebIDL interfaces exposed via the browser.

I think we should include a WebIDL API for registration so that there is a
standard way for a wallet to request that it become the user's default
wallet (scenario 1) and also for payment instruments to request inclusion
in the wallet (scenario 2).

Scenario 1: I visit the PayPal website and PayPal can request that they be
my wallet. The browser asks me to choose Yes or No and also allows me to
disable these kinds of requests in future for this site or all sites. I
choose yes and my browser now registers
https://paypal.com/wallet/ahopebailie as my wallet endpoint.

Scenario 2: I am on my bank's website and my bank requests that it add my
bank card to my wallet. My browser prompts me to add the card and when I
say Yes a request is proxied to the PayPal wallet endpoint to instruct
PayPal to add the card to my wallet.

These need some further thought and discussion but probably not before the
WG takes this on and digs into the details.


> > Should this be "best practices" or a technical specification?
>
> Registration and discovery MUST be a technical spec. I don't think it's
> possible to get interoperability w/o a REC-track deliverable. The good
> news is that this can be part of the WebIDL.
>
>
+ 1 as discussed above although not suggesting this is the only way it
would work. Just an idea.


> > Recommendation-track deliverables
>
> The section should also specify that the group may split/regroup
> deliverables as it sees fit to accomplish the goals set forth in the
> charter.
>

+1 I think there will be a lot of discussion still about how to do this :)


>
> > Dependencies and Liaisons
>
> Missing Web Payments CG and Credentials CG.
>
>
+ 1 will add


> > may consume for each participant; for editors
>
> Seems like an unfinished sentence?
>

Yes, will need to ask Ian what happened there, I think that's boiler plate
stuff that needs to be updated still.


>
> > public-paymentsarch-wg@w3.org
>
> Change to public-webpayments-wg@w3.org
>
>
+1 will do

[1] http://techcrunch.com/2015/06/08/apple-rebrands-passbook-to-wallet/