Re: [w3c/browser-payment-api] What is the format for payment method identifiers for distributed extensibility (#11)

To disagree slightly with @halindrome:

1. It should at least be a URL (as that's the decentralized identifier extensibility mechanism for the Web).
2. That URL MAY optionally contain human-and-machine readable information if dereferenced. @halindrome we shouldn't force there to be something at that URL. However, there are use cases that people have put forward (machine-readable payment method descriptions, human-readable specs, search crawlers matching payment apps to payment methods, etc.) for dereferencability, please don't block those use cases.
3. We could use short names, but it is claimed that having both short names and URLs confuse developers and/or implementers (do we have data to back this up?). Short names and URL equivalence to URLs are easy via JSON-LD. I'm suspect that there is data to back up this claim as it relates to our "registry", but would happy to be persuaded by data.

If the choice comes down to reverse-domain or short names, I'd prefer the latter as reverse domain is almost as verbose as a URL, and questionably dereferenceable to get to human-machine data. That is, it's the worst of both worlds.

Out of curiosity, what part of the Web platform has recently picked reverse domain names as its extensibility mechanism and why?

---
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/11#issuecomment-215992691