search

w3c / payment-method-manifest

Specification for Web Payments payment method manifests
https://w3c.github.io/payment-method-manifest/
Other
9 stars 13 forks source link

reconsider extra level of indirection for retrieving a manifest? #10

Closed dbaron closed 5 years ago

dbaron commented 7 years ago

This issue came up in the TAG during discussion of the TAG review in w3ctag/design-reviews#162.

One of the things that bothered a number of us about the specification was that the process for retrieving a manifest from a payment method identifier was to look for a Link response header with rel="payment-method-manifest" from a GET or HEAD response on the payment method identifier URL. This seemed bad for two reasons:

In https://github.com/w3ctag/design-reviews/issues/162#issuecomment-298143339 @triblondon enumerated four possibilities (including the spec's current behavior):

  1. what the spec does now, where a Link header is used from the identifier URL to find the manifest (disadvantage: extra level of indirection)
  2. require that the URL used as an identifier point directly to the payment method manifest (disadvantage: URL used as the identifier is less human-readable)
  3. making the URL of the manifest be a /.well-known/ URL (RFC 5785) that can be formed from the identifier URL without any network interaction (disadvantage: has to be at that URL)
  4. using a request header (e.g., Accept) to allow the identifier URL to produce a payment method manifest (disadvantage: requires using Vary: Accept, although that may often be needed anyway)

Within the TAG, there seemed to be the most support for (and no objection to) (2). However, we're certainly missing some of the context that the working group has, so we wouldn't insist on such a change (certainly not at this stage).

That said, we'd be interested in understanding more about the process that led the working group to make the choice it currently did, and whether perhaps there's another option that meets everybody's requirements.

zkoch commented 7 years ago

Thanks for the review!

There's actually a another disadvantage to (2) besides being less human readable and more error prone, which is that: it requires the existence of a manifest file. A manifest is a useful tool, but we don't require it. I think there are other issues, but that's the main one.

dbaron commented 7 years ago

I guess not requiring a manifest is another interesting question -- should people really be using new payment methods on the Web without giving any information about how to use them?

triblondon commented 7 years ago

Hey @zkoch we're still a bit perplexed about how you can practically use a custom payment method without saying anything about how it works. I'm also keen to clarify your comment about 'more error prone' - can you confirm my understanding that it is exactly as error prone as any mechanism that requires specifying a full URL of a resource, eg a link from one website to another?

triblondon commented 6 years ago

https://github.com/w3ctag/design-reviews/issues/162#issuecomment-332238610

cvan commented 6 years ago

I agree that discovering and accessing the URL to the Payment Method Manifest via a Link response header is less than ideal for web developers and service providers.

if a GET/HEAD request is necessary for identifying the URL, web developers will already need to configure their servers to set such response headers (e.g., Link: </pay/payment-manifest.json>; rel="payment-method-manifest"). if developers have the ability to set response headers, they'll likely also have the ability to conditionally serve different response bodies for a Web-App Manifest. as mentioned in https://github.com/w3c/payment-method-manifest/issues/10#issue-231214265, developers (and their CDNs) would need to introduce and respect a Vary header.

I'm new to this discussion, so forgive my ignorance. are there alternatives that have been proposed elsewhere or in other TAG reviews?

rsolomakhin commented 5 years ago

@cyberphone proposed an excellent solution in https://github.com/rsolomakhin/rsolomakhin.github.io/issues/28:

If there is no Link, Chrome might as well perform GET on the same URL.

I think this is a great idea. We should add this to the spec and ship it in Chrome :-D

domenic commented 5 years ago

Do we think it's a good idea to issue two requests, one HEAD then one GET? Or would it be better to just issue a single GET, and either ignore the body or use it, depending on the headers?

rsolomakhin commented 5 years ago

A single GET makes more sense from the standpoint of architecture.

The implementation (not the spec) should also have a fallback to HEAD if the GET fails for those payment handlers that explicitly wait for a HEAD request. We should measure how often the fallback succeed when the initial GET failed. When that number is close to zero, the implementation can remove the HEAD fallback.