13:34:24 RRSAgent has joined #wpwg 13:34:24 logging to https://www.w3.org/2022/05/04-wpwg-irc 13:34:27 Zakim has joined #wpwg 13:34:33 Meeting: Web Payments Working Group 13:34:38 Agenda: https://github.com/w3c/webpayments/wiki/Remote-Agenda-202205 13:34:53 Scribe: Ian 13:35:16 I have made the request to generate https://www.w3.org/2022/05/04-wpwg-minutes.html Ian 13:54:54 present+ Ian_Jacobs 13:58:19 present+ John_Fontana 14:00:10 present+ Carey_Ferro 14:00:27 present+ Anwar_Moco 14:00:29 Gerhard has joined #wpwg 14:00:36 present+ Doug_Fisher 14:01:17 dougfisher has joined #wpwg 14:01:29 present+ Anne_Pouillard 14:01:33 present+ Bart_de_Water 14:01:37 present+ Christiaan_Brand 14:01:41 present+ Gerhard_Oosthuizen 14:01:45 present+ Haribalu_V 14:01:50 Anne has joined #wpwg 14:01:52 present+ Nick_Burris 14:01:57 present+ Steve_Cole 14:02:13 present+ Tomoya_Horiguchi 14:02:21 present+ Jayadevi_Natarajan 14:02:28 present+ Jean-Michel_Girard 14:03:03 present+ Stephen_McGruer 14:03:45 present+ Hemnath_Dhananjayan 14:03:51 present+ John_Bradley 14:04:01 JMGirard has joined #wpwg 14:04:14 Carey has joined #wpwg 14:04:55 present+ Doug_Fisher 14:05:01 I have made the request to generate https://www.w3.org/2022/05/04-wpwg-minutes.html Ian 14:05:35 Topic: BPCE presentation 14:05:42 Chair: Ian 14:05:51 present+ Christian_Aabye 14:06:18 [Anwar Moco, BPCE presents] 14:06:37 Steve_C has joined #wpwg 14:07:03 Anwar: My BPCE colleagues and I have been looking into FIDO as a means of SCA. 14:07:05 present+ 14:07:09 ...thanks for the invitation to present today 14:07:32 present+ Sameer_Tare 14:08:21 Anwar: Theme today is how we can replace "CAP Readers" with some FIDO-based solution (e.g., roaming authenticators) 14:08:28 bryanluo has joined #wpwg 14:08:29 present+ Jonathan_Blocksom 14:08:37 present+ 14:08:38 present+ Bryan_Luo 14:08:40 SameerT has joined #wpwg 14:10:00 present+ Rufus_Thayalarajan 14:10:35 present+ Tim_Cappalli 14:11:17 Anwar: Our interest in SCA is driven by PSD2 requirements. 14:11:36 ...multifactor authentication 14:11:57 ...there are three use cases of interest in particular: 14:12:04 1) Connection / sign-on to services 14:12:11 2) Validation of sensitive operations 14:12:17 3) Validation of 3DS online payment 14:13:15 Anwar: What is "Sensitive" is defined in article 4 of the regulation. Every bank assess it on their own, but at a high level, it's any operation that might compromise the account 14:13:30 ...e.g., adding a new payee; initiating a transfer; even changing the phone number associated with the account 14:14:20 Anwar: I think (1) and (3) can be achieved with FIDO/SPC. 14:14:36 ...so my focus in today's discussion is validation of sensitive operations 14:14:54 [BPCE context] 14:15:07 Anwar: We offer different authentication approaches to our customers 14:15:38 ...password, OTP by SMS, App-based ("Secur'Pass"), CAP Reader and card, Password and OTP SMS 14:15:52 present+ Ryan_Watkins 14:16:32 Answer: We'd like to replace the CAP reader with some FIDO-based approach 14:16:55 s/Answer/Anwar 14:17:07 Anwar: One interesting reason is shortage of plastic for cards. 14:17:35 present+ Praveena_Subrahmanyam 14:18:09 Anwar: The CAP Reader generates a code (like an OTP) and that code is used to validate an operation 14:19:16 ...CAP Readers can operate in "code mode" and "response mode" 14:19:46 present+ Adam_Kelly 14:20:18 [Slide on use cases that involve CAP Readers] 14:21:16 Anwar: Although there are use cases that involve smartphones, we also have some use cases where smartphone will not suffice. 14:21:28 ...in some cases they cannot receive an OTP by SMS (e.g., while traveling) 14:21:41 ...in other cases they don't have a smartphone or prefer wired devices 14:22:07 ..in other cases may simply not be able to use their mobile device (e.g., an accountant who works for a customer) 14:22:28 ...so there are use cases where mobile apps won't work but Web will 14:23:02 ...in all use cases FIDO keys could be useful, even in the main solution might be something else. But in some cases FIDO would be the only likely available solution. 14:23:10 present+ Sam_Weiler 14:24:02 [Customer journey to add a new payee] 14:24:55 wseltzer has joined #wpwg 14:25:35 Anwar: Note that in the flow, even if the user is already logged into their mobile banking account, the user will be re-authenticated prior to the sensitive operation. 14:25:57 ...this second authentication might take place through CAP Reader, or through SMS OTP 14:25:58 ChristiaanBrand has joined #wpwg 14:26:17 ...the SMS OTP follows an enrollment and ID&V process where the user provides a phone number. 14:27:17 Anwar: PSD2 requirements involve both (1) What you See is What you Sign, and (2) Dynamic Linking (unique code) 14:28:01 ...we are interested in SPC for the payment transactions 14:28:25 ...the question is whether we can have something similar for sensitive operations (e.g., adding a payee name + IBAN) 14:28:47 present+ Sami_Tikkala 14:29:08 Anwar: Our data needs vary for these use cases; we still want to sign over that data. 14:29:08 q+ 14:29:16 q? 14:29:18 q+ 14:29:21 present+ Manish_Garg 14:29:36 ChristiaanBrand: How is the dynamic linking done today with CAP Reader? 14:29:48 ...does the Reader display the details today? or is it just a code that is entered? 14:30:58 Anwar: In "Response mode" the screen displays a code we provide. 14:31:12 ...and the CAP Reader generates a number that is based on the user and the code we provide 14:31:41 ChristiaanBrand: But there is no WYSIWYS capability in the CAP Reader. 14:32:00 ...FIDO2 does the same thing. 14:32:26 ChristiaanBrand...if the current practice with CAP Readers meets PSD2, then FIDO as it works today should work. 14:33:13 Ian: How do you get to the code? 14:33:24 ChristiaanBrand: The server generates a code (the FIDO2 challenge). 14:33:47 ...the hash includes details about the transaction. 14:33:59 ...once you have the string, you pass that in during get() 14:34:03 ...the authenticator signs the hahs 14:34:06 s/hahs/hash 14:34:31 ....CAP is likely symmetric/ FIDO is asymmetric but that should not affect PSD compliance 14:35:36 Ian: There are interesting trust questions; can info just be sent to the RP, or would the user need to be in a 1p context. 14:36:34 ChristiaanBrand: SPC is interesting due to mistrust, so WYSIWYS is especially useful. But in FIDO some of the trust is returned (e.g., you've plugged a key into your device). 14:36:38 present+ 14:37:03 ChristiaanBrand: SPC is an additional level of control; helps in the 3p case but also is an additional security measure to say "This is really what you are signing" 14:37:21 ...we are interested in a general transaction signing mechanism in WebAuthn 14:37:26 q? 14:37:29 ack ChristiaanBrand 14:37:31 ack smcgruer_[EST] 14:37:59 smcgruer_[EST]: ChristiaanBrand covered much of what I wanted to say. I wonder whether the CAP Reader argument is trusted display to the user. 14:38:29 q+ 14:38:59 q? 14:39:24 ack me 14:39:35 Ian: What more use cases would a user form field get us in an SPC dialog? 14:40:02 smcgruer_[EST]: Maybe WebAuthn should handle this. I don't think we should have users type codes into browser UX 14:40:10 ChristiaanBrand: It's so generic. 14:40:17 ...could be many thinks like signing lease agreements. 14:40:24 ...so makes sense to push down to WebAuthn 14:40:25 q+ 14:40:28 s/the CAP Reader argument is trusted display to the user/the CAP Reader argument shows that the reader has read what they are going to sign 14:40:33 ack Gerhard 14:40:43 q+ 14:41:01 Gerhard: If we are looking at open banking, the use case closest to this in SPC would be recurring payments, or future dates for payments 14:41:45 ...we might be able to get these use cases met faster via SPC 14:42:07 ...we find that users like physical tokens; they may distrust platform authenticators more 14:42:20 ...we've noted that for SPC we'd like to include support for remote authenticators 14:42:38 q+ 14:42:58 Gerhard: We will discuss this week learning more about creds on remote authenticators 14:43:14 Anwar: Yes, some people will still prefer an external device to authenticate (e.g., dongle) 14:43:22 ...and they can't save properties on their browser 14:43:32 ack bdewater 14:43:48 bdewater: I have such a reader; familiar with them. :) 14:44:17 bdewater: You can use these readers with a numeric response, but also connect via USB...in this case you would see the transaction details on the reader (at least the one I had in the netherlands) 14:44:32 ..but agree if hashes suffice, I agree FIDO meets the use case 14:44:32 q? 14:44:42 q+ John_Bradley 14:44:44 USB connected EMV-CAP reader vulnerability: http://www.cs.ru.nl/~rverdult/Designed_to_Fail_A_USB-Connected_Reader_for_Online_Banking-NORDSEC_2012.pdf 14:44:46 ...I'll share some research on vulnerabilities 14:44:53 ack me 14:44:56 ack John 14:45:05 there was also another group that researched UK bank CAP readers: https://blog.c22.cc/2009/12/29/26c3-optimised-to-fail-card-readers-for-online-banking/ 14:45:38 John_Bradley: I largely agree with the points from ChristiaanBrand. The PSD2 protocols, also STET, Berlin Group, FAP, etc. all support redirect-based mechanisms for the PSP to deal with banks. 14:46:05 ...those are all capable of 1p contexts. Like ChristiaanBrand I agree that having an id for the transaction is sufficient in the way that the challenge mode for the CAP reader works. 14:46:20 ...the CAP reader itself is punishable 14:47:30 q+ 14:47:55 update for the above link for the UK, this is the actual paper: https://murdoch.is/papers/fc09optimised.pdf 14:48:19 John_Bradley: Browsers have not previously supported generic signing capabilities; but I think that would be an interesting discussion. But we may need to constrain to canned information. 14:48:47 ...we should be able to add PSD2 transaction confirmation types. 14:48:48 ack Gerhard 14:49:35 Gerhard: SPC has three superpowers: (1) secure display (2) signing over standard data set (3) decoupling ceremony from validation 14:49:42 ...and allowing other parties to leverage a credential. 14:49:55 ...my understanding is that a full redirect happens in open banking 14:50:15 ...are you aware of an open banking scenario where a TPP can get consent on their own site (without redirect) 14:50:25 ...are there iframe scenarios? 14:52:54 Anwar: From my POV, the most common use case is the user is redirected to the 1p domain 14:53:11 ...but outside of PSD2 other use cases may be very relevant 14:53:25 ...regarding TPPs and 3p, I don't have more details 14:54:10 Gerhard: I am thinking, e.g., of subscription use cases, for example. 14:55:26 John_Bradley: While there are redirect protocols in PSD2, the ECB and other regulatory bodies have said "You can't force a PISP or an aggregation provider to do a redirect." 14:55:53 ...so all of the API providers have some direct backchannel flow, and are using CAP readers and OTP in those contexts. 14:56:05 ...also in PSD2 there are account aggregators where you may have a third party who is managing multiple accounts 14:56:10 ..and in the third party you can add payees, etc. 14:56:30 ...I was thinking that a lot of the payments use cases are covered [by SPC] but probably not yet good solution for embedded flows 14:56:45 ..where there are sensitive interaction use cases that we've not yet discussed 14:56:52 Gerhard: Are you talking about CIBA? 14:57:00 John_Bradley: CIBA is part of FAPI 14:59:06 Hemnath has joined #wpwg 14:59:06 I have made the request to generate https://www.w3.org/2022/05/04-wpwg-minutes.html Ian 15:03:50 kris_chapman has joined #wpwg 15:04:23 present+ Nick_Doty 15:06:18 -> http://www.w3.org/2022/Talks/wpwg-privacy-202205/wpwgp-202205.pptx Privacy deck 15:06:26 [Carey departs.] 15:06:40 Topic: Privacy and Payments Joint discussion 15:06:53 present+ Kris_Chapman 15:06:54 npd has joined #wpwg 15:07:17 present+ 15:07:45 present+ 15:07:55 [Ian does background] 15:09:46 [SPC issue 128] 15:10:23 smcgruer_[EST]: There is an existing webauthn threat where someone enrolls a user somehow and then the user does get() and reveals identifying information. 15:11:00 ...SPC makes enrollment a bit easier than WebAuthn. With WebAuthn you have to register in a 1p context, but with SPC registration can happen in a 3p context (with protections such as permission policy) 15:11:14 ...Privacy folks at Chrome asked us to include user activation requirement (not part of WebAutn) 15:11:22 ..so we propose to add this (and have pull request for it) 15:11:45 weiler: How does user know the RP? 15:11:51 smcgruer_[EST]: that happens in platform dialog 15:11:59 user activation doesn't seem burdensome because you'd be clicking 'buy' or 'pay now' or something anyway 15:12:10 [How clear is it to the user that this is a 3p?] 15:12:13 question: Is this a different iFrame 'permission' for create vs auth? 15:12:15 smcgruer_[EST]: The same concern happens (about user "clarity") on get() side 15:13:09 Gerhard: Is the the permission distinct between create() and get()? 15:13:18 ...could one set independent permissions? 15:13:30 smcgruer_[EST]: Today what SPC does is to use the payment permission policy. 15:13:34 permission policy doesn't seem like much of a protection if the threat model is a colluding first party site that already explicitly chose to embed tracker.com iframe 15:13:50 smcgruer_[EST]: ..what I'd like to see long term is that in WebAuthn they have a get() policy and I think there should be a distinct create() policy. 15:14:12 John_Bradley: There are two. We stopped implementation due to mozilla objection. We can probably revisit that objection. 15:14:51 ...so permissions are reserved in the specification (but not specified) but are unimplemented. 15:15:07 ChristiaanBrand: At the time, we were not aware of use cases; now that there are active use cases we can visit 15:15:43 John_Bradley: The credential itself is not cross-origin here; it's being created in the origin of the iframe 15:15:56 q+ 15:16:07 ack Gerhard 15:16:39 Gerhard: Based on that clarification from John_Bradley. If a merchant allows an iframe to be opened for an issuer and a credential can be created for the issuer, why would that at all be linked to SPC? 15:16:52 John_Bradley: SPC has a work-around because that create() is not allowed in WebAuthn 15:17:35 smcgruer_[EST]: Long-term solution is to revisit in WebAuthn 15:17:39 John_Bradley: +1. 15:18:55 smcgruer_[EST]: Plan, then, is to close loop in Chrome and deploy the change to the spec and implementation with user activation 15:19:19 ===== 15:19:25 SPC issue 216 15:20:41 q+ 15:22:05 [Ian does background] 15:22:08 ack weiler 15:22:38 weiler: Please add that text to the GitHub issue 15:22:59 Ian: Agreed. 15:23:20 weiler:Rather than encouraging the issuer to have per-instrument credentials, what if we made it easier. 15:23:28 ...e.g., create 5 credentials instead of one. 15:24:23 Ian: Or even more -- generate 100 that the RP can use randomly. 15:24:55 John_Bradley: Current limit is 25 on roaming authenticators. So 100 per account would make roaming authenticators unusable. 15:25:40 Ian: So how do we make work "N credential IDs generated"? 15:25:48 but, i think we specifically don't want that, right? 15:25:54 we want a single registration as far as possible 15:26:04 since that's the user friction/risky action 15:26:06 (Idea is N credential IDs for a single registration) 15:26:57 John_Bradley: You can't get N > 1 today. 15:27:14 ChristiaanBrand: When you do a payment, you are already giving strongly identifying user information. 15:27:45 q+ 15:27:54 ChristiaanBrand:...so the odds are significant the user has already been identified. And often times the data is validated (e.g., shipping info) 15:28:07 ack weiler 15:28:24 weiler: My recollection is that the concern is correlation earlier in the payment flows. 15:28:49 at least in the 3ds flow, i don't think it can be used that way 15:29:10 it's also not an SPC issue, but rather a 3ds issue 15:30:05 ChristiaanBrand: You aren't asking the authenticator for credentials; the backend is the place you get the credentails 15:30:11 q? 15:30:15 +1 to Christiaan 15:30:32 +1 Sounds more like ACS issue than SPC issue. 15:30:35 John_Bradley: So if card issuers create different credentials for each payment instrument and only return the credentials for each instrument, that works. 15:30:54 ACS/3ds 15:31:26 q+ to ask whether rp implementations would be willing or interested 15:31:30 > For many current online payment flows this may not be a significant concern, as the user already provides sufficient information to do this joining anyway (e.g. their address), however it could become a privacy attack if, e.g., payment tokenization becomes commonplace. 15:31:30 ack nod 15:31:40 npd: Would RP implementations be willing to do this? 15:31:40 ack npd 15:31:40 npd, you wanted to ask whether rp implementations would be willing or interested 15:31:51 NPD: The spec actually does have guidance to RP 15:32:16 ...in the future we might have more tokenized payments 15:32:57 ...the question I have is: are banks interested in doing separate registrations per instrument? 15:34:08 ChristiaanBrand: big goal is to reduce friction with few registrations 15:34:33 ...we'll have problems with credit card numbers as keys 15:34:45 q+ 15:34:46 ...there is a balancing act between ease of use and privacy 15:34:49 q+ 15:34:54 ...we would prefer FIDO to OTP 15:35:01 q- 15:35:30 Gerhard: To a number of the points raised, in SPC right now as it stands you don't know if the device has credentials. How the credentials are bound to strings on the server and how people get them is out of scope. 15:35:52 ...I support adding guidance to external systems 15:35:59 q+ 15:36:03 ack Gerhard 15:36:24 Gerhard: It's an issue but not for the SPC itself, IMO 15:36:25 ack weiler 15:36:49 weiler: If we assume that there are people who want to do tokenized payments moving forward, how do we make it so that they can do that and expose less information. 15:36:58 are we saying "be mindful" or are we saying, the account will always be a stable cross-instrument identifier? 15:37:08 John_Bradley: You probably can't with WebAuthn as it is designed. You would need to build a backend with tokenized credentials. 15:37:30 smcgruer_[EST]: If an RP wants to do that, they should open a popup or redirect to their own domain. 15:37:42 q+ 15:38:26 Gerhard: SPC can be used in 1p context. if RP is concerned about sharing information, they can ask to redirect the user to the 1p context. 15:38:56 ..the RP may well want to control the situation. 15:39:56 Ian: could authenticators do salting? 15:40:20 John_Bradley: You'd need to change CTAP and have special authenticators have by reference credential IDs that are capable of doing unsalting. 15:40:29 ...would be major changes to CTAP 15:40:33 was the suggestion before that this embedded cross-origin iframe feature of SPC will simply be incomptaible with tokenized payments? 15:40:58 i don't know that you need SPC when you have a tokenized payment 15:41:07 praveena has joined #wpwg 15:41:10 the point is that you'll only get a token ONCE auth has completed 15:41:15 so, you use SPC to MAKE a tokenized credential 15:41:22 after that, you probably don't need 3ds/spc 15:42:03 npd: Call out in the spec perhaps the use case when SPC would not be useful from a privacy perspective. 15:42:18 John_Bradley: Yes, tokenization that is privacy preserving is probably incompatible with 3p context. 15:43:09 ACTION: Stephen to revisit the guidance text to make clearer potential of tokenization to be incompatible with cross-origin part of SPC. 15:43:15 ===== 15:43:48 q+ 15:43:51 I think that's the reason that the account connection is an important privacy risk, if it would undermine future tokenization privacy. but actually, if we just note that with tokenization of payments, that would replace this, then we might be less concerned about any future impact. 15:44:22 ack smcgruer_[EST] 15:44:31 Issue SPC 154 15:44:47 i agree with stephen. i don't think a user can reason about this. 15:44:53 smcgruer_[EST]: I don't see how this is different from WebAuthn in an iframe. I cannot today as a user opt-out of someone using WebAuthn in an iframe 15:45:05 ... the only notification I get is domain in the platform dialog. 15:45:20 ChristiaanBrand: I don't think user has information to make this kind of decision; would be incredibly hard. 15:45:33 John_Bradley: Would only apply to 3p context for payments; not webauthn generally 15:46:05 smcgruer_[EST]: Someone could do the same thing with WebAuthn and there would not be an opportunity to opt-out 15:46:25 https://github.com/w3c/secure-payment-confirmation/issues/157#issuecomment-1057208347 15:46:51 [We review that proposal for WebAuthn /CTAP] 15:48:28 [Gerhard recaps our goal of asking WebAuthn to take this topic into account as they look into providing support for new CTAP bit] 15:48:38 q? 15:48:40 q+ 15:48:40 ack me 15:48:46 ack weiler 15:48:57 weiler: What is special about SPC in terms of cross-origin? 15:49:16 John_Bradley: WebAuthn credentials must be used by origin that created them; SPC credentials can be used by other origins. 15:49:48 [There are 2 axes: Who is doing get()? Is it in 1p or 3p context?] 15:51:40 ChristiaanBrand: It has become apparent that some folks want the bit. I don't think at this point in time that we need to tell the user anything about this because iframes look similar. But we'll have the discussion in WebAuthn. 15:51:45 q+ 15:51:48 but I can see that the bank/issuer might not want their credential to be used without running inside their code (iframe or otherwise) 15:52:01 weiler: If you feel that way, why not make this part of all credentials? 15:52:07 ChristiaanBrand: That's a good question. 15:52:51 ChristiaanBrand: The RP needs to be able to say "ok to use in 3p context". RP may never be ok to use in a 3p context and not set the bit. So this is not really about the user. It's an RP thing. 15:53:11 ...the RP can always check the signature so may not be important anyway, but WebAuthn recognizes the use case and desire 15:53:24 ...there has not been an intent to make this a user visible thing but we can have the conversation 15:53:32 q+ johnbradley 15:53:34 ack SameerT 15:53:54 SameerT: Christian covered what I was going to say; this is an RP-oriented capability 15:54:03 ...the user could be informed via terms and conditions. 15:54:13 ...this is an RP policy decision 15:54:29 queu== 15:54:30 queue== 15:54:58 John_Bradley: When the bit is set and used in a payment context, there is additional data in the assertion ("on behalf of") information. 15:55:15 ...the only people who need to validate that information are the RPs. 15:55:26 ..so in the iframe POV RPs know what is going on; they are the ones displaying the iframe. 15:55:36 ..they already know the context (e.g., I'm ok with this merchant doing this) 15:55:51 q+ 15:55:59 ...the RPs acknowledging that they want a credential to be usable in a 3p context is important; don't want it to happy by surprise. 15:56:01 ack weiler 15:56:25 weiler: I see merit in having user choice in here also. Is there anything in the design that would prevent the user from downgrading the creation. 15:56:52 5 minutes left. 15:56:55 s/I see/If, after thinking about this more, I still see/ 15:57:00 ChristiaanBrand: I would want to understand better what we are solving for. 15:58:00 === 15:58:05 SPC 142 15:59:35 Ian: The normative text is now very specific (see the slide) 15:59:55 weiler: I hope you will continue to document "how to do this" 16:00:02 smcgruer_[EST]: +1 16:00:13 ...our goal is to exhaustively spec ways to not leak data 16:00:23 ...WebAuthn does still have this section. 16:01:06 smcgruer_[EST]: Still important to have security and privacy sections that highlight the scary stuff. 16:02:06 just to add for record for future PING discussions, in 3ds implementation of SPC (merchant initiated) the following requirement is imposed on merchants "Note: The 3DS Requestor is not allowed to change or store any of the data received for the SPC authentication from the 3DS Server". 16:02:16 weiler: Please include index to mitigation and close 142 16:02:42 === 16:02:47 Issue 431 16:02:50 Issue 143 16:02:59 Ian: We think this is same as 77 and propose to close it in favor of 77 16:03:20 I have made the request to generate https://www.w3.org/2022/05/04-wpwg-minutes.html Ian 16:03:52 q+ 16:04:04 ack SameerT 16:04:10 SameerT: regarding 77 again.... 16:04:29 ...we have a requirement in 3DS spec that the merchants NOT STORE any data when using SPC in 3DS 16:05:11 weiler: Could say e.g., that in spec 16:05:49 ACTION: Ian to work with editor on text related to 77 on guidance to RPs. 16:05:57 but it sounds like the question is just about 77, but agreement that 143 is a duplicate 16:06:36 weiler: Ok to close 143 as a dup of 77 16:08:10 ChristiaanBrand: We should be sure to state what the actual issue is we want to address. 16:09:56 RRSAGENT, make minutes 16:09:56 I have made the request to generate https://www.w3.org/2022/05/04-wpwg-minutes.html Ian 16:10:00 RRSAGENT, set logs public 16:12:36 zakim, bye 16:12:36 leaving. As of this point the attendees have been Ian_Jacobs, John_Fontana, Carey_Ferro, Anwar_Moco, Doug_Fisher, Anne_Pouillard, Bart_de_Water, Christiaan_Brand, 16:12:36 Zakim has left #wpwg 16:12:41 RRSAGENT, bye 16:12:41 I see 2 open action items saved in https://www.w3.org/2022/05/04-wpwg-actions.rdf : 16:12:41 ACTION: Stephen to revisit the guidance text to make clearer potential of tokenization to be incompatible with cross-origin part of SPC. [1] 16:12:41 recorded in https://www.w3.org/2022/05/04-wpwg-irc#T15-43-09 16:12:41 ACTION: Ian to work with editor on text related to 77 on guidance to RPs. [2] 16:12:41 recorded in https://www.w3.org/2022/05/04-wpwg-irc#T16-05-49