Re: Analysis of W3C Web Payments Specifications (2017)

Hi Manu,

Your analysis is 100% correct when looking from a Web(only) perspective.

The problem is that the wast majority of all implementers of the
PaymentRequest API will likely be targeting native payment applications
like Android Pay and Saturn [1].

One might believe that this is due to "historical reasons" but the naked
truth is that the Web platform still doesn't offer the capabilities needed
for security-oriented applications including access to TEEs.

Another reason for the preference of native applications is the logical
desire reusing investments in payment systems in a more universal way [2].

ServiceWorkers are cool but have serious drawbacks compared to native
applications also from a distribution point of view. The fate of the
PaymentHandler in the real world is yet to seen.

Yes, this departs quite a lot from the initial expectancies and promises
but that's what makes life interesting (and sometimes challenging); you
never really know for sure what's ahead!

Thanx,
Anders Rundgren

1] https://github.com/cyberphone/saturn/blob/master/PSD2.md#saturn---optimized-for-payments

2] https://www.nfcworld.com/2017/02/14/350165/norwegian-banks-join-dnb-make-vipps-single-mobile-wallet-customers/
"Vipps has ambitions to become a 360 degrees payment service for all situations," DNB says

On 2017-11-01 03:45, Manu Sporny wrote:
> 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
>

Received on Wednesday, 1 November 2017 06:11:56 UTC