Re: [webpayments] How are payment instruments registered? (#14)

@adrianhopebailie 

> There needs to be a globally unique id for the app that is known to the publisher and the mediator. If 
> the id is not provided by the publisher what would the publisher use to detect if their app is installed?

I understand the publisher's need. But if it's only the publisher's need, then that data can be private to the publisher. They MIGHT use URIs but they should not be obligated to use them if the data is only for internal use.

> At this stage there are a number of ways proposed that an app could be registered and not all of them are done via the browser so there is no way for the mediator to associate the app with an origin other than through some property of the app (like it's ID). 

That's a fair point. But it is not clear to me that a URI is the way to go (since I could easily put whatever URI I want in that field). There may be multiple ways to establish the origin with confidence; on the Web it might be through HTTP. Others may wish to use PKI. If we feel origin is important, I don't think URIs as strings do the job. (There may be a way to use URIs for access to services to authenticate origin dynamically, but I'm not well-versed in that sort of thing.)

>As we are developing a Web standard, it feels correct to me to use URLs as a platform independent way to identify the same app across various deployments.

In general, I would also lean toward using URIs as identifiers, but there are other considerations (such as "short strings are easier" like we're discussing on the other thread). Here the consideration is: does a URI really tell you the origin?

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/14#issuecomment-163691515