-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disallow ambiguous methodData declarations? #905
Comments
Thanks @crowgames! @rsolomakhin, @aestes, @marcoscaceres, @romandev do you have any thoughts on this? I hear some options are:
Thanks! Ian |
Let's throw. I can't think of a use case for having multiple. |
+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. |
Ok, proposed PR over at #908 |
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:
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.
The text was updated successfully, but these errors were encountered: