Disallow ambiguous methodData declarations?

[crowgames]

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.

[ianbjacobs]

Thanks @crowgames!

@rsolomakhin, @aestes, @marcoscaceres, @romandev do you have any thoughts on this? I hear some options are:

1. Adopt a last-one-wins approach as done with modifiers
   Define handling of multiple applicable modifiers #824
2. Throw an error
3. Leave as is. If so, what are the use cases that support this?
4. Other?

Thanks!

Ian

[marcoscaceres]

Let's throw. I can't think of a use case for having multiple.

[ianbjacobs]

@danyao and @Rouslan, I think I heard today support for this. Could you +1? Thanks!

[danyao]

+1 to throwing. It seems to me that a well-formed request should never have this shape and it's pretty easy for a developer to detect if they accidentally create an error. So throwing seems the simplest way to handle it.

[marcoscaceres]

Ok, proposed PR over at #908