The Formal Objection from Criteo to advancing the Web Payments Request API to a Recommendation contained several elements. The working group and Criteo, the objector, resolved most of these elements, and a Council was convened to consider the remaining objections.

The remaining objection from Criteo requested changes to strengthen normative language in the specification (from a SHOULD to a MUST) in one instance.

The objection was to open-ended language that, in the view of the objector, could be used by an implementer to justify preferencing one or several payment solutions for its own commercial interests, exceeding the scope of the working group to facilitate payments between users and merchants.

Notably, the objector requested that the formal language of the spec related to the show() method must be changed as follows:

Replace SHOULD with MUST in step 18 of the show() method part of section 3.3.

"The user agent SHOULD prioritize the user's preference when presenting payment methods."

The Council's recommendation is to overrule the objection.

Both the AB and TAG consider that putting user needs first is an important value and design principle of the web, and in that sense, agree with Criteo that it would be inappropriate for a user agent to use the flexibility offered by the specification language to put its interests, or the interests of some third party, ahead of those of the user.

However, there can be legitimate cases for deviating from what the implementer may understand to be the user's preference, which include:

• legal requirements in certain jurisdictions about the presence or ordering of payment methods;
• security concerns with some payment method(s), such that acting in the user's interest may differ from acting according to their preference;
• tools for parental controls, corporate policy management, or similar, which override the preference of the user.

Further, the specification talks about "user's preference" as a singular thing, presuming it to be known, but it may be complex and/or context-dependent, and isn't necessarily known to the user agent.

Due to such considerations, using MUST would not be appropriate as there would necessarily be exceptions, which are impractical to list exhaustively or even to fully anticipate. SHOULD already has the meaning of "MUST unless there are good reasons".

W3C Recommendations are voluntary standards, concerned with describing the expected behavior, not with verifying or enforcing compliance. The use of SHOULD here does not, by itself, guarantee that exceptions are made in the user's interest; and when exceptions are made, whether or not they are in the user's interest is subjective, and cannot be verified reliably.

In conclusion, if a user agent disregarded or de-prioritized users' interests, this would not be a matter of interoperability that could reasonably be addressed by better specification language. This is something that users can take into their own hands, for example, by choosing a different user agent. Therefore blocking the publication of the Recommendation to work on improvements to this phrasing did not seem appropriate to the Council.

Criteo raised some antitrust and competition concerns with some potential implementation approaches. The Council considers this out of scope, and does not take a position on these matters, and notes that as per the W3C Antitrust and Competition Guidance: “It is each participant's responsibility to obtain appropriate legal counsel regarding their conduct in W3C and to comply with applicable antitrust or competition laws and regulations.” This is true for this specification as for any other.

The Council discussed concerns that the sentence in question in the specification is effectively a prescription about user interface, which web specifications tend to stay away from. UI may vary significantly from one user agent to another, or by operating system, display technology (or non visual rendering), and so on. In the context of this specification, a choice is being offered to the user, but how that is accomplished is (rightfully) entirely undefined. The notion of priority may not even necessarily be applicable. The Council will not attempt a design review in these comments, but cautions that the approach of recommending user agent UI patterns or restrictions that aren't necessary for interoperability seems unnecessary, and doesn't respect user's right to choose a user agent with UI that works for them. Such language is difficult to test for, outside the scope of W3C recommendations, and could be avoided altogether. The Council did not formally consider the impact of this normative language on UI, since it was out of scope for Criteo's objection, but does not want this decision to be an endorsement of normative UI in specs for future decisions.

In recognition of Tim Berners-Lee's eventual retirement, the W3C Advisory Board and W3M have been exploring the possibilities of a Director-free future for the W3C. As part of these explorations, W3M invited the Advisory Board and the TAG to a third joint session for handling formal objections as a joint Council. This followed a similar process to the work done for the two previous instances with considerable work to document and gradually improve the process. We did suppose that the Council would have the powers to sustain or overturn a formal objection and explain its reasoning, but not to mandate any specific remedies. This report is the conclusion of this experimental Council on the matter of Criteos's formal objection to the Rec-track progress of the Web Payments Request API specification.

This conclusion has been forwarded to W3M as input into the Director's resolution of this issue. Following this experiment, the AB, TAG, and W3M, together with the Process CG, will be using this experience and its evaluation to help us chart the future of a Director-free Consortium.

The following is a breakdown of the vote we took and the Council felt it should be attached to the Final Report.

Abstain: 5
Overrule / Not Uphold: 11
Not Present: 4