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

Here is my understanding of where we have arrived:

* We have discussed two use cases where we need to compare identifiers:
   - Payment app recommendations. ("Has the user already registered this payment app?")
   - Payment app permissions from payment method manifest files. ("Hey browser, you are
      authorized to let people register this payment app to support this payment method that
      I own.")

   Both of these use cases ultimately relate to permissions, and for both of these I have understood
   that origin information suffices. Thus, there is no need here for a new kind of "payment app
   identifier"; we can just use origins.

* We also have discussed "how do people find the code of a Web-based payment app?" One way is 
   that they follow a URL, which loads code which does everything that's necessary. In this 
   scenario, there is no special new kind of "payment app identifier"; there is just a URL to some   
   code. And there might be different code bases on the same origin.

* We have also discussed this question: "If we refer to a payment app by origin, how can someone
   get from origin information to the code of a Web-based payment app?" One tentative answer
   has been: use script_url in Web App Manifest.

My summary, therefore, is that there is not currently a need for a special "payment app identifier."
For matching, we use origin. For finding code, we use ordinary URLs.

(I welcome comments on whether this is a fair summary, what is missing, etc.)
Ian
  

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