- From: Shane McCarron <shane@spec-ops.io>
- Date: Tue, 12 Apr 2016 17:08:08 -0500
- To: Payments WG <public-payments-wg@w3.org>
- Message-ID: <CAJdbnOCCmJM=F7GTwGCmqRZ8Ng+mZ1MUsiKHNieisuArR3v09A@mail.gmail.com>
Apologies - Ian mentioned that my comments may be unclear. I am in no way saying Spec-Ops formally objects to anything. On Tue, Apr 12, 2016 at 10:22 AM, Shane McCarron <shane@spec-ops.io> wrote: > Spec-Ops has reviewed the draft specifications. Many others have comment > on the details in earlier responses. We in particular strongly agree with > the comments made by Adrian Hope-Bailie about the architecture and payment > method identifier documents. Our responses to the CFC are below: > > >> - Proposal 1: Publish "Payment Request API" as a FPWD >> - >> https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/paymentrequest.html >> >> > +1 on publishing this document - while riddled with issues these should > spark broader community review and comment. > > >> >> - Proposal 2: Publish "Payment Request API Architecture" as a FPWD >> - >> https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/architecture.html >> >> > -1 on publishing this document. It is misleading in its current form and > may turn off potential adopters with its too-tight focus on browser payment > and lack of detail on the overall architecture of payments. > > >> >> - Proposal 3: Publish "Payment Method Identifiers" as a FPWD >> - >> https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/method-identifiers.html >> >> > -1 on publishing this document. It is too immature to publish at this > point. > > >> >> - Proposal 4: Publish "Basic Card Payment" as a FPWD >> - >> https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/basic-card-payment.html >> >> > +1 to publish this, as without it the Payment Request API document is > contextless and would be hard for people to follow. However, we agree with > AHB (and others) that the inclusion of WebIDL adds a level of complexity > that is unnecessary for this and future Payment notes. The WebIDL should > be stripped out and replaced with something friendlier / easier for > non-browser manufacturers to grok. > > Spec-Ops is also fine with publishing NONE of these documents, fixing the > systemic issues with the architecture so that we have a cohesive story, and > the publishing all of the relevant documents - even if they are issue-laden. > > > On Tue, Apr 12, 2016 at 9:15 AM, Adrian Hope-Bailie <adrian@hopebailie.com > > wrote: > >> Having re-read my email I realize my wording is more negative than >> intended. >> >> Ripple is okay with publishing the Payment Request API and Basic Card >> Payment specifications: >> >> 1. if they are both published, and; >> 2. with the understanding that there is still substantive work to do >> on both. >> >> We do not support publishing the Payment Method Identifier and >> Architecture documents as we believe these are not yet ready. >> >> On 12 April 2016 at 09:57, Adrian Hope-Bailie <adrian@hopebailie.com> >> wrote: >> >>> After a thorough review of the proposed specifications Ripple's position >>> is as follows: >>> (These are the views of Ripple as a WG member and not my personal views >>> as the chair) >>> >>> >>> *Structure of documents*We believe that the way that the documents are >>> structured is not optimal and would propose the following new structure: >>> >>> - A stand-alone normative specification which defines the role and >>> conformance criteria for a *payment mediator*. The bulk of this >>> specification would be produced from content already in the payment request >>> API specification and payment apps proposal. This specification should >>> define the algorithms for: >>> - registration of a payment app >>> - updating the stored information about a payment app >>> - accepting and validating a payment request >>> - calculating the list of payment apps that can process a payment >>> based on the intersection of method identifiers in the installed payment >>> apps and payment request >>> - returning a payment response >>> >>> - A stand-alone normative specification which defines the role >>> and conformance criteria for a *payment app*. The bulk of this >>> specification would be produced from content already in the payment apps >>> proposal. This specification should define the algorithms for: >>> - returning a list of supported payment methods >>> - processing a payment request >>> - returning a payment response >>> >>> - A *payment methods specification* which defines payment method >>> identifiers, a data model for payment method data, the process for new >>> payment methods to be defined in new payment method messaging >>> specifications and the requirements for such a specification. This would be >>> based on the existing payment method identifiers specification but require >>> substantive additional content. >>> >>> >>> - A *messaging and extensibility specification* which describes how >>> payment request, payment response (and possibly other) messages can be >>> extended and the algorithms that should be used to convert between >>> in-browser objects (defined in WebIDL) and JSON encoded messages. >>> >>> >>> - A *user agent API* specification which details the conformance >>> criteria for user agents as payment mediators in addition to any extra user >>> agent functionality such as gathering of user data prior to payment >>> processing. The bulk of this specification would be produced from content >>> already in the payment request API specification. This specification will >>> have a normative dependency on the payment mediator, messaging and >>> extensibility and payment methods specifications and will define API >>> endpoints for: >>> - registration of a payment app >>> - update of a payment app >>> - accepting a payment request >>> - returning a payment request (to a web based payment app) >>> - accepting a payment response (from a web based payment app) >>> - returning a payment response >>> >>> - An *HTTP API* specification which details the HTTP client and >>> server conformance criteria for HTTP clients/servers as payment apps or >>> payment mediators. This specification will have a normative dependency on >>> the payment mediator, payment methods, messaging and extensibility and >>> payment apps specifications and will define API endpoints for: >>> - registration of a payment app >>> - update of a payment app >>> - accepting a payment request >>> - getting a list of supported payment apps for a given payment >>> request >>> - getting a payment request >>> - accepting a payment response >>> - getting a payment response >>> >>> >>> In terms of the existing documents proposed for publication: >>> >>> 1. Payment Request API (-0.5) >>> >>> We do not support publishing of this specification at this time. We do >>> not have a formal objection to publishing on the understanding that the >>> document may have substantive changes before moving to candidate >>> recommendation as we believe the scope set out by this document is a good >>> reflection of the direction of the group and is therefor a fair yard stick >>> for evaluation of patent commitments. >>> >>> Our issues with this document are as follows: >>> >>> - The current specification doesn't define clearly how the Payment >>> Request API fits into the larger architecture. A brief architecture related >>> paragraph that links to the architecture document would be valuable. >>> - It is extremely challenging to understand the life-cycle of a >>> payment request through this API with no explicit description of the >>> processing that is required at the edges of this component. *Nowhere >>> in the specification is it explicitly explained that a payment request is >>> passed to a payment app for processing.* >>> - The aspects of the payment apps specification that describe a >>> registration API should be included in this specification. >>> - The role of payment mediator versus the additional behavior of the >>> user agent to facilitate checkout are intermingled and unclear. >>> >>> 2. Payment Request API Architecture (-1) >>> >>> We object to publishing this document at this time. >>> >>> Our issues with this document are as follows: >>> >>> - The current draft of the document is incomplete and includes only >>> the aspects of the payment request architecture that are relevant to >>> processing a payment within a user agent. We believe this is misleading in >>> terms of the scope of the WG's work. >>> >>> >>> 3: Payment Method Identifiers (-1) >>> >>> We object to publishing this document at this time. >>> >>> Our issues with this document are as follows: >>> >>> - The current draft of the document provides very little substantive >>> value as it contains three proposals that make up the bulk of the document. >>> - There is no document that describes the role of payment method >>> specifications (like the Basic Card Payment Specification) or how these >>> should be structured. >>> - There is no consensus on the appropriate way to match payment >>> method identifiers from the payment request with those supported by a >>> payment app. >>> >>> >>> 4. Basic Card Payment (-0.5) >>> >>> We do not support publishing of this specification at this time but >>> believe that if the Payment Request API specification is published then >>> this specification should be published too. As such we do not have a formal >>> objection to publishing on the understanding that the document may have >>> substantive changes before moving to candidate recommendation. >>> >>> Our issues with this document are as follows: >>> >>> - The document uses WebIDL to describe extensible data that is never >>> processed by the user agent. This gives the impression that user agents >>> will need to explicitly support each new payment method which is absolutely >>> incorrect. >>> - There is no specification that the document references that >>> defines the requirements for a payment method specification. As such it is >>> impossible to evaluate if this document will meet the needs of payment app >>> implementers and payment processors. >>> >>> For Ripple, >>> Adrian >>> >>> On 11 April 2016 at 20:22, Nick Shearer <nshearer@apple.com> wrote: >>> >>>> We support FPWD publication of all four proposals. >>>> >>>> Nick. >>>> >>>> On Apr 5, 2016, at 12:29 PM, Adrian Hope-Bailie <adrian@hopebailie.com> >>>> wrote: >>>> >>>> This is a Call for Consensus (CfC) to publish one or more documents as >>>> First Public Working Drafts (FPWD) of the Web Payments Working Group. >>>> >>>> - Proposal 1: Publish "Payment Request API" as a FPWD >>>> - >>>> https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/paymentrequest.html >>>> - Proposal 2: Publish "Payment Request API Architecture" as a FPWD >>>> - >>>> https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/architecture.html >>>> - Proposal 3: Publish "Payment Method Identifiers" as a FPWD >>>> - >>>> https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/method-identifiers.html >>>> - Proposal 4: Publish "Basic Card Payment" as a FPWD >>>> - >>>> https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/basic-card-payment.html >>>> >>>> For each proposal: >>>> >>>> - We invite responses on this thread to each of the proposals. >>>> - Silence will be taken to mean there is no Formal Objection [1], >>>> but positive responses are encouraged. Publication as a FPWD does NOT >>>> indicate that a document is complete or represent Working Group consensus. >>>> - If there are no Formal Objections by 12 April 2016 (1pm EDT), the >>>> proposal will carry and the Chairs will request that the Director approve >>>> publication as FPWD(s). >>>> >>>> The W3C Director takes Formal Objections seriously, and therefore they >>>> typically require significant time and effort to address. Therefore, please >>>> limit any Formal Objections to issues related to the scope of these >>>> documents rather than technical content where the Working Group has not yet >>>> made a decision. Please include substantive arguments or rationale for >>>> consideration by the Director. >>>> >>>> If there are Formal Objections, the Chairs plan to contact the >>>> individual(s) who made the Formal Objection to see whether there are >>>> changes that would address the concern and increase consensus to publish. >>>> Depending on the number and nature of the Formal Objections, the Chairs >>>> will either make a decision either to pursue FPWD and report the Formal >>>> Objections to the Director (as required by W3C Process), or to postpone >>>> publication until there is greater consensus to publish. >>>> >>>> If there is a decision not to publish a document, we will adjust our >>>> communications to let people know about the Editor's Drafts and the >>>> decision to delay their publication as FPWDs. >>>> >>>> NOTES: >>>> >>>> - Publication of a FPWD is a signal to the broader community that >>>> we are seeking review of the specification(s) in their early stages. To >>>> frame that discussion, we plan to publish a blog post with the publication: >>>> - https://www.w3.org/2016/03/15-wpwg-blog.txt >>>> - Publication of a FPWD triggers an event under the W3C Patent >>>> Policy. >>>> - The Working Group discussed this Call for Consensus at its 17 >>>> March 2016 teleconference >>>> - https://www.w3.org/2016/03/17-wpwg-minutes >>>> >>>> For the Chairs, Adrian Hope-Bailie >>>> >>>> [1] https://www.w3.org/2015/Process-20150901/#Consensus >>>> >>>> >>>> >>> >> > > > -- > Shane McCarron > Projects Manager, Spec-Ops > -- Shane McCarron Projects Manager, Spec-Ops
Received on Tuesday, 12 April 2016 22:09:04 UTC