- From: Shane McCarron <shane@spec-ops.io>
- Date: Tue, 12 Apr 2016 17:59:30 -0500
- To: Payments WG <public-payments-wg@w3.org>
- Message-ID: <CAJdbnOAKvyp9Za6v1JXcv5CPqeMeM5+hqP2==tq4tKXeAb7O4w@mail.gmail.com>
Along these lines.... and not to bury the working group in administrativia, but I am super open to adopting a working model like the following: - Propose changes via PR - Debate PRs until agreed or rejected - Merge PRs that are agreed - Automatically rev the WD via Echidna (W3C publication tool that just works) daily if there are merges. Again, this is just a way of doing publications post-FPWD. A lot of W3C working groups use it. It generates a lot of "churn" when a document is in flux, but... it means nothing public-facing is stale. On Tue, Apr 12, 2016 at 5:16 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote: > <wg chair> > Thanks Shane this helps us to get to a decision on the way forward. > </wg chair> > > <wg member> > > It would appear that Ripple is the only member strongly opposed to > publishing the Payment Method Identifiers spec at this time. > > In the interest of getting consensus and moving us forward I withdraw my > objection but request that the group urgently address the fact that this > document is: > > 1. Loaded with unanswered questions and issues > 2. Incomplete, as it provides very little concrete direction for the > industry on how to define a new payment method and write the appropriate > specifications for this. > 3. Ambiguous, as it proposes 3 options for achieving it's goals > > I ask that this document become a priority deliverable for the WG and that > changes to the editor's drafts be pushed to the the WD regularly so that > the current draft is not left out in public for much longer. > > </wg member> > > On 12 April 2016 at 18:08, Shane McCarron <shane@spec-ops.io> wrote: > >> 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 >> > > -- Shane McCarron Projects Manager, Spec-Ops
Received on Tuesday, 12 April 2016 23:00:27 UTC