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

1. Coil supports the proposal

On Mon, 19 Oct 2020 at 21:36, Michel Weksler <michel.weksler@airbnb.com>
wrote:

> 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
>> >
>> >
>> >
>> >
>> >
>>
>>
>>