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

Worldpay support publication of both specifications as FPWD.

 

1. The HTTP API:

 

Worldpay supports the publication to improve awareness of this important use
case.

Worldpay also intend to produce an implementation.

 

2. The Core Messages API:

 

Worldpay supports commonality of messages where feasible between the HTTP
and Browser APIs though appreciates that this alignment has not yet been
sufficiently discussed.

We have no objection to it being renamed to HTTP Core Messages at FPWD, but
encourage the group to invest time on alignment of the messages between the
APIs prior to CR of either.

 

Matt Saxon, on behalf of Worldpay.

 

 

From: Telford-Reed, Nick [mailto:Nick.Telford-Reed@worldpay.com] 
Sent: 11 August 2016 10:47
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>
http://worldpay-hackathon.bemyapp.com

 

 <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 <http://www.dnb.nl> . Worldpay, the logo and any associated brand
names are trade marks of the Worldpay group.
 

 



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus