Re: CfC to publish documents as FPWD of the Web Payments WG

Facebook got in the game kind of late and we don't have all the context yet, but we certainly don't have any formal objections, so that's a de facto

+1 on all 4 specs from FB


On Apr 9, 2016, at 2:44 PM, Wayne Carr <wayne.carr@linux.intel.com<mailto:wayne.carr@linux.intel.com>> wrote:

+1 on all but the Architecture spec

Publishing the Architecture spec, but I'd prefer some changes first.  These are minor cleanups except for the last part.

So, not a formal objection -- more a suggestion for some fixes before publication of that one.

-- comments follow -

Architecture Document

#1 Architecture Doc - at the start, clarify what UA is for people who don't know.  It's in the key early paragraph that explains what part of web payments this is about.

Abstract: "The group is chartered to develop multiple technologies. The current document describes a set of technologies —the Payment Request Architecture— that, together, provide merchants with a consistent way to request payment information from the user, aided by a user agent."

s/user agent/User Agent (e.g WebBrowser)/

The term User Agent is often capitalized to indicate it has a special meaning in W3C, often being the Web Browser-- and with the emphasis on whether Browser vendors would implement, may as well call that out.


s/web/Web/g
In doc sometimes it is Web and sometimes web.

#2 forward references to terms like "Payment Mediator "

Rename Glossary (now at the end) to Definitions and put it at the top so when forward references happen the reader has already seen a short definition.

#3 the Issues copied here use terms not defined in the architecture doc like "payment instrument" - that's going to confuse readers
That issue starts out as being about registering a payment app sharing that registration across browsers, but in the further descriptions it discusses registering a Visa card (which I think would be in the payment app and not in these specs at all).  For FPWD, the text of the Issues that is copied should be cleaned up to avoid confusion.

#4 Figure 1 looks like it has not been completed - may not be rendered correctly in my browser - should have some uniform way of indicating specs (like they're boxes of some color).  Names of specs in the diagram don't match up directly with the following sections.

#5 section 3.1 Payment Method Identifiers - text is "The Payment Method Identifiers [METHODIDENTIFIERS] specification defines the format of Payment Method Identifiers."   I think many readers won't know what that mean.

Should have a sentence or two that indicates they're names of payment methods formatted in some way to avoid name clashes or whatever it is

#6 section 3.2 Payment Request API
The description focuses solely on matching up the supported and available methods. It should be explicit that after that match up, the request to actually pay is also made.  also that the result could be an indication the payment has been made or could be information about how the store could complete the payment.  (I think at present this requires too much work from the reader to figure out how it works)

#7 ensure a Web page can be used as a Payment Application.  Add something about defining that in the Architecure document before FPWD.  It should be possible to do this without relying on native code payment apps on the target device.

Since Web pages don't have access to tamper proof execution on the user device, a Web page payment app would need to have secure functions executed on a secure server.  One means of doing that could be:

 1. Web page Payment App registration can be done like service registration in Web Intents. User navigates to a Web page that offers a Web page Payment Application.  Web page calls a registration API, passing a Web page payment app URL and indicates what payment methods it supports.  Reregistration changes URL or payment methods or unregisters.  (whatever WebIntents ended with)
 2. Payment Mediator selects Payment Application as usual
 3. Browser (Payment Mediator) starts Web page Payment Application page in a tab if it has been chosen for a payment.  The payment app can interact with the user to login with Web Authentication, etc.
 4a. WG defines an additional, alternative payment request API that passes a JSON object that contains the information that is passed to the other (currently proposed) payment request API that comes from and is, optionally, digitally signed by the merchant.
 4b. Define a way to pass the JSON payment request object to the payment application Web page when it is opened in a tab. (e.g. the JSON payment request is placed in a defined location in the DOM)
 4c. Define a way for the Web page Payment Application to return a JSON object with the payment response (confirmation that it was payed or else with the information about how to complete the payment) (where again the JSON object can optionally be digitally signed, this time by the entity paying).  (e.g. in the object in the DOM the Web page payment app where it gets its input, there is an API for providing the result.)

Digitally signed JSON is to avoid tampering in the client pages, for either the merchant of payment app page.  It also could make it simpler to separate request object generation from the decision by the user to process the payment.  In an IoT situation, things could request purchases and get signed payment requests from merchants and those later could be used in a device the user interacts with to approve them.