Re: [w3c/webpayments-payment-apps-api] The relationship between payment apps and service workers (#33)

Great to see broad consensus on using ServiceWorkers. A question remains: what should we do with manifests, if anything? Let me try to convince you that we need manifests.

Here's why I think manifests are useful. Suppose a merchant website at `https://shop.com` calls `PaymentRequest` with a supported payment method of `https://bobpay.xyz`. The user has installed a Service Worker from `https://alicepay.xyz` that supports `https://bobpay.xyz` as a payment method. Should the browser allow AlicePay to respond to BobPay's payment method? One way to authorize AlicePay is to check `https://bobpay.xyz/payment-manifest.json` to see if there're any restrictions in there. If BobPay's `payment-manifest.json` specifies no restrictions or explicitly allows AlicePay to use its payment method, then the browser should show AlicePay as one of the payment app options.

Now that (I hope) you're convinced of usefulness of manifest files, what should be inside of them? These manifests specify payment app restrictions, if any. Restrictions can be expressed as a whitelist of allowed payment apps.

How should payment apps be identified? Service Workers can be downloaded from the web. The URLs where they reside can serve as the payment app identifiers. So the service worker at `https://bobpay.xyz/sw.js`, for example, can be the payment app identified as `https://bobpay.xyz`. So let's go with URLs to identify payment apps.

Example `https://bobpay.xyz/payment-manifest.json` file with a whitelist of payment apps:

```json
{
  "externally_supported_apps": ["https://alicepay.xyz", "https://charliepay.xyz"]
}
```

Example `https://bobpay.xyz/payment-manifest.json` file without payment app restrictions:

```json
{
  "externally_supported_apps": ["*"]
}
```

Browsers need to know how to display the payment app Service Workers in UI, so the user can select them. For example, browsers may need the title of a payment app along with its icon in several sizes. The web already has a way to specify this through manifests.

Before we get into specifying payment app Service Worker titles and icons, let's not forget native apps, either. Payment apps can be Service Workers, Android apps, iOS apps, Windows apps, etc. Therefore, it's useful to split up `payment-manifest.json` into several sections: "web", "android", "ios", "windows", etc.

* The "web" section can specify:
  * Human-readable title of the app.
  * App icons in several sizes.
  * (Service Worker will register itself, so there's no need to specify the location of the service worker.)

* The "android" section can specify:
  * A way to identify a payment app (package name and signing certificate fingerprint).
  * Where the app can be downloaded, if it's not installed yet.
  * (There's no need to specify icons and title, because that is already available from the OS.)

* And so on...

I think you see the pattern. Here's an example of what `https://bobpay.xyz/payment-manifest.json` might look like. Two points before we read into this too much:

1. I do not presume that any of this is set in stone and final.
1. Native apps should live at extension points of the spec. The spec should describe only web apps, IMHO.

```js
{
  // Other payment apps that can use "http://bobpay.xyz" payment method.
  "externally_supported_apps": ["https://alicepay.xyz", "https://charliepay.xyz"],

  // Description of the Service Worker payment app "https://bobpay.xyz".
  "web": {
    "name": "BobPay - The World's Best Way to Pay",
    "short_name": "BobPay",
    "icons": []
  },

  // Descriptions of the Android payment app for "https://bobpay.xyz".
  // Using a list here enables support for developer version and
  // production version of the Android app, for example.
  "android": [{
    "platforms": {
        // Where the app can be downloaded, if it's not installed.
        "play": "https://play.google.com/store/apps/details?id=xyz.bobpay.app1",
        "mios": "https://mi.cn/store/id=xyz.bobpay.app1"
       },
      // Next two fields provide a way to authorize a locally installed app.
      "package": "com.example.app1",
      "sha256_cert_fingerprints": ["14:6D:E9:83:C5:73:06:50"]
  }],

  // Descriptions of the iOS payment app for "https://bobpay.xyz".
  "ios": "TBD"

  // And so on...
}
```

Thoughts?

-- 
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/33#issuecomment-245356298