validate supportedMethods

[marcoscaceres]

The spec currently specifies:

dictionary PaymentMethodData {
    DOMString supportedMethods;
};

But those are not actually strings: they are either enums (e.g., "basic-card") or USVStrings for URLs. This causes problems when doing URL comparisons as required by the Payment Method Identifiers spec (which calls into the URL spec).

[ianbjacobs]

+1: they are enums or restricted strings for URLs.

[domenic]

They need to be parsed into URLs at some point. Does the spec not say when that happens?

[marcoscaceres]

It doesn't look like it. I was expecting it maybe in "Process payment methods" during construction of PaymentRequest.

[marcoscaceres]

Related: w3c/payment-method-id#20

[ianbjacobs]

@marcoscaceres and @domenic,

Good catch.

The Payment Method Identifer talks about string matching, and distinguishes the enum v. URL case.
In addition, in the URL case, that spec talks about how the URLs are used to fetch payment method manifest files; we are still working those:
https://w3c.github.io/webpayments/proposals/Payment-Manifest-Proposal.html

For the "match" requirements of Payment Request API, would it be possible to point to the definitions of matching in Payment Request API?

The Payment Method Manifest proposal also plays a role in matching - the user agent fetches the file (in the case of a URL PMI) and determines, for example, which origins are authorized to serve payment apps for that payment method.

I suggest that we raise as a separate issue: How does the payment method manifest file change Payment Request API?

Ian

[marcoscaceres]

On 20 Mar 2017, at 11:59 pm, ianbjacobs ***@***.***> wrote: @marcoscaceres and @domenic, Good catch. The Payment Method Identifer talks about string matching, and distinguishes the enum v. URL case.

Sure, it needs a little overhaul tho. The enum needs to be defined. The algorithm for comparison needs a little love too.

In addition, in the URL case, that spec talks about how the URLs are used to fetch payment method manifest files; we are still working those: https://w3c.github.io/webpayments/proposals/Payment-Manifest-Proposal.html

This might be overstepping a bit... just trying to solve for Payment Requests.

For the "match" requirements of Payment Request API, would it be possible to point to the definitions of matching in Payment Request API?

It's undefined right now I think.

The Payment Method Manifest proposal also plays a role in matching - the user agent fetches the file (in the case of a URL PMI) and determines, for example, which origins are authorized to serve payment apps for that payment method.

This is all out of scope right now (as far as this issue is concerned).

I suggest that we raise as a separate issue: How does the payment method manifest file change Payment Request API?

It shouldn't change anything right now to the level you are proposing. I'm just concerned with defining a union of an enum and USVString. We can look at manifests etc. after.

…

Ian — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ianbjacobs]

@marcoscaceres,

You wrote "it needs a little overhaul tho."

That would be great. Can that be done for discussion on Thursday?
At the payment manifest discussion this week I'd like to talk about the
dependencies (PR API and payment method manifest) and whether, for example,
where the additional third party payment app matching semantics implied by the manifest
file are specified.

Ian

[marcoscaceres]

On 21 Mar 2017, at 12:25 am, ianbjacobs ***@***.***> wrote: @marcoscaceres, You wrote "it needs a little overhaul tho." That would be great. Can that be done for discussion on Thursday?

Maybe... what I have in mind doesn't change how it works. Just a bit more precise.

At the payment manifest discussion this week I'd like to talk about the dependencies (PR API and payment method manifest) and whether, for example, where the additional third party payment app matching semantics implied by the manifest file are specified.

We can probably have those discussions without needing any spec changes.

…

Ian — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ianbjacobs]

@marcoscaceres,

"We can probably have those discussions without needing any spec changes."

Agreed.

For the other discussion on "should we go to CR" it would be nice to see the changes. However, even if they are not ready yet, we will see them as of the CfC.
Ian

[domenic]

My main concern is defining when URLs are parsed (and thus when errors are thrown for bad URLs). The actual type in the IDL is not important; DOMString is fine instead of a union, as there will be no observable difference (USVString conversion would need to happen anyway at URL parsing time).

[marcoscaceres]

I concur.

[zkoch]

This fees like a CR issue, but feel free to remove if not.

[marcoscaceres]

Talking to @zkoch, we will use: if not valid payment method identifier, then try URL parser, re-throw exception. I.e., not an "enum".

[marcoscaceres]

Depends on w3c/payment-method-id#35 (we can hook into the validate algorithm I (re)defined there).

@domenic, might be of interest to you. I have Annevk review it (from a URL-spec perspective), and he seemed ok with it and gave a bunch of feedback.

[marcoscaceres]

@domenic, was working on a PR for this but got stuck. What should happen if:

const bad = [
  {
    // Contains Unicode character outside the valid ranges.
    supportedMethods: "💳-card",
  },
  {
    // Contains uppercase characters.
    supportedMethods: "Basic-Card",
  },
  {
    // Contains Unicode characters outside the valid ranges.
    supportedMethods: "¡basic-*-card!",
  },
  {
    // contains completely invalid url.
    supportedMethods: "http://user:[email protected]:12131231123321",
  },
];

const pr = new PaymentRequest(bad, details);

Should we:

• drop invalid ones, and throw if result is ends up being an empty list?
• .show() reject on show, because they are all bad?
• just set computer on fire? 🔥

[zkoch]

Chatted with @adrianba and we think: we've been moving towards explicitly throwing when encountering malformed data, so the appropriate action here is: reject on show if there is at least 1 bad identifier

a close second is setting computer on 🔥