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

> If these identifiers aren't intended to be used on the Web, but rather they are only ever going to appear in a JavaScript browser API as a simple enumeration, then I agree that they should just be simple strings. If the intent is for payment methods to fit into a larger Web Payments Architecture where they may be referenced in various payment-related messages on the Web, then a Web-based identifier is more appropriate.

URNs aren't web-based, they're an opaque string that (purposely) happens to vaguely resemble URL syntax.  They don't resolve to anything and have no intrinsic meaning.  Their only benefit over a simple enumeration is that they carry around a namespace label that helps identify what they're for when you see them out of context; this is particularly true for URNs where the payload is just a number or other meaningless identifier.  That's not the case here - the keywords have human-readable names, and aren't expected to be shared widely in any sense or be seen out-of-context of a particular API (unlike, say, ISBN numbers).  URNs are thus purely downside due to increased verbosity.

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

That's not what's being lost, that is *literally what we're saying is a bad idea*. If you're not using a URL *as a URL*, you're doing something that has been proven many times in practice to be a mistake.

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

Yes. "Maybe they'll resolve to something useful" is, again, an anti-pattern we've seen many times that causes nothing but pain for no benefit.  If you don't define precisely what's on the other end (and make that thing do something useful, such that screwing it up or killing it will hurt), the endpoint will devolve to utter trash very quickly, and make it very difficult or impossible to ever use for anything in the future.  Use precisely what you need, and no more, of the URL stack: plain identifiers from a registry if all you need is a way to uniquely identify things; plain origins if you just need it for a reasonable security/identity boundary that's shared across web and apps (and is obviously not meant to be resolved, since it's just pointing at a homepage); or URLs if and only if you're actually using what's at the end of the URL for something worthwhile, such that people will notice if they screw it up.

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

By "without having to interact with the W3C", I presume you're trying to say something like "without having to go through an annoying/arduous beaurocratic process that takes a nontrivial amount of time".  There's no reason it has to be like that!  A registry can *literally* just be a text file in a well-known location that your group updates on request - it's a 5-minute email/edit/commit process.  You don't have to publish a new spec version every time you update a registry.

Something that I'm still somewhat missing, tho (I thought I had it, but you're implying something different) is *what does this unique identifier do*? @ianbjacobs suggested that its purpose (as an origin) was to tell the browser what app/SW to boot up to handle some custom payment method.  I can understand that, tho it could really do with some better explanation in this spec.  In that case it's not really a "unique identifier" at all; that is, it couldn't be replaced by a GUID.  It's a very specific and meaningful message that gives the browser directions on how to act.

Is this true?  If not, what part is wrong, and how? Arbitrary extensibility is hard to get right; there's a lot of terrible dead-ends in existence that work quite badly, but little indication of what the right ways to do it are.

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