Reference manifest spec

[marcoscaceres]

The spec says:

In particular, owners of proprietary payment methods can use Web servers under their control to publish security information about authorized payment apps.

I think we should remove this. Identifiers should be identifiers - they are used by developers (for the purpose of the API) and should not be used in the manner above.

[ianbjacobs]

@marcoscaceres,

Our expectation is that people will publish payment manifest files at these URLs.

Editorially, this sentence might be considered somewhat redundant with the first sentence of the paragraph. The two could be merged, and the first sentence of the paragraph would become:

"When the party responsible for a payment method wishes to publish machine-readable information associated with the payment method (such as security information about authorized payment apps), it does so with a URL."

Ian

[marcoscaceres]

Although I'm extremely supportive of the payment manifest spec, I still don't think this spec should say anything like the above. Also, the manifest spec, IIRC, just serves back a HTTP Link header, which itself links to the manifest.

As such, we shouldn't imply anything about what to expect at the endpoint (not in this spec).

@zkoch, wdyt?

[ianbjacobs]

My understanding is that there was a strong desire to indicate what to expect at the end point of these URLs (and thus, it seems appropriate to mention it in this spec, as a reference to the payment method manifest spec).

Ian

[marcoscaceres]

That doesn't make any sense tho? These are identifiers for the purpose of Payment Request. We are not going to replay 20 years of namespace discussions, I hope.

Now, we could have a note that references the manifest spec - but we can't make the reference here normative because we can't expect, for example, Mozilla, to support the payment manifest to also support this spec.

[ianbjacobs]

Our consensus was to set an expectation that people will publish payment manifest files at these URLs. What is a good way to express that?

Ian

[marcoscaceres]

We should just say that other specs may use the http end points. This spec doesn't put any restrictions on that.

[ianbjacobs]

As I said, the consensus was that we say more specifically what sort of thing one will find. We will also want an informative reference to payment method manifest spec (in an informative note of some sort).

(In the future we may merge the two specs, but there is no push to do that in the short term.)

Ian

[zkoch]

I'm trying to go back and remember these conversations. For a long time we said identifiers are just that - identifiers. Nothing more. But we can layer functionality on top of these identifiers and them being URLs makes it pretty easy to do this (e.g. payment method manifest). Given that we have a separate spec now that clarifies what exactly that is, I would be comfortable taking that language out if @marcoscaceres thinks it's cleaner without.

[ianbjacobs]

Given that our expectation is that people will publish these payment method manifests, I think we do a disservice if we remain silent in the PMI spec about this. I would love for @marcoscaceres to propose language he thinks is architecturally sound while still referring to the payment method manifest spec.

Ian

[ianbjacobs]

Hi @marcoscaceres,

This was closed without addressing my request to reference the manifest spec. At least I don't see a reference in PR #35.

Ian

[marcoscaceres]

Apologies, will add!

[ianbjacobs]

Thank you.

It also occurs to me that we might want to elevate the good practices doc at some point...I'll take this to the WG.

Ian