Meeting minutes
<brent> date: 2025-08-13
Brent: Now monthly meeting, coming back from hibernation. Now in maintenance mode with a raft of recommendations.
… Need to talk about TPAC as we have time booked during that week then dive straight into issues.
… Any other items/
<Zakim> manu, you wanted to provide updates on incubated items.
Brent: I don't think our work mode is going to take 10 minutes.
work mode
Brent: If I forget to talk about it before TPAC, feel free to publicly shame me.
… Chair hat on, this maintenance group will only make progress and move forward if people are actively engaged and not relying on workgroups to spur them to action.
… We are of necessity needing to operate as a duocracy, and we need to keep that in mind as we do our triage. I think a monthly meeting is probably sufficient as it will allow us to move things forward.
… And we can leave open the conversation of do we need to meet more often.
manu: +1 to that plan, certainly in the beginning.I will continue to volunteer to edit the minor releases of the specs I was editor on previously if the group is OK with that.
… I would love more help around some of the issues and PRs.
… I am wondering what our merge criteria is going to be. I'm fine if we review and merge if there is consensus before the next weekend. As we're meeting less often, we can extend the merge window from one week to two.
… The other thing we need to pay attention to is that because we're in maintenance mode there are some caveats that we can only make class 1-3 changes, no class 4 changes unless we're fixing something serious.
… Happy to raise PRs, +1 to others willing to raise PRs.
Brent: Looking for folks in the group to let their opinions be known.
KevinDean: +1 to two-week merge window.
JoeAndrieu: I want to align with the cadence of meetings. I want to suggest if you miss something in a meeting that you need a longer merge window, so +1 to a longer merge window.
<dlongley> +1 two-week merge window seems fine to me, if something comes up at a meeting we can revise afterwards (probably) if really needed.
Brent: The way I imagine it working, if we discuss an issue in a meeting, then we use consensus as a basis for a PR. In an issue we haven't discussed in a meeting, it could be appropriate to create a PR and discuss in the next meeting.
<manu> +1 to what Brent just suggested.
<JoeAndrieu> +1 to the meeting alignment
<dlongley> brent's suggestion also sounds fine to me and happy to go with it and we can change that if we need to
Brent: I think the two-week merge window should be at either end of a scheduled meeting.
manu: +1 to that. It sounds good, and it addresses Joe's concern.
… In theory, there's little damage we can do this time around as we can't make major changes.
Brent: I'm not hearing anyone out of alignment, so let's proceed in that direction.
… Anything else about the work mode?
Incubated Items Update
manu: Over the summer, the CCG has been meeting to incubate some items that some folks want to move into the VCWG.
<manu> Incubation link: w3c-ccg/
manu: This is an issue that's tracking all the incubation items. There are multiple items. There's the VC-API group that's been meeting for a while now. There's the data integrity group and the ???.
… The groups have listed items to be promoted to VCWG. Some of them are in scope for the current charter, some of them are out of scope, and we may need to recharter to deal with them.
… The groups continue to refine scope and work on language, but it needs broader group refinement and feedback.
… There are some specifications that are not quite ready yet, where the group needs to do more work before moving over.
… I think we should have a discussion about expectations. We really need to set priorities on these specs.
Brent: I think a necessary indication of something from the CCG being done with incubation is that CCG has published it.
… I think publishing is a necessary step before we can take it on.
manu: +1 to that.
… I think we were holding back doing the publication until we got the nod from the CCG that they're ready.
… Maybe they want to push these out ahead of other specs, maybe further incubation could be done in parallel.
manu: +1 to the idea that we need to publish them as community group recommendations before we take them on.
<dlongley> +1 to publish final community group specs when the VCWG is ready to accept them
<dlongley> +1 people in VCWG have to say and be ready to take on the work
Brent: Another thing that I think is necessary for us to accept the specifications for incubation is a critical mass of people in the VCWG willing to take it on. We're looking for people who are willing to be editors and contributors.
… I welcome moving things forward but I don't want to get into a situation where we've taken on a lot of stuff and don't have anyone to do it.
manu: I agree, we can't move stuff forward unless people volunteer to do it. The only concern I have with rechartering is that it takes a long time.
… I wonder if we can say that we can take these incubation items on if there's interest. I don't want to recharter to take on two items then have to recharter next year with others.
… That said, there's not a super downside except people committing to doing the work and not doing it.
<dlongley> +1 to manu, good to list the specific optional items, even if we don't get to them
manu: For example, our last charter said we would work on a crypto suite if we get around to it, and we didn't. That doesn't count as a mark against us.
Brent: I think we're willing to recharter, but we don't want to recharter.
… We should leave it until there are items that absolutely require it.
… Because our current charter does allow us to work on the confidence method and the render method, we should encourage the CCG to publish them so we can work on them.
Brent: The DID WG and VC-API WGs are going strong, and there's only so much people can do.
manu: Two things. I would like us to prioritize specs as a group rather than work on them in a serial order. Last time around we had so much going on in parallel. It would be nice to see if we can focus and crank through the issues. I'd like to understand as a working group what the top three things that we want to get done are.
… There may be other specs that are a lot more work, and maybe the group wants to focus on those. I want us to have a prioritization discussion.
… Let's pull in the things that are in our charter first.
<dlongley> +1 to floating the next charter and one reason to recharter earlier is to allow the group to more freely prioritize from a fuller list of specs
manu: We're going to get through those, but it's going to take months to do so. I would like for us to flow to the next charter as well and get feedback so that we can be ready with it when those items come up in the queue.
Brent: I agree with that. To that end, beginning with prioritization, is it right to discuss in the meeting or raise issues in the GitHub repo?
manu: I think that's a VCWG decision, not a CCG decision. We can also raise prioritization in the chartering repository. I think you can raise issues on specific charters.
<brent> https://
<manu> +1 to use that repo ^
Brent: I think this is where we should raise an issue and capture the conversation.
… We need to have the prioritization conversation first.
… That's the wrong repo. I'll find the right one.
… I need to talk to Ivan to find out why that repo is archived.
<manu> w3c/
manu: I think that's the right repo.
Brent: That's the one.
… I need to talk to Ivan, because I think this is the base repository for our work.
… Do we want to raise new issues or transfer the existing ones?
manu: We should raise new ones.
ACTION: brent open an issue
TPAC
Brent: We have a meeting scheduled for Friday morning in Kobe. At this point I'm anticipating having charter conversations.
… Also possibly having a larger issue or two that we need to work through. I'm open to whatever else people would like to discuss.
Brent: Do folks agree that we'll have enough to talk about?
manu: +1 that we'll have enough to meet on.
… We will need to remember that we're in maintenance mode and there will be plenty to talk about in a one-day meeting.
… There's lots on confidence and render method, data model, and charter discussions.
… We could also do a round robin on deployments.
… There's always something interesting to hear about.
Brent: As we get closer, I'll have a draft agenda that people can contribute to.
Issues - VCDM
<brent> https://
<Zakim> manu, you wanted to note something we need to do across all specs.
Brent: The goal here is to know if this is something the group can work on or not.
manu: Now that we're in the maintenance mode, we need to do the work of publishing the interim versions. It's administrative stuff that editors can do in the background, but it can take some time.
Brent: We're meeting as a group to maintain these specs and we anticipate having to publish them.
<Zakim> JoeAndrieu, you wanted to check in about use cases and echidna
Brent: I think FPWD needs to be a resolution by the group. We can have a working draft before we have a first published working draft.
VC Use Cases
w3c/vc-use-cases#161
<JoeAndrieu> w3c/
JoeAndrieu: I want to check in regarding echidna in the use cases
document.
… I want to be sure that if we need help from the group we have a chance to chat about it.
Brent: I think we should talk about this, but I want to setup a topic for it.
JoeAndrieu: KevinDean has been deepest into the code. Apparently none of the browsers or headless engines that we've checked correctly save the embedded namespace when dealing with the <br> tags.
… We're running into problems with validator.nu that is generating errors.
KevinDean: I've been through multiple layers of this with mermaid, respec-mermaid, fixing the br tag gets undone by whatever render engine is being used. That said, I have a full workflow set up, but need to get back to error that triggered the whole discussion, error logs are gone, need to create new PR to re-run everything.
KevinDean: That's on my plate at the moment.
brent: Months of effort have gone into trying to fix this problem, seems to be a respec problem, do we want to move to bikeshed?
KevinDean: I don't know, will have a better answer once I'm able to do end-to-end, most recent tests was accepted, br tag w/o slash, don't know what's different, need to re-run everything to see where things stand to decide on path forward.
manu: Switching to Bikeshed won't fix this particular problem. It's not a ReSpec bug, it's a problem mixing XML and HTML. Moving to Bikeshed would cost us the ability to use Mermaid directly in the specification.
… I expect it to be a problem given the incompatibilities between HTML5 and XHTML.
Brent: Kevin and Joe, see Manu as a resource to help with this.
… Let me know what you need as soon as you need it so we can continue to move this forward.
… Anything else on this or the use cases before we jump back into the data model?
Issues - VCDM
<brent> https://
w3c/vc-data-model#1480
Brent: We're going to start by looking at 1480.
… Example use of render method. I think that this is clearly editorial and can be worked on by the group.
… I suggest that we create a label for things we're going to work on for this stretch of the group.
manu: We need labels to mark changes as class 1, 2, 3 so we know what we're working on and what change it is.
<dlongley> "class 1-3" could be a single tag :)
<dlongley> or we could be super precise now
manu: Class 1 is e.g., a spelling error, class 2 is e.g., a new example, class 3 is e.g., fixing a feature, class 4 is e.g., adding a feature.
… If it's an open issue, we're working on it one way or another. Just having a class label and being open tells us we're working on it.
Brent: I will remove "defer" and add "class 2".
w3c/vc-data-model#1467
<dlongley> +1 class 4
Brent: I think this is clearly a class 4 change and something we need to defer.
w3c/vc-data-model#1360
Brent: Add mechanism to cryptographically secure non-credential VP properties (contexts etc)
… This also feels class 4.
manu: You could probably argue that it's a new feature as we don't have this currently, I don't think, so it's a class 4.
Brent: I'll add class 4 label.
w3c/vc-data-model#1583
Brent: Structuring the security considerations section
… We've got feedback from the security group about how they would prefer security considerations to be structured.
… I think this is in scope for what we want to do.
JoeAndrieu: I don't know what class this is, I don't think it's class 4, because we're not changing what it needs to be conformant.
… We need to discuss with Simone when he is expecting specifications to include a threat model.
… We already have the VCDM, so we have some leeway, and we're not going to create a threat model for everything that is out there.
Brent: We can add this as a topic for TPAC.
… There's nothing normative in there.
https://
dlongley: I am thinking this is class 3 or less.
Brent: I'm making it class 2.
w3c/vc-data-model#1591
Brent: Incorrect Statement in Section 3.1
… It sounds like an editorial change so unless folks disagree I'm going to add class 2.
… If anyone would like to raise a PR for this one, that would be great.
w3c/vc-data-model#1592
Brent: multiple comments on the introduction section
<dlongley> +1 to class 2
Brent: Basically a review of the introduction.
… Should be class 2.
w3c/vc-data-model#1593
Brent: Add SD-JWT-VC to Ecosystem Compatibility section
<JoeAndrieu> FYI, I just closed #1599
Brent: We had a conversation about this, believe it's a class 2 as it's a list of examples.