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

We need to think carefully about this because we are hitting the issue I raised before with @jakearchibald and @marcoscaceres about the browser not being able to get information about the payment without actually installing the ServiceWorker.

This was the use case I was trying to explain (badly) on the Manifest issue list and I think we haven't solved it yet.

Is it practical for the browser to fetch the `.js` and execute it in an isolated context to see if it registers a ServiceWorker and if it does then it has the data it needs (like a logo, supported methods etc)? The browser wouldn't actually install the ServiceWorker until the user decides to do so.

Or are we better off deriving a **manifest file** URL from the payment app identifier and having the URL of the `.js` file in that manifest?

This would mean the ServiceWorker `.js` file could be at any location where the scope is still the identifier.

  * Payment App Identifier = http://psp.example/app/
  * Service Worker Scope = http://psp.example/app/
  * Payment App manifest file = http://psp.example/app/payment-app.manifest
  * Payment App js file = *Any legal location given scope above, defined in the manifest*

This also solves the native app issue somewhat because the manifest can define where to get a native app in some browser defined way (already proposed in the manifest spec.


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