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

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

Received on Monday, 19 October 2020 09:10:24 UTC