What is the format for payment method identifiers for distributed extensibility

[adrianba]

This issue comes from WICG/paymentrequest#34 and was discussed at the F2F.

[msporny]

Migrating from w3c/webpayments#25:

The Payment Request Architecture diagram specifies a Payment Method Identifier Registry and suggests that it may be a wiki. Who has write access to that wiki and what is the structure of that wiki?

I suggest that instead of a wiki, we use a document that is controlled by the Web Payments IG. The process for getting something into that document doesn't need to be complex (as simple as a pull request or an email to the group), but ultimately, entries into that document should be discussed.

For example, there are 669 cryptocurrencies, do all of them get to update their entries in the registry? Is the registry open to all?

I suggest we use URLs to identify payment types. Then we make the registry necessary ONLY if you want a short-name like "Visa" or "MasterCard", or you want to document how you are compatible with the Web Payments standard (standardized request format and response format).

The other thing we want to ensure is that there is some discussion upon the integration of a new payment method (actual standardization discussion, not just one person coming in and slapping their idea on a page). To be clear, none of this should prevent anyone from launching their own payment method. The registry is an optimization and information repository and is not required for new participants to enter the ecosystem.

I propose that, at a minimum, the following data is in each entry in the registry:

• payment method URL (the identifier)
• shortcode (like "Visa", "Bitcoin", etc.)
• payment request format
• payment response format

I propose that the best format for this document is as a Linked Data Vocabulary with a corresponding JSON-LD context as that formalizes how the data is expressed and represented across different syntaxes.

Spec refs:
http://web-payments.github.io/web-payments-messaging/#payment-instrument-registration
http://web-payments.github.io/web-payments-messaging/#payment-request
http://web-payments.github.io/web-payments-messaging/#payment-acknowledgement
http://wicg.github.io/web-payments-browser-api/#payment-instrument-registration
http://wicg.github.io/paymentrequest/specs/architecture.html#payment-method-registration-specifications
http://wicg.github.io/paymentrequest/specs/method-identifiers.html#issue-1
http://wicg.github.io/paymentrequest/specs/method-identifiers.html#issue-2

[ianbjacobs]

I have launched a twitter poll on the W3C account to see if we can gather some data on this:
https://twitter.com/w3c/status/723275778339835904

Ian

[sideshowbarker]

Here’s some raw feedback I’ve gotten on this question so far from soliciting opinions from others with experience writing and implementing specs for the platform:

• “I’m inclined to say [option] 2 [reverse domains] since URLs have terrible ergonomics”
• “「There is no way to automatically dereference a payment method identifier from this option to a resource located at a URL.」is the listed disadvantage… that sounds like RDF, I think I’m now convinced option 2 is the way to go”
• “That poll is super misleading… The alternatives here are URLs vs simple strings”
• “Everyone needs to understand that a new token will only become supported by shipping a new version of a browser, I don’t see how else this would work. So having com.visa.foo is cute, but kind of pointless too”

[halindrome]

Why would a new token only become supported with a new browser version? The browser is not part of the transaction except as a string matching engine in this instance. You would need a payment app that recognized the token and a merchant who wanted to use it.

Unless you think these tokens are enumerated in the WebIDL.... Which would be silly.

[ianbjacobs]

@sideshowbarker,

Thanks for getting some input.

“That poll is super misleading… The alternatives here are URLs vs simple strings”

Sorry it is read that way. We have three options and I thought it reasonable to list
them all. But I can see the case for organizing the question in two parts: URL or not?
If URL, then registry or not?

“Everyone needs to understand that a new token will only become supported by shipping a new version of a browser, I don’t see how else this would work. So having com.visa.foo is cute, but kind of pointless too”

I'm not sure I understand that point. I believe that our design does not require a browser upgrade in order for a merchant and user to be able to use a new payment method.

Ian

[dlongley]

@sideshowbarker, @halindrome, @ianbjacobs,

Everyone needs to understand that a new token will only become supported by shipping a new version of a browser, I don’t see how else this would work.

Yes, it sounds like that particular feedback doesn't apply as that person doesn't yet understand the architecture for the ecosystem.

Unfortunately, some of the other feedback may suffer from a similar problem.

[sideshowbarker]

Yes, it sounds like that particular feedback doesn't apply as that person doesn't yet understand the architecture for the ecosystem.

Unfortunately, some of the other feedback may suffer from a similar problem.

Actually I think the feedback is pretty clear as far as pointing out the options come down to URLs vs simple strings, and that some implementors of features for the platform who have experience with previous cases where we have used URLs and (pseudo)namespaces in cases where we could have used simple strings do not want to repeat that experience.

[rvm4]

I would vote for reverse domain names. I like the idea of using URLs, but I don't see an advantage to having a URI that we could actually hit with HTTP. The Payment App Registration proposal is indeed just a proposal, but if its an indication of where we are headed then we wouldn't be using the identifier itself as a way of acquiring information about a payment app.

[halindrome]

If it is a URI, then I want it to dereference to something meaningful. But I am in general fine with reverse domain names and no short forms.

[msporny]

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 as that assertion is turning people off to using URLs. 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?

[sideshowbarker]

As has been mentioned earlier in this thread and elsewhere, this is not really about a choice between URLs and reverse domain names. It’s more just about a URLs (and all their baggage) vs just a simple string in some form.

So the question to ask is more about how many parts of the Web platform have recently picked simple strings in similar cases rather than URLs. And the answer is, many.

[msporny]

@sideshowbarker wrote:

It’s more just about a URLs (and all their baggage) vs just a simple string in some form.

I don't see it that way at all. Why does it have to be an either/or? We can have both (as proposed by option 1a and 1b). The only argument that I heard against having both is that "people mess it up", but again - I'd like to see data on why and how people mess it up (other than "they screw up equivalence testing").

Are URLs really that hard to use? People seem to copy/paste them all the time to go to websites. Developers use them all the time when making REST API calls... and that's when hardly any money is involved at all. Do we think that people are going to 1) mess up copy/pasting URLs and then 2) not notice that people aren't paying them as a result? I find it hard to buy that argument, if that is the argument. Is that the argument against having URLs and aliases for those URLs?

So the question to ask is more about how many parts of the Web platform have recently picked simple strings in similar cases rather than URLs. And the answer is, many.

Like? Which cases are similar to the one that we're discussing? Links to specs and deployment experience would be helpful.

[dlongley]

Related to #46.

[ianbjacobs]

Closed via
#183

[adrianba]

The spec previously included a section on identifier requirements.

Requirements for identifiers

This section is non-normative.

There are a set of requirements that the payment method identifiers are designed to support:

1. It must be possible for the Working Group to mint a payment method identifier for any payment method.
2. It must be possible for anyone to mint a payment method identifier for a payment method under their control.
3. It should be possible to use a standard short string to identify common payment methods.
4. It must be possible for someone minting a non-standard identifier to make it globally unique in a cost-effective manner.