13:45:34 RRSAgent has joined #wpwg 13:45:38 logging to https://www.w3.org/2023/03/29-wpwg-irc 13:45:45 Meeting: Web Payments Working Group 13:46:01 Agenda: https://github.com/w3c/webpayments/wiki/Remote-Agenda-202303 13:46:03 Chair: NickTR 13:46:05 Scribe: Ian 13:46:12 agenda+ SRC WG input on SPC 13:49:52 clinton has joined #WPWG 13:58:32 takashi has joined #wpwg 13:58:38 present+ 13:58:42 present+ Clinton_Allen 13:59:14 jpmarzetti has joined #wpwg 13:59:42 present+ Carey_Ferro 13:59:44 cferro has joined #wpwg 13:59:45 present+ Christian_Aabye 13:59:53 present+ Juan_Pablo_Marzetti 13:59:58 present+ Holger_Kunkat 14:00:28 present+ David_Benoit 14:00:32 present+ Bryan_Penny 14:00:37 present+ Steve_Cole 14:01:07 TonyE has joined #wpwg 14:01:30 present+ Tony_England 14:01:35 present+ Takashi_Minamii 14:01:37 presnet+ Solai 14:01:41 present+ Solai 14:01:44 present+ Praveena 14:01:54 bryanpenny has joined #WPWG 14:01:54 present+ Harjender 14:01:54 praveenas has joined #wpwg 14:02:04 Gerhard has joined #wpwg 14:02:16 present+ Gerhard 14:02:16 present+ Tomasz 14:02:24 present+ Giorgio 14:02:32 present+ Gustavo_Kok 14:02:38 Steve_C has joined #wpwg 14:02:44 Solai has joined #wpwg 14:02:50 present+ Haribalu 14:03:05 present+ Nick_Burris 14:04:02 present+ Stephen_McGruer 14:04:09 present+ Omer 14:04:38 present+ Michael_Horne 14:04:52 present+ Arman_Aygen 14:05:30 present+ Nick_Telford-Reed 14:06:04 present+ Gokhan_Tekkaya 14:06:25 present+ Sue_Koomen 14:06:42 Topic: Agenda Bashing 14:07:13 Overflow candiate topics: 14:07:13 Frictionless payments 14:07:13 Relation to recurring payments use cases (e.g., is re-authentication necessary or avoidable?) 14:07:13 Recurring payments 14:07:13 More discussion needed? 14:07:14 API refactoring 14:07:15 Using CredentialsContainer.get() instead of Payment Request API (#56) 14:07:17 SPC integrations 14:07:19 PIX; how do issuers and merchants communicate? 14:07:21 Payment Request 14:07:23 Next features? 14:07:26 Payment Handlers 14:07:27 Next features? 14:07:31 Reminder of half-height modal window 14:07:33 ===== 14:08:13 Derek_Tong has joined #wpwg 14:08:20 present+ Derek_Tong 14:08:25 Sue has joined #wpwg 14:08:44 zakim, take up item 1 14:08:44 agendum 1 -- SRC WG input on SPC -- taken up [from Ian] 14:08:45 vasilii has joined #wpwg 14:08:53 present+ Vasilii 14:09:21 present+ AdrianHB 14:09:26 [Clinton Allen slides] 14:09:41 present+ Jean-Luc_di_Manno 14:09:50 jeanLuc has joined #WPWG 14:10:26 Clinton: A good place to start is to provide clarity between "recognition" (entering identity) and "authentication" (proof) 14:12:02 ...today we'll look at a few emerging technologies that are relevant to these topics 14:12:35 ...if we don't have a browser capability to identify / remember the consumer, they will need to enter their identity 14:12:46 ...so upcoming challenges: no cookie access 14:13:12 ...but if we do have some form of recognition, we can streamline and get closer to frictionless (e.g., display candidate list of cards) 14:13:44 ...we would store information about cardholder identity upon first checkout, and then be able to retrieve the identity for subsequent transactions. 14:14:07 ...we've talked about cookies, also "domain recognition" (cf bounce tracking to a domain that is separate from the merchant's origin) 14:14:18 ...FedCM is compelling for federated login 14:14:33 ...merchant recognition is also an option (for storing information in the merchant domain that is forwarded to the src system) 14:14:43 ...so those are the four main models we've identified as helping with recognition 14:15:22 ...one vision for what the browser can do to help is help with "horizontal recognition"...that is, cross-origins 14:15:32 SameerT has joined #wpwg 14:15:36 present+ 14:17:09 [Diagram of FedCM for recognition] 14:17:40 Clinton: Stephen's demo showed a card list (rather than merely identities); that may or may not be interesting 14:18:01 ...one thing we note when using FedCM for our use case is that some language (e.g,. "logging in") may confuse users for this case 14:18:15 ...another topic: de-dupe in some scenarios (multiple SRC systems) 14:18:39 q+ to ask Stephen (or anyone who knows FedCM) if there is room for a concept of recognition vs authentication? (can wait to end) 14:18:46 [Diagram showing FedCM to get identity followed by card selection followed by SPC] 14:19:24 clinton: In Stephen's demo, the FedCM response included the card reference so the user could pick the card and immediately go to authentication 14:19:45 q+ to ask if FedCM could return fedrated id token? 14:19:47 ack Adrk 14:19:49 ack AdrianHB_ 14:19:49 AdrianHB_, you wanted to ask Stephen (or anyone who knows FedCM) if there is room for a concept of recognition vs authentication? (can wait to end) and to ask if FedCM could return 14:19:49 ... fedrated id token? 14:19:55 q+ to ask about possibility of a "clicktopay.com" unified domain/recognition service 14:20:20 AdrianHB_: I understand the concept of the federated identity token for user recognition across SRC systems. 14:20:32 ...would that be an appropriate response from FedCM if you query each SRC system? 14:20:44 ...suppose instead of a card list you got a federated id token? 14:21:14 Clinton: I _think_ so. I don't yet understand the restrictions on what can be enrolled for credential management. We're open to all discussion. 14:22:05 Tomasz: Yes, I think it works in FedCM to return a federated id token 14:22:29 ...question is "who is the id provider"? 14:22:45 ...if SRC system, then could get back SRC-compliant token 14:23:00 Sue has joined #wpwg 14:23:04 ...if a third-party id provider, then there could be a round trip between id provider and SRC system to get a federated id token 14:24:14 [CORRECTION: Tomasz does not think the third-party intervention would be a thing] 14:24:50 s/[CORRECTION: Tomasz does not think the third-party intervention would be a thing]// 14:24:53 q+ 14:26:18 AdrianHB_: My understanding of FedCM: browser makes a 1p request to identity provider; the identity provider can recognize the user but there is no authentication. Is that the correct understanding? 14:26:45 Clinton: The thing that confuses me is "logged in" v "logged out" status. If you are logged in, then you are already authenticated in some capacity. 14:27:04 AdrianHB_: Maybe there is a distinction between "there is a valid session" v. not 14:27:44 Tomasz: From my perspective, Adrian's perspective is accurate -- identity returned but no assumptions about authentication 14:27:46 q? 14:28:04 ack nicktr 14:28:04 nicktr, you wanted to ask about possibility of a "clicktopay.com" unified domain/recognition service 14:28:32 present+ Doug_Fisher 14:28:44 NickTR: What is the latest on a consolidate recognition service (clicktopay.com) 14:29:30 Tomasz: We do have an idea for a solution using a recognition domain 14:29:49 ...user can be remembered by individual SRC system or a common entity 14:29:55 ...both models are supported in SRC 14:30:05 ...the common entity could become the identity provider 14:31:35 q? 14:31:53 q+ to ask if FedCM could replicate the SRC model 14:32:04 Ian: Common entity could help with de-dupe (using cookie jars for SRC systems) 14:32:07 ack jeanLuc 14:32:38 jeanLuc: If the flow is (1) user recognition (2) get card list (3) authenticate 14:33:44 Clinton: In a world where FedCM call returns candidate card list, it would short-circuit some of SRC functionality 14:34:35 JeanLuc: So fed cm gathers the card list (and bypasses SRCI-I) 14:36:20 Ian: I feel like it's still the same flow, just implemented differently (get identity, get card list is still happening) 14:36:39 Clinton: Right, set of capabilities are still there 14:36:40 q? 14:37:49 q+ to note the logged-out problem 14:37:53 Tomasz: I think the short-cut flow is very illustrative at this point 14:37:58 ...for the future maybe 14:38:00 ack AdrianHB_ 14:38:01 AdrianHB_, you wanted to ask if FedCM could replicate the SRC model 14:38:19 AdrianHB_: I think FedCM, if it returns a card list, will group cards by SRC system 14:38:33 ...assuming each SRC system is an identity provider 14:39:01 ...so the fully distributed version (not using common entity) would lead to a bucket display of cards (by SRC system) 14:39:12 ...to get a consolidated list you might need new FedCM capabilities. 14:39:21 ...e.g., adding de-duping 14:39:23 q? 14:39:33 AdrianHB_: That might be helpful for FedCM to include 14:40:33 ...it would be interesting to call FedCM with a list...I want an identity token from any or all of these, and please consolidate the data you get back from them; give back the data in one response. 14:40:38 ...but I don't know how that gets presented to the user 14:40:52 q+ 14:41:14 Clinton: I agree; I think that is a good reason to think about this as future functionality. 14:41:26 ...if FedCM is for recognition (today) perhaps we leave it as such for today 14:41:40 ack smcgruer_[EST] 14:41:40 smcgruer_[EST], you wanted to note the logged-out problem 14:41:43 ack smcgruer_[EST] 14:42:14 smcgruer_[EST]: Regarding card selection through FedCM, you would run the risk of not being logged into to some SRC system. 14:42:33 ...regarding de-dupe, we've suggested that the SRC folks raise an issue on FedCM to ad de-duping 14:42:42 ack jeanLuc 14:42:54 ack jeanLuc 14:44:16 -> https://github.com/fedidcg/FedCM/issues FedCM issues list 14:45:32 Tomasz: The SRC-I would need to call FedCM with all participating SRC systems. 14:45:58 ...so no SRC system is missed 14:46:08 ...this would happen via a JS SDK 14:46:36 Clinton: If we are using the identity as the FedCM credential, all the logic for presenting the candidate list happens within the SRC-I. 14:46:56 ..in the model where FedCM returns card list, that moves the logic of how the card information is presented into FedCM. 14:47:08 ...and maybe the merchant does not accept all card types 14:47:19 ...FedCM does not include card filtering mechanisms. 14:47:26 +1 - Let's find a way to use FedCM for recognition of consumer (not card list) 14:47:57 q? 14:48:05 [On Authentication] 14:48:30 Clinton: SCR 1.3 includes features for Authentication Facilitation Service 14:48:42 ...similar to GNAP flow 14:48:53 ..there's a request to a party to find out what authentication options are available. 14:49:07 ..the response of authentication methods includes a set of options, including SPC and FIDO 14:49:25 ...this allows the merchant to request authentication via one of the authentication methods. 14:49:41 ...suppose the merchant selects SPC 14:50:09 [We see slides where user enters identity, selects card, then SPC transaction dialog] 14:50:30 [Flow diagrams] 14:51:25 Tomasz: We've mostly talked about SPC in the context of 3DS. But what we are showing here is authentication without 3DS 14:51:33 q+ 14:52:48 Tomasz: In the flow, there is an authentication methods lookup phase (which could return "SPC") 14:53:06 ...at the same time, that response would include data needed for SPC (e.g., credentials, nonce) 14:53:40 [CORRECTION: Second request/response returns data] 14:53:50 ...then data used to trigger SPC 14:54:04 q+ to ask if account reference == PAR? 14:54:54 Tomasz: When merchant gets back the assertion, the merchant calls the authentication service again and provides assertion to the SRC system for validation 14:56:43 ack nick 14:56:43 nicktr, you wanted to ask if account reference == PAR? 14:57:22 NickTR: Where you refer to "account reference" ... is that PAR? 14:57:55 Tomasz: It's rather an SRC identifier for the card...it's a digital card id (not a PAN or PAR) 14:58:18 present+ Erhard_Brand 14:58:43 ack Ian 14:58:43 ack me 14:58:49 Ian: Any additional requirements for SPC from the SRC WG? 14:59:05 q+ 14:59:05 Clinton: I think the answer is "no" at this time :) 14:59:23 Tomasz: We are discussing fallback UI as an improvement 14:59:25 q+ 14:59:35 ack Gerhard 15:00:31 Gerhard: Does the SRC have similar display requirements as 3DS, or is it less prescriptive in display? 15:01:02 present+ David_Fraser(Visa) 15:01:34 Clinton: Regarding various payment scenarios (split payments, etc.). From an SRC perspective, I think the details of all the types could be presented prior to the SPC call...better separation of concerns 15:02:01 q+ 15:02:02 Tomasz: There are some UX guidelines for full checkout 15:02:12 zakim, close the queue 15:02:12 ok, Ian, the speaker queue is closed 15:03:39 Clinton: I am intrigued by GNAP for more formal management of transaction contexts 15:03:51 ack jean 15:03:59 jeanLuc: Interesting to see all the SPC possibilities 15:04:34 ...who has responsibility in the case of fraud if SRC performs authentication? 15:06:13 Clinton: I suspect the answer depends on the authentication methodology. So if it's 3DS it might be one answer, and another answer with a different authentication method 15:06:13 Tomasz: +1 15:06:13 ...SRC facilitates the authentication, but doesn't imply the SRC is the RP or authenticating party 15:06:13 ack Ian 15:06:20 I like these. 15:06:38 q? 15:06:46 Probably just say 'Passkey' rather than Touch ID. 15:08:01 Topic: Frictionless Payments 15:08:57 q+ Sammer 15:08:59 q- Sammer 15:09:01 q+ sameer 15:09:05 zakim, open the queue 15:09:05 ok, Ian, the speaker queue is open 15:09:08 q+ sameer 15:09:57 q+ 15:09:57 NickTR: There's a tension here of course between privacy and friction 15:09:57 ...important to keep both topics in mind 15:10:04 q? 15:10:09 ack SameerT 15:10:40 q+ to ask if FedCM could help with frictionless if it has a "payment" mode (that would also work with SRC). This would just change the prompt from "login" to "pay" or something 15:10:42 SameerT: Bringing recurring payments into SPC does not force merchants to use SPC. 15:10:50 +1 15:10:55 ....SPC is low friction, but still friction (from a 3DS perspective) 15:11:06 ...using SPC does not preclude frictionless uses of 3DS 15:12:22 q+ 15:12:28 +1 15:12:37 NickTR: I guess what we are looking for is "low friction" rather than no friction. Or "lubricated payments" 15:12:57 SameerT: The need to know this is the same user on the same device hasn't gone away 15:13:06 ack sameer 15:13:11 q? 15:13:52 Gerhard: I want to reflect on a few points. There seems to be two models on how this could be done 15:14:15 ...one group says "we want to silently detect presence of a user" 15:14:31 ...one group says "nick should be asked to be recognized, and consent to be recognized" 15:15:14 ...it might be interesting to have another option: "I don't know exactly who this is, but this is a trusted device" 15:15:24 ...i think we will get further with explicit consent. 15:15:45 ...another question is "who should choose"...should the bank choose? Or the merchant? or the user agent? or the customer? 15:16:25 ..the browser could have a flag whether the user is ok with frictionless 15:16:38 ...I think it's important to maintain some control in the bank (whether frictionless ok or not) 15:16:59 ..the last element is "what does friction look like during the transaction" 15:17:50 ...you could use SPC earlier in the checkout flow than just for authentication. 15:18:02 ...remember 2-factor not mandated in a lot of situations 15:18:39 ...I think there is a place where, if a bank allows it, you can do SPC with just a "Pay" button (no FIDO) 15:18:56 ...a cryptogram is still created (by the browser) 15:18:59 q? 15:19:01 ack Gerhard 15:19:33 ack AdrianHB_ 15:19:33 AdrianHB_, you wanted to ask if FedCM could help with frictionless if it has a "payment" mode (that would also work with SRC). This would just change the prompt from "login" to 15:19:37 ... "pay" or something 15:20:00 Two topics to consider • Silently detecting a recurring customer Vs • Consent to be detected as recurring customer (and getting a better experience) We have 3 options in my view • RP controlled, but with Customer Consent • Browser Agent Controlled, with customer saying ‘remember me’. • RP and Browser Agent controlled. Remember what Platform Authentication does – it requires • OS level breakout • Biometric or PIN as part of that. 15:20:09 AdrianHB_: Gerhard, when you talk about key material provided by the browser, is that a key that somehow ties to the browser vendor, or ties to the device? 15:20:46 Gerhard: I imagine a credential.get per-browser call to mind a key and the private key is stored in the browser 15:21:00 ...and the public key is domain bound 15:21:14 this possibly goes along the old proposal of browser id tied to a payment instrument stored and protected by the browser 15:21:32 AdrianHB_: Ok, the bank could do both FIDO-based and Web crypto-based registration 15:21:48 Gerhard: Right, that would allow the bank to first try browser-based, and if not , then go to SPC 15:21:48 I suggest efficient to replace frictionless. 15:22:19 AdrianHB_: I see Gerhard's model as being layered in the way that risk evaluation is layered. 15:22:36 ...at one extreme, just recognizing the customer might suffice (e.g., $1 purchase for something the user does every day) 15:22:53 ...then at the other end of the spectrum your security model needs to be stricter. 15:23:06 ...and there's space in the middle we've not yet explored 15:23:20 ..I am wondering whether FedCM could be used at the "low" end of the spectrum, 15:23:26 ...then SPC with browser credential is next level up 15:23:30 ...then SPC with FIDO is next level up 15:23:49 ...so in the case of SRC, the merchant could: 15:23:50 * Call FedCM 15:24:04 * Get back one or more tokens (resulting from the browser reaching out to one or more systems) 15:24:48 * Then there is a payment-specific dialog with a set of identities 15:25:19 ...so could FedCM have a "payment mode" where the customer is identified rather than talking about login 15:26:08 * Then with token, I can go back to SRC system and find what authentication mechanisms are available including SPC-lite and SPC-FIDO 15:26:25 ...all this would not require iframes or redirects. 15:26:35 q+ 15:26:43 ack jean 15:27:22 jeanLuc: I think there are two big problems: abandonment, conversion 15:27:28 ...from merchant perspective. 15:27:48 ...studies indicate people abandon when it takes time, or is complex, or tech problems. 15:28:12 q- 15:28:18 ...meanwhile, in France, 44% of out-of-band 2-factor authentications were abandoned 15:28:48 ...there's a lot of friction when the user leaves the merchant context, and when another device uses (and more opportunities for failure) 15:28:58 ...so it is desirable to keep user near merchant context. 15:29:25 ...merchants meanwhile are reluctant to use exemptions 15:29:29 ...what's great about SPC is that the issuer doesn't need to trust another party 15:30:14 ...any low-friction option should include a way for bank to validate the assertions 15:30:19 q+ 15:30:23 ack SameerT 15:30:57 SameerT: +1 to Jean-Luc; we've been trying to resolve this tension between 'user-as-user-of card" v. "user-as-customer-of-merchant" 15:31:45 ...SPC is a good compromise: some amount of friction, but less than other redirect approaches 15:32:01 ...what would be interesting to add on top is some sort of device recognition 15:33:03 NickTR: Say more about what you'd like 15:33:19 SameerT: in the app world we have an SDK generated id that is sticky 15:33:47 ...so issuers know the device until the user has removed the app or cleared the OS 15:34:13 ...in browser world we rely on data we can gather from JS and browser context 15:34:21 ...cf previous presentations on browser-protected ID 15:36:46 NicKTR: Note that merchant can set a 1p cookie (with user recognition) 15:37:03 SameerT: But SDK manages its own functions. The merchant app just communicates the information out 15:37:15 q+ 15:37:35 ...so even if merchant has a 1p cookie, the issuer has no way to know; the merchant doesn't share merchant recognition of user 15:37:37 ack smcgruer_[EST] 15:38:09 smcgruer_[EST]: As always, if you are running an SDK in a merchant app, the merchant can do whatever it wants to the SDK. The Web's iframe model is better, but hits 3p cookie issues. 15:38:32 +1 15:38:40 ...on mobile you are solving a different problem (individual merchant apps) compared to cross-origin 15:38:48 ...you can use CHIPS for "single merchant" problem 15:39:52 I have made the request to generate https://www.w3.org/2023/03/29-wpwg-minutes.html Ian 15:39:59 q? 15:40:29 David Benoit has his hand up. :) 15:40:34 gkok has joined #wpwg 15:40:36 smcgruer_[EST]: There is also a fundamental difference between app model and Web model. Users install apps and app stores mitigate risks. 15:40:44 ....on the Web, can't have same assurances 15:40:59 ...so Web standards are designed for a higher bar 15:41:45 ...we have no way to restrict identification technology to payments scenarios (except, e.g., with things like dedicated UX such as SPC) 15:42:12 q+ 15:42:39 q+ 15:42:49 ack Ian 15:44:58 ack gkok 15:45:15 Ian: I think FedCM has steam; may want to focus on "great low friction" rather than "Frictionless" 15:45:31 gkok: one issue with iframes is -- difficulty troubleshooting 15:46:01 ...example -- we troubleshoot payment transactions all the time and transactions are logged on the backend. 15:46:11 q+ to say I think "packing payments stuff in" actually solves some of the privacy/security issues even though it goes against the "extensible web" idea. 15:46:31 gkok:...where things iframes beak, hard to troubleshoot. 15:46:36 s/things/things in/ 15:48:09 q+ 15:48:43 NickTR: Interesting to hear about value of observability in these situations. 15:48:45 aka AdrianHB_ 15:49:25 AdrianHB_: Ian said something that I want to pursue: there's been an idea of extensible web...general purpose APIs 15:49:33 q? 15:49:37 ack AdrianHB_ 15:49:37 AdrianHB_, you wanted to say I think "packing payments stuff in" actually solves some of the privacy/security issues even though it goes against the "extensible web" idea. 15:49:43 q+ 15:49:44 q+ 15:50:07 AdrianHB_: But a disadvantage of this approach is that powerful features can be used "maliciously" 15:51:01 ...whereas, if we can build in payment-specific features, with understandable UI, that's a huge benefit 15:51:19 ...such dialogs prevent some malicious behavior 15:51:51 AdrianHB_: So while it might be more work for browser vendors to do payment-specific features, there's value 15:51:54 q+ 15:51:58 ack SameerT 15:52:22 SameerT: Regarding gustavo's comments, there have been some updates to 3DS to help with logging 15:52:37 ...and debugging ; happy to provide more details 15:52:39 ack smcgruer_[EST] 15:53:02 smcgruer_[EST]: To Adrian's point, I agree with you (even if not everyone in every browser would also agree) 15:53:19 ...I think there is benefit to provide more full-fledged UX to meet privacy needs 15:54:16 ...but still hard to do. 15:54:35 ...another thing we are struggling with: where to invest to find a success story 15:55:01 q+ 15:55:06 +1 - SPC is the start of something beautiful :) 15:55:10 :) 15:55:31 +1 15:55:32 NickTR: I think SPC is very successful (already); by the timeline of most payment developments, we are still at the beginning 15:55:45 ...traction of SPC is as fast as I've seen any payments tech get traction 15:55:48 ack clinton 15:55:59 clinton: one of the primary issues of payments on the web is inconsistent UX 15:56:01 q- 15:56:02 +1000 - SPC is ALREADY in the 3DS spec. That's like Flash Gordon fast 15:56:45 clinton: In tracking and making steps of authentication observable, that's one of the components of SRC 15:56:59 zakim, close the queue 15:56:59 ok, Ian, the speaker queue is closed 15:57:08 We are balancing SO many stakeholders. My observation is that we continue to iterate but continue to get closer to a solution that gets everything right 15:57:18 q? 15:57:19 clinton: I think we are getting the tools; just a matter of mashing them together efficiently. 15:57:21 ack gkok 15:57:58 gkok: It can be hard to know who to trust. Is there a way to reuse the Brazil central bank model of trusted entities, and indirect entities? 15:58:11 ...with incentives (e.g., direct entities get income, and risk punishment) 15:58:15 Issuers would have to implement SPC and issuer have the most inertia. As we observed for PSD2, openbanking or EMV 3DS. Issuers don't have same capacity as merchant to implement new technologies :( I guess it will need some time for issuers to understand and implement SPC 15:59:01 See Antifraud CG -> https://github.com/antifraudcg/proposals/issues 15:59:16 -> https://github.com/antifraudcg/proposals/issues/4 16:00:20 NickTR: Trusted/less trusted models imply (typically) a certification regime. Web doesn't have same model 16:00:56 NickTR: Thanks everyone for coming these past three days 16:01:15 ...I'm particularly excited by exploring in the group PIX, 16:01:15 (Ian: And more on frictionless!) 16:01:20 Topic: Next meeting 16:01:38 13 April 16:01:52 NickTR: Thanks to all the presenters this week! 16:01:59 I have made the request to generate https://www.w3.org/2023/03/29-wpwg-minutes.html Ian 16:02:46 RRSAGENT, set logs public 16:02:48 zakim, bye 16:02:48 leaving. As of this point the attendees have been Ian, Clinton_Allen, Carey_Ferro, Christian_Aabye, Juan_Pablo_Marzetti, Holger_Kunkat, David_Benoit, Bryan_Penny, Steve_Cole, 16:02:48 Zakim has left #wpwg 16:02:50 rrsagent, bye 16:02:50 I see no action items