Hi @zkoch, @rsolomakhin, @domenic, and Max,

(I am reviewing the spec [1] and will have a number of suggestions in an upcoming PR.)

Here are some scenarios where we want the right (secure) thing to happen:

(1) The browser implements Payment Request API but not Payment Method Manifest
(2) The browser implements Payment Method Manifest, but there is a failure of some
sort (related to fetching, parsing, or ingesting the manifest file).

The high level question that I think needs to be addressed in the specification is:
what is the browser expected to do in the PR API matching algorithms (of show() and
canMakePayment()) in these scenarios?

I could imagine a variety of things we could say.

(1) Be more explicit in PR API about this topic. There are different degrees of
statement we could make. For example:

a) For a URL payment method identifier, the user agent MUST NOT match a payment
app whose origin ("app origin") differs from that of the PMI ("pmi origin") unless pmi origin
explicitly delegates authority to match payment apps from app origin.
b) The same thing with "SHOULD NOT"
c) User agent behavior is undefined if the origin of a (potentially) matching payment
app differs from the origin of a URL PMI.

(2) In Payment Method Manifest, be more explicit about how conforming
user agents should match in the face of failures (fetching, parsing, ingesting).
For example, something like:

"For a given payment method origin, if the algorithms for fetching, parsing, or ingesting a payment method manifest at that origin fail, the user agent MUST NOT match payment apps whose origin differs from the payment method origin. @@add references to the relevant parts of show() and canMakePayment().@@"

In short: what needs to be said in the specification so that payment method owners can trust that user agents will do the right (secure) thing in these (and possibly other) scenarios?

Ian

[1] https://w3c.github.io/payment-method-manifest/