Web Payments Working Group Charter review (Manu)

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.

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

> passes through the Web context

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

> At that point much

Missing comma?

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

> Unfortunately these efforts

Missing comma, the rest of the sentence feels awkward.

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

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

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.

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

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

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

> confirmation of the terms and sending of any requested

Use an oxford comma, please.

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

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

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

> Dependencies and Liaisons

Missing Web Payments CG and Credentials CG.

> may consume for each participant; for editors

Seems like an unfinished sentence?

> public-paymentsarch-wg@w3.org

Change to public-webpayments-wg@w3.org

-- 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/

Received on Tuesday, 7 July 2015 03:13:34 UTC