Update of PMI spec #16
Conversation
- takes into account Lisbon discussion https://www.w3.org/2016/09/20-wpwg-minutes#item04 - takes into account 10 Nov discussion https://www.w3.org/2016/11/10-wpwg-minutes.html#item02 - Defines both URLs (when manifests needed) and W3C-minted short strings - New section on more sophisticated matching beyond PMI matching
| <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> |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
I suggest we discuss these at the 17 Nov call (as well as whether the Manifest spec should be included in the PMI Spec).
There was a problem hiding this comment.
Hi Adrian,
Per discussion at teleconf today, I've added a link to issue 17 in updates to the pull request.
| <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> |
There was a problem hiding this comment.
What happens if the URL parser returns failure?
There was a problem hiding this comment.
I'd like to hear from user agent implementers.
There was a problem hiding this comment.
Can we put in a placeholder that shows this behaviour needs to be defined?
There was a problem hiding this comment.
Two notes:
- I don't think this specification should say how to handle strings that are neither URLs nor W3C short strings. Behavior may vary in different contexts.
- Similarly, I don't think this specification should say what to do when there is, for example a 404 on a manifest file.
So if the URL parser fails, it means that the string is not a PMI per this specification (unless it happens to be a W3C short string). When the parser fails, the browser might do any number of things, including (1) still trying to match the string (2) ignoring the string. I think that the PR API spec should speak to this behavior but not the PMI spec.
There was a problem hiding this comment.
Similarly, I don't think this specification should say what to do when there is, for example a 404 on a manifest file.
I think we'll need to add that when we add the manifest stuff to this spec but happy to do that later when @maxpassion has this ready.
I think that the PR API spec should speak to this behavior but not the PMI spec.
There seems to be a lot of work still required on the show() algorithm to call out to the PMI matching now that we have that defined. https://w3c.github.io/browser-payment-api/#show-method
Happy to move it there but we should probably give the caller some indication that method identifiers have been removed (Step 8) /cc @adrianba @zkoch @rvm4
| 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> |
There was a problem hiding this comment.
Put regex in a freestanding code block or at least new line
There was a problem hiding this comment.
I've pushed a change that puts the snippet in a pre
| 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 |
There was a problem hiding this comment.
Maybe mention that filtering is defined in the payment method specs and that support is not a normative requirement of this spec?
There was a problem hiding this comment.
I don't think that's necessary because the text says "Payment methods may define filters" which means that the definitions would be in payment method specifications.
There was a problem hiding this comment.
My point was to be (more) explicit about why there is no filtering behaviour defined here
There was a problem hiding this comment.
Your original suggestion had two parts: (1) filtering is defined in payment method specs. I think that is covered by the existing text. (2) support is not a normative requirement of this spec. I think silence on the matter is equivalent in this case.
Your last comment is to say "why" there is no filtering behavior defined here. Do you have suggested text for that rationale?
Ian
There was a problem hiding this comment.
Payment methods may define "filters". These are used by callers of the API to affect the payment method identifier matching behavior. No generic filtering mechanism is defined therefor support for filtering is dependent on the level of support that implementations have for the payment methods that define "filters".
Per discussion at the 17 Nov call [1], added link to issue 17. Expectation is that the spec will be revised in TR space with these edits, then we will address new issues (and inclusion of manifest information) in subsequent drafts. [1] https://www.w3.org/2016/11/17-wpwg-minutes#item03
Take into account (but not verbatim) AHB text
|
Adrian, I took another pass at the filter description based on your text. It's not exactly what you wrote but I hope captures your intent. |
| filter alignment. Please note that at this time the | ||
| Working Group's expectations is that filters will be | ||
| defined within payment methods; there will not be | ||
| "generic" filters that work across payment methods.</li> | ||
| </ul> |
https://www.w3.org/2016/09/20-wpwg-minutes#item04
https://www.w3.org/2016/11/10-wpwg-minutes.html#item02