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

> I'm not sure what this refers to. Neither the existing setManifest() specification text, nor the proposal in #95 ties Payment Option 1:1 to a Service Worker. Each Service Worker can register 0, 1 or many Payment Options.

You are talking about the options and I am talking about apps. The choices presented to a user exist at two levels. The user is presented with a bunch of "apps" and under each app is a bunch of "options". The most common use of options will be to present different instruments that the app has stored.

The images from @marcoscaceres in https://github.com/w3c/webpayments-payment-apps-api/issues/98#issuecomment-275581133 are good illustrative examples.

My suggestion is that if we want to allow multiple "apps" per origin then the only way to do that is using scopes and these are defined by either a manifest or by a SW itself during registration. (Note that the scope of a SW is it's unique identifier so if there is no manifest defining the scope then only one SW can be installed per scope)

> That does actually sound pretty nice, but then we are not doing Payment Options anymore. You're now describing a single entry per Payment App. Nothing wrong with that approach, although there might be advantages to having multiple Payment Options per Payment App too.

You can still do payment options. Any SW that registers an "option" will do so under the "app" under whose scope it is currently executing. If we go back to the example of your two apps from the same origin, if a SW with the scope https://people.opera.com/tommyt/blue/ registers an option, that option will appear under the Blue "app" in the user choices.

> Implementation-wise, this does probably require us to keep track of all Service Workers that belong to a Payment App. "Belong to" meaning either registered through the App Manifest, or from a page that is associated with the App Manifest. Not sure how easy this is. It might be feasible.

No, I think you'd track which SW's are within which scopes. i.e. A scope delimits the app boundary.

> This does not sound that great, though. Our current specification, where Payment Options are registered by the individual Service Worker, and Payment Request events are passed directly to the correct Service Worker feels much more precise and elegant. It solves the last problem you describe, too, by allowing any Service Worker to register and handle payments, regardless of whether has a relation to a Web App Manifest.

My proposal is modeled on how `fetch` events work. There is no context binding a single Serviceworker to an event.

An alternative is to take some inspiration from the Push API: https://www.w3.org/TR/push-api

The Push API defines a concept of a [push subscription](https://www.w3.org/TR/push-api/#push-subscription): _"A push subscription is a message delivery context established between the user agent and the push service on behalf of a webapp. Each push subscription is associated with a service worker registration and *a service worker registration has at most one push subscription*."_

If we followed this model, then perhaps we would allow one SW per "option"? 

Stealing from the push spec I'd imagine a SW registration (assuming the handle payments permission has been granted already) to look like:

```javascript
// https://example.com/serviceworker.js
this.onpaymentrequest = function(event) {
  // This handler will only be invoked if the user selects the "Acard ***1234" option
}

// https://example.com/webapp.js
const methods = ['basic-card'];
const label = "Acard ***1234"
navigator.serviceWorker.register('serviceworker.js').then(
  function(serviceWorkerRegistration) {
    serviceWorkerRegistration.paymentAppManager.addOption(methods, label).then(
      function(paymentOption) {     
      }, function(error) {
      }
    );
  });
```

Imagine the following registered in a user's browser:

```
Origin 1: https://wallet.com
      |- App 1:  Wallet.com App (scope: "./" )
                          |-  Option 1: Acard ****1234
                          |-  Option 2: Bcard ****3456
                          |-  Option 3: Bitcoin
Origin 2: https://banka.com
      |- App 1:  Bank A Business (scope: "./business")
                          |-  Option 1: Credit Transfer
                          |-  Option 2: Bank Cheque
                          |-  Option 3: Corp Card ****4567
      |- App 2:  Bank A Personal  (scope: "./business")
                          |-  Option 1: Acard ****1234
                          |-  Option 2: Loyalty Points
```
Ignoring manifests and icons for now, to get to this, I'd imagine the following needs to happen:

  1. A webapp at `wallet.com` is granted permission to handle payments.
  2. A SW at wallet.com is registered and adds Option 1: Acard ****1234
  3. Another SW at wallet.com is registered and adds Option 2: Bcard ****3456
  4. Another SW at wallet.com is registered and adds Option 3: Bitcoin

**Note:** There is no manifest so there is no icon for wallet.com and all options registered by SWs under this origin are assumed to be under the same "app".

Next...

  1. A webapp at `banka.com` is granted permission to handle payments.
  2. The browser processes an app manifest for an app called Bank A Business which defines it's scope as `https://banka.com/business`.
  3. The app manifest points to a SW which, when it is registered registers three additional SWs:
     1. A SW that adds Option 1: Credit Transfer
     2. Another SW that adds Option 2: Bank Cheque
     3. Another SW that adds Option 3: Corp Card ****4567

**Note:** Without the manifest there is no way to know that these three options are expected to be part of a single "app" as the scope is defined by the manifest and all three SWs are located within the scope of the app.

**Also Note:** SWs also have a scope and this has to be unique so we must assume each of these SWs will register itself with a unique scope.

Next...

  1. The webapp at `banka.com` already has permission to handle payments.
  2. The browser processes another app manifest for an app called Bank A Personal which defines it's scope as `https://banka.com/personal`.
  3. The app manifest points to a SW which, when it is registered registers three additional SWs:
     1. A SW that adds Option 1: Acard ****1234
     2. Another SW that adds Option 2: Loyalty Points

**Note:** This is a second "app" under the same origin, partitioned from the first using it's scope. This is not a security boundary as the apps are under the same origin but it is a logical boundary which the browser can use when deciding how to present the options to the user (group them under "apps").



-- 
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-278154966