Re: CfC on publishing HTTP API and Core Messages - ACTION REQUIRED

Mozilla does not plan to implement the HTTP API.

We have concerns about splitting the WG's attention between the 
currently prioritized work and the HTTP API, and therefore vote "2" on 
the HTTP API. As the utility of the core messages API is contingent on 
the HTTP API, we also vote "2" on core messages.

If the core messages API is to be adopted, Mozilla supports the renaming 
that has been proposed by others.

/a

On 8/11/16 04:47, Telford-Reed, Nick wrote:
>
> Dear Web Payments Working Group Participants,
>
> At the F2F in London there was support [1] for issuing a Call for 
> Consensus (CFC) to publish two specifications:
>
> 1. The HTTP API
>
> https://w3c.github.io/webpayments-http-api/
>
> 2. The Core Messages API
>
> https://w3c.github.io/webpayments-core-messages/
>
> This is the Call for Consensus to publish. The Chairs and staff 
> document their concerns about these publications in this email. 
> Working Group participant responses will be very important to 
> determining next steps.
>
> Below:
>
> * Chair concerns and considerations
>
> * Proposal (ACTION REQUIRED)
>
> * Reminders about FPWDs, Consensus, and Formal Objections
>
> PLEASE RESPOND to the proposal by 18 August 2016 (1pm EDT).
>
> For the co-Chairs,
>
> Nick Telford-Reed
>
> [1] https://www.w3.org/2016/07/08-wpwg-minutes
>
> ====================
>
> CHAIR CONCERNS AND CONSIDERATIONS
>
> 1) Lack of clear support
>
> Activity on the issue lists and the repositories for these 
> deliverables has been limited to two organizations with the chairs 
> aware of a third organization with some implementation activity. This 
> suggests that the Working Group as a whole is not engaged in this work.
>
> While there were no objections to issuing a CFC at the July 
> Face-to-Face meeting, there was not clear support from a large set of 
> participants. The Chairs are worried about using Working Group time to 
> pursue work that is not broadly supported by the participants because:
>
> a) There is unlikely to be rigorous discussion or debate of the  
> deliverables and they are therefore unlikely to represent a balanced  
> view from the group.
>
> b) There is unlikely to be significant interest in shipping  
> implementations of these specifications.
>
> c) The WG will spend time and energy on a deliverable that has  a low 
> chance of progressing down the standards track.
>
> 2) Low priority at this time
>
> The Working Group has previously discussed the priority of its 
> deliverables. The outside-of-browser specifications are a lower 
> priority than other deliverables currently on our agenda. For that 
> reason, spending time on the content of the specifications or the 
> process of publishing them is taking important time away from 
> prioritized work (payment request API suite and payment apps).
>
> 3) Low interest from implementers in the group
>
> At this time we are aware of only two prospective implementations of 
> the HTTP API:
>
>   - Digital Bazaar, who are also the editors of the specification
>
>   - Worldpay
>
> We invite Working Group Participants to let us know of their plans to 
> implement.
>
> 4) Use cases not yet well-understood
>
> At a high level, we understand that the API is intended for 
> outside-of-browser payments such as payments on the Internet of 
> Things. However, it is not yet clear to the Chairs and staff what 
> concrete interoperability problems the API will solve in a still 
> immature market - one suggestion would be to provide interoperability 
> between two different "things" so that they could pay each other.
>
> For in-browser payments, we understand that the industry expectation 
> is that a Web application behave the same on any browser, so the 
> interoperability benefit of a standard is clear.
>
> Industry expectations may differ for out-of-browser payments. There 
> are already a number of APIs in use on the Web today that offer 
> payment APIs over HTTP (some of which also make use of the 402 - 
> Payment Required HTTP response code and define normative behaviour for 
> that scenario). We do not yet know whether these payment services or 
> their users are seeking interoperability improvements; understanding 
> those needs in greater detail would help motivate this work. While 
> standards could make it easier to make payments to different 
> endpoints, we don't yet have sufficient information about the business 
> demand so positive indications from group members would be helpful.
>
> 5) For Core Messages, too soon to conclude shared message pattern
>
> The goal of Core Messages is that we define the same data for 
> in-browser and outside-of-browser payments. We agree that if we CAN 
> avoid specifying the same thing twice, we should.  But it is too soon 
> to know whether we can accomplish that goal. Furthermore, there are 
> reasons to think we may not be able to, including:
>
> * There are different considerations for in-browser software
>
>   and for "open internet" protocols, notably around security
>
>   models.
>
> * In-browser payments are expected to be largely interactive,
>
>   while we understand at a high level that out-of-browser
>
>   payments are intended to be largely automated. Thus,
>
>   assuming a "mediator" for out-of-browser payments may be
>
>   inappropriate. We need to understand better the use
>
>   cases before making architectural choices that may not
>
>   apply.
>
> At this time, the Chairs and staff contacts believe that publishing 
> these deliverables as Editor's Drafts is certainly appropriate, but 
> there is not clear consensus to publish them as FPWDs. We feel it is 
> important to hear from the broad set of participants in the group to 
> inform the FPWD decision.
>
> ====================
>
> PROPOSAL (ACTION REQUIRED)
>
> Request that the W3C Director approve the following specifications as 
> First Public Working Drafts:
>
>   1. The HTTP API
>
> https://w3c.github.io/webpayments-http-api/
>
>   2. The Core Messages API
>
> https://w3c.github.io/webpayments-core-messages/
>
> For each specification, please indicate one of the following:
>
>   1. Support publishing it as a FPWD of the WPWG
>
>   2. Do not support publishing it as a FPWD of the WPWG at this time, but
>
>      may support it in the future once the WPWG can focus on it.
>
>   3. Do not support publishing it as a FPWD of the WPWG at any time
>
>   4. Support the consensus of the WPWG
>
>   5. Abstain
>
> We invite you to include rationale in your response.
>
> If there is strong consensus to publish --this means many answers of 
> type "1" and at most a small number of answers of type "2" or "3"-- by
>
> 18 August 2016 (1pm EDT), the proposal will carry.
>
> If there is strong consensus to postpone publication --this means many 
> answers of type "2" and at most a small number of answers of type
>
> "3"-- by 18 August 2016 (1pm EDT), the proposal will not carry but the 
> Chairs will expect the topic to return to the Working Group's agenda 
> once other priority topics have been suitably addressed.
>
> ====================
>
> REMINDERS ABOUT FPWDS, CONSENSUS, AND FORMAL OBJECTIONS
>
> * Publication as a FPWD does NOT indicate that a document is complete
>
>   or represent Working Group consensus.
>
> * In case of a decision to publish, the Chairs will request approval
>
>   as First Public Working Draft(s). In this case, if you wish your
>
>   LACK of support to publish to be conveyed to the W3C Director and
>
>   reviewed, please include the phrase "FORMAL OBJECTION" [2] in your
>
>   response and be sure to include substantive arguments or rationale.
>
> * Silence will be taken to mean there is no Formal Objection [2].
>
> * 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.
>
> * 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.
>
> [2] https://www.w3.org/2015/Process-20150901/#Consensus
>
> --
>
> Nick Telford-Reed | Technology Innovation | m: +447799473854 | t: +44 
> 203 664 5069
>
> s: WorldPay Centre, 270-289 Science Park, Milton Rd, Cambridge CB4 0WE UK
>
> http://worldpay-hackathon.bemyapp.com
>
> hack sig <http://worldpay-hackathon.bemyapp.com/>
>
>
> This e-mail and any attachments are confidential, intended only for 
> the addressee and may be privileged. If you have received this e-mail 
> in error, please notify the sender immediately and delete it. Any 
> content that does not relate to the business of Worldpay is personal 
> to the sender and not authorised or endorsed by Worldpay. Worldpay 
> does not accept responsibility for viruses or any loss or damage 
> arising from transmission or access. Worldpay (UK) Limited (Company 
> No: 07316500/ Financial Conduct Authority No: 530923), Worldpay 
> Limited (Company No:03424752 / Financial Conduct Authority No: 
> 504504), Worldpay AP Limited (Company No: 05593466 / Financial Conduct 
> Authority No: 502597). Registered Office: The Walbrook Building, 25 
> Walbrook, London EC4N 8AF and authorised by the Financial Conduct 
> Authority under the Payment Service Regulations 2009 for the provision 
> of payment services. Worldpay (UK) Limited is authorised and regulated 
> by the Financial Conduct Authority for consumer credit activities. 
> Worldpay B.V. (WPBV) has its registered office in Amsterdam, the 
> Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence 
> from and is included in the register kept by De Nederlandsche Bank, 
> which registration can be consulted through www.dnb.nl. Worldpay, the 
> logo and any associated brand names are trade marks of the Worldpay 
> group.
>


-- 
Adam Roach
Principal Platform Engineer
Office of the CTO