- From: Adrian Hope-Bailie <adrian@hopebailie.com>
- Date: Tue, 12 Apr 2016 09:57:56 -0400
- To: Payments WG <public-payments-wg@w3.org>
- Message-ID: <CA+eFz_LHW_3Cs9Qb7b27pM1LwX+-jL8d=MP2S4HQZAhHWaMt_Q@mail.gmail.com>
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
>
>
>
Received on Tuesday, 12 April 2016 13:58:25 UTC