We now have a spec: https://domenic.github.io/payment-method-manifest/

Presumably feedback should now be filed as issues in the repo, right?

There's now a blink intent to ship for this.

Yep, good idea to file the issues here.

https://w3c.github.io/payment-method-manifest/

One thing that came up in the TAG's initial 10-minute timeboxed discussion was the privacy implications here, that is, the question of when are these resources (the payment method identifier, the web payment manifest, the payment application manifest) are retrieved. But we'll discuss more in a subgroup.

And another question that came up was the question of whether the level of indirection of retrieving one resource and looking at a Link header on it, rather than just using the URL of the manifest as the identifier, was a good idea or not.

We had some further discussion of this, in the same two areas discussed above:

Privacy

@triblondon points out that one way the browser could obscure which users use merchants that use a particular payment is by the browser proxying the retrieval of the manifests through a central server, if it wanted to do so.

We should file an issue against the spec that it should have a Privacy Considerations section, which should discuss the issues where some of the parties involved can learn things about what others are doing in possibly unexpected ways, and what could be done to mitigate that.

Indirection in manifest retrieval

The justification the spec offers for the extra level of indirection is that the URL that is the identifier is designed to be more human-readable. @triblondon walked through some possibilities:

• what the spec does now, where a Link header is used from the identifier URL to find the manifest (disadvantage: extra level of indirection)
• 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)
• making the URL of the manifest be a /.well-known/ URL that can be formed from the identifier URL without any network interaction (disadvantage: has to be at that URL)
• 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)

The pending external feedback label seems a little insufficient here. We recorded discussion of two issues in https://github.com/w3ctag/design-reviews/issues/162#issuecomment-298143339 above. For the first (Privacy), an issue has been filed and acknowledged (but not fixed). For the second (Indirection in manifest retrieval), we don't seem to have solicited any external feedback yet. We presumably should decide if we want to recommend one or more of the four possible courses we enumerated above.

Discussed in today's TAG teleconference. There seemed to be the most support (and no objection) behind option 2 above:

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

I'll open an issue in the spec's repository about this issue.

Can you expound a bit more on that? This is in direct contradiction to a decision the WG made some time ago, so I'd like to better understand the rationale. Thanks!

We are waiting to hear back any feedback on our comment on their issue 10.

@zkoch we're aware this is about to ship in Chrome stable. Could you give us an up to date response on your issues 10 and 7 that we raised?

One question/thought: how likely is it that a developer will produce a single manifest that serves as both a PWA web app manifest and a payment manifest? It appears that none of the keys conflict today, but is this something that Web App Manifest maintainers should take into account when adding new fields in the future and perhaps non-normatively document in their spec?

Taken up at our call 29-08. We agreed we still need an answer. We will take it up at the f2f. @slightlyoff going to do some research.

So I spoke a bit with @zkoch, and it seems like there is potential for some conflict if developers do this. At a minimum, perhaps it would be good to have @marcoscaceres and @mgiuca come up with some sort of agreement about how to keep keys from colliding.

Right now, it's not a problem because I'm tracking all of them (🤞). I think it will have to remain a community effort to make sure we don't stomp on each other for now.

Closing this review now. TAG remains concerned about two issues that we don't think are yet completely addressed:

• Indirection in the retrieval of the manifest (see https://github.com/w3c/payment-method-manifest/issues/10)
• Avoiding collisions between this and web app manifest (and consideration of merging the two)