Skip to content
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

Closed
msporny opened this issue Mar 14, 2016 · 8 comments

Comments

@msporny
Copy link
Member

msporny commented Mar 14, 2016

Migrating from w3c/webpayments#30:

If the payment app identifier or payment method identifier is a URL, should there be a resource that can be fetched from the URL?

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

Is there a need to describe the payment method at the URL or provide some other information?

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.

@kirkalx
Copy link

kirkalx commented Mar 30, 2016

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.

@adrianhopebailie
Copy link
Collaborator

@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:

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.

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

@kirkalx
Copy link

kirkalx commented Mar 31, 2016

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

@adrianhopebailie
Copy link
Collaborator

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.

@kirkalx
Copy link

kirkalx commented Apr 1, 2016

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!

@adrianhopebailie adrianhopebailie changed the title Should a payment app identifier (URL) or a payment method identifier (URL) resolve to a machine readable resource that describes it? Should a payment method identifier (URL) resolve to a machine readable resource that describes it? Apr 19, 2016
@adrianhopebailie adrianhopebailie modified the milestones: Priority: Medium, Priority: High Apr 19, 2016
@adrianhopebailie
Copy link
Collaborator

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.

@adrianhopebailie adrianhopebailie modified the milestone: Priority: Medium Apr 22, 2016
@dlongley
Copy link

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>

@adrianhopebailie
Copy link
Collaborator

Migrated to w3c/payment-method-id#3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants