Meeting minutes
<Ivan Herman> Date: 2025-09-10
Brent Zundel: welcome everyone, this is the monthly VC WG call (in maintenance mode)
… we'll take a look at some issues, hopefully make some resolutions
… any changes/additions to the agenda?
SD-JWT media types update
Brent Zundel: ok, let's jump into SD-JWT Media Types
Brent Zundel: just to give an update - we've requested registration of application/vc+sd-jwt (and vp+...) in IANA
… the vc+ application is proceeding (Mike Jones had a couple of questions), the vp+ media type has been contested
… Mike Jones and I have been in conversation with the person who has contested it
… there is slight potential that this can lead to the SDO equivalent of an international incident
… we're waiting on word with the designated expert at the IETF
Manu Sporny: I love how just about everything we do results in that :)
… I saw the objector's response. I think they said there was no use cases for sd-jwt for presentations?
… I think the reason we asked for registration before -- one, it's helpful if you're using a certain cryptographic envelope format to be consistent
… the other one - there were some use cases related to (one of the counter arguments was - there is no need to selectively disclose a presentation -- that's not correct)
… sometimes, when you want to do a proof of existence
… like, I'm presenting something, and I want to prove that I have the info, doing a selecting disclosure in a VP is one way of doing that
… which establishes a legal anchor that you had the info at a particular point in time (but did not want to reveal it)
… so I want to make sure that at least those two use cases can be added to the record (and brought up at IETF if needed)
Ivan Herman: practical question - I get emails from Amanda B. (Bieber?) -- is there something I should do about those?
Brent Zundel: if you could forward those emails to me and Mike Jones
Ivan Herman: will do
render method and confidence method
Brent Zundel: Render Method and Confidence Method has recently become final community draft status documents
… the time has come for us to begin considering adopting them as work items for this group
<Manu Sporny> Confidence Method v0.9 - https://
Brent Zundel: our charter has no problem with this, we wouldn't have to recharter
<Manu Sporny> Verifiable Credential Rendering Methods v0.9 - https://
Brent Zundel: however, before making such a resolution, I would want us as a group to be sure that there's at least 2 people willing to be Editors
… and enough orgs / participants in the group intersted, to make it worthwhile
… I have concerns about our capacity (not our willingness)
… we can talk about other specs we could pull in (with a recharter)
Manu Sporny: we sent a poll out to the CCG and the VC WG
… we've gotten 28 responses. each spec (including renderMethod) includes -- the spec, how important it is for the ecosystem, whether or not the org is going to use the spec,
… and whether or not people are willing to be active Editors on the spec
… so, we're collecting email addresses of potential editors / implementers
… for render method and confidence method, we had 5 editor volunteers, plus 9 maybe
… for confidence method - 2 people and 10 people maybe
Manu Sporny: it's clear people want render method a bit more than confidence method, but people think confidence is important
Brent Zundel: I notice one of the question is 'will implement'? what's the granularity -- if more than one person in an org voted, would that show up as more than one?
Manu Sporny: yes. we should change it to one per org, we can do that
Brent Zundel: also, any of the volunteers here on this call?
Manu Sporny: Parth would be interested
Dmitri Zagidulin: I would be interested in being editor of the Render Method spec
Manu Sporny: also, some people in Singapore / apac are very intersted, but this time slot is awkward for them
Ivan Herman: do any of the editors that you listed belong to w3c / working group?
Manu Sporny: yes, a fair number of them are, I need to go back over it. (we don't have that data right now)
… but we can get at that data
Brent Zundel: chair hat firmly on, here's how I would like us to proceed
… I would like first step - to get at that additional info (people vs org, membership). following that,
… if the additional views are consistent with what we're seeing, I believe it would be appropriate for this WG to adopt Confidence Method and Render Method
<Manu Sporny> Here's the poll results (hopefully folks can see them): https://
Brent Zundel: as we do so, I believe we should explore a Task Force style work mode
… where the group continues on its monthly cadence, but a TF would be created for each spec that would proceed with their own call cadence, and would report on progress
<Dave Longley> +1 to task force approach
Brent Zundel: my recommendation is - we try out this mode as an experiment, to judge capacity for additional work. will inform our rechartering discussions
Ivan Herman: is the intention to incorporate the CCG document into the VC spec?
… in a VC 2.1 version? or to publish as separate recs / docs?
… we already have a large number of documents, and we know more docs have management costs
Manu Sporny: the plan would be to publish as separate. I don't know how we could easily fold it into the current spec
<Brent Zundel> +1 to them being separate documents
Manu Sporny: Render Method itself would add like 30 pages to the spec
Ivan Herman: ok, just something we need to make a decision on
… if we have separate docs, we need separate repos, first public working draft calls, etc
<Hiroyuki Sano> +1 to separate document
<Dmitri Zagidulin> +1 to separate
Manu Sporny: copy that, +1. Brent Zundel, I put myself on the queue to respond to your TF based plan
… the only downside (not saying we shouldn't do it) is -- we do, at some point, want broader WG focus and attention on this
… my concern would be - main group members might not see things they might have issue at
… so we'd need to find points through the process to sync with larger group
Brent Zundel: any time there'd be a resolution on the document, the WG would review it (such as, transition to a rec, etc)
… my hope is also - whenever there's sticky issues, those would be brought to the larger group
Ivan Herman: just to understand the procedure -- so for the time being, we'd meet once a month. Does that mean that concrete actions (transfering to repos etc) should wait till Mid-October?
Brent Zundel: this group could decide, today, to adopt them. but we're hoping to get more data. (so, yes, mid-october)
Manu Sporny: my concern with that approach is - we just published FCGSs, so we shouldn't be updating spec, ... though this may not be true for render and confidence method
Brent Zundel: yes, FPWDs we'll do those today
Manu Sporny: should we go through til the next of the specs?
Ivan Herman: I'd prefer to combine that with the general rechartering discussion
Brent Zundel: I'll make sure it's on the agenda next month
… by then, the IPR sign-off should be done for Render and Confidence method
… and we can have that conversation on other specs etc, to see if it makes sense to recharter
… we'll meet at TPAC (this time, not a super long meeting, refreshing)
… but I suspect the bulk of the TPAC meeting time will be a re-charter conversation
Manu Sporny: how long should we keep the poll open?
Brent Zundel: let's do one more push, and close it up next week
Manu Sporny: sounds good, I'll send another reminder, and close it off next Friday
Brent Zundel: ok, I think that was everything on that topic
<Phillip Long> +1 to another week - meeting with two institutions friday to brief them on the poll.
FPWD Resolutions
Brent Zundel: Ivan Herman, how granular do we need to be here? can we cover it with a single resolution?
… like, 'For each spec we're maintaining, if there are changes we need to make, we'll resolve to make a First Public Working Draft'?
Ivan Herman: you should talk to the person who's responsible for the process these days
Brent Zundel: I've been talking to that guy, and he's fine with it
Ivan Herman: let's try
Ivan Herman: that phrasing might be slightly too vague
Brent Zundel: (wordsmiths some potential proposals)
Manu Sporny: just to be clear. if this proposal passes -- I update anything that has changes (which is all the docs, as this point), bump a minor semver version, then we'll do an FPWD
… it'll get a new URL in TR space
… we'll use Echidna to publish updated working drafts for it. then transition to CR, then (using new process) go to Rec?
Brent Zundel: yes, that matches my understanding
Ivan Herman: just to be clear, that means we have to ask for a transition request (for an FPWD), publish it by hand old-school style, then once that's done, we'll do Echidna etc
Ivan Herman: other thing we'll have to do is - when we publish the FPWD, we'll make sure the history goes back to the current REC version
Brent Zundel: so far I'm hearing alignment, on process details?
<Brent Zundel> PROPOSAL: As the WG maintains the Recommendations under its purview, we will create a First Public Working Draft for a new version of each document as necessary.
<Ivan Herman> +1
<Brent Zundel> +1
<Dave Longley> +1
<Manu Sporny> +1
<Phillip Long> +1
<Dmitri Zagidulin> +1
<David Chadwick> +1
<Ted Thibodeau Jr.> +1
<Hiroyuki Sano> +1
RESOLUTION: As the WG maintains the Recommendations under its purview, we will create a First Public Working Draft for a new version of each document as necessary.
Manu Sporny: i think it's weird to ask for a transition request, for a point-release of a doc we're chartered to work with?
… is there any way we can modify the process to require less overhead?
Ivan Herman: so by coincidence, there were some discussions (chartering) on json-ld / rdf -- when you start a new version number,
… then officially you start a new line of recommendations in terms of IPR. hence the formalism
… I don't like it as much as you. so, 2.1 has its own IPR regime
… and whatever happened with 2.0 has no reflection
Brent Zundel: ok, with Process CG hat on, to answer Manu's question. the short answer is - yes, the process can certainly be changed
<Brent Zundel> https://
Brent Zundel: I'll drop a link into the chat. anyone who would like to see changes, please open an issue
… additionally, the process CG, under the AB, is planning on interrupting as many WG meetings as possible during TPAC, with questions and conversations about the process, to get feedback from the source
VC Issues
Brent Zundel: I think there's only one issue here that's not Class 4 (those are marked Future)
… everything else, Class 2, has been triaged
w3c/vc-data-model#1614
<Manu Sporny> +1 to what brent said -- mark as class 2
CID issues
Brent Zundel: ok, here's some CID issues, a couple marked as Editorial, some Class 3
w3c/cid#141
Brent Zundel: Manu Sporny, you've labeled this as Editorial. but it's recommending substantive changes. can you give us a summary?
Manu Sporny: the 'Editorial' tag might have been just leftover
… debatably Class 3?
Brent Zundel: it's removing a normative statement
Manu Sporny: yes, I think you can do that in a Class 3
Brent Zundel: so existing impls won't be affected
Manu Sporny: yes
Ivan Herman: this is about processing of these
… so if there's more content, go ahead
Brent Zundel: for this issue, I'm hearing Class 3, so I'll add that as a label, will remove Editorial and Future labels
<Manu Sporny> +1 to getting rid of editorial/future for all of these.
procedural issue on the changes
Ivan Herman: how do we want to proceed? I hear about Editorial / Class 3 changes etc,
… in practice, do we want to change the RECs as they are now? or just reflect them in the new working draft?
Brent Zundel: are you asking, should we publish FPWDs as they are, or do we add these changes?
<Brent Zundel> +1 to manu's -1
Manu Sporny: no, I'd be -1 to changing the current docs, that'll be harder procedurally
<Dave Longley> +1 to Manu Sporny, sounds much simpler
Ivan Herman: that makes me happy
Brent Zundel: agree, let's make review as simple as possible
w3c/cid#152
Brent Zundel: question is, is this truly editorial?
Dmitri Zagidulin: if you say 'during these cases, the Verifier's business logic takes over',
… is that normative? is that editorial?
Manu Sporny: this modification specifically is Class 2, since it's not in a normative statement
… it is modifying / suggesting a change to the Business Logic, which is almost always out of scope
Brent Zundel: so, Class 2 says "describes changes that do not functionally affect the interpretation of the document". does that apply here?
Manu Sporny: I get what you're saying. my concern about taking a broader view -- meaning, if we anchor the classes to
… normative statements in the spec
… in theory, the only statements we make in the spec that affect implementation are the normative ones.
… that's why I'm suggesting Class 2
Brent Zundel: ok, just want to be clear that, at times, there are substantive changes we're making that are not normative, so we're walking a fine line between Class 2 and Class 3
… which I'm ok with, as long as we have clear reasons for our decisions
<Manu Sporny> +1 to what brent said our strategy should be
<Phillip Long> +1 for Class 2
Brent Zundel: anyone opposed to me marking this as Class 2?
<Manu Sporny> +1 for class 2
<Dmitri Zagidulin> +1 for Class 2
Brent Zundel: ok, I'll get rid of 'Future', keep 'Editorial'
w3c/cid#154
Brent Zundel: clarify relationship to DID
… there was a comment made during review of CID - Introduction should clarify why CID is necessary (when DID exists)
… So, in my view, this is Editorial / Class 2 change
<Manu Sporny> +1 to this being class 2
<Phillip Long> +1 as an editorial class 2
Brent Zundel: ok, not seeing any opposition
Brent Zundel: all right, keep an eye on the mailing list. If you're assigned on an issue currently, feel free to raise PRs _after_ the FPWDs are processed
Brent Zundel: thank you all, good bye