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

Hi David,

Sorry, I don't want to unduly influence the CfC process but I am concerned
that an impression has been generated in the group that we MUST develop an
HTTP API.

Developing an HTTP API is not outside our scope (personally I hope the work
will continue) but nothing in the charter explicitly mandates us to do so.

Most importantly I don't believe this is relevant in deciding between the
choices presented in the CfC which is what I intended to point out.

Adrian

On 15 August 2016 at 15:56, David Ezell <David_E3@verifone.com> wrote:

> Hi Adrian:
>
> Reevaluating the charter is outside of my scope here.  I do understand
> your interpretation of “HTTP, Javascript, or…”  though I had not read it to
> be exclusionary before.
>
> I based my vote on the third item in “1. Goals”:
> " *  The messages exchanged between these parties over the Web.”
>
> And the first item in the “2. Scope” section that says as its first bullet:
> " *  a set of messages that can be used to accomplish payment."
>
> Perhaps these high-level things led me to a false sense of security.  In
> any case, I believe that Payment Through Browser (PTB) is a very important
> component of Payment on the Web - necessary, but not the whole picture.
>
> Best regards,
> David
>
>
> From: Adrian Hope-Bailie [mailto:adrian@hopebailie.com]
> Sent: Monday, August 15, 2016 3:23 AM
> To: David Ezell
> Cc: Telford-Reed, Nick; Payments WG Public
> Subject: Re: CfC on publishing HTTP API and Core Messages - ACTION REQUIRED
>
> Hi David, group,
>
> RE: "NACS voted yes for the charter, which includes the HTTP API."
> This is not entirely true. So we should be wary of blindly pursuing this
> work without reevaluating our charter.
> The relevant section of the charter lists the following deliverable:
>
>
> • User agent to server-side wallet communication: Where request messages
> are passed to a server-side wallet, for example via HTTP, JavaScript, or
> some other approach.
> While it's possible that this could be interpreted to mean that the WG
> should define an HTTP API I believe that this in fact defines the need to
> specify the interaction between the browser and a Web-based payment app and
> is therefor covered by the current Payment Apps API work.
> Adrian
>
> On 15 August 2016 at 02:54, David Ezell <David_E3@verifone.com> wrote:
> Hi All:
>
> Again, apologies for having been unable to attend the meeting in London.
> 1.       NACS votes “yes” to a public draft of the HTTP API.
> 2.       NACS votes “concur” to a public draft insofar as it supports
> commonality between the HTTP API and the Payment Initiation API.
>
> NACS voted yes for the charter, which includes the HTTP API.  We have
> understood that the folks guiding the WG would prefer to finish the Payment
> Initiation API before “shifting gears.”  This sequence is fine, as long as
> the HTTP API is published by the WG as soon as possible.
>
> Best regards,
> David
>
> From: Telford-Reed, Nick [mailto:Nick.Telford-Reed@worldpay.com]
> Sent: Thursday, August 11, 2016 5:47 AM
> To: Payments WG Public
> Subject: CfC on publishing HTTP API and Core Messages - ACTION REQUIRED
>
> 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
>
>
>
>
>
> 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.
>
>
>
>