Re: [w3c/webpayments-method-identifiers] Update of PMI spec (#16)

adrianhopebailie requested changes on this pull request.

Awesome updates. I'd recommend defining the manifest in this spec too?

Some comments require changes but some are just questions.

>        <section>
-        <h2>Identifier format</h2>
-        <p>Payment method identifiers are strings containing a <a>URL</a>. The string MUST be an <a>absolute URL</a>.</p>
+        <h2>Syntax</h2>
+ <p>When URLs are used for payment method identifiers they MUST
+   be absolute URLs including only the schema, origin, and path parts. The URL scheme MUST be <code>https</code>. These URLs MUST NOT include query string parameters or fragment identifiers.</p>

Would we ever support other secure schemes (besides `https`) that are, for example, less susceptible to DDoS attacks? (Like IPFS...)

Do we need to be more generic and just say "secure protocol"?

Also, could we leverage Subresource Integrity somehow to ensure the integrity of the manifest?

>        </section>
       <section>
-        <h2>Identifier equivalence</h2>
-        <p>When the PaymentRequest API is invoked, the web page provides a list of identifiers for supported payment methods.
-        The user agent must compare these identifiers to those available to the user and use this to filter what the user
-        can select. To determine whether two identifiers match, perform the following test:</p>
+        <h2>Matching</h2>

What happens if the URL parser returns `failure`?

> -      </div>
-
-      <div class="issue" data-number="3" title="Should a payment method identifier (URL) resolve to a machine readable resource that describes it?">
-        <p>There is an open issue about whether payment method identifiers should resolve to a resource if they are URLs.</p>
-      </div>
+    <section>
+      <h2>W3C-Defined Strings as Payment Method Identifiers</h2>
+      <p>W3C expects to publish a small number of payment method
+ specifications that define abstractions across
+ similar payment methods (such as credit card payments,
+ tokenized payments, or credit transfers). W3C expects these
+ payment methods will be implemented in a wide variety of third party
+ payment apps. W3C identifies these payment methods with (short) strings; W3C expects to mint these strings in payment method specifications published by the Web Payments Working Group.</p>
+      <section>
+        <h2>Syntax</h2>
+ <p>The syntax of W3C strings used as payment method identifiers is constrained by this regular expression: <code>[a-z0-9-]+</code></p>

Put regex in a freestanding code block or at least new line

>  
+      <ul>
+ <li>Parties may mint payment method identifiers to
+   represent different conditions. This scalable approach may work
+   well for a small number of independent conditions, but
+   may not scale well for complex relationships.</li>
+ <li>Payment methods may define "filters." Merchants provide

Maybe mention that filtering is defined in the payment method specs and that support is not a normative requirement of this spec?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-method-identifiers/pull/16#pullrequestreview-8949317