decision on formal objection to Payment Request API by Criteo
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.
remaining objection from Criteo requested changes to strengthen
normative language in the specification (from a SHOULD to a MUST) in
from the W3C Team
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.
the objector requested that the formal language of the spec related
must be changed as follows:
SHOULD with MUST in step 18 of the
part of section 3.3.
user agent SHOULD prioritize the user's preference when presenting
Council's recommendation is to overrule the objection.
basis for the decision
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.
there can be legitimate cases for deviating from what the
implementer may understand to be the user's preference, which
requirements in certain jurisdictions about the presence or
ordering of payment methods;
concerns with some payment method(s), such that acting in the
user's interest may differ from acting according to their
for parental controls, corporate policy management, or similar,
which override the preference of the user.
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.
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".
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.
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.
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.
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.
FO Council for Director-free process
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
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
following is a breakdown of the vote we took and the Council felt it
should be attached to the Final Report.
Overrule / Not Uphold: 11
Not Present: 4