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

> Using URNs is overengineering for no benefit.

This is a fair point. We settled on URNs so we could make the statement that all payment method identifiers are URIs. The extra boilerplate seems minimal and low cost to me, but curious what others think. I could be persuaded to go with a simple string. 

> URLs don't, origins do. Apps can have origins associated with them. If this is a goal (and it sounds reasonable at first blush), requiring that the URL not include any path data or fragment, and then just looking at the origin for identification, is a reasonable approach that is closer to matching with how people think of URLs.

Yes, agreed on origin. There are a few additional values to using URLs over origins:

1. It allows for multiple payment methods to exist at a single origin. There are a few uses cases where this is relevant, but I'd be okay saying that they need to get a unique origin for each payment method (easy enough with method1.domain.com and method2.domain.com). 

2. It seems more semantic at times to have path support. Take Android Pay for example. A payment method of "android.com" doesn't make sense. But a payment method of android.com/pay does make sense. It does seem a bit excessive to demand a subdomain to get the same semantic benefit that paths offer.

3. Easy versioning support (e.g. bobpay.xyz/payment-method/v1/). Again, subdomains could work here, but same potential issue. 

> If this is desired, then we must define exactly what it is that lives there, and require something there. If it's optional, it will be left out (or website reorgs will accidentally kill it), and things will continue to silently work.

Yes.

> This is a reason to allow arbitrary payment types, but it has nothing to do with how those payment types are identified.

No, there's a relationship. If we're going to show it, we have to be able to support it. If all we have is an identifier, we can't support it. This goes back to the above point where something has to exist at the end of that URL that can be de-referenced. But I agree that *if* we use origins or URLs, we really need to specify what must exist at the end of that URL.

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