Meeting minutes
<ivan> regrets{
Task Forces update
phila: task force check ins
… posted about the doc. its getting responses
phila: anyone else from task forces?
phila: moving on
Housekeeping
phila: housekeeping. Several documents we are maintaining as a group, not assigned to any particular task force
CID
<phila> https://
phila: the issue list for CID doc, there are 17 open issues and two PRs
… Joe added on a couple months ago.
… Do we care? Do we have the capacity to handle that?
phila: You raised issues in the recent past, can you say your views of CID?
JoeAndrieu: Good question.
phila: the only way, IMO, for that to move forward is new editors. Mike Jones, Drummond, Christopher Allen, Markus, the people involved aren't as involved any more.
… unless we get someone to step up, I'm not sure how we handle it.
… I don't think we can formally deprecate, but that doesn't mean it has to be high priority
… For this one, CID, we recognize its important. I wish we had time to do it, but we haven't.
… So until we have an editor or otherwise it becomes important, it'll just sit there.
ivan: are there any issues that point to a bug?
… our hands are tied a bit
phila: there is one issue, #166
<phila> Issue #166 w3c/
phila: That one is marked as possible errata. Raised by possible errata
<dmitriz> my question would be -- are there ANY implementations of CIDs in VC libraries currently? like, do we know of any software that issues or verifies CIDs?
phila: There are a lot listed as class 2 and class 3
… so pchampin has raised a couple errors
ivan: if it's class 2 we can handle it, but someone needs to
<dlongley> CID is now a base document for DIDs, IIRC.
ivan: I'm surprised. There were some alternatives in those digests. The editing process was doing it automatically.
dlongley: I'd have to look into that more closely
phila: seems like this is important
dlongley: I'm trying to remember the context. We moved a number of things into the CID, then started relying on CID, specifically for DIDs, as a profile of CID
… So I do think maintenance is important.
<Zakim> JoeAndrieu, you wanted to suggest transfer
JoeAndrieu: I agree with Dave Longley, we did bake this in -- we did have the DID spec depend on CIDs. I think the right thing is to figure out how to transfer it. That might depend on a future rechartering. It feels like the folks working on the spec need it to be maintained.
phila: I thought about the DID WG, but it is also resource constrained
dlongley: there are some definitions in CID that are used in Data Integrity
… not clear if its any easier for either DIDWG or VCWG to manage that. Maybe what we should need is a third group focused on data integrity
phila: seems unfortunate.
TallTed: part of the challenge is how these documents came to be.
… we initiated some of these in this group. We initiated the CID document because at that time the DIDWG didn't allow it.
… And we realized we needed to revise. But the hand off didn't happen. That's what I recall.
… We originated stuff for other groups that couldn't take it on.
ivan: Ted is correct, but incomplete.
… one of the problems was that there was a normative dependency suggested, which was opposed.
<TallTed> +1 ivan's recollection of JOSE-COSE complicating matters is correct
ivan: so we created CIDs to avoid this (JOSE COSE) dependency on Data Integrity
… So... merging things into DID document might lead to ugly discussions that will take us back to that political debate from years ago.
… So, the CID document probable needs to stay with us.
phila: We have a problem, then, that needs to be resolved
… First question: does anybody have the time to look that those issues and consider putting their hand up as editor, noting that we can only make Class 1 and Class 2 changes.
… only maintenance changes. Not deriving a whole new set of things. So, a relatively small ask.
… If anyone has the time & interest to learn how to edit a spec, this might be a good fit.
… Everyone in the group with experience is happy to help. This could be a good starter editor role.
… Now would be a great time to raise your hand.
michaelshea: I'm interested, but I'll need guidance on what's the right answer to the issues
phila: You will get plenty of feedback and help
michaelshea: I have not edited before
ivan: For Michael, I repeat a question: Benjamin, isn't it true that the hash digest values in documents were automatically created by some magic, rather than manual?
… Because there is an incorrect value. So can we figured out why?
bigbluehat: I'm not the one to generate those, but I'm happy to research and figure it out.
… This is in the CID spec?
phila: To recap: the CID document is one that we have for legacy reasons. But nobody is chartered to look after it.
… It exists because of a bunch of compromises, but its on our plate.
… No task force is focused on it
… But is seems other documents need to refer to it. So we should look after it, as much as our charter allows (class 1 and class 2)
… We are greatful for Michael Shea to take a look
… This might become his first editor role
ivan: I was wondering, are the multikeys part of this spec or are they just examples?
… one thing that came up in DI Task force, related to multibase.
… if we need multi-key definition added, that's a bit more work.
dlongley: yes, the multikey is in the CID spec
… that should just be a few additions to a table
… Thats one of many things that are in the CID spec and relied on elsewhere
phila: Dave, would you consider those Class 1/2 change or are we straying into Class 3.
<ivan> +1 dlongley
dlongley: it's true that there are new things in our new specs. it's just a question of where they go.
phila: is the DID WG expecting to recharter?
… ok, That's CID. That was one of seven that the group is meant to be maintaining
Bit String Status List
phila: The next topic: bitstring status list
<phila> https://
phila: This is important. It went to rec not that long ago. Nine open issues.
… One is broken links. Manu opened one. A bunch of what look like minor things. Except for Kyle Den Hartogs from last spring
… So what we must do? Can do? What is reasonable to do?
… Mike Prorock and Mahmoud are no longer active.
… Dave and Manu are, but they have a lot of work on their plate.
… Dave, does that issue list fill you with dread?
dlongley: It doesn't fill me with dread, but I also don't have the couple of hours to take a review on
… Looks like mostly editorial.
… Kyle's suggestion would be a bigger lift. We'd need someone to step up for that.
… Doesn't look horrible, just clarifications and clean up.
phila: I can't see anything jumping out saying "You need to fix this right now!"
… tempted to tag them all with next iteration
… Does anyone disagree that this needs immediate attention?
dlongley: I don't think there are any emergencies
<JoeAndrieu> +1 to no emergencies right now
phila: Is there an unofficial way to say "we're a bit busy, but we aren't actively working on this spec"
… can we put something like that on the ReadMe
ivan: If that's the reality, there is no shame to saying that we are focused on other things
phila: Thing is, if someone does find something serious, we can act on it.
… but if its something that can wait, we're going to wait.
… So, I'll look at the issues in more depth and triage, with a note on each explaining where we are at.
VCDM 2.1
phila: The big one is VCDM 2.1
… This is something we're going to have to think about.
… Ten open issues and one pull request. Some issues are Class 4. Some class 2.
… We published an FPWD
… had some discussion about deprecating DigestSRI
ivan: this is a place where the class story is irrelevant.
… this will have to go through the normal approval process
phila: the editors here are Manu, Ted, and Ivan.
… active members of the group. There are active issues. and An active PR (the DigestSRI deprecation)
phila: Ted how are you on this?
TallTed: My listing there is more work that has been done than prospective edits in the future
phila: Ivan?
ivan: Same problem. My hands are full. But I know the Manu is overrun, but this is a case where Manu has to run that.
… He's probably the only guy who has a view of the entire document to manage this.
… Ted did a bunch of editorial changes. I did a bunch in specific sections. But this is where Manu has to speak up
… That's the document where I would be uneasy touching
… This isn't going to go away. This is 2.1.
dlongley: the other comment I want to make, the document is largely complete and designed to be extensible.
… The design is to put specifics in other documents.
… So that's a pressure release valve.
ivan: To take renderMethod and confidenceMethod, we have an open issue. IMO, those things should be removed from VCDM altogether.
… There are things that we can take out.
<dlongley> +1 for using the extension model and simplify the VCDM
<JoeAndrieu> +1 to lean into extensions
phila: this is one where we need Manu's time
<pdl-ASU> +1 for taking out the things active TFs are doing good work on.
phila: I'm sure he would welcome additional help.
… If you'd like to be a co-editor, this is another opportunity for folks to volunteer
Implementation Guide
phila: The implementation guide. #9 on the agenda today
<phila> w3c/
phila: This is one that currently has 17 open issues. These are historic.
… Going back to previous charter. PRs that exist. One from JonnyCrunch, from 7 years ago tomorrow.
… Clearly this is not under active development. but we refer to this document in the VCDM
… And at least two from this year. Going back to '23
… So, who on earth is going to have time to spend on this.
<dmitriz> how important is it to the group?
phila: Original editor: Andre Sambra
<JoeAndrieu> s/Sandberg/Sambra
phila: we need someone to write the book about VCs
phila: no one is going to look at this any time now
… I'm just going to add a note in the read me saying that this is not under active development
… I'm currently in a middle of creating a Word Doc version of VCDM 2 that will go to ISO.
… I noticed lots of references within VCDM2 that point to implementation guide.
… I'm not saying we have time to do it, but is not unimportant. People rely on implementation guides.
… It is needed.
… So we might have to come back to this, after we finish the work we are actively working on now.
… but maybe later this calendar year, once we get some of our specs to CR
ivan: I am busy doing a 1.1 version of the overview, that folds in all the documents that we've been working on
… maybe readable in a few weeks
VCDM test suite
phila: That currently has a number of open issues. 17 open issues.
… some go back a couple years. Newest is less than a year old.
bigbluehat: A lot what's going on now, in terms of PRs, is dealing with the bitrot that happens.
… upgrading dependencies.
… Related is the canivc dashboard.
… That is gradually moving to W3C as a new open source project.
… That is a predominant interface for making sure that you pass and promoting that you pass.
bigbluehat: The specs have driven the test suites. The hope is that coupling the dashboard with canivc would let us keep an eye on this whole set of things
… The state of play for July 2026 is that we are prepping the house for that migration.
… Trying to get all the dependencies are up to snuff for when new tests come in.
… The bigger piece of work is comparing the new spec to see what tests might need to be added/removed/updated.
… Hopefully with the dashboard moving to W3C will encourage others to contribute
… It a useful thing and we'd love people to join us.
phila: Is *the* test suite aware of what's happening with renderMethod, confidenceMethod, etc?
bigbluehat: I kind of feel they have two options. All TR specs must have two implementers and the test suite is how we prove that.
… So where those tests live is not subjective. Must be a w3c repo, but a test suite can address multiple specs. But how we mix it in might become cumbersome.
… We have tried to make the core of the test suite a template so you can make new test suites simply
… Other task force specs like rendermethod is radically different
ivan: no problem with the same test suite for multiple specs
phila: thanks everyone.