Re: Call for Consensus to publish Payment Request API as a Candidate Recommendation, and a new Note

1. Airbnb supports the proposal.

- Michel


On Mon, Oct 19, 2020 at 2:10 AM Marcos Caceres <marcos@marcosc.com> wrote:

> I'd like to:
>
> 1. Support the proposal.
>
>
> > On 16 Oct 2020, at 12:10 pm, Ian Jacobs <ij@w3.org> wrote:
> >
> > Dear Web Payments Working Group Participants,
> >
> > This is a Call for Consensus to publish the following specification as a
> revised Candidate Recommendation:
> >
> >  Payment Request API
> >  https://w3c.github.io/payment-request/
> >  (GitHub commit 0d11184)
> >
> > and to publish the following (new) Working Group Note describing a
> feature removed from Payment Request (see more below):
> >
> >  The MerchantValidationEvent interface
> >  https://w3c.github.io/merchant-validation/?specStatus=WG-NOTE
> >
> >  (Note: Respec errors will be resolved prior to formal publication.)
> >
> > We would like to thank the editors for preparing these documents.
> >
> > PLEASE RESPOND to the proposal by 26 October 2020 (17h00 UTC).
> >
> > For the co-Chairs,
> > Ian Jacobs
> >
> > ===========================================
> > BACKGROUND
> >
> > Last year the Web Payments Working Group discussed (as described in
> > this blog post [1]) not advancing Payment Request API to Proposed
> > Recommendation until:
> >
> > - we had gained more adoption and implementation experience, and
> > - we gained more experience regarding a proposal [2] for
> >  issue 842 [3] regarding shipping addresses and privacy.
> >
> > One year later, implementations in Chromium-based browsers and Webkit
> > have remained essentially unchanged. There are no implementer plans in
> > the near term to address issue 842. Browser vendors believe that there
> > are sufficient privacy mitigations in place in the current API to
> > allow it to ship as part of the Web platform (as it has been for a
> > number of years).
> >
> > Given the stability and interoperability of the implementations and
> > plans of browser vendors, we are proposing to finalize "version 1" of
> > Payment Request API as a W3C Recommendation, and then to continue to
> > work on the API, including privacy considerations and new features
> > (such as our discussions around Secure Payment Confirmation).
> >
> > Payment Request API 1.0 is available through a number of payment
> > service provider libraries (e.g., Stripe and Braintree) and can be
> > used to make payments with Basic Card (in Chromium-based browsers),
> > Apple Pay, Google Pay, and Samsung Pay.
> >
> > This latest draft of Payment Request API includes a small number of
> > substantive changes since the 12 December 2019 Candidate
> > Recommendation [4].  Per the W3C Process, we are returning to
> > Candidate Recommendation (CR) before advancing to Proposed
> > Recommendation. However, we do not expect to remain for very long at
> > CR; see our optimistic timeline for advancing to Recommendation [5].
> >
> > Marcos Caceres is updating the Payment Request API test suite
> > accordingly. We plan to regenerate the implementation report [6] from
> > the updated test suite prior to any formal request to the Director to
> > advance the specification to Proposed Recommendation.
> >
> > [1]
> https://www.w3.org/blog/wpwg/2019/10/28/the-evolution-of-payment-request-api/
> > [2] https://github.com/w3c/payment-request/pull/873
> > [3] https://github.com/w3c/payment-request/issues/842
> > [4] https://www.w3.org/TR/2019/CR-payment-request-20191212/
> > [5] https://github.com/w3c/payment-request/wiki/REC_2020_Plan
> > [6] https://w3c.github.io/test-results/payment-request/all.html
> >
> > ===========================================
> > NON-EDITORIAL CHANGES TO PAYMENT REQUEST API
> > (Since 12 December 2019 Candidate Recommendation)
> >
> > The following features are not supported interoperably and thus have
> > been removed from Payment Request 1.0:
> >
> > * Merchant validation. Note: This was removed because it is only used
> >  in Apple Pay. It is now described in the informative Note mentioned
> above.
> > * hasEnrolledInstrument. Note: This feature is shipping in Chromium-based
> >  browsers and for now has been moved to the living Editors' draft of
> >  Payment Request. That is: as of now it remains part of the API post
> version 1.0.
> > * allowpaymentrequest. Note: This was simply deprecated in favor of
> HTML's
> >  "allow" attribute, which is supported interoperably.
> >
> > Other changes:
> >
> > * Remove recommendation to localize sheet based on body element
> > * Give AddressInit members defaults
> > * Disallow duplicate Payment Method Identifiers when creating request
> >
> > For the full commit history, see:
> > https://github.com/w3c/payment-request/commits/gh-pages
> >
> > ===========================================
> > PROPOSAL
> >
> > That the Web Payments Working Group request that the W3C Director
> approve publication of Payment Request API as a Candidate Recommendation.
> >
> > 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.
> >
> > We invite you to include rationale in your response.
> >
> > If there is strong consensus by 26 October 2020 (17h00 UTC) for the
> proposal, it will carry.
> >
> > ===========================================
> > 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.
> >
> > * We request that any Formal Objections be limited to changes made to
> > Payment Request API since the 12 December 2019 Candidate Recommendation:
> > https://www.w3.org/TR/2019/CR-payment-request-20191212/
> >
> > * 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/2020/Process-20200915/#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 will request approval from the W3C Director to
> > publish Candidate Recommendations (including review of any Formal
> > Objections).
> >
> > * See the optimistic timeline to Recommendation:
> > https://github.com/w3c/payment-request/wiki/REC_2020_Plan
> >
> > --
> > Ian Jacobs <ij@w3.org>
> > https://www.w3.org/People/Jacobs/
> > Tel: +1 718 260 9447
> >
> >
> >
> >
> >
>
>
>