Clarify security check for URL-based payment method identifier

[fred-wang]

In https://w3c.github.io/payment-method-id/#validation the following security checks are performed:

• If url's scheme is not "https", return false.
• If url's username or password is not the empty string, return false.

Chromium's implementation does the following ( https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/modules/payments/payments_validators.cc;l=160;drc=82d9604867706f5b9833f511acd47dffc58e6d91 ):

• If url's username or password is not the empty string, return false.
• If url's scheme is "https", return true.
• If url's scheme is not "http", return false.
• If url's origin is potentially trustworthy ( https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy )

(And equivalent form would be url's scheme is https://fetch.spec.whatwg.org/#http-scheme and url is https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy)

One argument for allowing APIs on non-HTTPS server is so that web developers to experiment their implementation before publication e.g. using an easy-to-test localhost server. I'm not sure whether that applies to web payment, will open a bug on Chromium's side (--edit: done at https://bugs.chromium.org/p/chromium/issues/detail?id=1200225 )

[rsolomakhin]

The "potentially trustworthy" http is being allowed for local testing on http://127.0.0.1 and allow-listed (on command-line) origins. We can update the spec to note that web browsers can provide affordances for local testing such as this.

[fred-wang]

I believe referring to https://fetch.spec.whatwg.org/#http-scheme + https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy would be enough. Note that there is already some explanation about why browsers may consider non-https URLs trustworthy on https://w3c.github.io/webappsec-secure-contexts/#implementation-considerations (albeit not for local servers).