Re: Next Steps Payment Request API; 28 January deadline for concrete proposals

Hi folks,

> As a note, we heard that the enumeration "for security and privacy
reasons" might satisfy the Formal Objection, but would likely not be
supported by implementers because it would not allow for other steps to be
taken to protect the user (e.g., due to resource consumption).

To confirm, Google Chrome does not support the proposal of an enumeration
of reasons.

The User Agent's goal is to do whatever best serves the user, whilst also
being aware of web developers and other needs or requirements. This leads
to a complex space where the need to intervene may fall outside a
constrained list, including potential future interventions that have not
been considered yet when a specification is written.

In the case of PaymentRequest, one could imagine (as theoretical examples)
situations such as a memory constrained device being unable to load any
PaymentHandler in response to a request, or a given PaymentHandler being
restricted by law in some country or region.

Thanks,
Stephen

On Tue, 18 Jan 2022 at 17:08, Ian Jacobs <ij@w3.org> wrote:

> Dear Web Payments Working Group,
>
> The Call for Consensus [1] to publish Payment Request API and Payment
> Method Identifiers as Recommendations ended last week with three statements
> of support and an objection from Criteo. The Chairs consider the objection
> from Criteo to be a strict subset of the Formal Objection they raised
> during the Proposed Recommendation review. Three additional statements of
> support for the
> proposal arrived after the Call for Consensus deadline.
>
> Criteo shared its perspectives on the Formal Objection at the 13 January
> Working Group meeting [2]. During that call it seemed that there might
> still be an opportunity to address the Formal Objection. Although we did
> not hear support for adding text that refers to disintermediation, we did
> perceive an opportunity to address the Formal Objection by including an
> enumeration of acceptable reasons for stopping the show() algorithm in
> steps 6 and 12. Although may not identify an enumeration for which there is
> consensus, we would like to try (for a limited period of time).
>
> In light of the responses to the Call for Consensus and last week's
> discussion, here is our plan:
>
> * Until 28 January (11pm UTC) the Chairs invite concrete proposals for an
> enumeration of reasons for an implementation of the
>   show() algorithm to stop (reject a promise) at steps 6 and 12.
>
>   We request that proposals take the form of pull requests [3] on the
> specification. If that is impractical, Working Group
>   participants may also send proposals to this list.
>
>   As a note, we heard that the enumeration "for security and privacy
> reasons" might satisfy the Formal Objection, but would likely
>   not be supported by implementers because it would not allow for other
> steps to be taken to protect the user (e.g., due to resource
>   consumption).
>
> * If the Chairs believe one or more proposals could reflect group
> consensus and satisfy the Formal Objection, we will organize a Call
>   for Consensus to adopt one of them. If adopted, then we will report to
> the Director that we have resolved the Formal Objection.
>
> * If the Chairs do not see signs of likely consensus, we will conclude
> that further consensus is unlikely and we will request
>   advancement to Recommendation with no changes to the specification.
>
> We will reiterate this plan during our 20 January teleconference [4].
>
> For the co-Chairs,
> Ian Jacobs
>
> [1]
> https://lists.w3.org/Archives/Public/public-payments-wg/2022Jan/0000.html
> [2] https://www.w3.org/2022/01/13-wpwg-minutes
> [3] https://github.com/w3c/payment-request/pulls/
> [3] https://github.com/w3c/webpayments/wiki/Agenda-20220120
>
> --
> Ian Jacobs <ij@w3.org>
> https://www.w3.org/People/Jacobs/
> Tel: +1 917 450 8783 <+1%20917-450-8783>
>
>
>
>
>
>
>

-- 
smcgruer • he / him

Received on Friday, 4 February 2022 20:56:12 UTC