Re: [w3c/browser-payment-api] Identifiers or Locators (#150)

>   * identifiers are "reverse domain names" that are just strings and
>     compared as such
>   * there is a "registry" into which people with such identifiers are
>     allowed to map the identifier to a "locator"

if i have such a (optional) mapping from string to URI, why have a 
naming convention such as reverse domain name?

>   * there is a web service that a payment app (or anyone) could hit to
>     check if there is a mapping for an identifier; and if so retrieve
>     that mapping

https://tools.ietf.org/html/draft-wilde-registries-01#section-5.6 
discusses this issue. that's basically re-inventing the DNS, unless 
you'd be willing to accept the risk from building this as a centralized 
service (which would need to be scalable and robust at a scale close to 
search engines in order to not become a bottleneck).

>   * dereferencing the locator returns a document (via conneg) that has
>     the rules you mentioned; stability, persistence, interrogation,
>     evolution, structure

so, is all this information stable? or does it change over time? if it's 
sable, why not have it in the registry? if it changes, what are the 
rules about how clients have to react to any of those aspects changing?

the main thing here is that the registry pattern usually establishes a 
contract: what gets registered is stable and implementations can depend 
on that. if you take that away and say that "a payment scheme is 
whatever the document retrieved from its identifier URI says it is at 
any point in time", you have a very different design. and not really one 
that requires self-describing identifiers or a registry anymore.

> I am sure there are arguments against a list and a non-list, but I don't
> know what they are.

my argument would be that instead of making identifiers self-describing, 
you require runtime retrieval. that's a very different design, and one 
where even having a registry might not be very useful anymore. with 
payment being as sensitive as it is, i doubt that there wouldn't be a 
lot of security issues when making all this payment scheme info dynamic 
instead of hardcoding it into the client when a new payment scheme is 
supported.

> Is this over complex? I like applications that are
> able to discover new information without an update.

first of all, let's hear from people actually implementing this whether 
they (a) want to and (b) are able to build this so that payment scheme 
information is delivered at runtime. so far the feedback said "no".

> Heck, one of the
> terms in the vocabulary of a document could be the "next update time";
> basically an expiration in time certain for the information about the
> payment method.

if you decide to do everything runtime, then at least you should take 
advantage of the web and do this via HTTP caching, if you wanted your 
payment scheme information to expire.


---
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/browser-payment-api/issues/150#issuecomment-213191040