Re: [w3c/webpayments-payment-apps-api] Multiple payment apps per origin (#98)

I think much of the confusion in this thread has to do with how a particular origin decides to divide its own code (into N many Service Workers) and whether or not the concept of a "Payment App" is *bound* to a Service Worker.

For those who are using the Working Group's original understanding of a "Payment App":

The argument here is that there is no 1:1 relationship between a Payment App and a Service Worker. A Service Worker is simply a division of labor mechanism for an origin. When we have said, in the past, that a "Payment App is just a Service Worker", that was a mistake. It is true that we will use Service Worker(s) to *implement* Payment Apps. But that's just because it's the browser's mechanism for writing code that gets registered to run in the background, without the user necessarily having to revisit the origin from whence it came.

A Payment App, due to the existing browser architecture, may cross the boundary of a single Service Worker. So we should not equate these two things. We should not be telling developers how to divide their origin's Payment App code. They can use as many Service Workers as they would like.

All we need a way to execute code without requiring the user to visit a web page. We need a way to ask the user for their consent to handle payments. That's what Service Workers provide.

I recommend we should stop talking about a "Payment App" registering itself. That will never happen -- it mixes our conceptual model and it confuses everyone. Those unfamiliar with our architecture and terminology are only thinking of an "app" as "the code from an origin". There is no other division. Only an origin can register what we've been calling a "Payment App".

Furthermore, there would be user consent required (from the browser) when this registration happens. The user consent is required when an *origin* asks the user if it can be allowed to "handle payment". The browser architecture and security model currently only understands one boundary: the origin. That means that any user consent that is required from the browser must be origin-bound. In other words, an origin may ask the user to grant permission to *an origin*. Nothing else.

So, when a user provides consent to handling payment through the browser, it means that they consent to allowing the entire *origin* to install Payment Apps (that will handle payment requests) at will. It has no ability to manage user consent at a more granular level (i.e., within an origin).

Now, this does not mean that we can't surface more information from an origin for the user to see in some UI. But, as far as the browser is concerned, we have already been given permission to do this. If we're going to ask for user consent to show these items, it's up to the origin to surface a UI to ask the user. Otherwise we'd be trying to invent something new that deviates from the browser's existing architecture and security model.

Moving on -- I'll leave whether or not we should maintain the terminology "Payment App" aside. What we should not do is talk about them as registering themselves. We should separate how we talk about the code an origin is running from what is effectively our "grouping" of an end user experience that a particular origin provides. That's what a Payment App really is, IMO.

While we came up with "Payment Apps" by thinking about the various roles that exist in a Web Payments ecosystem, I think what the Working Group has understood to be a "Payment App" in these implementation discussions has largely been driven from the end user's perspective:

It should be an icon + title that the end user uses to identify a particular experience. They expect that by selecting it or by selecting an item that is associated with it (through some kind of encapsulating indicator on the UI) that they will be choosing to have the same experience they had the last time they made that choice.

I believe that how a particular origin manages this experience (or experiences) is totally orthogonal to how it is surfaced for the end user, e.g. the origin may use as many Service Workers as its developers desire. We need to accept that reality and move on to talking about what will be surfaced, whether or not it can be done securely, and how it enables multiple "Payment Apps" from the same origin given that it appears to be a requirement.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-payment-apps-api/issues/98#issuecomment-275733813