Add section on Payment Handler Matching

[ianbjacobs]

Based on WG discussion today [1], this pull request endeavors (in a non-normative section) to:

• Raise awareness that for security reasons a user agent might not include a payment handler from an origin other than the origin of a URL PMI.
• Raise awareness that user agents may also increase the set of matching payment handlers based on payment method owner information.

This pull request is not more specific than that in order to make it easier to include this text in the CR draft. If there were support for being more explicit, I would be glad to mention two ways
that we are working on where payment method owners delegate authority: W3C-defined
payment method specs and Payment Method Manifest.

At this point, I have this algorithm in mind when looking at the question of matching
payment handlers from origins other then the origin of a PMI URL.

• If the user agent does not find a payment method manifest, then it should not include
  payment handlers from origins other than the origin of the PMI URI.

• If the user agent does find a payment method manifest, but it is broken in any way,
  then the user agent should not include payment handlers from origins other than
  the origin of the PMI URI.

• Otherwise, the user agent authorizes payment handlers from other origins
  according to the payment method manifest spec.

@rsolomakhin has written a Payment Handler API pull request [2] that addresses
the origin / payment method manifest consideration for Web-based payment apps.
However, that algo might reasonably apply to native mobile apps. Thus, it feels
to me like it belongs in PR API, but I am not proposing that it be included at this time
due to CR timing considerations.

Ian

[1] https://www.w3.org/2017/08/10-wpwg-minutes
[2] w3c/payment-handler#197

---

Preview | Diff

[marcoscaceres]

Approved with my small changes (don't use RFC2119 keywords in non-normative sections, please).

Fixed xrefs and tidy'd also.

[ianbjacobs]

Thank you, @marcoscaceres