Meeting minutes
<ivan> Date: 2025-09-10
brent: 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: ok, let's jump into SD-JWT Media Types
brent: 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: 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: practical question - I get emails from Amanda B. (Bieber?) -- is there something I should do about those?
brent: if you could forward those emails to me and Mike Jones
ivan: will do
render method and confidence method
brent: 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> Confidence Method v0.9 - https://
brent: our charter has no problem with this, we wouldn't have to recharter
<manu> Verifiable Credential Rendering Methods v0.9 - https://
brent: 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: 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: it's clear people want render method a bit more than confidence method, but people think confidence is important
<Zakim> brent, you wanted to ask about granularity of responses
brent: 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: yes. we should change it to one per org, we can do that
brent: also, any of the volunteers here on this call?
manu: Parth would be interested
dmitriz: I would be interested in being editor of the Render Method spec
manu: also, some people in Singapore / apac are very intersted, but this time slot is awkward for them
ivan: do any of the editors that you listed belong to w3c / working group?
manu: 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: 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> Here's the poll results (hopefully folks can see them): https://
brent: 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
<dlongley> +1 to task force approach
brent: my recommendation is - we try out this mode as an experiment, to judge capacity for additional work. will inform our rechartering discussions
ivan: 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: the plan would be to publish as separate. I don't know how we could easily fold it into the current spec
<brent> +1 to them being separate documents
manu: Render Method itself would add like 30 pages to the spec
ivan: 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
<hsano> +1 to separate document
<dmitriz> +1 to separate
manu: copy that, +1. Brent, 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: 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: 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: this group could decide, today, to adopt them. but we're hoping to get more data. (so, yes, mid-october)
manu: 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: yes, FPWDs we'll do those today
manu: should we go through til the next of the specs?
ivan: I'd prefer to combine that with the general rechartering discussion
brent: 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: how long should we keep the poll open?
brent: let's do one more push, and close it up next week
manu: sounds good, I'll send another reminder, and close it off next Friday
brent: ok, I think that was everything on that topic
<pdl0> +1 to another week - meeting with two institutions friday to brief them on the poll.
FPWD Resolutions
brent: ivan, 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: you should talk to the person who's responsible for the process these days
brent: I've been talking to that guy, and he's fine with it
ivan: let's try
ivan: that phrasing might be slightly too vague
brent: (wordsmiths some potential proposals)
manu: 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: yes, that matches my understanding
ivan: 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: 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: so far I'm hearing alignment, on process details?
<brent> 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> +1
<brent> +1
<dlongley> +1
<manu> +1
<pdl0> +1
<dmitriz> +1
<DavidC> +1
<TallTed> +1
<hsano> +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.
<Zakim> manu, you wanted to note process change request for transition request
manu: 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: 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: ok, with Process CG hat on, to answer Manu's question. the short answer is - yes, the process can certainly be changed
<brent> https://
brent: 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: 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> +1 to what brent said -- mark as class 2
CID issues
brent: ok, here's some CID issues, a couple marked as Editorial, some Class 3
w3c/cid#141
brent: manu, you've labeled this as Editorial. but it's recommending substantive changes. can you give us a summary?
manu: the 'Editorial' tag might have been just leftover
… debatably Class 3?
brent: it's removing a normative statement
manu: yes, I think you can do that in a Class 3
brent: so existing impls won't be affected
<Zakim> ivan, you wanted to ask about our processing on these?
manu: yes
ivan: this is about processing of these
… so if there's more content, go ahead
brent: for this issue, I'm hearing Class 3, so I'll add that as a label, will remove Editorial and Future labels
<manu> +1 to getting rid of editorial/future for all of these.
procedural issue on the changes
ivan: 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: are you asking, should we publish FPWDs as they are, or do we add these changes?
<brent> +1 to manu's -1
manu: no, I'd be -1 to changing the current docs, that'll be harder procedurally
<dlongley> +1 to manu, sounds much simpler
ivan: that makes me happy
brent: agree, let's make review as simple as possible
w3c/cid#152
brent: question is, is this truly editorial?
dmitriz: if you say 'during these cases, the Verifier's business logic takes over',
… is that normative? is that editorial?
manu: 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: so, Class 2 says "describes changes that do not functionally affect the interpretation of the document". does that apply here?
manu: 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: 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> +1 to what brent said our strategy should be
<pdl0> +1 for Class 2
brent: anyone opposed to me marking this as Class 2?
<manu> +1 for class 2
<dmitriz> +1 for Class 2
brent: ok, I'll get rid of 'Future', keep 'Editorial'
w3c/cid#154
brent: 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> +1 to this being class 2
<pdl0> +1 as an editorial class 2
brent: ok, not seeing any opposition
brent: 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: thank you all, good bye