Call for Consensus to Publish Payment Request API 1.1 as a First Public Working Draft - RESPONSE REQUESTED BY 18 JULY

Dear Web Payments Working Group Participants,

This is a Call for Consensus to publish the following specification as a First Public Working Draft:

  Payment Request API
  https://w3c.github.io/payment-request/
  (8 July 2022 draft plus any non-substantive edits).
  Expected Title: Payment Request API 1.1
  Expected short name: payment-request-1.1

Publication as a First Public Working Draft does NOT indicate that the document is complete or represents Working Group consensus.

PLEASE RESPOND to the proposal by 18 July 2022 (14h00 UTC).

For example, if you support the proposal, respond to this list with "1. Support the proposal."

We thank the editors for preparing this document.

For the co-Chairs,
Ian Jacobs

----------
BACKGROUND

W3C published [1] Payment Request API 1.0 as a Proposed Recommendation
in September 2021. Since then, W3C has been working to resolve two
Formal Objections from W3C Members; see the Team Report [2] for
details. At this time, a Council is evaluating the Formal Objections
to determine whether Payment Request API 1.0 should advance to
Recommendation or be returned to the Working Group for changes.

In the meantime, the Editors have continued to update the Editor's
Draft [3]. See below for information about changes since September
2021.

Developers and implementers are taking interest in the new features
defined in the Editor's draft. To provide them with more confidence
about these features, the Chairs would like to formally publish the
Editor's Draft as a new W3C Working Draft. This will also provide the
group with a foundation for potential discussion at TPAC about the
future of Payment Request.

It is not uncommon for a Working Group to work on different revisions
of a specification simultaneously (e.g., see the CSS WG). With that in
mind, and because our current charter [4] anticipates enhancements to
Payment Request 1.0, we seek to publish a first 1.1 draft.

Note: If Payment Request API 1.0 advances to Recommendation, the
Editors will determine whether it would be preferable to fold these
changes into an evolving 1.0 Recommendation, or to continue to nurture
a 1.1 branch. At the current time, we do not need to make that
decision.

[1] https://www.w3.org/blog/news/archives/9269
[2] https://www.w3.org/2022/03/prapi-fo-report.html
[3] https://w3c.github.io/payment-request/
[4] https://www.w3.org/Payments/WG/charter-201912.html

--------
PROPOSAL

That the Web Payments Working Group request that the W3C Director approve publication of Payment Request API 1.1 as a First Public Working Draft on the Recommendation Track.

Please indicate one of the following in your response:

1. Support the proposal.

2. Request some changes, but support the proposal even if suggested changes are not taken into account.

3. Request some changes, and do not support the proposal unless the changes are taken into account.

4. Do not support the proposal (please provide rationale).

5. Support the consensus of the Web Payments Working Group.

6. Abstain.

------------------------------------------------
CHANGES SINCE PROPOSED RECOMMENDATION (PUBLISHED SEP 2021)

See the diff:
 https://www.w3.org/2022/07/prapi-diff-20220707.html

Substantive changes (the primary reason to publish):

* Two new definitions for both the IDL type that
  PaymentMethodData/data should be converted into, and for the
  validation steps that a payment method will perform on it. This
  allows payment method specs to define these in a way that is
  cross-linkable to the PaymentRequest specification. This is useful
  for Secure Payment Confirmation. This change is mostly editorial,
  except that it allows for arbitrary error types to be thrown during
  validation (previously only TypeError would be thrown).

* Passing data on complete(). This is an optional feature that allows
  payment handler to provide some information about the nature of a
  completed payment.

* Validate .data on construction. This is an optional feature
  supported in Webkit.

Non-substantive changes:

* Added internationalization support for human readable labels (#971)

* Low-level changes related to imported concepts (e.g., whose names changed
  and we needed to update our reference to them).

* Editorial fixes (example, cross-reference fix)

-----------------
FORMAL OBJECTIONS

* If you wish your LACK of support to publish to be conveyed to the
  Director and reviewed, please include the phrase "FORMAL OBJECTION"
  in your response and be sure to include substantive arguments or
  rationale. 
  
* 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 this document rather than technical
  content where the Working Group has not yet made a decision.

* Silence will be taken to mean there is no Formal Objection.

* If there are Formal Objections, the Chairs plan to contact the
  individual(s) who made them to see whether there are changes that
  would address the concern and increase consensus to publish.

For more information, see:
 https://www.w3.org/2021/Process-20211102/#Consensus

----------
NEXT STEPS

Transition Request Following a Working Group Decision to Publish

* In the case where this Call for Consensus results in a decision to
  publish, the Chairs plan to request approval from the W3C Director
  to publish a First Public Working Draft (including review of any
  Formal Objections).

--
Ian Jacobs <ij@w3.org>
https://www.w3.org/People/Jacobs/
Tel: +1 917 450 8783

Received on Monday, 11 July 2022 13:45:46 UTC