18:57:14 RRSAgent has joined #vcwg 18:57:18 logging to https://www.w3.org/2023/08/16-vcwg-irc 18:57:52 TallTed has joined #vcwg 18:58:00 brent has changed the topic to: VCWG Meeting Agenda 2023-08-16: https://www.w3.org/events/meetings/36ecd2da-2ec3-4012-b74a-72546ab352f4/20230816T150000/ 18:58:10 zakim, start the meeting 18:58:10 RRSAgent, make logs Public 18:58:12 please title this meeting ("meeting: ..."), brent 18:58:16 andres has joined #vcwg 18:58:23 present+ 18:58:36 meeting: Verifiable Credentials Working Group weekly teleconference 18:58:40 pdl-ASU has joined #vcwg 18:58:45 chair: Kristina Yasuda 18:58:48 present+ 18:59:01 present+ 19:00:15 present+ 19:00:29 steele has joined #vcwg 19:00:42 present+ 19:00:56 decentralgabe has joined #vcwg 19:01:00 present+ 19:01:00 dwaite has joined #vcwg 19:01:07 present+ 19:01:10 present+ 19:01:13 kristina has joined #vcwg 19:01:15 present+ 19:01:18 gkellogg has joined #vcwg 19:01:53 present+ 19:02:17 Orie has joined #vcwg 19:02:21 present+ 19:02:28 DavidC has joined #vcwg 19:03:12 mpororkc has joined #vcwg 19:03:16 present+ 19:03:18 present+ 19:03:21 scribe+ 19:03:22 mprorock has joined #vcwg 19:03:23 present+ 19:03:26 scribe+ 19:03:42 scribe+ manu 19:04:00 kristina: We have Nick Steele joining us as an IE. 19:04:09 I'll be happy to scribe next week, after I get my bluetooth keyboard fixed or repaired :-) 19:04:12 present+ 19:04:20 present+ 19:04:29 selfissued_ has joined #vcwg 19:04:34 present+ 19:04:36 JoeAndrieu has joined #vcwg 19:04:43 nick_steele: I'm at 1Password, working on WebAuthn, working on new standards, working on FIDO, working on credential import/export on passkeys, interested in VCs as well, interested in helping in any way I can. 19:05:08 cabernet has joined #vcwg 19:05:10 present+ 19:05:13 present+ 19:05:15 present+ 19:05:24 kristina: any other re-introductions? 19:05:34 kristina_ has joined #vcwg 19:05:35 q? 19:05:45 zakim, who is here? 19:05:45 Present: andres, brent, pdl-ASU, shigeya, TallTed, decentralgabe, dwaite, steele, kristina, manu, Orie, seabass, DavidC, mprorock, dmitriz, bigbluehat, selfissued_, JoeAndrieu, 19:05:47 GregB has joined #vcwg 19:05:49 ... cabernet, dlongley 19:05:49 On IRC I see kristina_, cabernet, JoeAndrieu, selfissued_, mprorock, mpororkc, DavidC, Orie, gkellogg, kristina, dwaite, decentralgabe, steele, pdl-ASU, andres, TallTed, RRSAgent, 19:05:49 ... Zakim, brent, dmitriz, manu, hyojin, cel, csarven, dlehn, Jem, shigeya, bumblefudge1, cel[m], w3c_modbot, ounfacdo, seabass, saysaywhat, npd, MojGraph, cel[h], bumblefudge, 19:05:50 ... Github, bigbluehat, Dongwoo, hadleybeeman, stonematt, stenr, dlongley, rhiaro 19:05:59 present+ 19:06:04 kristina_: You got through PRs and issue triaging yesterday, any updates on PRs from yesterday? Mainly spending time on issue discussion today. 19:06:06 q+ 19:06:10 kristina_: Any concerns/comments? 19:06:13 ack brent 19:06:31 brent: On the topic of PRs, status updates for different work items, needed to get reviews from TallTed. 19:06:54 TallTed: Sure, I can take a look. 19:07:05 q+ 19:07:22 kristina_: I did re-review PR 1211 -- works for me, thanks. 19:07:22 ack kristin 19:07:44 q+ work item update on schemas 19:07:48 manu has joined #vcwg 19:07:52 ack decentralgabe 19:07:57 kgriffin has joined #vcwg 19:08:21 decentralgabe: vc-json-schema is coming along nicely, all but a few pre-CR ones are done... open to others to have others review work and open issues if they see fit. 19:08:27 q+ 19:08:27 q? 19:08:33 scribe+ 19:08:38 ack manu 19:08:55 manu: Just a quick heads up, Mike Prorock -- there are merge conflicts on StatusList, if you could look at those and fix them we can get that PR merged. 19:09:03 mprorock: I will attempt to get to that in the next 48 hours. 19:09:07 scribe- 19:09:12 q+ 19:09:16 ack Orie 19:09:19 kristina_: any updates on BBS? 19:10:07 Yes, it uses an HMAC with key 19:10:28 Orie: as far as I'm aware, no progress on BBS work item. Last progress was ecdsa-sd updates. There was a need to blind RDF NQuads in documented manner, that has been documented and incorporated into Data Integrity more generally, more specifically ecdsa-sd test suite has that capability, at some point in future we might see BBS adopt that, or we might see BBS not make it into CR. 19:10:44 kristina_: thanks, any update on vc-jose-cose PR? 19:10:53 selfissued_: Merged an editorial PR 19:10:56 Some of the SD-primitives are also applicable to BBS. Reviewing these now. 19:11:42 Orie: In general, work item needs a bunch of clean up ... now that PR 88 is in, in terms of general things, normative changes that need to be made before we go into CR -- need to be comfortable w/ mandatory header parameters, main risk for item -- statement that says there MUST be header values, media types, multiple plus signs, etc. 19:12:59 Orie: There might be folks concerned about multiple suffixes, normative statements addressing protected headers need the most amount of attention, probably also some cleanup / differentiation language that we want to make now that we have clear separation on work items on JSOn-LD and securing JSON and registered claim names (work item at IETF) -- probably some mutual citation should happen there, direct readers to appropriate place, don't think that's 19:12:59 blocking CR, but header parameters are blocking CR. 19:13:17 q+ 19:13:19 selfissued_: I appreciate the test suite repo being created, what's our plan to have there be tests? 19:13:21 ack Orie 19:13:23 q+ 19:14:14 q+ 19:14:24 Orie: I am about to open a PR with some initial test cases and structure, just got repo today, I was going to throw some strawman suggestion up for folks to look at... don't know if W3C Process for test suites, interested in knowing if what I'm going to say is run afoul ... would like to push commits straight to main, review on call, go over what we think is good enough and gather feedback from the group, if group hates it, we can make adjustments. 19:14:41 Orie: I'd like to push to main in the test suite repos. 19:14:44 ack mprorock 19:14:52 mprorock: +1 to push to main 19:14:56 selfissued_: yes, +1 19:15:10 mprorock: I have example representations for some of core tests. 19:15:14 ack brent 19:16:20 brent: Chair hat firmly on -- test suites are where folks who are willing to write code end up with a test suite that matches what they like, folks with opinions that don't write code, while we appreciate what you want, unless you're willing to write tests, then it's the do-ers that get to determine what test suite is to a large extent. Fully support generating test suite as they see fit, presenting it to group for feedback. 19:16:37 kristina_: concur - orie, you have the go-ahead. 19:17:13 kristina_: we have 33 pre-CR issues, with 2 not assigned 19:17:16 Topic: Issues 19:17:20 https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Abefore-CR+sort%3Aupdated-asc 19:17:28 kristina_: anyone need help w/ the issues -- anyone need guidance from the WG? 19:17:41 kristina_: if not, let's see if we can assign two of the issues. 19:17:48 subtopic: https://github.com/w3c/vc-data-model/issues/1205 19:18:09 kristina_: this one is about describing controller documents in core data model. 19:18:14 reminder that no one being assigned to an issue essentially means it will not happen. 19:18:31 q+ 19:18:43 scribe+ 19:18:43 ack manu 19:18:47 q+ 19:18:59 manu: I think it's a bad idea and we shouldn't do it. We define controller docs in the data integrity spec and if we want to point to something we can do that. 19:19:01 scribe- 19:19:08 ack Orie 19:20:49 gkellogg has joined #vcwg 19:21:25 q+ 19:21:32 Orie: I am not a huge fan of having to point to Data Integrity to understand how to verify something that uses a DID. Problem that I see, is that if you are using JWT or SD-JWT and you are issuing from a DID and you want to talk about expectation on issuer key representation and envelopes will be -- we will have to refer to Data Integrity from vc-jose-cose spec, currently we point to OID documents, we don't talk about DIDs yet, there isn't a way to talk 19:21:32 about DIDs and key material and point to DID spec, in VCs, we would have to do that. because of way did spec and vc spec, vc-cose-jose should point to VC spec, not to DID spec... resolution was out of scope... how to use DIDs w/ vc-jose-cose, refer to Data Integrity spec to do that, as long as we want to do that, we can do that... if we want to cite different document for controller format, reference needs to move. 19:21:34 +1 to its fine and close the issue 19:21:46 q+ 19:21:53 ack seabass 19:21:57 GregB_ has joined #vcwg 19:21:58 kristina_: is it an option to just add a summary in VCDM? and point elsewhere. 19:22:16 That is not true. 19:22:25 seabass: From my udnerstanding of ecosystem, people might need to understand vc-jose-cose and other ones in data integrity... not much of a problem either way or the other. 19:22:30 Many people probably do not plan to implement both. 19:22:36 yeah, i would not assume everyone will understand both securing mechanisms.. 19:22:41 ack decentralgabe 19:23:03 decentralgabe: It goes beyond cleanliness, I don't want to refer to multiple specifications, pursuing a path of being able to verify DID w/o needing to rely on DI spec would be valuable. 19:23:05 @Orie - for those who don't plan to implement DI, why not talk about controllers in whatever securing JOSE spec ? 19:23:12 valuable enough to volunteer to be assigned? 19:23:16 q+ 19:23:19 As it stands, I plan to refer to data integrity controller documents section from vc-jose-cose... since its MUCH better than referring to DID Core. 19:23:33 if no one else volunteers I can try, but I will need help 19:23:36 q+ 19:23:36 ack dmitri 19:24:00 q+ to talk about copying / editing the section from data integrity 19:24:06 dmitriz: question to Orie - understand not wanting to refer to many different specs, why not say controller document/verification belongs to securing spec, just use that? 19:24:18 ack manu 19:24:25 scribe+ 19:24:29 q+ 19:24:37 manu: The problem with copying and pasting between two specs is that they drift over time. 19:24:53 dmitriz: They wouldn't be exactly the same. 19:25:10 yeah, I would assume the definition of a controller doc will not have to match btw securing docs 19:25:13 DID core DOES NOT define how to get key material. 19:25:20 making it mostly useless to refer to 19:25:23 manu: This feels like a worse thing. We could just refer to DID core, it does specify the controller document, but not as well as data integrity does. If we copy and paste between both, it will diverge, which will be bad. 19:25:35 manu: Now we're talking about divergent definitions of the controller document and that would almost certainly get objections. 19:25:39 manu: That's it. 19:25:47 Imo divergent definitions might be better than bad definitions... could see objections either way. 19:25:53 kristina_: Could we frame it as key discovery instead of controller documents? 19:25:58 kristina_: could we talk about key discovery mechanism? Inclusive of DIDs, but not limited to? 19:26:02 scribe- 19:26:02 ack Orie 19:26:02 Orie, you wanted to talk about copying / editing the section from data integrity 19:26:48 +1 Orie 19:27:06 Orie: I like dmitri's idea, repeating controller document guidance, I would feel better doing that than citing data integrity... I think it's ok, as long as definitions are compatible, ok for one document to take more securing mechanism focused approach, stuff specific to JOSE/COSE that Data Integrity is not going to talk about... makes sense to copy content and describe security considerations associated with controller documetns used w/ vc-jose-cose. 19:27:17 another option would be to reference what's in data integrity and add some additional requirements as needed vs. just copying and changing. 19:27:20 isn't some divergence expected? 19:27:41 q+ 19:27:43 Orie: There would probably be divergence, is the divergence substantial enough to create formal objections? I can see either side leading to problems if it's not handled properly, duplicating content would be easier path than puttin git in core data model. 19:27:43 q? 19:27:47 ack seabass 19:28:34 seabass: I don't think I understood what Dmitri said... in dat amodel specification, when you are securing VC, you must refer to specification regarding verification, regarding vc-jose-cose, or Data Integrity, while that implies that those specs copy/paste, it does not necessitate copying/pasting. 19:28:44 right, so, we have two different decisions. 1) whether to summarize or specify key discovery in the core VC DM. yes or no. and 2) If no, if we rely on securing specs for key discovery, whether to copy the text, or pick one spec 19:28:45 seabass: If there is a risk of divergent defintions, we can propose another REC-track spec. 19:29:07 I doubt we can propose another rec track document... especially since that document would look like DID Core. 19:29:07 kristina_: adding another rec-track spec at this time would be difficult (chair hat on) 19:29:19 seabass: I thought we were only halfway through charter... we would have another chance at REC-track documents? 19:29:48 kristina_: W3C Process wise, yes, we have a year left, but we need the last year to resolve comments, administrative review, timeline wise, unfortunately, no -- we can't add another rec-track document at this time. 19:29:58 q? 19:30:26 brent: Everything you said was accurate, W3C Process requires wide review of REC-track documents, wide review takes time, ends up in multiple CR phases, going to PR and REC takes several months to do that... already are straining bounds of possibility on specs we have in flight. 19:30:27 ack dlongley 19:30:41 +1 19:30:43 -1 19:30:43 dlongley: Another suggestion was vc-jose-cose references what's in Data Integrity and additional requirements. 19:30:45 q+ 19:30:51 ack mprorock 19:31:11 mprorock: I will firmly object in every way shape or form for referencing from vc-jose-cose, those two documents need to be 100% separated, not willing to budge on that. 19:31:12 +1 to separation 19:31:27 +1 to keeping the securing documents separate 19:31:53 +1 to moving the issue 19:31:55 kristina_: We don't have agreement to add to core data model, don't agree on divergence is a risk or not, and this is decision of vc-jose-cose authors -- can we move issue to vc-jose-cose and PR would be opened... that's the option I heard the least objections on. 19:32:08 kristina_: ok, I'll move issue to vc-jose-cose. 19:32:26 kristina_: going back to issues... 19:32:45 subtopic: https://github.com/w3c/vc-data-model/issues/1206 19:33:13 q+ 19:33:16 kristina_: we discussed 3 weeks ago, there didn't seem to be agreement to add this to VCDM. 19:33:21 ack Orie 19:33:58 Orie: Our current language says document has to be compact, don't know if you can use URL in compact JSON document, I expect people have done that in v1 of spec, expect them to keep doing that. 19:34:32 Orie: We should expect to see people mix compact type w/ expanded tpes, or just put URLs in there... that can create logical/validation issues... ifyou process as JSON-LD and RDF and doesn't expect to not have them, libraries can explode. 19:34:33 q+ 19:34:45 scribe+ 19:35:05 Orie: This is in the category of not addressing this particular piece, make it clear to implementers that it's not ok to do, might see this in the wild, we should providde some guidance. 19:35:13 ack manu 19:35:35 A JSON processor has not problem with arrays of strings. 19:35:51 manu: The problem isn't with JSON-LD processing, a JSON-LD processor will be fine. Doing vanilla JSON processing will have to look out for the long and short forms. The reason we made the rule is so that vanilla JSON processors could just use the shortened form. 19:35:52 JSON Processors don't understand "compact form"... thats a JSON-LD concept. 19:36:21 manu: If the JSON processors put that logic in -- that would work just fine. I agree we should put in guidance to say "don't do that, if there's a shortened form, use that, not the full URL". 19:36:38 JSON processors don't understand anything - semantic meaning is always added by the scheme, like an OWL document in the case of JSON-LD 19:36:56 gkellogg has joined #vcwg 19:37:15 q? 19:37:17 who is willing to be assigned? 19:37:19 manu: As Orie said, there are some ecosystems might expect that. If we didn't use JSON-LD (only vanilla JSON) people would still need to pay attention to it. So some guidance that says you might experience it in the wild, and the ecosystem you're operating in might use long URLs when they could have used short ones, but in general, use the short form for everything when you can. 19:37:32 scribe- 19:37:34 kristina_: anyone willing to be assigned? 19:37:41 q+ 19:37:47 ack seabass 19:39:00 seabass: I just want to say that URIs and IRIs are difficult to work with, JSON-LD is about dealing w/ that, but in general, this is an advantage that when processing pure JSON, you don't have to parse actual keys themselves... "a" and value, then "x" and value, you don't have to parse string value -- parsing becomes a lot more difficult, if it is feasible, we should enforce short names and that will be a tangible help for those not going full JSON-LD 19:39:00 route. 19:39:51 zakim, who is here? 19:39:51 Present: andres, brent, pdl-ASU, shigeya, TallTed, decentralgabe, dwaite, steele, kristina, manu, Orie, seabass, DavidC, mprorock, dmitriz, bigbluehat, selfissued_, JoeAndrieu, 19:39:55 ... cabernet, dlongley, GregB 19:39:55 On IRC I see gkellogg, GregB_, kgriffin, manu, kristina_, cabernet, JoeAndrieu, selfissued_, mprorock, DavidC, Orie, dwaite, decentralgabe, steele, pdl-ASU, andres, TallTed, 19:39:55 ... RRSAgent, Zakim, brent, dmitriz, hyojin, cel, csarven, dlehn, Jem, shigeya, bumblefudge1, cel[m], w3c_modbot, ounfacdo, seabass, saysaywhat, npd, MojGraph, cel[h], bumblefudge, 19:39:56 ... Github, bigbluehat, Dongwoo, hadleybeeman, stonematt, stenr, dlongley, rhiaro 19:40:07 IMO that guidance would be fine... 19:40:08 q+ to clarify from chairs 19:40:19 scribe+ 19:40:45 manu: If I'm going to do a PR for this, it would say that you should use short form URLs, not long ones, but if you use long ones it's ok, just don't expect interop.l 19:40:58 s/interop\.l/interop\. 19:41:07 ack seabass 19:41:07 seabass, you wanted to clarify from chairs 19:41:10 scribe- 19:41:25 seabass: When we're talking about using long or short forms, we are talking about official and VC context, not other context. 19:41:32 scribe+ 19:41:35 I would say we are talking about all contexts. 19:41:41 manu: Compact form means every single context that's applied. 19:41:58 seabass: So fragmentation is an issue? 19:42:14 manu: No, that's not what's being said. For a given document, if you're using a set of contexts, you are expected to use the short form for everything that's defined in those contexts. 19:42:57 manu: The comment you made on fragmentation I didn't follow, because not every VC will use the same context. A VC for a permanent resident card will use one set of contexts and one for a university degree, a different set of contexts will be used. The guidance will be to use the short form with each respective context used. 19:43:28 manu: If there's a short form version of the thing, don't use the long form. It doesn't mean you can't use URLs anywhere, you can of course do that. But when using the specific vocab and context you're using, use the short form. 19:43:49 seabass: When people create contexts for use for anyone issuing and consume VCs, people should use shortened forms for those and that helps with interop at a second order. 19:43:51 seabass: I'm for that. 19:43:55 kristina_: ok, thanks for clarification 19:43:57 scribe- 19:44:09 s/consume VCs/consuming VCs 19:44:14 kristina_: we have 12 minutes, let's go through before CR that don't have "ready for PR" 19:44:38 subtopic: https://github.com/w3c/vc-data-model/issues/1150 19:44:40 https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Abefore-CR+sort%3Aupdated-asc+-label%3A%22pr+exists%22+-label%3A%22ready+for+PR%22 19:45:01 kristina_: protected term errors when doing v1 and v2, dave has pointed to multiple PRs in his latest comment, what's plan here? 19:45:41 dlongley: I don't plan to do PR unless it's done as a final pass before CR over all of the other issues we have -- we have a number of things that will need tomake changes to v2 context (other specs, etc) -- we need to make pass at context at the end, tagged this item and others to make sure we get everything in there. 19:45:50 kristina_: waiting for v2 context to be "final final" 19:45:59 dlongley: Not "final final", just right before we go to CR. 19:46:19 gkellogg has joined #vcwg 19:46:28 subtopic: https://github.com/w3c/vc-data-model/issues/1089 19:46:47 q+ 19:47:02 ack brent 19:47:09 +1 brent 19:47:13 brent: I think this issue can be closed. 19:47:15 +1 to close 19:47:20 +1 to close 19:47:20 manu: +1 to close 19:47:22 +1 to close 19:47:26 brent: context has lots of stuff in it. 19:47:35 we are bundling everything into v2 context now. 19:47:41 not just data integrity proofs. 19:47:51 subtopic: https://github.com/w3c/vc-data-model/issues/1214 19:48:31 q+ 19:48:44 q+ to warn of interoperability issues 19:48:46 ack Orie 19:48:57 scribe+ 19:49:18 manu: We have talked about using name and description in VCs and put it in the context, this is about adding spec text for those things. 19:50:08 Orie: I think the current v2 context plans to use schema.org definitions for these, when you consider entire VC vocabulary, you'd expect to see schema.org term definitions -- theoretically, we could have added name registered claim name from jose registry, there would be contention about which registry defines name -- wanted to surface that thing... I have been doing so many PRs for registered claim names, I expect that particular URL would never be 19:50:08 surfaced and name would be protected, name would throw an error eventually, probably more information than people care about, wanted to put it in context. 19:50:13 ack seabass 19:50:13 seabass, you wanted to warn of interoperability issues 19:50:55 He is right... expect people to put HL7 in the description field. 19:51:01 seabass: From other spec efforts, although you can't stop people from doing stupid things, if you provide name/description, careful to say that "this shouldn't be used for" and list cases where it would be more useful to extend it rather than dumping human readable information into those fields. 19:51:10 q+ 19:51:20 kristina: I'm not sure Orie or Sebastian agreed w/ Manu's suggestion on what to put in the text. 19:51:21 ack selfissued_ 19:51:32 selfissued: The issue points out name and description are in the cotnext and not in the spec. 19:51:33 q+ 19:51:42 ack manju 19:51:45 ack manu 19:51:58 manu: That's what this issue is about, aligning those two things, making sure that we define them in the spec as well. 19:52:07 We will define name as forever being https://schema.org/name 19:52:13 Why can't we delete them entirely? 19:52:27 scribe- 19:52:32 And never being https://www.iana.org/assignments/jwt#name 19:52:34 kristina: again, Manu said one thing... orie mentioned schema.org, do we have agreement on the direction. 19:52:42 re: why not delete them... because they are very commonly used and helpful in the ecosystem 19:52:46 q+ 19:52:55 ack Orie 19:53:19 Orie: I think we have a path forward, we add sections of text to name/description and we make it reflect what's in the context today, would expect text on name/description on schema.org -- we mean same thing as in context today. 19:53:34 we could recommend a length for them (something "short") 19:54:08 Yes, but are they supposed to be displayed, say, in a wallet application? That makes it so much more important than a random human-readable helper for developers. 19:54:22 subtopic: https://github.com/w3c/vc-data-model/issues/1235 19:54:28 q+ 19:54:29 seabass: yes, they are expected to be displayed in wallets 19:54:36 seabass: that's a common use case in the ecosystem now. 19:54:43 q- 19:55:24 +1 to clear up that entity includes abstract concepts 19:55:27 jandrieu: I think references to entity implied that subject had to be something that physicaly exists, in RDF world, it can be a concept (doesn't need to "physically exist") -- we should clear up "entity" to include "abstract concepts" 19:55:40 +1 to ready for PR 19:55:47 manu: +1 entity includes abstract concepts -- 19:55:47 thanks for explaining - let's make sure that's an explicit suggestion in the specification though - in a previous specification I worked on, the 'name' field was used by everyone but never for the same thing!! 19:55:53 +1 19:56:00 jandrieu: I thik what Ted said makes sense... say entity is abstract. 19:56:04 +1 19:56:07 +1 19:56:11 s/is abstract/can be abstract/ 19:56:12 +1 19:56:35 seabass: +1 to being explicit that name is expected to be used, for example, to display information in wallets 19:56:38 kristina: We're at time, thanks for joining, see you next week at special topic call... we have two weeks, four more calls until TPAC, making good progress, let's keep it up. 19:56:45 only 10 before-CR issues that aren't yet ready for PR! 19:56:59 zakim, end the meeting 19:56:59 As of this point the attendees have been andres, brent, pdl-ASU, shigeya, TallTed, decentralgabe, dwaite, steele, kristina, manu, Orie, seabass, DavidC, mprorock, dmitriz, 19:57:02 ... bigbluehat, selfissued_, JoeAndrieu, cabernet, dlongley, GregB 19:57:02 RRSAgent, please draft minutes 19:57:03 I have made the request to generate https://www.w3.org/2023/08/16-vcwg-minutes.html Zakim 19:57:10 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 19:57:10 Zakim has left #vcwg 19:57:12 rrsagent, bye 19:57:12 I see no action items