Analysis of W3C Web Payments Specifications (2017)

Hi all,

We promised the Web Payments WG a high-level write up of our
polyfill implementation experiences before W3C TPAC 2017. Many thanks to
Dave Longley for helping to co-author this analysis.

Here is a link to the blog post:

http://manu.sporny.org/2017/w3c-web-payments/

The full text of the article is included below for archival purposes:

---------------------------------------------------------------------

The State of W3C Web Payments in 2017

   Challenges In Building a Sustainable Web Platform

   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:

   https://www.youtube.com/embed/Yb-gWT1t1Rg?rel=0

   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:

   http://manu.sporny.org/wp-content/uploads/2017/10/chart-2.png

   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:

   http://manu.sporny.org/wp-content/uploads/2017/10/chart.png

   The great news here is that this solution works right now in
   roughly 3.3 billion browsers, which is around 85% of the people
   using the Web today.

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:

   https://www.youtube.com/embed/bm3XBPB4cFY?rel=0

   Like the Web Payments polyfill, this solution works right now in
   roughly 3.3 billion browsers, which is around 85% of the people
   using the Web today.

   http://manu.sporny.org/wp-content/uploads/2017/10/chart-1.png

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 [13]Web Intents API, or [14]Web Share API,
   that's because they also fit this general pattern. There is a good
   write up of [15]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 [16]why convincing the Web
   Payments WG to design modular components for e-commerce failed. We
   had originally [17]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 [18]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 [19]increasing [20]number of
   [21]requests would be made to [22]add functionality into the API
   where said functionality [23]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 [24]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.

  13. https://www.w3.org/TR/web-intents/
  14. https://wicg.github.io/web-share/
  15. https://paul.kinlan.me/what-happened-to-web-intents/
  16. http://manu.sporny.org/2016/browser-api-incubation-antipattern/
  17.
https://docs.google.com/presentation/d/1OEoWZUb-hQKqjXRZqPmNakdwSHw9oclQc7-PfxJQomc/edit
  18. https://www.w3.org/2016/02/23-wpwg-minutes#api-layer
  19. https://github.com/w3c/payment-request/issues/639
  20. https://github.com/w3c/payment-request/issues/615
  21. https://github.com/w3c/payment-request/issues/145
  22. https://github.com/w3c/payment-request/issues/27
  23. https://github.com/w3c/payment-request/issues/145
  24. https://alistapart.com/article/application-cache-is-a-douchebag

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The State of W3C Web Payments in 2017
http://manu.sporny.org/2017/w3c-web-payments/

Received on Wednesday, 1 November 2017 02:45:56 UTC