15:00:57 RRSAgent has joined #vcwg 15:01:01 logging to https://www.w3.org/2026/07/08-vcwg-irc 15:01:18 present+ 15:01:29 phila has joined #vcwg 15:01:30 TallTed has changed the topic to: Meeting Agenda 2026-07-08: https://www.w3.org/events/meetings/b1a3e329-74d1-405d-ab47-2934b41c2ab4/20260708T110000/ 15:01:37 hsxavier has joined #vcwg 15:01:47 chair: Brent 15:01:58 present+ 15:02:13 meeting: VCWG 15:02:30 agenda: https://www.w3.org/events/meetings/b1a3e329-74d1-405d-ab47-2934b41c2ab4/20260708T110000/ 15:02:48 I have made the request to generate https://www.w3.org/2026/07/08-vcwg-minutes.html TallTed 15:03:11 previous meeting: https://www.w3.org/2026/07/01-vcwg-minutes.html 15:03:18 next meeting: https://www.w3.org/2026/07/15-vcwg-minutes.html 15:03:24 scribe+ 15:03:26 pdl_asu has joined #vcwg 15:03:27 denkeni has joined #vcwg 15:03:34 present+ 15:03:34 present+ 15:03:40 present+ 15:03:45 I have made the request to generate https://www.w3.org/2026/07/08-vcwg-minutes.html TallTed 15:03:51 present+ 15:03:53 Wip1 has joined #vcwg 15:03:56 brent: Welcome everyone, this is the VCWG weekly telecon at W3C. If you're not a member of the W3C and a registered participant of the WG, please let us know. 15:04:00 present+ 15:04:02 present+ 15:04:10 dlongley: present+ 15:04:47 present+ 15:04:51 brent: Agenda today: Brief around of updates from the task force, then a dive into the Confidence Method task force, then wrap up on maintenance on the CID spec. Any proposed changes to the agenda? Please add yourself to the queue. 15:04:52 q+ 15:05:02 brent: We handle all the queuing and note taking in IRC. 15:05:04 JennieM has joined #vcwg 15:05:05 ack manu 15:05:05 brent: Manu? 15:05:09 present+ 15:05:11 Elaine has joined #vcwg 15:05:44 michaelshea has joined #vcwg 15:06:00 manu: Thanks, Brent. We had a quick kind of discussion in the VC barcode call yesterday. This was around adding something to bitstring status list from the VC barcode spec, it's the TerseBitstringStatusList mechanism. The group was in agreement to do this but there's no FPWD BitstringStatusList yet for 1.1. Nothing has changed there, but we should get the wheels turning on that to get it published. 15:06:06 manu: So we have a place for those changes to land. 15:06:32 wes-smith has joined #vcwg 15:06:42 present+ 15:06:58 brent: Excellent question. The proposed additions to BitstringStatusList -- what's the assertion that they are in within the scope of the charter? It's a security mechanism that the barcode specification uses that layers on top of the bitstring status list spec. We could continue to just publish it within VC barcodes, that's well within charter, but we could break it out and put it in BSL instead, which the group feels is a better place. 15:07:24 manu: The group can decide where to put it, it's up to us, we can put it where we like. 15:07:35 q+ 15:07:36 brent: Is this mature enough to exist on its own, or could it use more development? 15:07:41 manu: I'll defer to Wes on that question. 15:07:41 ack wes-smith 15:08:34 wes-smith: I think it's mature enough. As part of the transition, I'll review it of course, but regarding charter-scoping, it's the "add features as needed by the new docs in the charter" and it fits easily there, the BitstringStatusListEntry is too big for VC barcodes, this is a smaller approach. 15:08:50 s/It's a security mechanism that the barcode specification uses that layers on top of the bitstring status list spec. We could continue to just publish it within VC barcodes, that's well within charter, but we could break it out and put it in BSL instead, which the group feels is a better place./Manu: It's a security mechanism that the barcode specification uses that layers on top of the bitstring status list spec. We could continue to just 15:08:50 publish it within VC barcodes, that's well within charter, but we could break it out and put it in BSL instead, which the group feels is a better place. 15:09:05 brent: That sounds good, I'm happy for us to draft some proposal language for FPWD for BSL 1.1. 15:09:50 michaelshea2 has joined #vcwg 15:09:51 q+ 15:09:55 ack phila 15:10:14 kezike has joined #vcwg 15:10:19 present+ 15:10:34 thank you Phil for remembering editors 15:10:54 phila: Looks ok to me. Thought comes to me -- I'm looking at the authorship, given that old editors aren't active in the group, the new editors would all be from the same company, that isn't a good look, can we have some others join? 15:11:04 phila: Could someone please volunteer to be a co-editor? 15:11:12 q+ 15:11:17 If no one eise will and it's light I would 15:11:19 ack TallTed 15:11:42 q+ 15:11:44 TallTed: I can't volunteer taking on extra work per se, but running the same tool on this that was run elsewhere? To analyze contributions? 15:11:50 manu: I can do a quick run on that. 15:11:55 q+ 15:12:02 q+ 15:12:02 ack phila 15:12:03 brent: Regardless of contribution, having a named editor would be very valuable. 15:12:07 ack KevinDean 15:12:21 ack manu 15:12:26 KevinDean: Yes, Kevin is volunteering. 15:12:39 phila: Thank you Kevin! 15:12:40 brent: Thank you. 15:12:42 manu: Thank you. 15:12:52 PROPOSAL: Publish Bitstring Status List v1.1 with a short name of vc-bitstring-status-list-1.1 as a FPWD 15:12:57 +1 15:12:57 +1 15:12:58 +1 15:12:59 dlongley: +1 15:13:02 +1 15:13:02 +1 15:13:03 +1 15:13:03 +1 15:13:03 +1 15:13:05 +1 15:13:06 +1 15:13:09 +1 15:13:14 +1 15:13:16 +1 15:13:18 +1 15:13:33 RESOLVED: Publish Bitstring Status List v1.1 with a short name of vc-bitstring-status-list-1.1 as a FPWD 15:13:57 brent: Thanks folks. Is there anyone on the call who would like to re-introduce themselves or otherwise give updates? 15:14:12 brent: I should probably let people know that starting last week, I also chair the advisory board. 15:14:27 brent: I'm not longer chairing the process community group. 15:14:36 s/not longer/no longer 15:14:41 Topic: Task Force Updates 15:14:56 brent: If you are heading up a task force and have a brief update for the group, please jump on the queue. 15:15:03 q+ to provide update for Recognized Entities. 15:15:08 ack manu 15:15:08 manu, you wanted to provide update for Recognized Entities. 15:15:08 brent: This isn't a formal go-around, but if you have something you'd like us to know, we'd like to hear it. 15:15:39 I have made the request to generate https://www.w3.org/2026/07/08-vcwg-minutes.html TallTed 15:15:49 manu: The Recognized Entities TF is making good progress, we have a set of PRs that we believe once we merge will make the spec more or less feature complete. We have also merged the initial draft of the threat model which is fairly complete, includes all the group's inputs on threats they are concerned about, rankings, DFD, categorizations. 15:16:26 manu: Phil Archer is reviewing, we could always use another reviewer. We have also prepared the self reviews for i18n, security, privacy, a11y, so in about two weeks if that TF gets to consensus on it, we're going to ask for horizontal review to go into CR. 15:16:54 manu: We expect it's going to take months for those groups to get around to it, but the hope is that puts us into very good shape for W3C TPAC and getting the Recognized Entities spec into CR during that meeting. 15:17:00 brent: Thank you, Manu. 15:17:07 brent: Not seeing anyone else on the queue. 15:17:13 brent: We can move on. 15:17:17 q+ 15:17:41 brent: Next up, we're going to look at confidence method. The chairs are anticipating that we will pick on a particular TF to talk about on the main call. 15:17:43 ack kezike 15:18:15 kezike: A quick update on VCALM. With VCALM the main things that we're doing -- we're making good progress with raising PRs. I am trying to get us down to zero issues by the end of the month. We are working on that. 15:18:39 kezike: We have a PR on the threat model going in next week, and work on the test suite as well. Patrick St. Louis has a new repo with a test suite PR. 15:19:21 Topic: Confidence Method 15:19:23 kezike: It's a refurbish of what we had before that was used previously with integration into VC playground but now we have a new mechanism that picks up on normative language in the spec and we can use OpenAPI to guide configuration of the test suites. Will be more to share later as it develops. Just wanted to give a quick update. 15:19:30 brent: Thank you. 15:19:36 wes-smith has joined #vcwg 15:19:40 subtopic: https://github.com/w3c/vc-confidence-method/issues/33 15:19:47 brent: Two issues to look at today. Denken and Joe feel free to jump in as much as you like. 15:20:04 brent: The definition of confidence method in the VCDM and in the confidence method spec aren't consistent, this issue was opened by Ivna. 15:20:09 s/Ivna/Ivan 15:20:13 q+ 15:20:20 brent: Let's talk about this. What should the definition be? Where are we at here. 15:20:22 ack JoeAndrieu 15:20:55 JoeAndrieu: There are two different issues here worth kicking around. The first is, what do we do to update the VCDM to update it to be aligned with confidence method, and the second is, is the definition that the CM spec has good? Because it is different from the VCDM spec. 15:21:14 related VCDM issue: https://github.com/w3c/vc-data-model/issues/1632 15:21:16 q+ 15:21:20 JoeAndrieu: The first one is logistical, because if the group agrees on a definition we can remove CM from VCDM, or we could update and point from the CM to VCDM. 15:21:20 q+ 15:21:26 ack manu 15:21:49 manu: +1 not having the definition in two places. I don't have a strong opinion on the definition. Probably the CM spec should define it not the VCDM spec. 15:22:22 manu: We can point from VCDM to the confidence method spec, for whatever language we might need there, but that's easy enough to do. That's probably an editorial change but even if not it's within the charter. 15:22:35 ack denkeni 15:22:38 dlongley: +1 that we should move as much as possible to the CM spec and remove from the VCDM. 15:23:25 denkeni: I started looking into CM as a way for digital identity for human beings, so that's why we were are more serious about checking that the subject of a VC is the holder and other issues. I am also wondering when we are using VC for digital product passport, is there a need for a CM about the subjects there? 15:23:32 denkeni: I'm curious about the use cases there to understand how it can be sued. 15:23:39 s/sued/used 15:24:00 brent: It sounds like we have general agreement that we should remove the CM from the VCDM and put it in the new spec, leaving a pointer if we need anything from the VCDM into it. 15:24:07 +1 to Brent's summary of where we are at with this issue. 15:24:11 brent: Stating that out loud. 15:24:31 kezike has joined #vcwg 15:24:32 q+ 15:24:36 brent: Second issue, what should the description, definition be here? In the issue Ivan lists both of them. Ted expresses support for the VCDM definition over the CM one. 15:25:00 brent: That's where the conversation should be. That's try to come to consensus about that and what the CM should say about itself. 15:25:02 q+ 15:25:05 ack manu 15:25:07 brent: Could you bring your comment in that you just made on the issue, JoeAndrieu ? 15:25:33 manu: I'm fine with either definition, Joe. I think the CM definition is more accurate wrt. what's going on. But I think that might be harder for first time readers to understand it at depth. I don't have a strong preference. 15:25:48 q+ 15:25:58 ack JoeAndrieu 15:26:00 manu: The first one is generalized enough to be in the VCDM and then put the detail in the CM spec, that's one way to do it. But I think we need to see a PR after the discussion today because it will need fine tuning. 15:26:40 JoeAndrieu: I think the one in the VCDM is not the one we want to proceed with. The thing I got behind with the CM -- is that the issuer provides something for the verifier to double check. 15:27:11 JoeAndrieu: The mechanisms of CM let the verifier do some checks on their own using DID auth/biometric/etc. to see if it matches up with what was issued. 15:27:32 q+ 15:27:45 q+ to talk confidence vs evidence 15:28:08 ack phila 15:28:09 JoeAndrieu: I'm not opposed with coming up with a shared term that an issuer might use to describe their confidence in a claim. But we are trusting issuers to make the claim, so we take what they are saying or not. But having an issuer say that they have a 95% confidence level in something is fine -- but there's nothing for a verifier to do with that. 15:28:52 phila: Those two definitions are quite different from each other. It's clear that the CM TF and spec is focusing on the identity of a subject in the VC. The whole point of issuing a VC is that an issuer is already sure enough to issue it. 15:29:05 phila: I can see how expressing a confidence level might be useful, but it's not what CM is about. 15:29:36 q+ to note "a subject" (can be used on many objects) not "the subject" (only used on the top-level credentialSubject) 15:29:38 ack TallTed 15:29:39 phila: Is it ok to slightly alter the CM definition in the VCDM that allows the CM spec to be about confidence in the subject? Can the VCDM put it in the hand of the issuer? 15:30:25 TallTed: Theoretically, an issuer only issues a VC about a subject that they are confident is the subject. I can't imagine that an issue would last very long or be looked to by many verifiers if they weren't confident about the subject about whom they were making claims. 15:30:39 TallTed: I don't see that it's particularly valuable to tell the verifier how they were confident in that identification. 15:30:51 TallTed: Either the verifier trusts the issuer on that or the whole thing falls to pieces. 15:31:26 TallTed: Many of the verifiable credentials that are discussed -- to take an example -- are in the educational field, that someone has taken a course and achieved a level of proficiency and got a grade about a 3.0 (whatever that means in that institution). 15:31:57 TallTed: We don't particularly care how that institution that this individual, bearing this identifier, is actually the individual that took that course. That's not the thing that we're concerned with. We're concerned with the grade that they received. 15:32:13 q+ to suggest that's assuranceLevel, not confidenceMethod 15:32:16 TallTed: Maybe what needs to happen is that the CM spec needs a little retitling because it's not a generic, it's a specific kind. 15:33:01 ack brent 15:33:01 brent, you wanted to talk confidence vs evidence 15:33:03 TallTed: That might do the job, I'm not particularly interested in blocking things, but it's not making sense how it's stacking up. We have a very generic definition in the VCDM but a very specific definition in the nominally generic CM spec. That can cause confusion for people trying to use these and we'd be better off avoiding it. 15:33:12 brent: It sounds like a little bit of this is confidence vs. evidence. 15:33:15 smccown has joined #vcwg 15:33:20 present+ 15:33:42 brent: I like Ted's suggestion that, because the CM spec, as currently being drafted is one specific confidence method, perhaps a more specific titling would be useful? That would clear this up for me. 15:33:45 brent: I like that idea. 15:33:52 ack manu 15:33:52 manu, you wanted to note "a subject" (can be used on many objects) not "the subject" (only used on the top-level credentialSubject) 15:34:04 manu: Two responses. One to something Phil said, something to what Ted said. 15:35:11 manu: Ted's item first. The spec currently contemplates three different types of confidence method. Does the subject have a cryptographic key and can they prove that, i.e., DIDAuth. Another is: Is there a static photo I can look at as a verifier to see if the person, shipping container, whatever in front of me matches? And third, is there some kind of liveness checking mechanism that can be done in a privacy-preserving way to check that the 15:35:11 human/cat/dog/whatever is what's referred to in the credential. 15:35:12 q+ 15:35:45 manu: What we typically do, the pattern we follow in the group is, we will define a generalized thing, like here are the quantum resistant cryptosuites and then we'll define a bunch of specific ones. This would follow that pattern. 15:35:52 manu: And potentially the BSL as well. 15:36:33 manu: Phil you mentioned "the subject" a couple of times, I want to make sure that it's not just one subject, it's "a subject". A VC can have a human and a cat, two different subjects, for example, and you can have a different confidence method on each one. 15:36:59 +1 about multiple subjects 15:37:00 ack JoeAndrieu 15:37:00 JoeAndrieu, you wanted to suggest that's assuranceLevel, not confidenceMethod 15:37:05 manu: The expectation is that assigning the photo for each of them, for example, could enable verifiers to get confidence about the identity of those subjects. 15:37:05 q+ 15:37:45 JoeAndrieu: First, I'm totally open for getting a better name for the document. I understand that updating the repo and short name might be complicated. That's perhaps why the name in the repo isn't just "VC Confidence". We knew we were defining things beyond just CMs. 15:37:51 JoeAndrieu: Bikeshedding opportunity. 15:38:39 hsxavier has joined #vcwg 15:38:48 JoeAndrieu: Regarding the content of what you said, Ted... I think we do care about understanding two things that the CM spec is trying to address. Assurance level -- sometimes we do care what did the issuer do to convince themselves that this person was a certain person, like we satisfied NIST level 3. That's valuable for the issuer to explicitly attest to that. 15:38:54 NIST IAL2 Remote Identity Proofing: https://pages.nist.gov/800-63-3-Implementation-Resources/63A/ial2remote/ 15:38:58 JoeAndrieu: For identity assurance prior to issuance. 15:39:15 JoeAndrieu: But the second part, a CM is really about what the verifier can do -- not what the issuer did. 15:39:52 JoeAndrieu: In the DIDAuth pattern, it's presumed that the issuer checked the DID to ensure the subject was in control of it -- but it's the use of the DID to prove use of its VMs at the verifier that's use of the CM. 15:40:01 ack michaelshea 15:40:36 q+ it can be about a business 15:40:36 michaelshea: More of a question than a statement -- examples all around peoples and cats, but does CM extend to a VC by an auditor regarding a meeting or whatever about a good? 15:40:46 ack denkeni 15:40:48 q+ to say it can be about a business, products maybe 15:41:31 denkeni: To add a little bit to Joe's comments. We face challenges too with the issuer to issue a credential unless we have a clear way to let the holder/presenter is the subject. If my brother got an education VC from MIT, but I can use his credential to claim I have credit from MIT. 15:41:42 Saad has joined #vcwg 15:42:19 denkeni: Online. It's very hard to avoid fraud. It's also interesting because when the verifier sees a VC issued by an issuer, what does the trust look like? Does the verifier need to trust every single claim in the VC or can the verifier question about every claim in the VC? This is an interesting question. 15:42:42 Saad has joined #vcwg 15:43:06 denkeni: Does the verifier trust the whole VC -- doesn't need to check any of them, trust is easier. But if that's not the case, we could add some CM to each claim to persuade the verifier the claims are trustable. If we want to pursue that then we probably need to rethink evidence and transform it into a unified structure. 15:43:15 ack JoeAndrieu 15:43:17 JoeAndrieu, you wanted to say it can be about a business, products maybe 15:43:17 denkeni: Like every claim can come with an evidence field. 15:43:50 JoeAndrieu: I'm a little wary of what you just proposed, Denken. I do embrace that the issuer can put claims in that moderate the primary claims. They can put in language in their claims like that now, Joe got 95% level in this in his class, etc. 15:44:46 JoeAndrieu: I wanted to speak to Michael's question -- CM as envisioned is a point of extensibility and some things aren't on our queue for this cycle. Some of those could be used for a business, you might have an LEI to get confidence in a particular business's identity. You might have some board minutes for decisions, etc. 15:45:23 JoeAndrieu: I can see CMs about businesses and which business is acting, etc. Products you can do the same thing. You're providing a mechanism -- when someone sees one, like the latest iPhone, and you might provide evidence for how to make sure it's really the latest real iPhone. 15:45:52 JoeAndrieu: There are things that manufacturers do to products so that they and law enforcement can check those things. And some of those things aren't public and then fraudsters can do those things if public, so sometimes hard to put there. 15:46:04 business is listed at Companies House in Britain... or is a registered DBA in community x in USA... or has presented successful audit by Big4AcctFirm... or (so many possibilities) 15:46:09 q? 15:46:09 JoeAndrieu: Would be great to have CM for making sure people are buying an actually valuable good, etc. 15:46:10 thanks Joe! 15:46:36 brent: Thanks, this was a great conversation. I encourage the CM TF to keep noodling on this and bring back things to the group. 15:46:41 Topic: Controlled Identifiers 15:46:43 brent: Moving over to CID now. 15:46:52 https://github.com/w3c/cid 15:46:55 brent: This specification is one which is within our remit to maintain. 15:47:00 brent: We're going to do some maintaining of it. 15:47:19 brent: If we look at -- there are two open PRs that we could look at. I think we have talked about one of them before. 15:47:24 brent: I'd like to look at 171 first. 15:47:28 subtopic: https://github.com/w3c/cid/pull/171 15:47:30 q+ 15:47:45 q+ 15:47:45 ack manu 15:47:54 manu: Just noting that this look editorial and good and we should merge it. 15:47:58 ack JoeAndrieu 15:48:18 JoeAndrieu: Yeah, I think it's editorial. Respec can use xref for this and it helps and makes it easier for other specs to reference this. 15:48:34 brent: A fantastically tiny change that could have a big impact, makes sense to merge it. 15:48:42 q+ 15:48:53 brent: Folks, jump onto that PR and give it a thumbs up if you like it. We can probably merge it after the call. 15:49:04 ack TallTed 15:49:34 +1 15:49:37 TallTed: I did put a comment on 170 -- the issue for 171. DID abbreviates Decentralized Identifier, so CID should abbreviate Controlled Identifier not Controlled Identifier Document. 15:49:44 +1\ 15:49:47 The PR will need to be updated to align w/ what Ted said :) 15:50:03 q+ 15:50:07 brent: Are we matching an acronym or a short name? 15:50:16 ack manu 15:50:16 s/+1\/+1/ 15:50:36 +1 15:50:39 manu: I don't know if I quite understood that question. But "CID" should expand to "Controlled Identifier" because "DID" expands to "Decentralized Identifier". We say DID document so we should say CID document and that would all align. 15:50:48 q+ to say I just updated the wrong def 15:50:55 brent: So, we are going to adjust the PR. 15:51:06 JoeAndrieu: I just put the alias in the wrong term. It's an easy fix. 15:51:24 brent: Looking at the issues now. 15:51:32 subtopic: https://github.com/w3c/cid/issues/167 15:52:06 brent: This was raised by Pierre-Antoine, not a lot of conversation, let's talk about it. 15:52:08 q+ 15:52:19 ack JoeAndrieu 15:52:19 JoeAndrieu, you wanted to say I just updated the wrong def 15:52:23 ack manu 15:53:14 manu: Have to context swap a lot in my head here. When you define a datatype in a specification -- you have to define what it is and what it's used for, an you need to define the lexical space for the datatype like -- how do you express it using text. vs. what's the value space, mathematically what could this value be. 15:53:32 manu: Where some of those values may not always map into the lexical space, like you can't represent "Infinity" in ASCII or whatever. 15:53:42 manu: As a single symbol, etc. 15:53:54 Elaine has joined #vcwg 15:54:18 manu: How do you take the value and map it into lexical space -- these things need to be defined. This one is about the canonical mapping is not the lexical-to-value mapping and it should go the other way. 15:54:23 brent: Yes, this is saying it should go the other wya. 15:54:26 s/wya/way 15:55:03 q+ 15:55:09 manu: One thing we can do in a PR here is just remove the canonical mapping or if it's possible to define it. Ivan suggests we just remove it. I'd like to understand why we should just remove it first, but don't care either way, just want to take more time. 15:55:25 brent: Requires expertise in multibase? 15:55:27 ack TallTed 15:55:33 manu: That and RDF. 15:55:46 TallTed: Does anyone know if we have anywhere an actual definition of canonical mapping? 15:55:51 manu: Maybe in RDF concepts? 15:56:07 brent: The definition, I believe is linked to in the first comment. 15:56:13 q+ 15:56:27 ack manu 15:56:50 manu: We should delete this, I think I know what would need to happen -- and when we go through the pain of writing all that text I don't think anyone would care or pay attention to it. 15:56:53 manu: +1 to deleting it. 15:57:04 brent: Excellent. Anyone willing to do this PR? 15:57:10 manu: Easy first issue, just deleting that text. 15:57:14 q+ 15:57:22 q- 15:57:29 michaelshea: I'll take a wack at it. 15:58:14 brent: Ok, that is time for the meeting today. Thanks all for being here! 15:58:19 brent: Thanks for scribing, Dave. 15:58:26 dlongley: Sure! 15:59:39 Jem_ has joined #vcwg 17:05:06 rrsagent, draft minutes 17:05:08 I have made the request to generate https://www.w3.org/2026/07/08-vcwg-minutes.html denkeni 18:03:21 Zakim has left #vcwg