15:00:41 RRSAgent has joined #wpwg 15:00:41 logging to https://www.w3.org/2022/01/20-wpwg-irc 15:00:45 Meeting: Web Payments Working Group 15:01:09 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20220120 15:01:12 Chair: Nick 15:01:15 Scribe: Ian 15:01:17 present+ 15:01:22 present+ Anne_Pouillard 15:01:30 present+ Arno_van_der_Merwe 15:01:34 present+ Bart_de_Water 15:01:37 present+ Caroline_Medina 15:01:41 present+ Clinton_Allen 15:01:52 present+ Gerhard_Oosthuizen 15:01:54 present+ Jean-Michel_Girard 15:01:57 present+ Jonathan_Grossar 15:02:04 present+ Marianna_Cunha 15:02:07 present+ Susan_Pandy 15:02:11 present+ Nick_Telford-Reed 15:02:28 present+ Praveena_Subrahmanyam 15:02:36 present+ Doug_Fisher 15:02:54 agenda+ PR API Status 15:03:01 agenda+ Upcoming changes to User-Agent string 15:03:07 agenda+ Review of Privacy Resources 15:03:12 scribe: Nicktr 15:03:21 present+ Ryan_Watkins 15:03:25 Gerhard has joined #wpwg 15:03:26 present+ Erhard_Brand 15:03:38 present+ Jean-Luc_Di_Manno 15:03:42 present+ Stephen_McGruer 15:03:49 JL has joined #wpwg 15:04:01 present+ Tomoya_Horiguchi 15:04:39 I have made the request to generate https://www.w3.org/2022/01/20-wpwg-minutes.html Ian 15:04:43 zakim, take up item 1 15:04:43 agendum 1 -- PR API Status -- taken up [from Ian] 15:05:03 JMGirard has joined #wpwg 15:05:45 ian summarises state of Payment Request -> https://lists.w3.org/Archives/Public/public-payments-wg/2022Jan/0030.html 15:06:26 [No questions] 15:07:23 NickTR: The meeting last week was constructive; we wanted as chairs to create an opportunity to further resolve the objection, e.g., through an enumeration of reasons in the spec why the implementation could stop the show algorithm. 15:07:32 zakim, close item 1 15:07:32 agendum 1, PR API Status, closed 15:07:33 I see 2 items remaining on the agenda; the next one is 15:07:33 2. Upcoming changes to User-Agent string [from Ian] 15:07:37 zakim, take up item 2 15:07:37 agendum 2 -- Upcoming changes to User-Agent string -- taken up [from Ian] 15:07:55 zakim, take up item 3 15:07:55 agendum 3 -- Review of Privacy Resources -- taken up [from Ian] 15:08:13 -> https://github.com/w3c/webpayments/tree/gh-pages/privacy Privacy and Web Payments 15:08:22 present+ Werner_Bruinings 15:09:25 NickTR: First we wanted everyone to be aware of these resources. 15:09:41 werner has joined #wpwg 15:10:22 -> https://github.com/w3c/webpayments/blob/gh-pages/privacy/use-cases/README.md Use cases known to be impacted by changes to browsers 15:10:56 jonathan has joined #wpwg 15:11:02 Nick: Some user experiences likely to be affected, e.g., which bank you used (stored in a 3p cookie) 15:11:21 +q 15:11:47 ack JL 15:12:08 Jean-Luc: We also observe impact on SRC (keeping track of user identity) 15:12:14 ...that's not yet in the use cases 15:13:08 ACTION: Ian to add the SRC user recognition use case to the resources 15:13:39 Gerhard: After the user recognition step, there's a challenge step. 15:14:14 Jonathan: First there is user recognition (done today through cookie); we need to identify alternative solutions 15:15:22 q+ 15:15:46 Jean-Luc: There is also a question of SRC SDK...to be sure how all the systems recognize the same user; federated ID issue. 15:16:01 Jonathan: I think that is an aspect of the same recognition issue 15:16:01 +q 15:16:07 ack nick 15:16:40 NickTR: We know that Safari and Firefox already have restricted cookie access; how does SRC work in those browsers? 15:16:45 present+ Manjush_Menon 15:16:53 ack Cli 15:17:21 Clinton: In browsers with limited 3p cookie access, the consumer has to re-enter identifying information and possibly other information 15:17:53 NickTR: Is there any data that suggests that friction is causing additional drop-off? 15:18:08 Clinton: I don't think I have any data, but at least intuitively the friction creates challenges. 15:18:39 ...and having a cookie or other mechanism for user recognition would be an improvement. Where confidence is low, you can do a 1-time challenge or email 15:18:51 ...once card has been selected, you can go through a cardholder authentication. 15:19:54 q? 15:19:59 NickTR: Who would see in their analytics whether there was a statistically significant drop off? Would it be PSPs or SRC systems? 15:20:14 Clinton: The SRC systems might be involved, but I think the SRC-I would be the most likely to detect this 15:20:22 I have made the request to generate https://www.w3.org/2022/01/20-wpwg-minutes.html Ian 15:20:31 q+ 15:20:37 ack Ger 15:21:01 Gerhard: Just a thought in terms of making that journey easier: in a 3p environment, think of discoverable credentials. 15:21:15 ...is there restricted access to discoverable credentials in a 3p context? 15:21:55 smcgruer_[EST]: WebAuthentication authentication is available in 3p iframes in Chrome. So what you are describing is roughly possible (where implemented) 15:22:28 ...there is also a proposal by Google called "Conditional UI" 15:22:57 ..it would fit well here: the page could allow the user to enter an identity, but also click on a button for FIDO authentication. 15:23:15 ...it could be a fit, but would in any case be a world with more friction than cookies 15:23:28 Jonathan: You could prompt for FIDO authentication, but you don't know credential IDs in this context. 15:23:55 ...could the browser prompt the user to consent, and that could reveal the SRC identity 15:25:02 smcgruer_[EST]: Discoverable credentials allows calls to find out what credentials are available. But there are origin (1p) limitations. 15:25:25 q? 15:25:59 ...if rp.com is in a cross-origin iframe, rp.com can ask for discoverable credentials for rp.com 15:26:10 Jonathan: Does this exist today? 15:26:36 smcgruer_[EST]: rp.com can initiate an authentication. 15:28:25 q+ 15:28:42 ack 15:28:42 present+ Jeremy_Ney 15:28:45 ack clinton 15:29:17 clinton: for discoverable credentials, if all SRC systems used a common origin, would that be a simpler solution? 15:29:35 smcgruer_[EST]: yes, in general having a single origin would make this easier. 15:29:52 ...if there's a single origin, you can open a popup in a 1p context and you have your cookies 15:30:05 present+ Mike_Taylor 15:30:26 use cases are here -> https://github.com/w3c/webpayments/blob/gh-pages/privacy/use-cases/README.md 15:30:54 Manjush: Is the current construct that it has to be based on a popup experience or initiated via a button? 15:31:28 smcgruer_[EST]:How to get a 1p context: popup, redirect, payment handler, native browser integration 15:31:55 manjush: We are also contemplating a model where the SRC experience is embedded in the merchant origin 15:32:05 present+ Jade_Kessler 15:32:27 present+ Ali_Beyad 15:32:58 zakim, close item 3 15:32:58 agendum 3, Review of Privacy Resources, closed 15:32:59 I see 1 item remaining on the agenda: 15:32:59 2. Upcoming changes to User-Agent string [from Ian] 15:33:02 zakim, take up item 2 15:33:02 agendum 2 -- Upcoming changes to User-Agent string -- taken up [from Ian] 15:33:27 present+ 15:33:32 apolgies for being late 15:35:09 Mike: We plan to make changes to user agent string; want to understand potential impact of changes of payments flows. 15:35:26 present+ Rowan_Merewood 15:35:41 Mike: Strings are a hot mess. Can be used for covert tracking 15:35:47 ...parsing is painful and fragile 15:36:11 ...to address these we would like to (1) freeze some information in the string and (2) reduce some other information 15:36:45 ...we could keep some information that would continue to change (e.g,. OS, browser name, major version number) 15:37:16 ...we also want to provide a new API that provides hints about the user agent 15:37:35 ..."UACH" is User Agent Client Hints 15:37:58 ...UACH will provide some of the high entropy bits that are being removed from the UA String 15:38:05 ...we also plan to reduce some of the JS Apis 15:38:45 ...timelines: we launched an origin trial in October; a couple of months to go for testing 15:38:59 ...we want people to test now to tell us if we are breaking things 15:39:22 ...in M96 we created a mechanism to get hints on first request 15:40:14 ...if you are doing content negotiation on the first request, it's problematic because you only get data on second request 15:40:33 ...moving forward we would provide info on first request; cached for subsequent visits 15:40:51 ...once we are past testing phase, we will roll this out in Chrome 101 on Desktop 15:41:05 ...that's when we reduce the "minor version" information, which will turn to "0.0.0" 15:41:28 ...during this period we want people to migrate to UACH 15:41:38 ...we'll continue to reduce the string on mobile in phase 3 15:41:58 ...there will be a deprecation path for some period of time 15:42:10 ...up to approximately May 2023 15:42:48 -> https://docs.google.com/presentation/d/1tec2bCpGHGM4FkX4y4GFlBwCa9dWs1ukGot-xkHRX-A/edit#slide=id.g10c56b38801_0_1933 15:42:48 Mike's slides 15:43:28 Mike: User Agent string is loosely defined in HTTP spec (at IETF) 15:43:41 ...but it's very loosely defined 15:44:06 NickTR: What are expectations about similar changes in other browsers? 15:44:08 +q 15:44:31 Mike: We are aware of similar actions. Safari has largely frozen UA string; only major and minor version update these days 15:44:52 ...Firefox also capped version of MacOS and Windows and they are considering further ideas 15:45:13 ...there's no coordinated plan among all the browsers, but there is general sentiment to reduce information in the string 15:45:30 -> https://wicg.github.io/ua-client-hints/ UACH specification 15:45:41 ...being worked on in the WICG 15:46:07 ...this is intended to work cross browser 15:46:10 q+ 15:46:15 q+ 15:46:36 Mike: We don't yet have a formal position from Apple. Mozilla is interested in the JS API. 15:46:50 q? 15:46:51 ack JL 15:46:53 ack JL 15:47:25 Jean-Luc: You are removing the UA string to reduce tracking. But there are legitimate use cases (e.g. risk assessment). 15:48:09 Mike: We don't plan to remove the UA string completely; we just plan to reduce it. 15:48:14 q+ 15:48:39 Mike: UACH can be used to regain some entropy that we are removing from the string. 15:48:44 q? 15:48:46 ...we are moving this from a passive to an active surface 15:48:48 q+ 15:49:05 Mike: This should help the browser support legitimate anti-fraud use cases 15:49:08 ...see also trust tokens 15:50:48 q- 15:50:57 Ian: Could you add a user consent feature to give back more data? 15:51:32 Mike: It's not part of our vision to add a permissions model. But there has been discussion about how the user could provide consent where the user says "I'm ok with this site asking for this." 15:51:33 ack Ian 15:52:05 IJ: Is that conversation to happen in antifraud CG? 15:52:09 smcgruer_[EST]: +1 15:53:16 Ian: We've also looked at trust tokens; not quite all we need for determining "trust this browser WITH THIS INSTRUMENT." 15:53:44 Gerhard: Clarifying question - some stuff is being taken away and some is given back. Is there any plan to stop sending information to some domains to prevent misuse? 15:53:57 Mike: We are actively considering that; see the privacy budget discussion. 15:54:23 ...it's an abstract idea that the browser can track how much entropy an origin is requesting. And the browser might be able to act on the user's behalf when a lot is being demanded. 15:54:34 q+ 15:54:39 ...we need something to enforce the entropy collection if it's not valid or doesn't reflect user consent. 15:54:41 ack Gerhard 15:54:45 zakim, close the queue 15:54:45 ok, Ian, the speaker queue is closed 15:54:52 I have made the request to generate https://www.w3.org/2022/01/20-wpwg-minutes.html Ian 15:55:21 Gerhard: Any thinking about bringing the user into the entropy discussion? 15:55:42 q- 15:55:54 Mike: These are conversations that are being had: what does privacy budget mean? 15:56:21 Ian: Go see the privacy community group => https://www.w3.org/community/privacycg/ 15:56:22 ack clin 15:56:24 ack clinton 15:56:46 clinton: In this context is "entropy" used commonly? 15:57:12 https://en.wikipedia.org/wiki/Entropy_(information_theory) 15:57:14 Mike: This is an information theoretic use of the phrase. Bits of identifying information. I think 33 bits of information is all you need to identify every human on the plan. 15:57:18 s/plan/planet 15:57:37 ...we are trying to prevent bad actors from being able to identify users individually 15:58:07 Mike: You are welcome to send me questions (email in slides) and let me know whether you think this will break deployments (e.g., no more minor version in the strings) 15:58:11 I have made the request to generate https://www.w3.org/2022/01/20-wpwg-minutes.html Ian 15:59:28 Topic: Next meeting 15:59:31 3 February 15:59:36 I have made the request to generate https://www.w3.org/2022/01/20-wpwg-minutes.html Ian 15:59:43 RRSAGENT, set logs public 16:02:28 mikehorne has joined #wpwg