[w3c/payment-request] Disallow ambiguous methodData declarations? (#905)

In my Masters' thesis, I found a set of issues with the Web Payment APIs (see #903 for further reference). This is one of the mentioned issues.

The current specification allows for methodData declarations that have the following form:

```
const methodData = [
  {
    supportedMethods: "https://example.com/bobpay",
    data: {
      merchantIdentifier: "XXXX",
      bobPaySpecificField: true,
    },
  },
  {
    supportedMethods: "https://example.com/bobpay",
    data: {
      merchantIdentifier: "YYYY",
      bobPaySpecificField: true,
    },
  },
];
```
Such an ambiguous methodData declaration (two different entries for a single payment method identifier), is not further discussed by the spec. 
If a payment handler and/or the trusted payment UI are inconsistent regarding which entry they use, this might have serious implications (such as diferent merchants receiving the payment).
This especially holds true for potential future named payment methods such as basic-card.

In case of the declaration of modifiers, the spec offers a "last-one-wins" approach.
I advocate that such ambiguous methodData declarations should not be allowed at all, at the very least they should be mentioned to raise awareness. 
In my opinion they should lead to an erroneous case on payment request creation.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/905