- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Mon, 30 Jan 2017 22:26:44 -0500
- To: Adam Roach <abr@mozilla.com>, Ian Jacobs <ij@w3.org>, Payments WG <public-payments-wg@w3.org>
On 01/30/2017 07:07 PM, Adam Roach wrote: > On 1/30/17 12:58, Ian Jacobs wrote: >> Proposed way forward in light of recent threads >> >> I have endeavored to synthesize recent discussions and would like to see >> whether we can get to agreement on a model for payment apps: >> https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130 >> >> That proposal includes: >> >> • A proposed way forward >> • Issues where we have not yet converged (and commentary on current discussion) >> • Suggested resolutions to issues (based on point 1.) >> >> Even if there is not yet agreement on those points, I hope that the proposal >> helps frame the discussion. > > Thanks, Ian! I have some initial thoughts on this proposal; some aspects > of it are new to me, though, and may require additional consideration. > As my general statement regarding the priority of constituencies drew > fire on the call last week, I have highlighted the two specific > proposals that I believe are inverting these priorities. > > *Identity*: This is a radical departure in the meaning of "payment app." > For avoidance of doubt, I would propose ejecting the name "payment app" > altogether (since we're basically shutting down that concept if we adopt > this definition), and instead call these "payment web apps." I have > also heard non-trivial objections from people regarding the implicit > limitation here: this would limit a single origin from appearing in the > "list of things that users select" more than once. If we can get > explicit payment provider buy-on in this restriction, I'm fine; > otherwise, I have serious concerns that we're going down a path that > will be cleaner in the sense of theoretical purity, but fail to meet > author (merchant and/or payment provider) needs. > > *Registration*: This is a bit unclear. The notion here is that a service > worker makes itself part of a payment web app by registering for > payment-related events? As others have noted, it may be that "payment app" is not the best name here. It may make sense from an end user's perspective, but is confusing from other perspectives. I don't have an alternative name, but perhaps thinking about them in a different way could help us come up with one. When I hear "payment app", I start thinking that we're talking about some container for all of the code for a particular software program. And if the user selects it, then we'll "run that program". I think that's wrong headed here, given the browser architecture. It creates artificial restrictions like "only one payment app per origin", or "only one payment app per Service Worker". Instead, when the end user makes a selection during payment, all that really happens is we pass some hints to an origin about what they selected and what they want to do now. Then there's an expectation for the origin to handle payment on that basis. We have no say in how that origin organizes its code. The browser only understands the origin boundary; we shouldn't be trying to force our conceptual model into the browser model, we should be layering it on top of it. I think we should think of "payment apps" as simply a mechanism for origins to logically organize the entry points into various payment experiences it offers -- and to surface those entry points to the user in a way that can be communicated back to the origin when a selection is made. That's it. In order to give origins this flexibility, here is a slight tweak to Ian's proposal: To start, users must consent to give an origin permission to "handle payments". This permission grants origins the ability to register as many "payment apps" as they would like, when they would like, and to receive payment request events when one of their payment apps has been selected. This is the only user consent that the browser need to concern itself with, everything else is governed by the origin itself. These payment apps are merely used to identify different payment experiences at the same origin. How code is organized at the origin (the number of Service Workers, whatever else) is largely unrelated to these logical groupings. The origin should register an icon, title, and identifier for each payment app, as well as a set of supported payment methods. These can be changed granularly and as the origin sees fit. The origin may also potentially register additional icon and title information along with the payment methods so the browser may implement a more granular selection screen (and reduce the number of clicks a user must make to get through the process). The origin may ask the user for consent to register these payment apps, but this has nothing to do with any browser API. It's entirely up to the origin to decide how to implement this on their site. If they provide a good experience, the user won't revoke the origin's permission to handle payments. Taking this approach would enable a number of previously mentioned use cases, such as allowing the same origin to provide a "Personal Banking" experience and a "Business Banking" experience or allowing a service provider/aggregator origin to provide a number of different white-labeled payment experiences. -- Dave Longley CTO Digital Bazaar, Inc.
Received on Tuesday, 31 January 2017 03:27:16 UTC