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

+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.