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

> Open payment methods are ones that can be standardized by the W3C, and for those we are relying on URNs, so many of the issues outlined above by Tab go away for these types of methods. The WG will most likely contain a registry of these different payment methods (e.g. urn::w3c-payments::basic-card).

Using URNs is overengineering for no benefit. They're intended for global identifiers that can appear in many contexts, so the extra information is useful in identifying them.  Here, tho, it's merely an enum used in an API.  You can drop literally all of that but the last identifier (`basic-card`) and get exactly the same benefits with vastly improved usability.  URNs are not used in this way anywhere else in the entire web platform, for precisely this reason - they add nothing but line-noise for these types of cases.

> There are many different proprietary payment methods out there, and it's not reasonable to ask those payment method providers to have to go through some W3C process (even if we make it light weight) to get an identifier into our registry that makes their method available inside of PaymentRequest.

Looking over PaymentRequest, I'm not clear what 3rd-party payment methods even *do*.  The browser is supposed to "supply a UI" for the payment method, but I can't tell how it's supposed to do so for an arbitrary unknown payment method. Is there some sort of interpolation based on the fields in the PaymentMethodData?  Are we assuming that browsers will just know about a bunch of 3rd-party methods and know what sort of UI to generate for them?  (If so, then this is ripe for at least light standardization. A simple registry of what kind of information to collect is a very low-friction way to promote interoperability.)

> URLs allow us to make assertions about identity and ownership. 

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.  (It still doesn't help the `http://example.com` vs `http://www.example.com` problem, but eh.)

> Something can (and should) live at the end of the that URL (e.g. a manifest file) containing information about that payment method.

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.

> But more importantly, there are numerous financial agreements that require certain payment methods to be listed irrespective of a user's preference.

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

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