IRC log of wpwg on 2022-01-13

Timestamps are in UTC.

14:43:30 [RRSAgent]
RRSAgent has joined #wpwg
14:43:30 [RRSAgent]
logging to
14:43:35 [Ian]
Meeting: Web Payments Working Group
14:43:47 [Ian]
14:43:50 [Ian]
Chair: Nick
14:43:52 [Ian]
Scribe: Ian
14:43:56 [RRSAgent]
I have made the request to generate Ian
14:55:15 [Ian]
present+ Ian_Jacobs
14:56:16 [clinton]
clinton has joined #wpwg
14:57:11 [Ian]
agenda+ Reminder of anti-trust and competition guidance
14:57:26 [Ian]
agenda+ Criteo review
14:57:40 [Ian]
agenda+ Context setting
15:00:07 [Ian]
present+ Nick
15:00:12 [Ian]
present+ Wendy_Seltzer
15:00:43 [Ian]
present+ Lionel_Basdevant
15:01:06 [Ian]
present+ Stephen_McGruer
15:01:10 [Ian]
present+ Joshua_Koran
15:01:35 [Ian]
present+ Anne_Pouillard
15:01:49 [Ian]
present+ Nick_Shearer
15:02:47 [benoit_]
is there a different webex link for today? the normal one doesn't work
15:03:04 [Anne]
Anne has joined #wpwg
15:03:10 [Ian]
present+ Jonathan_Grossar
15:03:42 [Ian]
present+ David_Benoit
15:03:43 [benoit_]
15:04:11 [Ian]
present+ Philippe_Le_Hegaret
15:04:38 [wseltzer]
15:04:40 [Ian]
zakim, take up item 1
15:04:40 [Zakim]
agendum 1 -- Reminder of anti-trust and competition guidance -- taken up [from Ian]
15:04:48 [wseltzer]
15:04:56 [wseltzer]
Ian: Some stage setting
15:05:08 [Ian]
Nick: Thanks everyone for joining today's call.
15:05:24 [nicktr]
15:05:25 [nick_s]
nick_s has joined #wpwg
15:05:27 [Ian] a reminder of antitrust and competition guidance
15:05:45 [Ian]
(...we share that when we have guests in particular)
15:05:48 [Ian]
zakim, take up item 2
15:05:49 [Zakim]
agendum 2 -- Criteo review -- taken up [from Ian]
15:06:20 [wseltzer]
Ian: we started a member review for Payment Requests and Payment Identifiers.
15:06:34 [wseltzer]
... we got an objection from Criteo, which I've been discussing with them
15:06:38 [nicktr]
ian: For Payment Request and Payment Method Identfiers, we had two formal objections during member review, including one from Criteo
15:06:56 [Ian]
15:07:02 [nicktr]
...we have addressed some of the concerns in editorial changes
15:07:51 [Bastien]
Bastien has joined #WPWG
15:07:51 [nicktr]
...but there were some elements that we couldn't reach consensus
15:08:02 [Ian]
present+ Bastien
15:08:07 [nicktr]
...including topics that might be better addressed in a cross-group fashion
15:09:17 [plh]
plh has joined #wpwg
15:09:20 [Zakim]
As of this point the attendees have been Ian_Jacobs, Nick, Wendy_Seltzer, Lionel_Basdevant, Stephen_McGruer, Joshua_Koran, Anne_Pouillard, Nick_Shearer, Jonathan_Grossar,
15:09:24 [Zakim]
... David_Benoit, Philippe_Le_Hegaret, Bastien
15:09:32 [nicktr]
...In the end, we put forward a call for consensus without addressing the remaining issue
15:09:56 [nicktr]
...we have extended the CfC until tomorrow so that Criteo could address the group directly
15:09:59 [Ian]
present+ Susan_Pandy
15:10:03 [Ian]
zakim, close item 3
15:10:03 [Zakim]
agendum 3, Context setting, closed
15:10:04 [Zakim]
I see 2 items remaining on the agenda; the next one is
15:10:04 [Zakim]
1. Reminder of anti-trust and competition guidance [from Ian]
15:10:09 [Ian]
zakim, close item 1
15:10:09 [Zakim]
agendum 1, Reminder of anti-trust and competition guidance, closed
15:10:10 [Zakim]
I see 1 item remaining on the agenda:
15:10:10 [Zakim]
2. Criteo review [from Ian]
15:10:14 [Ian]
zakim, take up item 2
15:10:14 [Zakim]
agendum 2 -- Criteo review -- taken up [from Ian]
15:10:25 [Ian]
Nick: I'd like to invite colleagues from Criteo to talk through the concern.
15:10:35 [Ian]
present+ Robert_Savage
15:10:42 [Ian]
Josh: Thanks everyone for coming today to hear our concerns directly.
15:10:56 [Ian]
...I hope an interactive conversation will get us to a better outcome.
15:11:08 [Ian]
...Ian laid out the perspectives he heard, and I tend to agree with most of them.
15:11:27 [Ian]
...e.g., discussions of competition in other fora is a good thing, and that should not limit discussion here if there are particulars in this document that would raise concerns.
15:11:41 [Ian]
...the summary of the outstanding concern we have is that standards can give rise to competition issues,
15:11:50 [Ian]
...otherwise w3c would not have its antitrust guidelines.
15:12:08 [Ian]
...the current specification does not yet acknowledge that implementers must not self-preference their own solutions in an anti-competitive manner.
15:12:18 [Ian]
...we acknowledge that w3c cannot control what other organizations can do
15:12:37 [Ian]
...our ask is not for that, but that the spec include text that would raise awareness.
15:12:40 [Ian]
...some specifics:
15:12:59 [Ian]
...section 14.5 says that browsers can rely on other considerations to do whatever they like
15:13:27 [Ian]
...various statements in the specification are not about user choice or to facilitating transactions between merchants and users
15:13:30 [JY_Rossi]
JY_Rossi has joined #wpwg
15:13:47 [Ian]
...we should not leave spec open-ended to whatever browser wants to do
15:14:15 [Ian]
...we want to chat about this to see if we can come to some alignment even if we don't enumerate every possible behavior
15:14:36 [Ian]
...we want to make sure spec does not lead implementers to violate existing w3c policy
15:15:12 [Ian]
...suppose I control the user agent and also offer my own payment solution, I could put my solution at the top and even filter out other competitors
15:15:21 [Ian]
Nick: Any questions or comments?
15:15:47 [nick_s]
15:15:51 [Ian]
Josh: Do people disagree? Is anything I said controversial?
15:15:54 [Ian]
ack Nick
15:16:32 [Ian]
Nick: I don't know that it's controversial. But I would disagree strongly with the proposed change. I don't believe it's appropriate for a standard to have normative language about what implementers must do in reference to laws that are themselves not defined in the standard.
15:16:54 [Ian]
...the W3C antitrust and competition guidance is not referenced in any standard today.
15:17:09 [Ian] exists as part of our organizations all working together.
15:17:30 [Ian] second concern is: how do you determine that conduct violates antitrust and competition guidelines?
15:17:48 [Ian]
...e.g., in some countries, it's a regulatory requirement that some payment methods be placed above others; in other countries it's not.
15:18:04 [Ian]
...I see the concerns but do not support the language as proposed because I don't believe it's appropriate for a technical language.
15:18:18 [Ian]
Josh: We are not wedded to how the concern is addressed; we are open to any method to address the concern.
15:18:51 [Ian] other standards bodies, there is a pre-amble before each meeting (or referenced in other documents) that the work is not meant to be done in a cartel; we are here to generate open standards to facilitate interactions.
15:19:23 [Ian]
...I don't think addressing an anti-competitive concern should be controversial; how do we ensure that the current spec is not supporting illegal activity.
15:19:39 [Ian]
...regarding the point "how would we judge that conduct violates local law or this spec?" I would submit that that is not our job.
15:19:40 [nick_s]
15:20:12 [Ian]
Josh: It's not the role of a standards body to judge the behavior. The standards body produces "neutral" technology that makes things easier ... we just want to be sure we are making the web a better place
15:20:46 [Ian]
...there are some principles within W3C that guide decisions (e.g., privacy). I also think that decentralization is an important principle.
15:21:03 [Ian]
ack nick
15:21:18 [Ian]
s/Nick: I/Nick_S: I/
15:22:20 [Ian]
Nick_S: I understand your position. W3C standards in some countries would be illegal (e.g., algorithms related to crypto). We don't speak to that in the standards. That's one of my fundamental objections here. You are taking a concept that is beyond the expertise of the participants on this call and insert references to legal language that is inherently non-normative.
15:22:36 [Ian]
...there is no single global definition of anti-trust.
15:22:47 [Ian]
...we have to be careful here; there is no precedent in W3C standards to speak to this topic.
15:23:07 [Ian] would be like the encrypted media extension spec saying "don't facilitate piracy"; it does not.
15:23:14 [Ian]
...what's the difference in this case?
15:23:35 [Ian]
..if we want to ensure that users have choice, are there ways to express that without making references to legal matters?
15:23:47 [wseltzer]
15:23:48 [Ian]'s a nuanced issue because there are multiple layers of choice here.
15:23:55 [Ian]
...the merchant may have a preference
15:24:02 [Ian]
...the implementer may have a payment method
15:24:05 [Ian]
...the user has preferences
15:24:09 [Ian]
...there are many stakeholders here.
15:24:39 [Ian]
...can we find language that addresses that issue but in different ways? I think if we do it in this standard it will open a box that I don't think should be in W3C's remit.
15:24:50 [Ian]
Josh: You make some good points, Nick_S.
15:25:07 [Ian]
...our hope is to address the concern; don't need to pursue the proposal as it was written.
15:25:23 [Ian]
...we have also talked about priority of constituencies, for example.
15:25:41 [Ian]
...but there is a difference between this spec and the other examples that were cited (piracy, use of cryptography)
15:25:54 [Ian] the other cases, neither one of those is part of an extant policy of W3C.
15:25:57 [nick_s]
15:26:07 [Ian] the case of antitrust, there is W3C policy in this space.
15:26:16 [Ian]
present+ Chris_Wood
15:27:22 [Ian]
Josh: One approach could be to include a reference to the antitrust guidance to handle this objection. Without some fix, ambiguous language could be used to violate W3C policy.
15:27:27 [Ian]
ack N
15:27:51 [Ian]
Nick_S: My understanding is that the antitrust policy is for participants in the standards creation, not for implementers.
15:28:03 [Ian]
....that policy is primarily to address interactions among participants while creating the standards
15:28:09 [wseltzer]
15:28:11 [Ian]'s not clear that you can reference it in the standard.
15:28:13 [Ian]
ack wseltzer
15:28:34 [Ian]
wseltzer: Thank you, Nick_S. And thanks everyone for participating here. W3C has different types of policies with different origins
15:28:49 [Ian]
...this one was written to govern the behavior of participants in w3c venues
15:29:13 [Ian]
...while the same principles might apply to implementers and those using the technologies,
15:29:50 [Ian]
...we don't currently have references to this policy in our specs for implementers.
15:30:01 [Ian]
..that is why Ian proposed that this is a consortium-wide discussion.
15:30:14 [RRSAgent]
I have made the request to generate Ian
15:30:45 [benoit]
15:31:00 [Ian]
Nick: I am hearing that referencing the antitrust policy in ways it was not designed for should not be done by the WG, but should be first addressed in the AB or wherever.
15:31:04 [Ian]
ack ben
15:31:20 [wseltzer]
15:31:21 [Ian]
David: I think I partially agree with Nick_S's suggestion that this is out of scope of the technical specification.
15:31:45 [JY_Rossi]
present+ JY_Rossi
15:31:59 [Ian]
...perhaps in this instance, we could make reference that implementers of the standard need to be aware that there are obligations that need to be met. But the standard does not dictate how things are done.
15:32:30 [Ian]
15:33:07 [Ian]
Josh: There's a nuance here that I'm seeing. We're not saying that each spec needs to add a ton of language asking people to become experts in local laws.
15:33:47 [Ian]'s an analogy: if I were to propose a spec that required someone to pay a royalty, that would be rejected. That's what we are saying here, too.
15:34:21 [Ian]
...we are saying that there is an existing W3C policy, and that this specification introduces ambiguities that could allow someone to violate that policy.
15:34:25 [nick_s]
15:34:54 [Ian]
Josh: I don't think he intent was to allow disintermediation. Could we clean up the language such that an implementer could not simply say "I'm just following the spec."
15:35:27 [Ian]
Nick_S: I'd really like to see if we can find an approach without legal language. Here's an example that's tricky, for example if a payment service provider is compromised.
15:35:54 [Ian]
...browser engines have revoked entire certificate authorities because either they've been compromised or issued bad certs. Browsers have unilaterally revoked them.
15:36:06 [smcgruer_[EST]]
15:36:20 [Ian] might want to make the argument that that was anti-competitive. But those actions were taken because the security interests of the user are so paramount that we have to do that and can't allow the behavior to continue.
15:36:46 [Ian] can imagine a scenario where a payment provide is acting in ways detrimental to the user, and implementers may need to take actions on the user's behalf.
15:36:54 [wseltzer]
ack nick
15:36:58 [Ian]
...the challenge is how to define that.
15:37:09 [smcgruer_[EST]]
15:37:50 [Ian]
Josh: I agree with you, Nick_S. In the spec already written, there are already enumerations of calling out to the user that there are security issues. But the problem is that there is nebulous language in the spec that could include "my own business reasons" and we don't think that's in the spirt of the specification.
15:38:11 [Ian]
...we do not need to mention anticompetitive policy. We can bound the spec where it is currently unbounded.
15:38:17 [Ian]
ack smcgruer_[EST]
15:38:27 [Ian]
smcgruer_[EST]: Thanks Nick_S; I share many of your perspectives.
15:38:49 [Ian] terms of nebulous language: tricky especially where normative.
15:39:12 [Ian]
...there's a delicate balance. Need, for example, to allow browser to react to not-yet-extant security concerns.
15:39:19 [Ian]
...I took a look at points in the spec.
15:40:02 [Ian]
(Stephen reviews 3.3.6, 3.3.12, @@, 3.3.18)
15:40:26 [Ian]
smcgruer_[EST]: Of these, the most nebulous is 3.3.18; but it's tricky because it involves user experience.
15:40:50 [Ian]
15:41:10 [Ian]
josh: Also 14.5
15:41:13 [Ian]
smcgruer_[EST]: That one is non-normative.
15:41:31 [Ian]
Josh: We are not saying you need to list every security concern.
15:41:49 [Ian]
...if you are saying that we can limit browser stepping in ONLY for security and privacy, that would eliminate the ambiguity.
15:42:15 [Ian]
smcgruer_[EST]: I am sympathetic to that statement. Not sure whether trying to constrain the spec in that way could create problems
15:42:16 [Ian]
15:43:46 [nicktr]
ack Ian
15:44:14 [Ian]
Josh: Perhaps rather than "when the user agent wishes" and instead something in the neighborhood of "when the user is protecting people for security or privacy"
15:44:22 [Ian]
...eliminate the open-ended discretion.
15:45:22 [Ian]
Ian: I think speaking about "security and privacy" does not remove ambiguities in those spaces
15:45:30 [nicktr]
15:45:36 [smcgruer_[EST]]
15:45:37 [Ian]
Josh: But if we could limit ambiguities to "security and privacy" that would be a step forward.
15:45:40 [Ian]
ack smcgruer_[EST]
15:46:20 [Ian]
smcgruer_[EST]: I would be interested in the broader w3c perspective on whether every exit condition in every API needs enumerated conditions.
15:47:08 [Ian]
Josh: Then we should block the current spec rather than moving forward.
15:48:20 [Ian]
Ian: Is "protect the user" open-ended?
15:48:43 [Ian]
Josh: There are many ways to protect the user that aren't about security and privacy.
15:48:58 [Ian]
(Ian was referring to "Optionally, if the user agent wishes to disallow the call to show() to protect the user, ")
15:51:21 [nicktr]
15:51:29 [Ian]
RRSAGENT, make minutes
15:51:29 [RRSAgent]
I have made the request to generate Ian
15:51:37 [Ian]
Topic: Next steps
15:51:59 [Ian]
Nick: People who have concrete suggestions may send them to the mailing list.
15:52:11 [Ian]
..otherwise we have a CfC that closes tomorrow.
15:52:54 [Ian]
...thank you everyone for coming together today
15:53:09 [Ian]
...we really appreciated the presentation
15:53:19 [Ian]
15:53:24 [RRSAgent]
I have made the request to generate Ian
15:53:41 [RRSAgent]
I have made the request to generate Ian
16:08:22 [Gerhard]
Gerhard has joined #wpwg