Matching payment apps and security in a world of payment method manifests

[ianbjacobs]

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/

[rsolomakhin]

For (1), I prefer option (a).

For (2), Chrome pretty much behaves as you've described, but we also add cache to help with intermittent network connectivity. We currently set the cache to expire after 30 days from last refresh. We refresh the cache for a payment method on each PaymentRequest that uses this method. How much of our caching behavior needs to be specced?

[adrianhopebailie]

I have some concerns about this.

Limiting by origin as a default (if no manifest can be found) forces payment method publishers to invest the resources required to host a manifest even if they want their payment method to be entirely open.

[ianbjacobs]

@adrianhopebailie, let's talk about ways to signal "open" without having to serve a payment method manifest file.

[rsolomakhin]

let's talk about ways to signal "open" without having to serve a payment method manifest file.

I believe the solution here would be to contact W3C to mint an identifier like "basic-card" or "interledger".

[ianbjacobs]

Here are some ways that we could signal "this is an open payment method":

• URL PMI could include some reserved string at the end (e.g., "no-manifest"). That doesn't feel right architecturally.

• We could adjust the "Fetching payment method manifests" algorithm so that there's a
  valid header response that means "This is an open payment method and there is no payment
  method manifest file."

• Payment method manifest file where there is no defaultApps specified and
  the value of supportedOrigins is "*".

• Publish a short PMI in a W3C payment method specifications.

Are there others?

We've not discussed the first two in detail.

Ian

[adrianhopebailie]

I believe the solution here would be to contact W3C to mint an identifier like "basic-card" or "interledger".

In which case I believe we need to provide better guidance on the process for this. It's currently undefined.

[domenic]

I must admit I am a little lost on the outcome of this discussion. Should we be making any changes to the spec based on it? Either algorithm changes, or additions to the security/privacy considerations section? (Currently there is just a pointer from that section to here.)

[adrianhopebailie]

@ianbjacobs we haven't picked this up in any calls. Do you want to put it on our agenda for tomorrow?

[ianbjacobs]

Hi @adrianhopebailie,

I have a mild preference for not putting it on the full group agenda until we have a proposal to discuss. What would you think of having it on the Monday payment app editor call first?

Ian