14:59:11 RRSAgent has joined #vcwg 14:59:16 logging to https://www.w3.org/2024/05/08-vcwg-irc 14:59:16 RRSAgent, make logs Public 14:59:17 please title this meeting ("meeting: ..."), brent 14:59:32 meeting: Verifiable Credentials Weekly Teleconference 14:59:38 chair: Brent Zundel 15:01:21 present+ 15:01:44 present+ 15:02:48 KDean has joined #vcwg 15:03:47 JoeAndrieu has joined #vcwg 15:03:56 present+ 15:04:08 zakim, who is present? 15:04:08 I don't understand your question, manu. 15:04:13 present+ 15:04:13 RRSAgent, draft minutes 15:04:14 I have made the request to generate https://www.w3.org/2024/05/08-vcwg-minutes.html TallTed 15:04:21 RRSAgent, make logs public 15:04:22 brentz has joined #vcwg 15:04:22 selfissued has joined #vcwg 15:04:23 Zakim, who's here? 15:04:24 Present: brent, manu, JoeAndrieu, TallTed 15:04:25 On IRC I see selfissued, brentz, JoeAndrieu, KDean, RRSAgent, Zakim, TallTed, manu, shigeya, dlehn1, cel, ivan, dlongley, csarven, jyasskin, rbyers, hadleybeeman, rhiaro 15:04:27 present+ 15:04:47 scribe+ 15:05:00 present+ 15:05:28 brentz: Welcome to the VCWG weekly meeting, our agenda today consists of some announcements, controller document to FPWD, work item status updates, PRs, and issue processing. 15:05:46 scribe+ 15:05:47 hsano has joined #vcwg 15:05:59 present+ 15:06:05 manu: This went out to the mailing list this morning, both the VCWG and the CCG mailing list. 15:06:43 dmitriz has joined #vcwg 15:06:47 California DMV Launches OpenCred with Support for Verifiable Credential based Driver’s Licenses: https://lists.w3.org/Archives/Public/public-credentials/2024May/0016.html 15:06:48 present+ 15:06:52 manu: The state of California, specifically the department of motor vehicles in CA, announced they are launching an open source platform that supports all the things this group is doing as well as OID4 and other API work. 15:06:55 manu: It's a verifier. 15:07:00 PL-ASU has joined #vcwg 15:07:18 @manu - what's your sense regarding what sort of Known Issuer lists their platform will be running? (if it's a general platform) 15:07:23 bigbluehat has joined #vcwg 15:07:28 manu: The big news is that CA DMV is issuing VC driver's licenses now. It's limited to 1.5M person pilot and there's an expectation that after the pilot it will open to a broader population. 15:07:31 present+ 15:07:51 present+ 15:07:54 brent has joined #vcwg 15:08:00 manu: It was announced last week that this is the first of multiple W3C VCs that CA will be issuing. There will be further announcements about what those will be as time rolls on. There is a general desire to align with what this work is doing, there is no request for a change in direction. 15:08:17 manu: There's an expectation that CA DMV will align with the things that we are doing here, whatever becomes a REC they will be aligned with. 15:08:33 smccown has joined #vcwg 15:08:46 manu: There are 27M people in CA that hold DLs, the number from last week, half a million people today have a W3C VC in their wallet app. 15:09:02 manu: There is also announcement that CA DMV has integrated TruAge which uses W3C VCs into their CA DMV app. 15:09:08 manu: That's an add on people can use there. 15:09:25 manu: This is a very big public deployment and big news for this community, focus is on rollout and to the larger citizenry. 15:09:37 brent has joined #vcwg 15:09:40 present+ 15:09:43 q? 15:09:44 manu: I do not speak for the state of CA, but as one of the organizations that worked on the open source platform, OpenCred, I'm happy to answer any questions if anyone has any. 15:09:47 scribe- 15:09:47 q+ 15:09:56 ack dmitriz 15:09:58 q+ 15:10:23 scribe+ 15:10:32 dmitriz: Is it only verifier? 15:10:46 manu: It is only a verifier platform, it speaks CHAPI, VC API, OID4VP, it does standard verification over that. 15:11:03 manu: It has hooks to call out to other verifier platforms and potentially issuer platforms, but that would use the VC API to call out to remote issuance platforms. 15:11:10 jenniem has joined #vcwg 15:11:21 manu: The known issuers are hard-coded for now. When you download and setup the opensource software, you specify the issuers that you trust. 15:11:25 manu: You put it in a config file. 15:11:34 thanks! 15:11:35 yep 15:11:36 manu: There is plenty of room to improve that feature over time. 15:11:45 ack selfissued 15:12:14 selfissued: First, congratulations. What is their plan, to the extent you understand it, for migrating to the new specs once they are recommendations and what securing mechanisms are they using? 15:12:41 present+ 15:12:57 manu: They are migrating. This work started a long time ago, so they used VC-JWT 1.1, but this group has moved from that. It's safe to say that anything this group puts out is on the table for what they end up migrating to. 15:13:01 selfissued: Thank you. 15:13:09 Topic: Controller Document FPWD 15:13:24 s/only verifier?/only verifier? And what trusted issuer lists or mechanism are they using if any?/ 15:13:29 scribe- 15:14:18 DavidC has joined #vcwg 15:14:26 present+ 15:14:57 q+ 15:15:07 scribe+ 15:15:09 ack selfissued 15:16:11 brent: We're going to be getting the controller document into shape -- as we had consensus for it to have everything from DI and VC-JOSE-COSE -- so that's what we'll be doing to get all of those things in there. 15:16:21 selfissued: Having reviewed everything and comparing it to data integrity and vc jose cose, for the most part they were nearly identical, I'm hopeful that this is largely syntactic exercise and will be straightforward. 15:16:24 q+ 15:16:30 (https://w3c.github.io/vc-controller-document/FPWD/2024-FPWD/) as a 15:16:30 W3C First Public Working Draft with a target publication date of May 15:16:30 30th 2024. 15:16:30 q- 15:17:10 q+ 15:17:18 ack manu 15:17:48 manu: The controller document is not specific to VCs. I think Ivan would want us to pick a shortname that isn't VC specific. That would be the only modification ... to rename to "controller-document". 15:17:52 brent: How does that draft proposal look? 15:17:55 (yeah, it's used for example for ActivityPub actor profiles, unrelated to VCs) 15:17:59 q+ 15:18:10 q- 15:18:11 selfissued: Is it expected that other WGs would reference this, including the newly reformed DID WG? 15:18:16 brent: short answer, yes. 15:18:18 +1 to Manu's simplification for the name of the Controller Document. 15:18:25 brent: Short answer is "yes", hopefully they will think it's great. 15:18:38 PROPOSAL: Publish the Controller Document v1.0 specification (https://w3c.github.io/vc-controller-document/FPWD/2024-FPWD/) as a W3C First Public Working Draft with a target publication date of May 30th 2024 and a short name of controller-document 15:18:38 brent: Any changes to new draft proposal? Seems good for folks? 15:18:43 +1 15:18:44 manu: +1 15:18:45 +1 15:18:45 +1 15:18:45 dlongley: +1 15:18:46 +1 15:18:49 =1 15:18:50 +1 15:18:53 +1 15:19:00 +1 15:19:01 +1 15:19:03 +1 15:19:04 +1 15:19:31 brent: There will be one more set of changes to bring it fully inline w/ Data Integrity, after that's done, we should raise issues/PRs/modify it. 15:19:36 brent: There will be one more set of changes to bring it fully inline with DI -- at which point doing PRs and raising issues and so on will begin. 15:19:37 q+ 15:19:40 scribe- 15:20:04 brent: There was an email to the group indicating the expected timeline for this document, and for it to be published in time for it to be used for other docs, we're going to be keeping a very tight schedule, everyone should keep that in mind. 15:20:18 Resolved: Publish the Controller Document v1.0 specification (https://w3c.github.io/vc-controller-document/FPWD/2024-FPWD/) as a W3C First Public Working Draft with a target publication date of May 30th 2024 and a short name of controller-document 15:20:23 ack selfissued 15:20:33 selfissued: I would characterize that we're ready for issues/PRs. 15:20:33 q+ 15:20:39 scribe+ 15:20:54 ack manu 15:20:54 brent: I keep invitation open to manu to raise PR 15:20:56 brent: I keep the invitation open to raise that PR if he sees it necessary to make sure it all lines up. 15:21:34 manu: Things have changed. You're largely right, Mike. Much of it is intact, but some algorithmic errors have been fixed and there's a delta and we should bring it up to speed. It's fine to raise issues because either the update will address them or we will have to do more PRs. 15:21:37 manu: I'm fine with raising issues now. 15:21:52 decentralgabe has joined #vcwg 15:21:54 manu: When is it ok to raise the PR to move the rest of the DI stuff over? 15:21:56 present+ 15:22:19 brent: In order for this to meet process, we need to bring it up to date w/ Data Integrity, at that point, we'll follow normal operating mode. 15:22:32 brent: In order to meet the group consensus to create the document in the first place, it needs to be aligned with what's in VC-JOSE-COSE and DI. I'm confident the former is covered but the not the latter, once the DI fixes are in that's when the document is actually ready. 15:22:38 brent: That PR will go in as soon as it exists. 15:22:43 selfissued: I will review it when it's in. 15:22:45 manu: Ok, thanks. 15:22:50 scribe- 15:22:52 Topic: Work Item Status Updates/PRs 15:22:52 brent: ok, moving on to work item status updates. 15:23:19 brent: For work items, if there are any issues that group should be aware of, PRs to review, please queue to share those. 15:23:20 q+ 15:23:23 scribe+ 15:23:26 ack manu 15:24:00 manu: So there's obviously a set of new issues on the controller document that people should look at, I won't go into any of those. For the data model, we have hit a snag on ... for David Chadwick's PR there are merge conflicts. Can you fix those before we merge? 15:24:04 DavidC: Yeah, sure. 15:24:22 manu: The content integrity section has a number of objections on it. I presume we'll talk about those at some point. The rest of the specs are doing their normal thing, that's it from me. 15:24:23 do you have links to the content integrity objections? 15:24:32 https://github.com/w3c/vc-data-model/pull/1484 15:24:35 q+ 15:24:37 brent: We have some time to look at the content integrity PR. 15:24:38 brent: we have some time to look at that PR. 15:24:40 scribe- 15:24:40 subtopic: https://github.com/w3c/vc-data-model/pull/1484 15:24:44 ack selfissued 15:24:49 q+ to speak as DI. 15:24:53 q- 15:24:53 q+ 15:24:58 subtopic: VC-JOSE-COSE 15:25:27 selfissued: There is one PR that's been filed to address issue manu raised on examples. I would ask people to let this one go through, it clears up attribution issue to separate whether we're generating examples the right way from dealing w/ IPR. 15:25:40 selfissued: in fullness of time, we can/will update examples, Gabe will update that. 15:26:18 selfissued: I'd like to merge that one, few new issues for VC JOSE COSE. One from Martin Thomson noting showing headers in examples. Will need Gabe to look at this as well. I agree, we should be showing headers. 15:26:32 selfissued: I do have a procedural question, now that we've published a CR draft, can we merge stuff or do we mess something up? 15:27:17 brent: You can merge whatever you need to into Candidate Recommendation Draft, as long as it doesn't include normative changes, then we're good to proceed. If there are normative changes, then before we move to PR, we will have to do another CR snapshot and get horizontal review on those changes. 15:27:26 selfissued: Intellectually, I understand, practically I don't. 15:27:52 brent: Merge whatever you need to merge. If there is a normative change, there should be a change log, if there are normative changes, then make sure we do CR Snapshot before we do PR. 15:28:05 selfissued: We can merge non-normative stuff into main? 15:28:08 brent: yes 15:28:21 subtopic: https://github.com/w3c/vc-data-model/pull/1484 15:28:45 brent: This PR has had a number of comments on it, number of requests for changes, Manu could you talk us through it? 15:28:57 brent: Folks that would like to see changes, please do so. 15:29:00 scribe+ 15:29:39 manu: This PR started out as a request from Jeffrey Yaskin to rewrite the content integrity section so that it matched the pattern of the other sections. This section was originally written by Mike Prorock, it was the first attempt at it and it went through a lot of churn and needed clean up. 15:30:22 manu: There were a number of things agreed to -- as far as "please raise an issue noting X and Y" in the content integrity section. There was not agreement on the digest format we would use, but there was agreement that it would be between `digestSRI` and `digestMultibase` or both and leave it to implementers to decide on which ones to implement, if not both of them. 15:31:05 manu: This section was largely rewritten editorially, but there are objections to the way it was rewritten because we now mention both `digestSRI` and `digestMultibase` in the spec; one argument is that was always true, there was an issue marker in the spec that said we would rely on implementers to pick. 15:31:40 q+ 15:31:41 manu: The counterargument to that is that we never agreed to that but that's challenged as well. Largely this is an editorial rewrite of the section and the thing that's under contention is that `digestMultibase` is being specified more clearly based on the issue marker. 15:32:18 ack manu 15:32:19 manu: I would be interested in hearing Mike's concerns here and Jeffrey Yaskin has also jumped in with good questions we should answer and while we're reworking the section we should address those. 80% are questions with answers, 20% we might want to discuss. 15:32:22 ack selfissued 15:32:23 scribe- 15:33:13 selfissued: Obviously, I'm the one who had made the point that we shouldn't be normatively adding multibase to the VCDM spec since we have been careful to not include it before. I understand that there is an issue comment, but I'm not willing to elevate multibase beyond that issue comment. 15:33:14 q+ 15:33:14 q+ 15:33:16 scribe+ 15:33:16 q+ 15:33:21 ack DavidC 15:33:25 q- later 15:34:00 q+ 15:34:06 DavidC: This new text should have removed the note, suggest removing that bit, rework editorial, and discuss later. 15:34:07 manu: Yes, I think that the new text, actually, if you look at it carefully, the changes have been made, it's clearly addressing Jeffrey's comments. I think the new text on multibase isn't replacing anything. We should have struck out the note. Then we can put that into a new PR and just work on that PR alone. 15:34:16 ack dmitriz 15:34:17 brent: ok, so smaller more controversial bit to its own PR. 15:35:12 dmitriz: I'm curious, wrt. digestMultibase, since Mike's objection is primarily to text encoding part, the base part, possibly not the multihash part of it, can we change direction, fix the base, fix it to base64url, and have it as digestMultihash that provides significant benefits, digestMultibase approach is smaller. 15:35:13 dmitriz: I'm curious, with regards to `digestMultibase`, since Mike's objection seems to be primarily to the base encoding part, perhaps not the multihash aspect of it, I'm wondering if there's still time or opportunity to change direction and require the base to be base64url and have it be a digest multihash, which provides significant size benefits over the digest SRI approach. 15:35:30 ack manu 15:35:32 dmitriz: Would Manu and other proponents consider pivoting and leaving the multibase aspect. 15:36:10 s/leaving the multibase aspect/leaving the multihash aspect/ 15:36:25 manu: Sure. I think there's a misunderstanding about what's in the spec today. Today we normatively reference DI and VC-JOSE-COSE -- because this group decided that because we're publishing those we will normatively reference those from VCDM. As a result, we can pull in those normative things from those specs. If the concern is not defining them in VCDM, that's not happening. 15:37:13 manu: We're using it from the other specs. The more confusing thing is that we're taking the definitions from DI -- and moved them into the controller document. The thing with the normative definition for multibase is in the controller document. Now we'd have to ref the controller document from the VC data model. In the same way we ref SRI. 15:37:51 manu: We can't just ref SRI, we have to specify a field and the format of that field and we have language around that. We have to define it somewhere. We have to figure out where to define it -- we could define it in controller document, we could define it in VC-JOSE-COSE, we could define it in DI. I don't have a strong feeling where it goes. 15:38:37 manu: But to use that feature we have to talk about it in the VCDM. I don't quite understand what Mike's objection -- are you objecting to where it's defined (it must be defined somewhere, but we have to normatively reference it to use it). I don't really care where it's defined but it has to be somewhere, the easiest place is in the VCDM, but we can put it in DI or somewhere else. 15:38:43 manu: We could throw it all in the controller document. 15:38:49 q+ 15:39:08 brent: Just to summarize, currently the VCDM normatively references `digestSRI` and defines a profile of how we're using it? 15:39:43 manu: No, it references SRI, which is a web browser thing. We use a tiny piece of SRI but we can't just do that. We have to define what the value is in the `@context`, its range, how it's encoded, etc. SRI doesn't do that, it's targeted at browsers. 15:40:08 manu: We chose to do that work in VCDM, it's a couple of sentences, it's simple. But we have to do that for `digestMultibase` as well, but it's already defined in DI and we can just ref it. 15:40:12 brent: That was helpful. 15:40:13 ack selfissued 15:40:45 selfissued: As Dmitri points out, the problem with digestMultibase is its dependent upon multibase, where inexplicably it defines something like 26 encodings for the same data, which is a travesty for interop. 15:40:46 q+ 15:40:50 scribe- 15:40:59 q+ to propose using base64url `u` prefix only. 15:41:03 selfissued: my objections are not about where this is defined, it's to using it at all, because it hurts interop. I'm on public record about that. 15:41:04 q- later 15:41:15 selfissued: The multibase encoding is a failure to make a choice, we should steer clear of it. 15:41:16 ack dlongley 15:41:16 dlongley, you wanted to propose using base64url `u` prefix only. 15:41:28 @dlongley - but if we're gonna use 'u' prefix only, why don't we just specify that we're using u, and save the extra character 15:41:52 dlongley: 2nd Dmitri's proposal to resolve this, to say that we only support the base64url prefix, which is the multibase prefix for base64url, nopad encoded, if we do that, then that gets us past the objection, then we get data savings, and so on. 15:41:53 q- 15:42:02 q+ 15:42:18 q+ 15:42:20 brent: proposal on the table is we specify which base and do that in this section of VCDM. Mike, would that address your objections? 15:42:24 ack dmitriz 15:42:38 q+ 15:42:45 dmitriz: I like Dave's suggestion, but if we're fixing that we're just fixing base64url, and drop the 'u' and save ourselves an extra character. 15:42:46 ack selfissued 15:45:01 selfissued: Well, Dmitri's suggestion is rational, threw me off. In response to brent's suggestion, I'm unwilling to define any form of digestMultibase in our core spec, I understand the irony, which defines this in controller document, and I do appreciate we got to compromise to DI where we don't normatievly ref 26 choices, but we decide w/ what Dmitri said, what choices we make, I do not know whether a form of digestMultibase is defined in controller 15:45:01 document, if we're going to define that w/ base64url encoding I'd do it there to keep everything together. The other question, I do support defining the fields necessary to use digestSRI in our spec in the Content Integrity section. Finally, I haven't read Jeffrey's comments, read them w/ eye, is he asking for Multibase to be specified. or is he asking unrelated editorial things? 15:45:04 ack dlongley 15:46:22 dlongley: One of the advantages of using multibase is it introduces layers and a separateion of concerns, so you can compress any multibase data regardless of whichever data is done, ifyou want to compress using CBOR-LD, it can do that sort of compression, or use tech that is not a VC, different choices on encoding, here in our group we can say base64url, no one has to go rewrite new tech, type is multibase, no new tech needs to be written to that 15:46:22 particular field, that other tech continues to work, we get benefit that there is interop around that prefix, we get best of both worlds if we make that choice. 15:46:25 @dlongley - since that's driven off of an RDF data type, can't we define a base64url data type, and have processors just work off that/ 15:46:33 q+ 15:46:37 ack dmitriz 15:47:10 q+ 15:47:20 dmitriz: Dave's point about CBOR-LD processors makes a lot of sense, since signal processors are working off of, RDF type multibase, why dont' we define RDF type for base64url, same logic, same compression can be invoked? 15:47:24 ack dlongley 15:47:33 q+ 15:47:34 but there's like only 3-4 15:47:36 encodings 15:47:42 realistically 15:48:00 (base64url, base32lower, base32upper... like what else are you gonna use) 15:48:07 dlongley: What we're suggesting now is a new RDF type for every encoding type, or we can re-use work out there, already implementions using that... if the world had decided to take a different approach, and communities were using RDF, then that might have worked, but there are separations of concerns, trying to re-use technologies, if we re-invent yet another way to do it, we're less interoperable. 15:48:48 dlongley: simplest thing to do is take implementations already out there, will work w/ other tooling, we should ivnent fewer things, we should profile it down, it addresses Mike's concern, they don't have to use it either and will just work w/ VCs w/ one prefix. 15:48:50 ack selfissued 15:49:10 q+ to say that's not what i meant so i will clarify 15:49:25 selfissued: I guess I disagree with the characterization, it's not inventing something, it's something that's been around for a decade and a half. If we need context and vocabulary term, let's create it. 15:49:52 Multiformats Considered Harmful https://self-issued.info/?p=2408 15:49:53 selfissued: To Dave's point, that's what people have already used, that people chose to not make a choice doesn't mean we should promolgate that or promote that. 15:49:54 q+ 15:50:25 selfissued: I did a blog post on the issue, I think multibase is an interop mistake and we should get rid of it, if we chose a prefix, we're half getting rid of it, we'll see how this works out. 15:50:31 ack dlongley 15:50:31 dlongley, you wanted to say that's not what i meant so i will clarify 15:51:30 q+ to ask if we have a compromise 15:52:18 dlongley: First to clarify, I didn't mean to imply that base64url encoding , the alphabet is what's being invented. We'd be inventing a new RDF type for a single base-encoding. Regarding failure to make a choice, depends on whether or not people feel things are equivalent. Community that built Multibase had their reasons. JWK allows different keys to be parameterized instead of saying one key format. We tried to re-use that work, and we've successfully 15:52:18 been interoping w / that technology. I would prefer us to not invent a new thing and cut it there because it seems like picking a prefix of U and putting it on there solves all the problems doesn't solve... we're building on other communities to greatest extend that we can profile those down, we should do that, instead of inventing something new. 15:52:24 ack manu 15:52:32 scribe+ 15:52:47 manu: There are a number of misconceptions around what multibase is including in that post that Mike wrote. 15:53:08 manu: I think we're talking about reinventing the wheel here, we're going to invent a single RDF type for a specific encoding of base64url-no-pad. 15:53:16 q+ 15:53:36 manu: That is hyper-specializing the encoding format when we don't need to do that when we can just put a `u` on the front and say VCs use that and that addresses the "not making a choice" thing that Mike is concerned about. 15:54:04 manu: Why would people choose different base encodings? There are legitimate reasons for doing so. Base32, for example, when encoding in a QR format, compresses way better than base64url. There are technical reasons for it. 15:54:19 manu: You can't think that all encodings work for all use cases. When you get into embedded and compression use cases, those encodings matter. 15:54:52 manu: There are totally valid reasons why people would want to use different base encodings and multibase understands that and that not every base encoding works everywhere. Base64 doesn't work in URLs. That's what Base64Url was created. 15:55:34 manu: There are many ways to send things and the ecosystem matters, it's not a failure to decide. It's understanding that the world is bigger than just us in this group and utilizing a way that lets you signal what base encoding is used so we can just use the multibase format across all the layers instead of having to reinvent the stuff at every layer. 15:55:49 manu: I appreciate you wrote that article but I think it's off base and it's not the reason multibase exists, it misses the point. 15:56:26 brent: It sounds like, maybe overly optimistic, it sounds like we're dancing around a middle ground that not everyone likes but we can live with, use base64url encoding, that's the choice we're making for multibase option for content integrity section. 15:56:36 scribe- 15:56:54 brent: feels like we're close there. 15:56:54 ack selfissued 15:57:31 the effect is larger than the invention of a tag itself 15:57:39 selfissued: Mainly going to respond to Dave's comment, defining base64url RDF type would be invention, perhaps, but it's not a very big invention, it's just tagging what this field uses. Creating the tag is perhaps an invention, but that's a good thing, it let's people know what choice was made. 15:57:43 I think a better title for that blog post would be "I Consider Multiformats Harmful" as it doesn't seem to incorporate anyone else's opinion 15:58:05 brent: please chime in in the PR, let's explore that middle ground. 15:58:30 zakim, who is here? 15:58:30 Present: brent, manu, JoeAndrieu, TallTed, selfissued, KDean, dlehn, dmitriz, bigbluehat, PL-ASU, hsano, smccown, DavidC, decentralgabe 15:58:32 On IRC I see DavidC, brent, smccown, bigbluehat, PL-ASU, dmitriz, hsano, selfissued, RRSAgent, Zakim, TallTed, manu, shigeya, dlehn, cel, ivan, dlongley, csarven, jyasskin, rbyers, 15:58:32 ... hadleybeeman, rhiaro 15:58:53 zakim, end the meeting 15:58:53 As of this point the attendees have been brent, manu, JoeAndrieu, TallTed, selfissued, KDean, dlehn, dmitriz, bigbluehat, PL-ASU, hsano, smccown, DavidC, decentralgabe 15:58:59 RRSAgent, please draft minutes 15:59:01 I have made the request to generate https://www.w3.org/2024/05/08-vcwg-minutes.html Zakim 15:59:07 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 15:59:07 Zakim has left #vcwg 15:59:38 rrsagent, bye 15:59:38 I see no action items