19:58:19 RRSAgent has joined #vcwg 19:58:23 logging to https://www.w3.org/2024/01/31-vcwg-irc 19:59:03 brent has changed the topic to: Meeting Agenda 2024-01-31: https://www.w3.org/events/meetings/36ecd2da-2ec3-4012-b74a-72546ab352f4/20240131T150000/ 19:59:12 zakim, start the meeting 19:59:12 RRSAgent, make logs Public 19:59:14 please title this meeting ("meeting: ..."), brent 19:59:46 meeting: Verifiable Credentials Working Group Weekly Teleconference 20:00:05 chair: Brent Zundel 20:01:24 JoeAndrieu has joined #vcwg 20:06:29 scribe+ 20:06:44 DavidC has joined #vcwg 20:06:50 present+ 20:06:56 pdl-asu has joined #vcwg 20:07:02 present+ 20:07:08 brent: Agenda today is straightforward, will look at PRs on core data model and highlight PRs for other work items and jump into data model issue processing. 20:07:09 present+ 20:07:12 brent: Any other suggestions? 20:07:17 RRSAgent, draft minutes 20:07:19 I have made the request to generate https://www.w3.org/2024/01/31-vcwg-minutes.html TallTed 20:07:26 present+ 20:07:26 RRSAgent, make logs public 20:07:29 manu: Quick announcement about BBS signatures stuff. 20:07:31 brent: Ok. 20:07:37 DavidC: Can we see how jose-cose is progressing as well? 20:07:52 brent: Yes, we plan on covering that but we don't have either vc-jose-cose editors here yet, but we can look. 20:08:04 present+ 20:08:07 Topic: Work Item Status Updates/PRs 20:08:12 dlongley: present+ 20:08:25 brent: Will you talk to us about BBS, Manu? 20:08:43 manu: Yes, one work item is to produce an unlinkable signature spec using BBS. Greg Bernstein has been pushing that forward at DIF, IETF, and here. 20:08:53 manu: Some of the rest of us in the group have been supporting. 20:09:15 manu: We, Digital Bazaar, just last week launched a breakthrough, the first time we've done combined digital signatures with both NIST-crypto and BBS together. 20:09:42 Breakthrough: Parallel Signatures - NIST, ECDSA-SD, and BBS: https://lists.w3.org/Archives/Public/public-credentials/2024Jan/0054.html 20:09:56 manu: We took all the specs this group is working on in this WG and applied all of them to a single VC such that the single verifiable credential was secured using data integrity and every cryptosuite: ecdsa, ecdsa-sd, eddsa, bbs. 20:10:02 manu: There's an announcement on the CCG talking about this. 20:10:33 manu: Also talks about how you can try this out in the vc-playground (vc-playground.org) and how Anoncreds is also being aligned so we can do parallel DI proofs with that as well. 20:10:52 manu: I know a lot of us have been striving towards this and now that there's a system in the VC playground out there that people can test against will help with interop. 20:11:06 manu: We do know a couple of vendors that are implementing and expect them to make some announcements in the future about that. 20:11:17 brent: Thank you, Manu, cool. Are there any PRs on BBS? 20:11:25 manu: Yes, there are several ready to merge, 12 of them. 20:11:44 https://github.com/w3c/vc-di-bbs/pulls 20:11:49 manu: Most of them came from implementation experience while Digital Bazaar went through their implementation and while Greg did his independent implementation as well. 20:11:58 manu: I expect that we'll merge those PRs within the next couple of days / weekend at the latest. 20:12:01 brent: Thank you, Manu. 20:12:11 brent: Still not seeing anyone from vc-jose-cose on the call, I will try giving an update. 20:12:16 https://github.com/w3c/vc-jose-cose/pulls 20:12:17 brent: There are 7 open PRs. 20:12:42 brent: I had a conversation with Gabe -- he said they believe they have an agreed upon course of action for each of the open issues of which there are 29, 15 of which are before CR. 20:12:48 brent: A number of those are being addressed by the open PRs. 20:12:53 brent: More PRs will continue to be raised. 20:13:07 brent: vc-jose-cose is slowly making progress but isn't quite to the point where we can anticipate when it will go into CR. 20:13:15 brent: With that, any questions on that before we move into the core data model? 20:13:24 https://github.com/w3c/vc-data-model/pulls 20:13:38 brent: Here are the PRs open on the core data model. I believe most of these are editorial/post-CR type PRs. 20:13:45 brent: Manu, a couple to look at on this call? 20:13:52 manu: Yes, we need to make a decision on one of them specifically. 20:14:03 subtopic: https://github.com/w3c/vc-data-model/pull/1416 20:14:27 manu: There's a PR opened that suggests adding SHACL as a credential schema language in addition to the JSON schema stuff. This PR is to add it to the core specification. 20:14:59 manu: Ivan has noted that there are a number of issues with using SHACL as a credential schema language, notably SHACL doesn't support datasets (only supports 1 graph, not multiple and we use multiple in the core data model). 20:15:15 manu: It is not necessary for us to put this as a core part of the VCDM as you can always do this as an extension. 20:15:47 manu: This is coming in pretty late, we don't know how many people would implement, feature freeze was a while ago, and I believe Ivan got agreement from Kristof [sp?] to close it. 20:16:13 s/Kristof [sp?]/Christoph/ 20:16:21 brent: SHACL doesn't support what our data model requires? 20:16:33 manu: Yes, you could be very careful how you use it and ensure certain parts of the data model but not all of it. 20:16:53 brent: Ok, so nice to see a PR from people reading our spec to do cool things with it ... but unlikely that this PR will be merged. Any comments before moving on? 20:16:56 q+ 20:16:57 q+ 20:17:00 q+ 20:17:02 ack JoeAndrieu 20:17:30 JoeAndrieu: I'm just wondering if we could queue up something in the implementation guide to support explaining some of this. How you could extend/use SHACL in this way/be careful about these things ... that might address the request. But I agree with feature freeze, I don't want to change the VCDM in some way. 20:17:31 ack TallTed 20:17:51 TallTed: We might want to encourage the person to open issues instead of going straight to PR. 20:18:15 brent: In fairness to them they did open a discussion but we don't use that so nobody really engaged because we don't use that feature. So I created an issue based on that discussion. 20:18:19 brent: We will be marking it as future. 20:18:19 ack manu 20:18:54 manu: I'd argue against using SHACL at this point in time, so I think it's dangerous to just do partial, you could argue that JSON schema falls into that same category but it's also possible to use it by matching against context to check semantics, etc. 20:19:36 manu: I think a future version thing is what it is, we shouldn't merge the PR because of limitations in the current version of SHACL. We should see if this works by having an extension incubate this and try it out and only then later potentially put into a future VCDM. 20:19:50 manu: They should use the extension point to attempt this and they need to have an answer to the SHACL doesn't support datasets concern. 20:20:03 brent: Thank you, Manu. Another PR to look at? 20:20:12 manu: No other PRs to look at, editorial. 20:20:35 q+ 20:20:39 brent: All of them except for the one we just discussed have nothing but approvals, so I anticipate that following our normal timeline they will be merge. 20:20:46 s/will be merge/will be merged./ 20:21:16 DavidC: You pointed me to the latest JOSE COSE stuff and it looks like they've taken out the SD-JWT examples and replaced them with pure JOSE examples but the text still says they are using SD-JWT and the media type is still sd-jwt. 20:21:40 DavidC: So previously we had a document that said it was pure JOSE but it was SD-JWT ... and now the examples are JOSE and the text says SD-JWT ... so a bit of a mishmash at the moment. 20:22:03 brent: The call we had was to keep the SD-JWT aspects of the spec but add JOSE back in. 20:22:12 yes, +1 to what brent just said... that's my understanding as well. 20:22:20 DavidC: Yes, my understanding is the same as yours but they've removed SD-JWT examples completely and JOSE is back in the examples. 20:22:37 DavidC: What they wanted to do was close my PR which added the description of the SD-JWT one. I think Ted can come in here and he's been semi-following this as well. 20:22:45 s/will be merged../will be merged./ 20:22:45 q? 20:23:01 TallTed: I agree, I've been following that but not the immediate discussion just now. What's the question? 20:23:30 DavidC: Ted, you did some editorial suggestions to my PR and then Gabe was closing it ... and I think it's not done and you, Ted, were agreeing with me. 20:23:58 DavidC: So this hasn't been completed yet, because the example for VP SD-JWT and no text describing that ... and that example is gone now... both SD-JWT examples are removed at the moment. I'm not sure what's happening with the spec. 20:24:18 TallTed: If the examples have been removed then the issue is resolved by removing them, but if they come back, then the issue will be revived. 20:24:29 DavidC: They've got text and media type for SD-JWT but examples for pure JOSE. 20:24:52 brent: While I appreciate the concerns and you feel that a discussion would be valuable -- but having half that discussion while the vc-jose-cose editors aren't here ... not the best use of our time perhaps. 20:25:01 DavidC: Yes, but having it in the minutes makes clear it needs to be addressed. 20:25:07 brent: Thank you, David. 20:25:18 brent: Moving onto issue processing. 20:25:56 brent: Right now, every issue is official post-CR, but some aren't labeled as such yet and we should make sure that they are issues that we feel need to be addressed. 20:26:08 s/and you feel that a discussion would be valuable -- but having half/and feel that a discussion would be valuable -- having half/ 20:26:12 Topic: Issue Processing 20:26:13 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Apost-CR+sort%3Aupdated-asc 20:26:46 subtopic: https://github.com/w3c/vc-data-model/issues/1410 20:27:06 brent: Does this spec need a normative credentials specification section... we talked about this a couple of weeks ago. 20:27:29 brent: If we do this, it's likely it will require some normative text. We created a CR-2 label for it and so it's triaged and Manu has accepted an assignment for it... can you speak to this Manu? 20:27:39 Jeffrey's concerns are here: https://github.com/w3c/vc-data-model/issues/1388#issuecomment-1875788296 20:28:12 manu: Jeffrey Yaskin raised a number of concerns -- saying he would like to see specifications that define new credential types like ... types for driver's licenses, or employment authorization documents, or digital coupons, or whatever ... that we have guidance to those specs in the core data model. 20:28:32 manu: So we established things securing specs must do and he's saying we should establish things that credential type specs must do. 20:29:16 manu: He suggested some items in the comment I linked to. One way to do that is to have a section that is like the securing specs ... and specify requirements there. I'm still a bit fuzzy on what we'd write in that section. We don't have to write that section, it's not clear that if we wrote something Jeffrey would be happy with it, I could try to make an attempt... I need direction from the group. 20:29:29 manu: Is this worth doing this at this point? Do we do one PR and try to make it work and if we don't just close it? 20:29:44 q+ to say types seems like a centralized limit that would violate the goal to allow anyone to say anything 20:30:03 brent: So this issue is asking for, suggesting that the core data model needs a section of normative requirements aimed toward potential credential type spec authors that would guide those authors and tell them what their specs are required to include to be best compliant with the core data model. Is that right? 20:30:07 manu: Yes, I think that's close. 20:30:07 I like the idea of giving one PR a shot for normative requirements for type specification authors per https://github.com/w3c/vc-data-model/issues/1388#issuecomment-1875788296 20:30:20 ack DavidC 20:30:27 brent: So kind of what the DID spec did with DID methods. 20:30:30 manu: Yes. 20:30:30 ack JoeAndrieu 20:30:30 JoeAndrieu, you wanted to say types seems like a centralized limit that would violate the goal to allow anyone to say anything 20:30:57 JoeAndrieu: I think this is a form of centralization that is probably not going to be good for us. It would mean that if your new type of credential doesn't fit and we're trying to stand in that way. 20:31:09 q+ 20:31:12 q+ 20:31:15 ack manu 20:31:19 JoeAndrieu: The difference with DID methods is we're running a registry, which I also oppose, and we don't have a similar registry and I don't think we should add one, so we shouldn't try to do this. 20:31:54 manu: I think Jeffrey is talking about security requirements, so things that a spec would need to say to be processed as regular JSON -- so you can process as JSON-LD or as JSON ("credential type-specific processing"). 20:32:20 manu: I don't think this creates a centralization concern. 20:32:22 ack brent 20:32:48 brent: So, in addition to your credential spec needing a security considerations section, what other normative guidance might be necessary for it to work with the core data model? 20:32:52 q+ 20:32:59 https://github.com/w3c/vc-data-model/issues/1388#issuecomment-1875788296 20:33:00 brent: So what, specifically, might we provide in terms of guidance? 20:33:00 ack manu 20:33:36 manu: He's got like three things in an issue. Like "you must use enveloping proofs", I don't agree with that one. He also has "never create a claim that says: 'this other claim means some other claim means nothing if this one exists'. 20:33:40 Here are some normative requirements that we could write into this section: https://github.com/w3c/vc-data-model/issues/1388#issuecomment-1875788296 20:33:41 brent: Where is this? 20:33:51 q+ to say, all three of these seem arbitrary and limiting 20:33:59 manu: Again -- I think it would be very challenging writing the language, willing to give it a shot, but not expecting success. 20:34:10 ack JoeAndrieu 20:34:10 JoeAndrieu, you wanted to say, all three of these seem arbitrary and limiting 20:34:35 q+ 20:34:38 JoeAndrieu: They seem pretty arbitrary, the first one Manu didn't even agree with -- trying to establish these things, I think we don't have a good enough understanding to get to consensus and limiting what people are allowed to say with VCs I would oppose. 20:34:42 ack DavidC 20:34:58 DavidC: I find number 3 is problematical given our data model where we have claims that invalidate others. 20:35:21 subtopic: https://github.com/w3c/vc-data-model/issues/1415 20:35:23 brent: We're looking primarily for triage. 20:35:40 q+ 20:35:49 ack manu 20:36:03 brent: This one is about credential-type specific processing vs. type-specific credential processing. 20:36:08 brent: That sounds better to me. 20:36:11 manu: I agree. 20:36:16 TallTed: I can also take this one. 20:36:25 brent: I will assign Manu and Ted, and whoever gets there first wins. 20:36:35 brent: Labeling that one CR-2. 20:36:47 subtopic: https://github.com/w3c/vc-data-model/issues/1419 20:37:13 brent: We already had a conversation about this one through the PR that was raised, this is the SHACL one. At this point, it seems likely we'll just label this future but we should allow the conversation to come to completion on the PR before making that designation here. 20:37:19 brent: Happy to take comments if folks have them, otherwise moving on. 20:37:50 brent: Next three are PR-exists and editorial, taking the liberty as marking them as CR-2. We don't have to talk about them unless folks are inclined. 20:37:52 present+ 20:38:04 brent: 1418,1424... [and one other]. 20:38:29 brent: Jumping into processing the rest of the issues. 20:38:34 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc 20:38:52 brent: We will be talking through this, but there was one issue in particular that folks wanted to talk about today which was an older issue but still valid. 20:39:05 brent: It is the only issue currently marked pending close, issue 942 we can talk briefly about it. 20:39:09 subtopic: https://github.com/w3c/vc-data-model/issues/942 20:39:38 brent: As I recall things, please correct me ... as I recall things, we did not come to consensus as a group about creating the new role of Issuee. It was proposed to the group, we had long conversations about it, but ultimately the group could not come to agreement on doing this. 20:40:26 brent: As Kristina mentioned with her comment -- there was no consensus in the group for that. The issue was then adjusted to be about adjusting the holder property to talk a little bit about it. This conversation has gone on for a long time and my recollection is we don't have consensus to add Issuee as a new role... 20:40:31 agree w/ brent's summary 20:40:32 q+ 20:40:36 q+ 20:40:36 brent: ... and unless everyone on this call disagrees then I'm happy to close it out. 20:40:37 ack JoeAndrieu 20:40:47 q+ 20:40:50 JoeAndrieu: Thanks, the main issue --- I wanted to bring it up and let David have this moment to try and speak against it. 20:40:57 ack manu 20:41:13 manu: To underscore ... I agree with your recollection, Brent, I think that's where the group is and wouldn't personally want a new role in the ecosystme. 20:41:32 dlongley: I didn't think it made sense as a role, but perhaps a property. 20:41:41 ack DavidC 20:41:47 brent: The extension model allows `issuee` to be added as a property. 20:41:55 DavidC: Can we please record that this role has always existed. 20:42:01 s/ecosystme/ecosystem/ 20:42:17 brent: I appreciate your view on this but it's not mentioned by name as a role in the spec, so it's a new role. 20:42:45 DavidC: Just because it wasn't listed doesn't mean it hasn't existed. The issuer has always issued the credential to the issuee, it's just English grammar if you like, it's just not documented as such. 20:43:08 issuee is a shadow-role, filled by the first holder who gets a VC from an issuer. 20:43:08 brent: I appreciate that perspective and I disagree with it, my chair hat off, as a contributor, I don't think that's the case. 20:43:19 ack TallTed 20:43:54 TallTed: As I said in a few places, included in that issue, I don't have anything against defining this term, whether it's fully defined and in the spec or just reserved and I would suggest reserving that label `issuee` for future use. It does always exist and has existed as David says, we haven't highlighted it. 20:43:59 q+ 20:44:01 Thankyou Ted 20:44:03 TallTed: It's just the first holder of the VC. 20:44:23 TallTed: Having it, would resolve some issues to address some issues that are elsewhere in these documents and we've gone in circles because we didn't have this term to use. 20:44:26 q+ to agree issuee is just the first holder, not a Role, which is a specific term we define 20:44:27 ack manu 20:44:54 manu: I'm still a -1 to add this, I get what both David and Ted are saying, yes the concept has always existed since the dawn of time since the first VC was issued by an issuer and handed to the first holder, the issuee. 20:45:06 manu: I don't think we have consensus, a strong -1 to add this at this time, I don't think it's helpful. 20:45:10 ack JoeAndrieu 20:45:10 JoeAndrieu, you wanted to agree issuee is just the first holder, not a Role, which is a specific term we define 20:46:05 JoeAndrieu: I'm a -1 as well, the vernacular fact that you might refer to the first holder as an issuee doesn't create a new role, they are still a holder. Adding it as a role to the list of roles would make it a new role. When the holder presents a VC we could call them a presenter, but that doesn't mean we add it as a role, as it confuses the simple 3-party model that highlights the difference with VCs and previous phone-home architectures. 20:46:11 subtopic: https://github.com/w3c/vc-data-model/issues/1274 20:46:37 brent: A little bit more about verification method type schema. Either this is just an answer we need to give or some editorial content to resolve it. 20:46:54 brent: Do we need more information about the `verificationMethod` property, does it need to be done, is there anyone willing to do it? 20:46:55 q+ 20:47:02 ack manu 20:47:13 manu: I'm trying to parse what they are saying. I guess I said this was ready for PR a year ago... 20:47:19 manu: I think the spec was in a different place then. 20:47:48 manu: The easiest fix for this is to just point to the `verificationMethod` property in the DI spec, but others in the group might object to us doing that because it's also defined in vc-jose-cose, we don't have a unified controller document spec yet. 20:47:55 manu: The other thing we could do here is just delete the note. 20:48:05 manu: I don't know if this note is really helping anymore. 20:48:37 q+ 20:48:42 manu: If folks are ok, we could just delete the note, it came from a time long long ago, where we needed to highlight that the digital signature might include things like the public key associated with it and so on -- and now we have whole specs talking about all of that. I suggest we just delete the note. 20:48:45 ack brent 20:48:50 brent: Big +1 to cleaning up the spec you suggested. 20:48:58 brent: I think getting rid of some things that aren't necessary now that we're on version 2. 20:49:15 brent: The suggestion is to resolve this issue by removing the linked note and move forward in that way. 20:49:20 dlongley: +1 to that path forward 20:49:25 +1 to that path 20:49:26 brent: Any opposition to that? 20:49:34 brent: Let's do that, awesome. 20:49:39 subtopic: https://github.com/w3c/vc-data-model/issues/1293 20:50:00 brent: Clarify the evidence section to point to OBv3 evidence property issue, raised by Manu and assigned to no one, Manu, walk us through this? 20:50:31 manu: The current evidence property doesn't use real examples and this is just about updating it to use real examples to use an OpenBadge v3 example of evidence. 20:50:53 brent: So this is about updating examples to make use of OpenBadges v3 examples -- and changing the text or not? 20:50:59 manu: Just to update the examples. 20:51:05 +1 to that ;-) I'll make a stab at that/ 20:51:08 brent: Can anyone be assigned to update those examples? 20:51:11 q+ 20:51:21 brent: I see Phil Long will work on it. 20:51:52 ack DavidC 20:51:58 DavidC: It was just to say that the other real example is the one from New York customer work -- the OpenID foundation work. Similar examples in the CCG. 20:52:08 DavidC: If you want to refer to that as well, as another solid example you could. 20:52:17 brent: If you have links to either of those that would be really helpful. 20:52:23 DavidC: How should I get those across? 20:52:32 brent: Add them directly to the issue, excellent, thank you very much, David. 20:52:34 Thanks David 20:52:46 subtopic: https://github.com/w3c/vc-data-model/issues/1291 20:53:04 q+ 20:53:08 brent: Multiple credential status lists -- is it possible to have multiple credential statuses, i.e., have `credentialStatus` be a set? 20:53:12 ack manu 20:53:17 brent: The short answer is "yes". Do we want to have an example? 20:53:26 manu: We have an example in the bitstring status list spec on having multiple statuses. 20:53:38 Multiple Status Lists in One Verifiable Credential: https://w3c.github.io/vc-bitstring-status-list/#multiple-status-lists-in-one-verifiable-credential 20:53:42 manu: But that's just for the bitstring status list type... let me get a link in here. 20:53:57 manu: Maybe they are wanting something slightly different which is wanting different types of credential statuses. 20:54:14 manu: We could just reuse the example from bitstring status list. Or we could point to those examples? 20:55:01 q+ 20:55:09 brent: We could create an example or modify example 17 in the spec so that credential status an array of objects, but hesitation to propose that as a path forward is that then we have to say how those statuses interact. Maybe we just have to say -- if you have multiple statuses and they are conflicting, good luck figuring that out. 20:55:16 manu: Yes, +1 to the same concerns. 20:55:18 ack manu 20:55:34 manu: He does provide an example -- about revocation and suspension. We could just use the example and add the warning that you just mentioned, Brent. It feels like it would address this issue. 20:56:15 q+ 20:56:20 brent: Ok. There's a proposal on the table, we take the suggestion from the issue, work it into the example we already have in the spec and then add a sentence to the spec that says, should multiple statuses be included and they be in conflict, the verifier's business logic needs to take that into account. 20:56:22 ack JoeAndrieu 20:56:49 q+ 20:56:53 JoeAndrieu: I like that general approach, +1, I don't think it's as much about them being in conflict as they represent different things semantically, we just need the validation phase to be able to pull in all the factors and be able to understand the semantics to make a decision. 20:56:56 ack dlehn 20:57:23 q+ 20:57:28 ack manu 20:57:30 dlehn: Is the processing of things like this similar to how you'd process proofs, where you have ANDs and ORs -- and it's a bit more work, but should we do that sort of thing? 20:57:43 manu: I'm concerned about saying that much in the spec this late in the process. 20:57:57 q+ to speak to GS1's new use case 20:58:20 manu: Most of the usage of credential status that I know of right now is whether it's revoked/suspended/or does it have 1-30 different values (multi-status stuff). I don't think we have enough implementation experience to make broad statements about composition. 20:58:25 ack JoeAndrieu 20:58:25 JoeAndrieu, you wanted to speak to GS1's new use case 20:58:28 manu: And we should stay silent now until there's more implementation experience. 20:58:32 JoeAndrieu: General +1 to Manu. 20:58:53 JoeAndrieu: We do want to say that this is possible, and however many there are, they are inputs to validation and how composition happens and so on is the verifier's business. 20:59:28 JoeAndrieu: They need to figure it out. There's also a use case contribution by Kevin from GS1 -- as GTINs get brought in during acquisitions there's a need to track status things. 20:59:58 brent: If anyone here says "that's a good idea, let's clean this up" -- assign yourself! If no one volunteers it won't get done. 21:00:17 brent: Thank you all for being here, still a lot of work to do, hoping we can continue the momentum, thank you Dave for scribing, thank you all for being here, see you next week! 21:00:24 zakim, who is here? 21:00:24 Present: DavidC, pdl-asu, TallTed, brent, dlehn, JoeAndrieu 21:00:26 On IRC I see DavidC, JoeAndrieu, RRSAgent, Zakim, brent, dlongley, steele, TallTed, tzviya, dlehn, Github, w3c_modbot, bumblefudge1, cel[h], bumblefudge, saysaywhat, matrix638, 21:00:26 ... AnthonySpencer, ounfacdo, MojGraph, enick_708, cel[m], npd, seabass, SintayewGashaw, joraboi445, KamirKami, rhiaro, csarven, shigeya, cel, jyasskin, manu, ivan, rbyers, 21:00:26 ... hadleybeeman, stenr, bigbluehat 21:00:43 present+ Will 21:01:06 present+ manu 21:01:17 present+ dlongley 21:01:31 zakim, end the meeting 21:01:32 As of this point the attendees have been DavidC, pdl-asu, TallTed, brent, dlehn, JoeAndrieu, Will, manu, dlongley 21:01:33 RRSAgent, please draft minutes 21:01:35 I have made the request to generate https://www.w3.org/2024/01/31-vcwg-minutes.html Zakim 21:01:41 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 21:01:41 Zakim has left #vcwg 21:01:45 rrsagent, bye 21:01:45 I see no action items