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

Hi Adrian:

I’m certainly not trying to derail any consensus.  I also can appreciate the desire to reduce scope in order to concentrate consensus.  Please continue as you think best.

You wrote:
> 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.

I will not quibble with any of that, and I'm glad you are personally in favor.

I do, however, think I need to explain why an HTTP API is important from the NACS perspective:
> Today, our merchants spend millions of dollars on “in-app” software using proprietary message formats.  NACS interest is in 
> having standards that work in the browser OR in-app – that approach allows maximum flexibility to the merchant.

Gray Taylor of Conexxus (the standards arm of NACS) has talked about this "in-app lock-in" problem many times.

There is also a link below to a presentation[1] I gave at a W3C workshop last year - see slide 9 for some details of an "in-app" solution from one of our retailers.  To be clear, for NACS, the merchant should have a choice of using an "in-browser" solution, or continuing to use "in-app" technology without having to support multiple channels.  We would not want to exchange one kind of lock-in for another kind.

I think having compatible web standards that support both of these use cases would truly help the web progress in payments.  I apologize that I hadn't noticed the growing gap between my thinking and the state of play.

Best regards,
David

[1] https://www.w3.org/2015/digital-marketing-workshop/slides/DigitalMarketingandPayments.pdf 

From: Adrian Hope-Bailie [mailto:adrian@hopebailie.com] 
Sent: Monday, August 15, 2016 11:03 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,
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.

Received on Monday, 15 August 2016 16:49:21 UTC