Re: [w3c/webpayments-payment-apps-api] Payment app identifier to manifest filename mapping (#48)

> how to leverage (and not respecify) Web Manifest

Hooray! Another reason it is great to have @marcoscaceres involved in this.

> The "scope" of the service worker is its primary key

This is the point I have been trying make :smile: (See https://github.com/w3c/webpayments-payment-apps-api/issues/48#issuecomment-261786242)

Web-based payment apps **ARE** service workers, therefor we should identify a web based payment app **the same** way a Service Worker is identified (using the scope URL).

**Can we agree that the thing we are calling the _Payment App Identifier_ must be the scope of the service worker?**

The challenge now is providing some sort of discovery mechanism to the browser for recommended payment apps. If the payee simply gives the browser a list of _Payment App Identifiers_ (scope URLs) then the browser is able to determine if the apps are already installed or not and for those that are it has meta-info like the icon and label.

But, for all of the apps that are not installed the browser can't go any further. My compromise was to define a convention for the relative location of either the Service Worker script (`./payment-app.js`) or a payment app manifest file (./manifest.json`).

In this case the browser can at least know where to go to install the service worker. Without this, it is stuck.

The advantage of pointing to a manifest file is that the browser can get information about the app without executing the service worker registration logic.

The alternative is that for each recommended payment app the merchant supplies both the payment app identifier (scope URL) and a URL to the manifest or service worker script.

So the recommended apps data in the payment request might look something like this:

```
   [{ 
      "id" : "http://bobpay.com/paymentapp/v1", 
      "manifest" : "http://bobpay.com/paymentapp/v1/manifest.json"
    },
    {
      "id" : "http://alicepay.com/", 
      "script" : "http://alicepay.com/sw.js"
    }]
```

**1. Do we prefer a convention for a relative URL (assuming we will still decide if that should apply to script or manifest file or both)?**
**2. If we prefer a more verbose payment request as shown above, do we still want to support the idea of a manifest file that allows the browser to get data about the app without executing it's registration flow?**

I think that the security issue @jakearchibald raises about the security risk introduced if the app provides a logo and label, is very important. We've come up against this "How do we verify an apps integrity?" question multiple times and I don't know if we have a good answer.

Presenting the user with a list of URLs as "recommended payment apps" seems like a non-starter, no?



-- 
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/48#issuecomment-274076316