- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 15 Aug 2016 13:20:52 -0400
- To: Web Payments WG <public-payments-wg@w3.org>
Regarding the recent call for consensus on publishing the HTTP API and
Core Messages specifications:
Digital Bazaar votes in favor (yes) of publishing the HTTP API. We also
vote in favor (yes) of publishing the Core Messages specification and
suggest renaming it to "HTTP API Core Messages" to address Ripple's
publication concerns.
Our rationale for voting in favor of both specifications can be found at
this blog post.
http://manu.sporny.org/2016/yes-to-http-api/
The text content of the blog post above included below for the purposes
of archival at W3C.
-----------------
Advancing the Web Payments HTTP API and Core Messages
Summary: This blog post strongly recommends that the Web Payments
HTTP API and Core Messages work be allowed to proceed at W3C.
For the past six years, the W3C has had a Web Payments initiative
in one form or another. First came the Web Payments Community
Group (2010), then the Web Payments Interest Group (2014), and now
the Web Payments Working Group (2015). The title of each of those
groups share two very important words: “Web” and “Payments”.
“Payments” are a big and complex landscape and there have been
international standards in this space for a very long time. These
standards are used over a variety of channels, protocols, and
networks. [10]ISO-8583 (credit cards), [11]ISO-20022 (inter-bank
messages), [12]ISO-13616 (international bank account numbers), the
list is long and it has taken decades to get this work to where it
is today. We should take these messaging standards into account
while doing our work.
The “Web” is a big and complex landscape as well. The Web has its
own set of standards; [13]HTML, [14]HTTP, [15]URL, the list is
equally long with many years of effort to get this work to where
it is today. Like payments, there are also many sorts of devices
on the Web that access the network in many different ways. People
are most familiar with the Web browser as a way to access the Web,
but tend to be unaware that many other systems such as banks,
business-to-business commerce systems, phones, televisions, and
now increasingly appliances, cars, and home utility meters also
use the Web to provide basic functionality. The protocol that
these systems use is often HTTP (outside of the Web browser) and
those systems also need to initiate payments.
It seems as if the Web Payments Working Group is poised to delay
the Core Messaging and HTTP API. This is important work that the
group is [16]chartered to deliver. The remainder of this blog post
elaborates on why delaying this work is not in the best interest
of the Web.
Why a Web Payments HTTP API is Important
At least 33% of all payments[[17]1
][[18]2], like subscriptions and automatic bill payment, are
non-interactive. The Web Payments Working Group has chosen to
deprioritize those use cases for the past 10 months. The Web
Payments Working Group charter expires in 14 months. We’re almost
halfway down the road with no [19]First Public Working Draft of an
HTTP API or Web Payments Core Messages, and given the current rate
of progress and way we’re operating (working on specifications in
a serial manner instead of in parallel), there is a real danger
that the charter will expire before we get the HTTP API out there.
The Case Against the Web Payments HTTP API and Core Messages
Some in the group have warned against publication of the Web
Payments HTTP API and Core Messages specification on the following
grounds:
1. The Web Payments HTTP API and Core Messages are a low
priority.
2. There is a lack of clear support.
3. There is low interest from implementers in the group.
4. The use cases are not yet well understood.
5. It’s too soon to conclude that payment messages will share
common parts between the Browser API and the HTTP API.
While some of the arguments seem reasonable on the surface,
deconstructing them shows that only one side of the story is being
told. Let’s analyze each argument to see where we end up.
The Web Payments HTTP API and Core Messages are a low priority.
The group decided that the Web Payments HTTP API and Core Messages
specs were a relatively lower priority than the Browser API and
the Payment Apps API until June 2016. There was consensus around
this in the group and our company agreed with that consensus. What
we did not agree to is that the HTTP API and Core Messages are a
low priority in the sense that it’s work that we really don’t need
to do. One of the deliverables in the charter of the Working Group
is a [20]Web Payments Messages Recommendation. The Charter also
specifies that “request messages are passed to a server-side
wallet, for example via HTTP, JavaScript, or some other approach”.
Our company was involved in the writing of the charter of this
group and we certainly intended the language of the charter to
include HTTP, which it does.
So, while these specs may be lower priority, it’s work that we are
chartered to do. This work was one of the reasons that our company
joined the Web Payments Working Group. Delaying this work is
making a number of us very concerned about what the end result is
going to look like. The fact that there is no guiding architecture
or design document for the group makes the situation even worse.
The group is waiting for an architecture to emerge and that is
troubling because we only have around 8 months left to figure this
out and then 6 months to get implementations and testing sorted.
One way to combat the uncertainty is to do work in parallel as it
will help us uncover issues sooner than at the end, when it will
be too late.
There is a lack of clear support.
In the list of concerns, it was noted that:
“Activity on the issue lists and the repositories for these
deliverables has been limited to two organizations… This suggests
that the Working Group as a whole is not engaged in this work.”
Previous iterations of the HTTP API and Core Messages
specifications have been in development for more than 5 years with
far more than two organizations collaborating on the documents. It
is true that there has been a lack of engagement in the Web
Payments Working Group, primarily because the work was
deprioritized. That being said, there are only ever so many people
that actively work on a given specification. We need to let people
who are willing and able to work on these specifications to
proceed in parallel with the other documents that the group is
working on.
There is low interest from implementers in the group.
We were asked to not engage the group, which we didn’t, and still
ended up with two implementations and another commitment to
implement. Note that this is before First Public Working Draft.
Commitments to implement are typically not requested until
entering Candidate Recommendation, so that there is now a request
for implementation commitments before a First Public Working Draft
is strange and not a requirement per the W3C Process.
If the group is going to require implementations as a prerequisite
for First Public Working Group publication, then these new
requirements should apply equally to all specifications developed
by the group. I personally think this requirement is onerous and
sets a bad precedent as it raises the bar for starting work in the
group so high that it’ll result in a number of good initiatives
being halted before they have a chance to get a foothold in the
group. For example, I expect that the SEPA Credit Transfer and
crypto-currency payment methods will languish in the group as a
result of this requirement.
The use cases are not yet well understood.
It has also been asserted that the basic use cases for the Web
Payments HTTP API are not well understood. We have had a use cases
document for quite a while now, which makes this assertion shaky.
To restate what has been said before in the group, the generalized
use case for the HTTP API is simple:
A piece of software (that is not a web browser) operating on
behalf of a payer attempts to access a service on a website that
requires payment. The payee software provides a payment request to
the payer software. The payment request is processed and access is
granted to the service.
Any system that may need to process payments in an automated
fashion could leverage the HTTP API to do so. Remember, at least
33% of all payments are automated and perhaps many more could be
automated if there were an international standard for doing so.
There are more use cases that would benefit from an HTTP API that
were identified years ago and placed into the Web Payments Use
Cases document: [21]Point of Sale, [22]Mobile, [23]Freemium,
[24]Pre-auth, [25]Trialware, [26]In-Vehicle, [27]Subscription,
[28]Invoices, [29]Store Credit, [30]Automatic Selection,
[31]Payer-initiated, and [32]Electronic Receipts. Additional use
cases from the W3C Automotive Working Group related to paying for
parking, tolls, and gasoline have been proposed as well.
The use cases have been understood for quite some time.
It’s too soon to conclude that payment messages will share common parts
between the Browser API and the HTTP API.
The work has already been done to determine if there are common
parts and those that have done the work have discovered around 80%
overlap between the Browser API messages and the HTTP API
messages. Even if this were not the case, I had suggested that we
could deal with the concerns in at least two ways:
1. The first was to mark this concern as an issue in the
specification before publication.
2. The second was to relabel the “Core Messages” as “HTTP Core
Messages” and change the label back if the group was able to
reconcile the messages between the Browser API and the HTTP
API.
These options were not surfaced to the group in the call for
consensus, which is frustrating.
The long term effects of pushing off discussion of core messages,
however, are more concerning. If we cannot find common messages,
then the road we’re headed down is one where a developer will have
to use different Web Payments messages if payment is initiated via
the browser vs. non-browser software. In addition, this further
confuses our relationship to ISO-20022 and ISO-8583 and will make
Web developers lives far complex than necessary. We’re advocating
for two ways of doing something when we should be striving for
convergence.
The group is chartered to deliver a [33]Web Payments Messages
Recommendation; I suggest we do that. We are more than 40% of the
way through our chartered timeline and we haven’t even started
having this discussion yet. We need to get this document sorted as
soon as possible.
The Problem With Our Priorities
The problem with our priorities is that we have placed the Browser
API front-and-center in the group. The group did this for two
reasons:
1. A subset of the group wanted to improve the “checkout
experience” and iterate quickly instead of focusing on
initiating payments, which was more basic and easier to
accomplish.
2. A subset of the group was very concerned that the browser
vendors would lose interest if their work was not done first.
I understand and sympathize with both of these realities, but as a
result, the majority of other organizations in the group are now
non-browser second-class citizens. This is not a new dynamic at
W3C; it happens regularly, and as one of the smaller W3C member
companies, it is thoroughly frustrating.
It would be more accurate to have named ourselves the Browser
Payments Working Group because that is primarily what we’ve been
working on since its inception and if we don’t correct course,
that is all we will have time to do. This focus on the browser
checkout experience and pushing things out quickly without much
thought to the architecture of what we’re building does result in
“product” getting out there faster. It is also short-sighted,
results in technical debt, and makes it harder to reconcile things
like the HTTP API and Core Messages after the Browser API is
“fully baked”. We are supportive of browser specifications, but we
are not supportive of only browser specifications.
This approach is causing the design of the Web Payments ecosystem
to be influenced by the way things are done in browsers to a
degree that is deeply concerning. Those of us in the group that
are concerned with this direction have been asked to not
“distract” the group by raising concerns related to the HTTP API
and Core Messages specifications. “Payments” and the “Web” are
much bigger than just browsers, it’s time that the group started
acting accordingly.
Parallel and Non-Blocking is a Better Approach
The Web Payments Working Group has been working on specifications
in a serial fashion since the inception of the group. The charter
expires in 14 months and we typically need around 6 months to get
implementations and testing done. That means we really only have 8
months left to wrap up the specs. We’re not going to get there by
working on specs in a serial fashion.
We need to start working on these issues in parallel. We should
stop blocking people that are motivated to work on specifications
that are needed in order for the work to be successful. Other
groups work in this fashion. For example, the Web Apps Sec group
has [34]over 13 specs that they’re working on, many of them in
parallel. The same is true for the Web Apps working group, which
has roughly [35]32 specs that it’s working on, often in parallel.
These are extremes, but so is only focusing on one specification
at a time in a Working Group.
We should start working in parallel. Let’s publish the HTTP API
and HTTP Core Messages specifications as First Public Working
Drafts and get on with it.
References
10. https://en.wikipedia.org/wiki/ISO_8583
11. https://en.wikipedia.org/wiki/ISO_20022
12. https://en.wikipedia.org/wiki/International_Bank_Account_Number
13. https://en.wikipedia.org/wiki/HTML
14. https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
15. https://en.wikipedia.org/wiki/Uniform_Resource_Locator
16. https://www.w3.org/Payments/WG/charter-201510.html#deliverables
17.
https://www.nacha.org/news/ach-volume-increases-23-billion-payments-2014
18. http://creditcardforum.com/blog/credit-card-statistics/
19. https://www.w3.org/2015/Process-20150901/#first-wd
20. https://www.w3.org/Payments/WG/charter-201510.html#deliverables
21. https://www.w3.org/TR/web-payments-use-cases/#uc-pos-kiosk
22. https://www.w3.org/TR/web-payments-use-cases/#uc-mobile
23. https://www.w3.org/TR/web-payments-use-cases/#uc-freemium
24. https://www.w3.org/TR/web-payments-use-cases/#uc-preauth
25. https://www.w3.org/TR/web-payments-use-cases/#uc-trialware
26. https://www.w3.org/TR/web-payments-use-cases/#uc-vehicle
27. https://www.w3.org/TR/web-payments-use-cases/#uc-subscription
28. https://www.w3.org/TR/web-payments-use-cases/#uc-invoices
29. https://www.w3.org/TR/web-payments-use-cases/#uc-store-credit
30. https://www.w3.org/TR/web-payments-use-cases/#uc-automatic-selection
31. https://www.w3.org/TR/web-payments-use-cases/#uc-payer-initiated
32. https://www.w3.org/TR/web-payments-use-cases/#uc-electronic-receipts
33. https://www.w3.org/Payments/WG/charter-201510.html#deliverables
34. https://www.w3.org/2015/03/webappsec-charter-2015.html#deliverables
35. https://www.w3.org/2014/06/webapps-charter.html#deliverables
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Web Browser API Incubation Anti-Pattern
http://manu.sporny.org/2016/browser-api-incubation-antipattern/
Received on Monday, 15 August 2016 17:21:16 UTC