-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should a payment method identifier (URL) resolve to a machine readable resource that describes it? #46
Comments
I believe that any resource pointed to should only be explanatory (e.g. pointing to an appropriate URL about the web payments API). There should be no sense that the URL owner has any additional powers over that payment method than ownership of that particular URL gives them. My reasoning is that for decentralized currencies like bitcoin, there is no one central domain name that would be seen as representing bitcoin (e.g. the traditional choice bitcoin.org is now owned by figures who are quite controversial in the bitcoin community). It might be tempting for these to be given a URL directly owned by the working group, which again indicates that there should be no additional power associated with ownership of the URL. |
@kirkalx consider that there may be multiple payment methods for paying via Bitcoin proposed by various people. If the WG takes a position on the "best" way for that to work it could publish a payment method spec at a w3.org owned URL and hope that the Web community favors that one but we can't enforce that any more than we can enforce the card networks to adopt our basic card payment spec. Put another way, I disagree with this:
If the Bitcoin community doesn't trust the owners of bitcoin.org then I'd expect them to not use payment methods where the identifier is a bitcoin.org URL but to self-select a better payment method managed by an entity they trust (which could be w3.org). |
Thanks for the reply Adrian, I agree that is the right approach. I was waylaid by thinking that there had to be one universal URL for the "bitcoin" payment method. Confusion over the nature of bitcoin as a currency and a payment method yet again. Hopefully we don't get the other extreme of a chaotic proliferation of different URLs all essentially meaning "pay with bitcoin". |
+1 - one way to avoid this is to get the Bitcoin community engaged in the WG and to produce a Bitcoin Payment Method spec (along the lines of the Basic Card Payment spec) that is endorsed by the WG. It would be published as a W3C WG Note and we can use a w3.org URL as the base for the payment method identifier. It was proposed in our call yesterday (https://www.w3.org/2016/03/31-wpwg-minutes.html#item05) that we produce payment method specs for as many of the flows we have documented as we can. This will depend entirely on resources available to write the specs and interest from the group in reviewing them and publishing them. |
Thanks for the suggestion Adrian. I'll get in touch with Gabriel Abed of bitt.com who I believe has made a start on this (for bitcoin). Cheers! |
The previous title of this issue conflated two entirely different issues. The discussion on this thread is primarily about payment method identifiers and in fact there is no mention anywhere else of payment apps even having an identifier let alone it being a URL. If there is a need to discuss whether or not payment app identifiers should resolve to something then this should be logged as a separate issue. |
This text was proposed as a set of requirements for content from resolved payment method identifiers: <section>
<h2>Content at Payment Method Identifier URLs</h2>
<p>
Payment method identifier URLs that resolve to content:
</p>
<ol>
<li>MUST be served over HTTPS,</li>
<li>SHOULD support HTTP Content Negotiation,</li>
<li>SHOULD provide a human-readable document that describes the
payment method when <code>text/html</code> is requested, and</li>
<li>SHOULD provide a machine-readable document that describes the
payment method when <code>application/ld+json</code> is requested.
</li>
</ol>
</section> |
Migrated to w3c/payment-method-id#3 |
Migrating from w3c/webpayments#30:
Yes. We should suggest that the resource should be machine-readable (expressed as JSON-LD, at a minimum) for the reasons specified here:
http://www.w3.org/TR/json-ld/#introduction
We should not require it, but encourage it.
At a bare minimum, you could publish a human readable string in various languages for the payment method / app. You could also publish the payment method and/or apps branding image.
You could also make it so that a payment method URL may list the payment apps that are capable of processing the payment method. This would make it easy for user agents to retrieve a payment app if one isn't available in the user agent already. It could address the "no available payment apps" use case. I'm not suggesting that's how it would work, just that it seems like there are enough use cases to think more deeply about it.
The text was updated successfully, but these errors were encountered: