How should we address payment method manifest files?

[ianbjacobs]

@zkoch wrote a first proposal:
https://github.com/zkoch/zkoch.github.io/blob/master/pmi.md

Since then there have been a number of suggestions. Here is a first pass summary of some pros and cons (help welcome!):

1. Hard-coded URL
   Pro: Simple configuration
   Con: Limits server to one manifest file per payment method. Squats URI space.

2. HTTP Link header (used in conjunction with caching)
   Pro: Greater flexibility in naming, serving multiple resources.

3. Content negotiation
   Pro: One URL
   Con: (1) challenging for server operators to deploy correct mime types; conneg is even more complex (2) Proxies and caches do not always work well with conneg

4. Serve JSON for PMI; link to human readable content from there
   Pro: Optimizes for the information we know today we want to associate with a PMI. Still allows follow your nose to get more information.
   Con: People get back data instead of human readable info by default so less friendly.

[adamroach]

We discussed this in Lisbon, so I've had a bit of time to think about it already --

Strong preference for option 2 (HTTP Link header) -- I think its "con" list is pretty compelling. :)

Option 4 also seems workable. I don't think human readability is a major consideration here -- the only people who would try to resolve these URLs are developers, and JSON shouldn't be a problem for them.

[halindrome]

I am comfortable with 2.

[zkoch]

I would add a con for 2 of: "More challenging and time consuming to developers to integrate"

[adrianhopebailie]

Can we define more than 1 of these with an order of preference for browsers to follow?

That way those that are able to do the more correct ones that require fewer request round-trips can implement those and those who are not able to can do the simpler ones on the understanding that they may be impacting the user experience.

[ianbjacobs]

At the 5 January 2017 call [1] there was a preference for option 2 (HTTP Link Headers). Google and Samsung are going to experiment and bring findings back to the group by 26 January. We also plan to do a little homework on the extent of support of HTTP Link Headers, though it was pointed out that the number of registered link relationships [2] is encouraging.

We picked this rel string: payment-method-manifest

Ian
[1] https://www.w3.org/2017/01/05-wpwg-minutes#item02
[2] http://www.iana.org/assignments/link-relations/link-relations.xhtml#link-relations-1

[mnot]

Browsers support Link headers, in that they're exposed anywhere else HTTP header fields are exposed, such as Fetch and XmlHttpRequest.

Some browsers also support a handful of relations natively, e.g., stylesheet, prefetch, preload. So the barrier to them directly supporting a new relation (if they choose to) shouldn't be too high.

[rsolomakhin]

Link headers work for us.

[adrianhopebailie]

@mnot I think the concern is more about how easy it is for developers to service HEAD requests.

My take from the call was that this is not considered a blocking issue as we expect "hosting" a payment method to be a fairly sophisticated exercise.

[rsolomakhin]

I looked into this and it appears to be quite easy. Here's how you do it in Node.js:

app.head('/bobpay', function(req, res) {
  res.status(200).links({
    'payment-method-manifest': 'payment-manifest.json',
  }).end();
});

And here's PHP:

<?php
header("Link: <payment-manifest.json>; rel=\"payment-method-manifest\"");
?>

[adrianhopebailie]

@rsolomakhin how about if my domain is hosted on GH Pages? 😄

If you have access to a server and the ability to do more than just put static files on that server then I agree it's pretty easy.

When defining these things it's always nice to think about the developer that doesn't have these luxuries. In this case though, I think we're safe requiring them.

[ianbjacobs]

At today's teleconference [1] we resolved that:

• Payment method identifiers that are URLs can be used to discover machine readable information.
• We are defining a specification (Payment Method Manifest Spec [2]) that will house that machine readable information.
• Given a payment method identifier (URL) user agents will discover payment method manifest files via HTTP Link headers.

Editorial notes:

• The Payment Method Identifier spec and Payment Method Manifest spec today are distinct; at some point they might be combined but we need to discuss that further.
• We need to update the PMI spec to make clearer that the other spec (today) defines the manifest file's contents
• We need to update the manifest file spec to talk about addressing those files (via HTTP Link headers).

[1] https://www.w3.org/2017/02/02-wpwg-minutes#item04
[2] https://w3c.github.io/webpayments/proposals/Payment-Manifest-Proposal.html