Before this PR, the spec was vague about the timing attack and also didn't
specify at all that an implementation must return a NotAllowedError instead of
the normal PaymentRequest NotSupportedError in the case of
no-matching-credentials. Whilst we don't want to enforce that UAs show a dialog
here (they may decide, for example, that a delayed response instead is
sufficiently privacy preserving), this PR does try to make the actual concern
clearer and more normative, and add a normative requirement for the return
value.
@rsolomakhin - can you take a quick look from a technical perspective? Goal is to make some things a little more explicit, still without being restrictive on the UA-owned parts.
Before this PR, the spec was vague about the timing attack and also didn't specify at all that an implementation must return a NotAllowedError instead of the normal PaymentRequest NotSupportedError in the case of no-matching-credentials. Whilst we don't want to enforce that UAs show a dialog here (they may decide, for example, that a delayed response instead is sufficiently privacy preserving), this PR does try to make the actual concern clearer and more normative, and add a normative requirement for the return value.
Should also improve the situation called out in https://github.com/w3c/secure-payment-confirmation/issues/142
Preview | Diff