Advancing the Web Payments HTTP API and Core Messages

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.

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
    1. The Web Payments HTTP API and Core Messages are a low
    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

   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

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



-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Web Browser API Incubation Anti-Pattern

Received on Monday, 15 August 2016 17:21:16 UTC