Re: [w3c/webpayments-method-identifiers] Why URLs? (#9)

I think what is getting lost in this conversation -- especially for those who haven't been following the discussion for the past several months -- is that these URLs are just identifiers. They don't have security properties associated with their origins.

Backing up: what we want is a delegation model that allows third parties to mint new, guaranteed unique identifiers for their payment methods (NOTE: PAYMENT METHODS, NOT PAYMENT APPS -- there is an n-to-m mapping of methods to apps) without having to interact with the W3C in order to do so. URLs are an easy way to go about doing so, although other things would work as well. If the WG is willing to take the assertion that URLs are an anti-pattern due to their historical baggage (e.g., ability to resolve, incorrect assumptions around equality), then we can consider other approaches to achieve the same goal. Some approaches might include:
- URNs, with a subdelgation model underneath the top level. E.g., W3C-issued URNs would be something like `urn:payment:w3c:basic-card`, while any third party could use an issued, fully-qualified domain under payment: `urn:payment:bobpay.com:bobpay1`
- Basic strings for W3C-issued values (e.g., `basic-card`), and some other format for third parties; e.g.:
 - UUIDs for third-party values (e.g., `{f3653ce8-048e-4a17-81b9-73ecdc03daf5}` for "bobpay v1"
 - Strings qualified by domain name for third-party values (e.g., `bobpay.com|bobpay1`)
 - To avoid the concerns of domains being re-issued, we could use strings qualified by some other unique, per-organization value for third-party values (e.g., if we used [enterprise numbers](http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers) : `24829|bobpay1`)

Now, I'm also hearing that the ability to resolve these identifiers is a _desired feature_, although opinions seem to vary on what exactly that feature is. I think we need to have a much better view about exactly what the goals of resolution are before we take that on as a requirement that constrains our choice.

-- 
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-method-identifiers/issues/9#issuecomment-240218974