The State of W3C Web Payments in 2017


Challenges In Building a Sustainable Web Platform by Manu Sporny and Dave Longley

There is a general API pattern that is emerging at the World Wide Web Consortium (W3C) where the browser mediates the sharing of information between two different websites. For the purposes of this blog post, let’s call this pattern the “Web Handler” pattern. Web Handlers are popping up in places like the Web Payments Working Group, Verifiable Credentials Working Group, and Social Web Working Group. The problem is that these groups are not coordinating their solutions and are instead reinventing bits of the Web Platform in ways that are not reusable. This lack of coordination will most likely be bad for the Web.

This blog post is about drawing attention to this growing problem and suggesting a way to address it that doesn’t harm the long term health of the Web Platform.

The Web Payments Polyfill

Digital Bazaar recently announced a polyfill for the Payment Request and Payment Handler API. It enables two things to happen.

The first thing it enables is a “digital wallet” website, called a payment handler, that helps you manage payment interactions. You store your credit cards securely on the site and then provide the card information to merchants when you want to do a purchase. The second thing it does is enable a merchant to collect information from you during a purchase, such as credit card information, billing address, shipping address, email address, and phone number.

When a merchant asks you to pay for something, you typically:

  1. select the card you want to use,
  2. select a shipping address (for physical goods), and
  3. send the information to the merchant.

Here is a video demo of the Web Payments polyfill in action:

It’s one thing to mock up something that looks like it works, but implementations must demonstrate their level of conformance by passing tests from a W3C test suite. What you will find below is the current state of how Digital Bazaar’s polyfill does against the official W3C test suite:

As you can see, it passes 702 out of 832 tests and we don’t see any barriers to getting very close to passing 100% in the months to come.

The other thing that’s important for a polyfill is ensuring that it works in a wide variety of browsers including Google Chrome, Apple Safari, Mozilla Firefox, and Internet Explorer. Here is the current state, where the blue shows native support in Google Chrome on Android, with the Polyfill making up even more of the support in the rest of the browsers:

The great news here is that this solution is compatible with roughly 3.3 billion browsers today, which is around 85% of the people using the Web. In order to take advantage of this opportunity, just like the native implementations, the polyfill has to be deployed by merchants and payment app providers on their websites.

Credential Handler Polyfill

Digital Bazaar also recently announced that they have created an experimental polyfill for the Verifiable Credentials work. This polyfill enables a “digital wallet” website, called a credential handler, to help you manage your verifiable credential interactions. This feature enables websites to ask you for things like your shipping address, proof of age, professional qualifications, driver’s license, and other sorts of 3rd-party attested information that you may keep in your wallet. Here is a video demo of the Credential Handler polyfill in action:

Like the Web Payments polyfill, this solution is compatible with roughly 3.3 billion existing browsers, which is around 85% of the people using the Web today. Again, this doesn’t mean that 3.3 billion people are using it today, the polyfill still has to be deployed on issuer, verifier, and digital wallet websites to make that a reality.

General Problem Statement

There is a common Web Handler pattern evident in the above implementations that is likely to be repeated for sharing social information (friends) and data (such as media files) in the coming years. At this point, the general pattern is starting to become clear:

  • There is a website, called a Web Handler, that manages requests for information.
  • There is a website, called the Relying Party, that requests information from you.
  • There is a process, called Web Handler Registration, where the Web Handler asks for authorization to handle specific types of requests for you and you authorize it to do so.
  • There is a process, called Web Handler Request, where the Relying Party asks you to provide a specific piece of information, and the Browser asks you to select from a list of options (associated with Web Handlers) that are capable of providing the information.
  • There is a feature that enables a Web Handler to optionally open a task-specific or contextual window to provide a user interface.
  • There is a process, called Web Handler Processing, that generates an information response that is then approved by you and sent to the Relying Party via the Browser.

If this sounds like the Web Intents API, or Web Share API, that’s because they also fit this general pattern. There is a good write up of the reason the Web Intents API failed to gain traction. I won’t go into the details here, but the takeaway is that Web Intents did not fail because it wasn’t an important problem that needed to be solved, but rather because we needed more data, implementations, and use cases around the problem before we could make progress. We needed to identify the proper browser primitives before we could make progress. Hubris also played a part in its downfall.

Fundamentally, we didn’t have a general pattern or the right composable components identified when Web Intents failed in 2015, but we do now with the advent of Web Payments and Verifiable Credentials.

Two Years of the Web Payments WG

For those of you that have seen the Payment Request API, you may be wondering what happened to composability over the first two years of the Working Groups existence. Some of us did try to solve the Web Payments use cases using simpler, more composable primitives. There is a write up on why convincing the Web Payments WG to design modular components for e-commerce failed. We had originally wanted at least two layers; one layer to request payment (and that’s all it did), and another layer to provide Checkout API functionality (such as billing and shipping address collection). These two layers could be composed together, but in hindsight, even that was probably not the right level of abstraction. In the end, it didn’t matter as it became clear that the browser manufacturers wanted to execute upon a fairly monolithic design. Fast forward to today and that’s what we have.

Payment Request: A Monolithic API

When we had tried to convince the browser vendors that they were choosing a problematic approach, we were concerned that Payment Request would become a monolithic API. We were concerned that the API would bundle too many responsibilities into the same API in such a highly specialized way such that it couldn’t be reused in other parts of the Web Platform.

Our argument was that if the API design did not create core reusable primitives, it would not allow for it to be slotted in easily amongst other Web Platform features, maintaining a separation of concerns. It would instead create a barrier between the space where Web developers could compose primitives in their own creative ways and a new space where they must ask browser vendors for improvements because of a lack of control and extensibility via existing Web Platform features. We were therefore concerned that an increasing number of requests would be made to add functionality into the API where said functionality already exists or could exist in a core primitive elsewhere in the Web Platform.

Now that we have implemented the Payment Request API and pass 702 out of 832 tests, we truly understand what it takes to implement and program to the specification. We are also convinced that some of our concerns about the API have been realized. Payment Request is a monolithic API that confuses responsibilities and is so specialized that it can only ever be used for a very narrow set of use cases. To be clear, this doesn’t mean that Payment Request isn’t useful. It still is a sizeable step forward for the Web, even if it isn’t very composable.

This lack of composability will most likely harm its long term adoption and it will eventually be replaced by something more composable, just like AppCache was replaced by Service Workers, and how XMLHttpRequest is being replaced by Fetch. While developers love these new features, browsers will forever have the dead code of AppCache and XMLHttpRequest rotting in their code bases.

Ignoring Web Handlers at our Peril

We now know that there is a general pattern emerging among the Payments, Verifiable Credentials, and Social Web work:

  1. Relying Party: Request Information
  2. Browser: Select Web Handler
  3. Web Handler: Select and Deliver Information to Relying Party

We know, through implementation work we described above, that the code and data formats look very similar. We also know that there are other W3C Working Groups that are grappling with these cross-origin user-centric data sharing use cases.

If each of these Working Groups does what the Payment Request API does, we’ll expend three times the effort to create highly specific APIs that are only useful for the narrow set of use cases each Working Group has decided to work on. Compare this to expending far less effort to create the Web Handler API, with appropriate extension points, which would be able to address many more use cases than just Payments.

Components for Web Handlers

There are really only four composable components that we would have to create to solve the generalized Web Handler problem:

  1. Permissions that a user can grant to a website to let them manage information and perform actions for the user (payments, verifiable credentials, friends, media, etc.).
  2. A set of APIs for the Web Handler to register contextual hints that will be displayed by the browser when performing Web Handler selection.
  3. A set of APIs for Relying Parties to use when requesting information from the user.
  4. A task-specific or contextual window the Web Handler can open to present a user interface if necessary.

The W3C Process makes it difficult for Working Groups chartered to work on a more specific problem, like the Web Payments WG, to work at this level of abstraction. However, there is hope as Service Workers and Fetch do exist. Other Working Groups at W3C have successfully created composable APIs for the Web and the Web Payments work should not be an exception to the rule.

Conclusion

It should be illuminating that both the Web Payments API and the Credential Handler API were able to achieve 85% browser compatibility for 3.3 billion people without needing any new features from the browser. So, why are we spending so much time creating specifications for native code in the browser for something that doesn’t need a lot of native code in the browser?

The polyfill implementations reuse existing primitives like Service Worker, iframes, and postMessage. It is true that some parts of the security model and experience, such as the UI that a person uses to select the Web Handler, registration, and permission management would be best handled by native browser code, but the majority of the other functionality does not need native browser code. We were able to achieve a complete implementation of Payment Request and Payment Handler because there were existing composable APIs in the Web Platform that had nothing to do Web Payments, and that’s pretty neat.

When Web Intents failed, the pendulum swung far too aggressively in the other direction of highly specialized and focused APIs for the Web Platform. Overspecialization fundamentally harms innovation in the Web Platform as it creates unnecessarily restrictive environments for Web Developers and causes duplication of effort. For example, due to the design of the Payment Request API, merchants unnecessarily lose a significant amount of control over their checkout process. This is the danger of this new overspecialized API focus at W3C. It’s more work for a less flexible Web Platform.

The right thing to do for the Web Platform is to acknowledge this Web Handler pattern and build an API that fits the pattern, not merely charge ahead with what we have in Payment Request. However, one should be under no illusion that the Web Payments WG will drastically change its course as that would kick off an existential crisis in the group. If we’ve learned anything about W3C Working Groups over the past decade, it is that the larger they are, the less introspective and less likely they are to question their existence.

Whatever path the Web Payments Working Group chooses, the Web will get a neat new set of features around Payments, and that has exciting ramifications for the future of the Web Platform. Let’s just hope that future work can be reconfigured on top of lower-level primitives so that this trend of overspecialized APIs doesn’t continue, as that would have dire consequences for the future of the Web Platform.

Leave a Comment

Let us know your thoughts on this post but remember to play nicely folks!