14:43:06 <RRSAgent> RRSAgent has joined #vcwg
14:43:10 <RRSAgent> logging to https://www.w3.org/2024/04/03-vcwg-irc
14:43:10 <Zakim> RRSAgent, make logs Public
14:43:11 <Zakim> please title this meeting ("meeting: ..."), ivan
14:43:26 <ivan> Meeting: Verifiable Credentials Working Group Telco
14:43:26 <ivan> Date: 2024-04-03
14:43:26 <ivan> Agenda: https://www.w3.org/events/meetings/3c7f5c66-5e34-468a-837e-2c2bf12de748/20240403T110000/
14:43:26 <ivan> chair: gabe
14:43:27 <ivan> ivan has changed the topic to: Meeting Agenda 2024-04-03: https://www.w3.org/events/meetings/3c7f5c66-5e34-468a-837e-2c2bf12de748/20240403T110000/
14:55:39 <TallTed> TallTed has joined #vcwg
14:58:50 <hsano> hsano has joined #vcwg
14:59:15 <decentralgabe> decentralgabe has joined #vcwg
14:59:46 <pauld_gs1> pauld_gs1 has joined #vcwg
14:59:48 <decentralgabe> present+
14:59:57 <pauld_gs1> present+
15:00:26 <hsano> present+
15:01:20 <TallTed> present+
15:01:39 <TallTed> RRSAgent, draft minutes
15:01:40 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/03-vcwg-minutes.html TallTed
15:01:47 <ivan> present+
15:01:52 <selfissued> selfissued has joined #vcwg
15:02:05 <selfissued> present+
15:02:11 <JoeAndrieu> JoeAndrieu has joined #vcwg
15:02:41 <ivan> present+ selfissued, hsano, manu, davidc, JoeAndrieu, dlongley, mahmoud
15:02:42 <JoeAndrieu> present+
15:02:44 <TallTed> s/Date: 2024-04-03//
15:02:44 <JoeAndrieu> scribe+
15:03:09 <JoeAndrieu> decentralgabe: anyone for introductions?
15:03:22 <manu> q+
15:03:22 <GregB> GregB has joined #vcwg
15:03:24 <JoeAndrieu> ... hearing none. work item status updates?
15:03:27 <ivan> present+ gregb
15:03:32 <ivan> q+
15:03:33 <GregB> present+
15:03:36 <decentralgabe> ack manu
15:03:51 <JoeAndrieu> manu: couple of updates. the bbs cryptosuite was approved for publication a few days ago
15:03:54 <ivan> q-
15:03:55 <TallTed> previous meeting: https://www.w3.org/2024/03/27-vcwg-minutes.html
15:03:55 <TallTed> next meeting: https://www.w3.org/2024/04/10-vcwg-minutes.html
15:03:59 <manu> BBS Cryptosuite approved for publication: https://github.com/w3c/transitions/issues/594
15:04:14 <JoeAndrieu> ... The editors have prepped for publication. Expected to go out tomorrow.
15:04:15 <TallTed> RRSAgent, draft minutes
15:04:16 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/03-vcwg-minutes.html TallTed
15:04:22 <DavidC> DavidC has joined #vcwg
15:04:28 <DavidC> present+
15:04:32 <JennieM> JennieM has joined #vcwg
15:04:35 <decentralgabe> Topic: Work Item Status Updates/PRs
15:04:39 <JoeAndrieu> ... Moving on to bitstring status list... The spec has 21 open issues. However, the vast majority have PRs or are "during CR" issues
15:04:43 <TallTed> ivan -- RRSAgent thought `Date` was an attendee
15:04:48 <JoeAndrieu> ... 5 we just to track horizontal reviews
15:04:51 <TallTed> s/ivan -- RRSAgent thought `Date` was an attendee//
15:04:59 <JoeAndrieu> ... Most issues are editorial.
15:05:10 <ivan> present+ JennieM
15:05:13 <JoeAndrieu> ... Privacy from PING and some on internationalization. We are addressing those.
15:05:25 <JoeAndrieu> ... There are a few that deserve a group discussions
15:05:34 <dlehn> present+
15:05:42 <JoeAndrieu> ... Open ended status lists
15:05:49 <JoeAndrieu> ... VC data model is moving along.
15:06:15 <JoeAndrieu> ... the long pole in that tent is Jeffrey Yaskin's editorial changes. They are fairly straightforward.
15:06:26 <JoeAndrieu> ... We do need to talk about four issues and PRs for bitstring status list.
15:06:37 <JoeAndrieu> ... Would you rather do that now or during PR review?
15:06:39 <ivan> present+ will
15:06:45 <JoeAndrieu> decentralgabe: Let's save for the PR review
15:07:19 <JoeAndrieu> manu: VC Data model update: we have five pull requests outstsanding. One needs some attention, especially David Chadwick's issuee PR.
15:07:33 <decentralgabe> q?
15:07:46 <JoeAndrieu> decentralgabe: Mike can you give an update on JOSE COSE?
15:08:04 <JoeAndrieu> selfissued: no before CR issues. no PRs outstanding. I think its time for CR.
15:08:18 <ivan> q+
15:08:20 <JoeAndrieu> ... Any guidance on what it will take to prepare for CR?
15:08:23 <decentralgabe> ack ivan
15:08:48 <JoeAndrieu> ivan: You have to generate a final version for the CR using one of two options
15:09:23 <JoeAndrieu> ... 1. modify respec header and put the publication status as "CR" and then generate it. In the sense that the upper right hand corner has a menu that can generate a static html.
15:09:30 <JoeAndrieu> .... essentially export a final version
15:09:47 <JoeAndrieu> .... What's typically done is you put that export in a separate folder in the repo, and I take it from there.
15:10:03 <JoeAndrieu> ... before that, however, you have to run throught he two publication tests at the W3C
15:10:15 <JoeAndrieu> ... one that looks at format. another that looks at links.
15:10:29 <JoeAndrieu> ... Doing that might highlight errors that need fixing.
15:10:36 <JoeAndrieu> ... This is something that normally editors do.
15:10:53 <JoeAndrieu> ... NOTE: in the header of the document, you'll also have to put a publication date
15:10:55 <manu> q+
15:11:12 <TallTed> RRSAgent, draft minutes
15:11:13 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/03-vcwg-minutes.html TallTed
15:11:19 <JoeAndrieu> selfissued: That makes sense conceptually, but I don't know concretely how to do it.
15:11:19 <JoeAndrieu> decentralgabe: No problem.
15:11:19 <decentralgabe> ack manu
15:11:29 <JoeAndrieu> manu: I'm also happy to help with the mechanics
15:11:44 <JoeAndrieu> decentralgabe: thanks.
15:11:57 <JoeAndrieu> ... for ivan do we send out something for wider review?
15:12:16 <JoeAndrieu> ... If I remember correctly we sent out emailing folks that a CR has been published
15:12:29 <JoeAndrieu> ivan: that's my job. We (as group) have to agree its ready for PR and have a resolution on that.
15:12:38 <JoeAndrieu> ... then I raise the administrative actions to move forward
15:12:59 <JoeAndrieu> ... Unfortunately, next week is an AC meeting in Hiroshima, so we should choose a date the week after at the earliest
15:13:04 <JoeAndrieu> ... and even that is tight.
15:13:06 <selfissued> Proposed resolution:  vc-jose-cose is ready to go to CR
15:13:12 <JoeAndrieu> ... The important thing is that we need a formal resolution
15:13:29 <JoeAndrieu> ivan: we should agree on a date and put it in the resolution
15:14:05 <JoeAndrieu> ... Publication is usually Tue or Thu. The earliest to be safe would be on the 16th. Let's try for the 18th of April
15:14:23 <manu> q+
15:14:27 <decentralgabe> ack manu
15:14:34 <JoeAndrieu> manu: I think we need exit criteria
15:14:38 <TallTed> resolution should include datestamped version of document, a la `https://www.w3.org/TR/2024/WD-vc-jose-cose-20240403/`
15:14:47 <JoeAndrieu> ... and we need to point to some kind of static version of the document
15:14:59 <JoeAndrieu> ivan: for the resolution, the static version isn't important, but we do need exit criteria
15:15:20 <JoeAndrieu> ... "every feature implemented by at least two implementations"
15:15:50 <JoeAndrieu> manu: people objected previously about date stamps
15:16:03 <JoeAndrieu> ivan: then lets fix resolution and formally go next week
15:16:17 <JoeAndrieu> ... because of the AC meeting, this won't slow anything down anyway
15:16:34 <JoeAndrieu> TallTed: draft resolution should be "draft proposal"
15:16:42 <JoeAndrieu> decentralgabe: makes sense.
15:16:56 <JoeAndrieu> ... move on to review of VC data model issues
15:17:13 <decentralgabe> Topic: VCDM issue and pr processing - https://github.com/w3c/vc-data-model/issues
15:17:43 <JoeAndrieu> decentralgabe: looking at issues, they all have assignees except 1360
15:17:46 <manu> q+
15:17:48 <decentralgabe> subtopic: https://github.com/w3c/vc-data-model/issues/1360
15:17:51 <decentralgabe> ack manu
15:18:03 <JoeAndrieu> manu: we deferred this to a future WG
15:18:09 <JoeAndrieu> decentralgabe: ok. no worries there.
15:18:16 <manu> q+ to switch to status list issues
15:18:17 <JoeAndrieu> ... current issues don't seem pressing. there are two PRs
15:18:22 <decentralgabe> ack manu
15:18:22 <Zakim> manu, you wanted to switch to status list issues
15:18:30 <JoeAndrieu> manu: can we turn to status list issues?
15:18:49 <decentralgabe> subtopic: https://github.com/w3c/vc-data-model/pull/1456
15:18:49 <JoeAndrieu> ... 1468 the definition of issuee is probably the one that needs discussion
15:18:58 <JoeAndrieu> decentralgabe: quickly on 1456, can we close this?
15:19:09 <DavidC> q+
15:19:18 <manu> q+ to note media types discussion continues at IETF.
15:19:35 <bigbluehat> bigbluehat has joined #vcwg
15:19:37 <decentralgabe> ack DavidC
15:19:55 <decentralgabe> subtopic: https://github.com/w3c/vc-data-model/pull/1468 definition of issuee
15:20:01 <JoeAndrieu> DavidC: Heads up. The PR exists for the issuee property, but Ted asked to move the discussion back to the issue
15:20:14 <JoeAndrieu> ... because we lose the comments in the PR when it is resolved.
15:20:17 <manu> q-
15:20:26 <JoeAndrieu> ... So, lets talk about the PR in the issue.
15:20:36 <JoeAndrieu> ivan: can you add the issue reference in the minutes?
15:20:43 <TallTed> q+ https://github.com/w3c/vc-data-model/issues/1467
15:20:47 <JoeAndrieu> DavidC: 1467
15:20:51 <TallTed> ack https://github.com/w3c/vc-data-model/issues/1467
15:20:52 <DavidC> issue #1467
15:21:12 <TallTed> link -- https://github.com/w3c/vc-data-model/issues/1467
15:21:12 <ivan> https://github.com/w3c/vc-data-model/issues/1467
15:21:19 <TallTed> q+
15:21:24 <manu> q+
15:21:29 <manu> q-
15:21:42 <JoeAndrieu> decentralgabe: might be useful to add a comment to the PR stating that
15:22:03 <decentralgabe> ack TallTed
15:22:04 <JoeAndrieu> DavidC: It's there, but it's buried in the middle.
15:22:27 <JoeAndrieu> TallTed: let's talk about in the issue, then we create a new PR, which likely would be different
15:22:38 <JoeAndrieu> decentralgabe: David would you like to discuss this?
15:22:52 <TallTed> s/create a new PR/implement it in the PR (or in a new PR)/
15:22:52 <decentralgabe> subtopic: https://github.com/w3c/vc-data-model/issues/1467 (issue) for discussing the issuee definition
15:22:58 <JoeAndrieu> DavidC: Yes. One of the issues, is does the issuer issue the credential directly or indirectly?
15:23:11 <JoeAndrieu> ... currently the text doesn't have anything one way or another
15:23:19 <JoeAndrieu> ... we should bring that up to the WG
15:23:38 <JoeAndrieu> ... irrespective of the definition of issuee, should we talk about direct/indirect issuees?
15:23:55 <manu> q+
15:23:56 <JoeAndrieu> TallTed: I think that's a different discussion. Should be a different issue and we can talk about it on its own
15:24:04 <decentralgabe> ack manu
15:24:30 <JoeAndrieu> manu: One of the concerns I have about adding terminology is that it becomes harder for people to talk about the system
15:24:38 <ivan> present+ bigbluehat
15:24:59 <ivan> q+
15:25:03 <JoeAndrieu> ... I agree there is a concept of an issuee, and I wouldn't oppose mentioning that in the spec, but changing the three-party model is problematic
15:25:11 <dlongley> q+ to say in my view, the current text doesn't have any issues wrt. "direct/indirect" language (or the absence of it), it's the potential introduction of "issuee" (depending on how we do it) that might cause trouble
15:25:14 <JoeAndrieu> ... sometimes the distinctions matter, sometimes not
15:25:25 <JoeAndrieu> q+ to say parallels to presenter and recipient
15:25:44 <DavidC> q+
15:25:44 <GregB> +1
15:25:45 <JoeAndrieu> ... if we add to many special terms it harms adoption because its harder to explain what we are doing
15:26:11 <JoeAndrieu> ... I don't think the juice is worth the squeeze
15:26:34 <JoeAndrieu> ... Its fine if we want to talk about issuees as subclass of holder, but creating a new term and injecting it throughout is problematic.
15:26:35 <dlongley> +1 to manu
15:26:39 <decentralgabe> ack ivan
15:26:50 <JoeAndrieu> ivan: I feel uneasy about the whole discussion.
15:27:08 <JoeAndrieu> ... As far as I can see, the term and possible changes are in a non-normative section, but we are in CR.
15:27:23 <JoeAndrieu> ... we are not supposed to come up with new features without a good technical reason
15:27:56 <JoeAndrieu> decentralgabe: I see a label of CR1
15:28:02 <JoeAndrieu> ... do you suggest we close this, Ivan?
15:28:33 <JoeAndrieu> ivan: non-normative language is fine, but normative language can be in a second CR but still needs a good reason. But I'm not the technical expert.
15:28:50 <JoeAndrieu> decentralgabe: I think with the new issue, we might benefit from seeing where the discussion might lead.
15:29:00 <decentralgabe> ack dlongley
15:29:00 <Zakim> dlongley, you wanted to say in my view, the current text doesn't have any issues wrt. "direct/indirect" language (or the absence of it), it's the potential introduction of "issuee"
15:29:03 <Zakim> ... (depending on how we do it) that might cause trouble
15:29:27 <JoeAndrieu> dlongley: I don't think the current text has anyissues wrt direct/indirect language. It was the potential introduction of issuee where that created potential problems.
15:29:44 <JoeAndrieu> ... the current text is not prescriptive about those things, so we should be careful if we add that
15:30:06 <JoeAndrieu> ... I wouldn't have an issue with talking about special cases, subclasses, etc. but probably not a good idea to modify the generic core text
15:30:20 <decentralgabe> ack JoeAndrieu
15:30:20 <Zakim> JoeAndrieu, you wanted to say parallels to presenter and recipient
15:30:23 <decentralgabe> scribe+
15:31:13 <dlongley> +1 to avoid confusing / changing the primary roles and language around it
15:31:33 <decentralgabe> JoeAndrieu: not a big fan of introducing issuee in a way that confuses the three primary roles...we talk about it at a highlevel and also subclassing. we know it is the holder who is presenting. we can talk about these distinctions (when the holder receives, presents)...
15:31:43 <decentralgabe> ... our architecture we need to retain given the process
15:31:45 <dlongley> +1 to Joe
15:31:46 <decentralgabe> scribe
15:31:49 <decentralgabe> scribe-
15:31:51 <decentralgabe> ack DavidC
15:32:00 <JoeAndrieu> DavidC: As a result, I already removed it from the diagram.
15:32:13 <JoeAndrieu> .... Also, agreed that the changes are non normative.
15:32:30 <JoeAndrieu> ... The other thing is that its there because the role does exist. It's always been there.
15:32:58 <JoeAndrieu> ... because we've not mentioned it. I'd be happy if we don't make it a formal defintion, but say somewhere that the issuee is a subclass of holder.
15:33:09 <JoeAndrieu> ... I think the term should be in the VCDM since it is used elsewhere.
15:33:27 <manu> q+
15:33:28 <JoeAndrieu> decentralgabe: Thanks, David. Everyone, please chime in on the issue
15:33:37 <decentralgabe> Topic: https://github.com/w3c/vc-bitstring-status-list
15:33:38 <JoeAndrieu> ... Let's move to bitstring status list
15:33:39 <decentralgabe> ack manu
15:33:43 <JoeAndrieu> manu: there are two brief updates
15:33:47 <manu> subtopic: https://github.com/w3c/vc-bitstring-status-list/issues/136
15:33:53 <JoeAndrieu> ... #136
15:34:12 <JoeAndrieu> ... Just a heads up. Spoke with Mahmoud yesterday about this localize status message.
15:34:22 <JoeAndrieu> ... I'm going to work with Mahmoud to address this.
15:34:29 <JoeAndrieu> ... I'm confident we can address this
15:34:41 <manu> subtopic: https://github.com/w3c/vc-bitstring-status-list/pull/160
15:35:11 <JoeAndrieu> ... The other one is a general heads up that there are PRs that are being raised both in the BBS crypto suite and the Bitstring status list for preventing unnecesary correlation.
15:35:19 <JoeAndrieu> ... This maybe belong in the VCDM
15:35:45 <JoeAndrieu> ... Now that we do have a ZKP proposal in the CR phase, we may want to start moving some of this generalized advice to the base specification
15:36:00 <JoeAndrieu> ... The advice applies to any securing mechanism that uses unlinkable or selective disclosure
15:36:44 <JoeAndrieu> decentralgabe: Manu, would you like to open an issue and tag VC-JOSE-COSE editors to sync up on language
15:36:56 <ivan> q+
15:36:59 <JoeAndrieu> manu: I think that'll happen automatically when we raise the PR. So I think we can go straight there.
15:37:02 <decentralgabe> ack ivan
15:37:20 <ivan> q-
15:37:26 <manu> subtopic: https://github.com/w3c/vc-bitstring-status-list/pull/155
15:37:27 <JoeAndrieu> manu: three more issues for bitstring
15:37:47 <JoeAndrieu> ... there was a request for talking about decoy values. This was requested by PING
15:38:12 <JoeAndrieu> ... based on the discussion in that issue, I think we are coming to the conclusion that decoy values undermine privacy
15:38:20 <JoeAndrieu> ... but I'd like to get feedback from the group
15:38:38 <smccown> smccown has joined #vcwg
15:38:42 <JoeAndrieu> ... Consider a list with 100,000 entries. Current guidance is to assign that randomly.
15:38:54 <JoeAndrieu> ... In that way, any observers won't gain insight into the population
15:39:21 <JoeAndrieu> ... but if there are decoys, that reduces the group privacy dynamic
15:39:50 <JoeAndrieu> ... this isn't saying decoy values are bad, but in vc status list it undermines randomizing
15:39:58 <JoeAndrieu> q+
15:40:08 <manu> scribe+
15:40:11 <decentralgabe> ack JoeAndrieu
15:40:23 <manu> JoeAndrieu: I'll look at the issue and try and understand it and provide feedback
15:40:39 <dlongley> +1 to getting more feedback on that PR
15:40:56 <JoeAndrieu> manu: one last issue, 151
15:40:59 <manu> subtopic: https://github.com/w3c/vc-bitstring-status-list/issues/151
15:41:29 <JoeAndrieu> ... In the bistring status list, we have a feature that allows open-ended status messages, used for supply chain stuff
15:41:41 <JoeAndrieu> ... so you can have multiple states for a given VC.
15:42:13 <JoeAndrieu> ... When PING was doing their review, they said "it looks like the issuer can change the amount of information that is published without notifying the subject"
15:42:57 <JoeAndrieu> ... This will lead to a privacy violation where on Day 1 the messages are "pending" and "cancelled" but on Day 2 it becomes "cancelled due to criminal activity"
15:43:31 <JoeAndrieu> ... Discussion: is it ok to keep this feature in there. It is marked as "at risk"
15:43:37 <ivan> present+ identitywoman
15:43:45 <JoeAndrieu> ... or would people would object to CR because the feature isn't useful
15:43:59 <ivan> present+ mccown
15:44:01 <JoeAndrieu> decentralgabe: I noticed Brent is assigned.
15:44:18 <JoeAndrieu> manu: brent added some comments. He's reppng measure.io. They were an advocate of that feature.
15:44:21 <JoeAndrieu> q+
15:44:23 <Identitywoman> Identitywoman has joined #vcwg
15:44:26 <manu> scribe+
15:44:29 <Identitywoman> present+
15:44:30 <decentralgabe> ack JoeAndrieu
15:45:19 <manu> JoeAndrieu: Manu summed up my concerns well. It becomes an avenue for arbitrary content being published w/o the subject being involved. Brent's argument was that we have same privacy as VCs. I disagree because holder is not in the loop (where they are with wrt. VCs).
15:45:36 <dlongley> +1 to Joe
15:45:50 <decentralgabe> q+
15:45:51 <manu> JoeAndrieu: If we had a shared expectation where the user could know w/ shared states, if future version needs new state, individual could use new VC with that knowledge. What we have is a publication architecture that undermines privacy considerations put into VCs.
15:45:53 <manu> q+
15:45:53 <pauld_gs1> q+
15:45:58 <manu> q- later
15:46:01 <manu> scribe-
15:46:03 <DavidC> +1 to JoeAndrieu
15:46:14 <decentralgabe> ack decentralgabe
15:46:17 <JoeAndrieu> decentralgabe: with chair hat off, can we avoid this problem by noting the status message in the credential itself
15:46:23 <manu> Yes, +1 to what decentralgabe that's what I was on the queue to suggest as well.
15:46:25 <mkhraisha> mkhraisha has joined #vcwg
15:46:27 <manu> scribe+
15:46:50 <manu> JoeAndrieu: Instead of having a multi-bit status list you have multiple entries... status list should be of a constrained set if it's going to be of a set.
15:46:51 <dlongley> +1 to Joe again :)
15:46:55 <decentralgabe> ack pauld_gs
15:47:27 <JoeAndrieu> pauld_gs1: within these status lists, there is nothing from preventing an issuer from adding additional information
15:47:32 <decentralgabe> ack manu
15:48:11 <JoeAndrieu> manu: two things. If this is the concern, that privacy characteristics change after the fact. Then locking the states into the credential itself, then the holder knows the deal.
15:48:16 <mkhraisha> q+
15:48:18 <JoeAndrieu> ... this does make things more complicated.
15:48:34 <JoeAndrieu> ... if we don't make that change, then it is true that multi-status allows leakage after the fact
15:48:42 <JoeAndrieu> ... which is likely going to lead to objections
15:49:19 <JoeAndrieu> ... To Paul's point, what we write in the spec with affect how people deploy, so while it is true that issuers can add anything they want, but that is very different from the WG saying this is how you can do.
15:49:21 <dlongley> +1 to Manu, i think Joe's point is that we don't need to bless or approve of a particular approach in the standard, we can even speak against it (but we don't control behavior)
15:49:47 <JoeAndrieu> ... instead we can highlight that there is a better way. we can have implementation guidance that explains this privacy risk so that issuers can apply best practices
15:50:06 <JoeAndrieu> ... we would be establishing clear guidance
15:50:12 <decentralgabe> ack mkhraisha
15:50:13 <dlongley> a major point of VCs is not to repeat the status quo where a user communicates to a verifier some way for them to then ask an issuer for whatever they want.
15:50:31 <JoeAndrieu> mkhraisha: I don't think it would be seen negatively to commit to a static list of states.
15:50:42 <JoeAndrieu> ... Let me talk with the rest of the traceability folks, but I think it can work
15:50:46 <ivan> q=
15:50:49 <ivan> q+
15:50:53 <decentralgabe> ack ivan
15:50:57 <JoeAndrieu> decentralgabe: That's it for the agenda
15:51:11 <JoeAndrieu> ivan: there is one PR #159 which has to be done before CR
15:51:11 <ivan> subtopic: https://github.com/w3c/vc-bitstring-status-list/pull/159
15:51:32 <JoeAndrieu> ... this is related to mechanics of the repository
15:51:55 <manu> scribe-
15:51:55 <JoeAndrieu> ... the vocab is wrong, we have to change the context file, ... there are some changes we need to get in before CR
15:52:10 <manu> +1 to making the changes Ivan is suggesting :)
15:52:16 <JoeAndrieu> decentralgabe: not to folks, please review 159
15:52:22 <manu> You have 4 positive reviews now, Ivan. :)
15:52:39 <JoeAndrieu> decentralgabe: that wraps up the schedule. any other items
15:52:56 <JoeAndrieu> ... that's a wrap. Please review the issues, especiall on bitstring status list and VCDM
15:53:09 <JoeAndrieu> ... next week VC-JOSE-COSE considered for CR
15:53:30 <ivan> rrsagent, draft minutes
15:53:32 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/03-vcwg-minutes.html ivan
15:56:07 <gkellogg> gkellogg has joined #vcwg
15:57:22 <TallTed> s/not to folks/note to folks/
15:57:25 <TallTed> RRSAgent, draft minutes
15:57:27 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/03-vcwg-minutes.html TallTed
18:40:26 <Zakim> Zakim has left #vcwg
18:41:37 <gkellogg> gkellogg has joined #vcwg
19:10:07 <steele> steele has joined #vcwg
19:38:24 <gkellogg> gkellogg has joined #vcwg
19:55:01 <gkellogg> gkellogg has joined #vcwg
19:58:20 <gkellogg> gkellogg has joined #vcwg
20:28:20 <gkellogg> gkellogg has joined #vcwg
20:45:14 <gkellogg> gkellogg has joined #vcwg
21:12:30 <gkellogg> gkellogg has joined #vcwg
21:29:51 <gkellogg> gkellogg has joined #vcwg
21:46:56 <gkellogg> gkellogg has joined #vcwg
21:57:25 <gkellogg> gkellogg has joined #vcwg
22:11:09 <steele> steele has joined #vcwg
22:17:45 <gkellogg> gkellogg has joined #vcwg
22:48:28 <gkellogg> gkellogg has joined #vcwg
23:07:10 <gkellogg> gkellogg has joined #vcwg
23:58:51 <gkellogg> gkellogg has joined #vcwg