06:35:12 RRSAgent has joined #vcwg 06:35:16 logging to https://www.w3.org/2026/06/04-vcwg-irc 06:35:16 RRSAgent, make logs Public 06:35:17 please title this meeting ("meeting: ..."), ivan 06:36:09 Meeting: Verifiable Credentials Working Group F2F, Brussels, 3rd day 06:36:21 ate: 2026-06-04 06:36:21 7 06:36:21 Agenda: https://www.w3.org/events/meetings/b7f65d9a-7340-4d1c-a587-6639d054592b/ 06:36:31 chair: brent, phila 06:36:35 s/7// 06:36:48 ivan has changed the topic to: Meeting Agenda 2026-06-04: https://www.w3.org/events/meetings/b7f65d9a-7340-4d1c-a587-6639d054592b/ 06:39:57 brent has joined #vcwg 06:59:21 phila has joined #vcwg 07:03:41 JennieM has joined #vcwg 07:03:50 present+ 07:03:54 brent has joined #vcwg 07:04:01 present+ 07:04:13 present+ manu, carolynn, brent, phila, elaine, wes, wip, joe, 07:04:18 present+ 07:04:26 present+ ivo 07:04:58 present+ shigeya 07:05:14 present+ olvis 07:09:16 present+ 07:09:25 Wip has joined #vcwg 07:10:15 IvoL has joined #vcwg 07:10:23 Elaine has joined #vcwg 07:10:37 JoeAndrieu has joined #vcwg 07:11:26 manu has joined #vcwg 07:11:26 hyojin has joined #vcwg 07:11:26 hadleybeeman has joined #vcwg 07:11:26 jyasskin has joined #vcwg 07:11:26 dlehn has joined #vcwg 07:11:26 dlongley has joined #vcwg 07:11:26 shigeya has joined #vcwg 07:11:27 wes-smith has joined #vcwg 07:11:40 Carolynn has joined #vcwg 07:11:47 present+ 07:12:42 present+ 07:13:05 present+ 07:13:48 present+ ganeesh 07:15:03 KevinDean has joined #vcwg 07:15:20 scribe+ 07:15:20 present+ 07:16:13 present+ 07:16:19 Topic: Barcodes and data Integrity 07:16:21 brent: Welcomes the group, thanks the host, asks everyone to follow code of conduct. Today first session is bar code and data integrity. 07:16:23 Topic: Barcodes and DI 07:17:31 wes: will do something different today. Will talk about recent work not directly related to barcode but credential status. Was are the next steps 07:17:42 Elaine8 has joined #vcwg 07:18:43 Wes: Work is a forgery defense technique for VCs 07:18:48 q+ 07:19:22 ack JoeAndrieu 07:19:24 The group discusses internet connectivity issues 07:19:37 https://aipagents.xyz/ 07:20:36 JoeAndrieu: A group is claiming that a DID method is standardised by W3C because they have registered in the DID registry. 07:21:41 q+ 07:21:42 gannan has joined #vcwg 07:21:49 manu: Data integrity for VC barcodes. digital signatures should be added to barcodes. Need to get signature sizes small enough to fit in barcodes. 07:23:22 q+ to chime in on Q-day timelines 07:25:35 q+ 07:25:36 q+ to ask about Apple's open source announcement https://www.helpnetsecurity.com/2026/05/27/apple-quantum-resistant-encryption-open-source/ 07:25:38 ack ivan 07:25:40 ...working on quantum-resistant crypto schemes. Challenge is that the tech industry is concerned by quantum computers able to break all crypto used today (perhaps in 2-3 years, or 7-10 years more realistically). Need to secure VCs assuming this will happen soon. FWPD will contain a number of post-quantum crypto suites, reusing NIST work. Module 07:25:41 lattice algorithm are being adopted. There is a backup if this one fails. But they have not been tested sufficiently to ensure 100% certainty, therefore multiple algorithms are being considered 3-4. Skisign has very small signature sizes, but don't think this will be standardised in the next years. Not expecting controversy on this. hope is the 07:25:41 post-quantum content in a CR by TPAC. But Skisign may not be included. 07:26:04 s/lattice algorithms/... lattice algorithms/ 07:26:17 FWIW, Apple's open source supports ML-KEM and ML-DSA, 07:26:26 s/post-quantum content/... post-quantum content/ 07:27:47 q+ to note factoring commonalities, cryptosuite registry, etc. 07:28:03 q+ to provide update to BBS 07:28:44 ack brent 07:28:44 brent, you wanted to chime in on Q-day timelines 07:28:50 ivan: crypto-suite in the barcode and in documents means that there are lots of commonalities in these documents. editorial work may be needed to remove duplications. Issue is we have 10-15 crypto-suites in various documents and this has become chaotic. Nowhere is there a listing of these suites to help people understand how to use them. We may 07:28:50 need a note or appendix in DI spec which gives a clear overview of all cryptosuite and references to relevant specs so people can find their way in the maze as today it is a mess. 07:29:13 s/need/…need/ 07:30:11 q+ 07:31:03 ack phila 07:31:13 brent: google does a lot of PQC research and has moved it deadline to be 100% PQ to 2029. So this is happening sooner than anyone anticipated. However, there may be some gradual risk to PQC and as it becomes more available will reach all applications. So the threat is real but not immediate. Will JOSE/COSE be updated for PQ ? IETF is already 07:31:13 freaking out on this for us ! 07:31:34 s/freaking out/... freaking out/ 07:31:38 q+ to provide feedback on examples 07:31:41 ack JoeAndrieu 07:31:41 JoeAndrieu, you wanted to ask about Apple's open source announcement https://www.helpnetsecurity.com/2026/05/27/apple-quantum-resistant-encryption-open-source/ 07:31:44 phila: TPAC is only 4 months away. Will PQR examples be added to the document ? 07:32:03 ack manu 07:32:03 manu, you wanted to note factoring commonalities, cryptosuite registry, etc. and to provide update to BBS and to provide feedback on examples 07:32:06 q+ to speak to library support 07:32:13 ack manu 07:32:13 manu, you wanted to speak to library support 07:32:15 JoeAndrieu: apple's annoucement on PQ software libs. 07:32:19 wes-smith has joined #vcwg 07:33:50 ack ivan 07:33:52 manu: Yes, Greg has done this work to refactor specs to make it easy for others to write new cryptosuite. We have a cryptosuite registry but noone has been doing it. Do we want to keep going down that path ? Manu would prefer overview document rather than registry. To provide guidance on usage. Caveat is that it must be kept up to date. Dangerous 07:33:52 to let it drift. Something to consider for workload. 07:34:09 s/to let it/... to let it/ 07:34:21 q+ ivan 07:34:25 ivan: These are crypto-suites that we standardised, so this should not be a problem. 07:35:45 manu: BBS is continued to be pushed at IETF. Going very slowly but don't know why it's going so slowly. Questions have not received good feedback. Tremendous interest but no sense of urgency but this is a problem as this will be probably broken by PQC, so we are running out of time. 07:36:22 ...examples ? Yes we need 8 hours or so to add another tab for examples, with gigantic signature for QR. 07:37:23 ...library support : Joe's questions. Available in SSL and others. These libs depend on single underfunded persons. Apple's additions are a good thing if you are on Apple. 07:37:23 ack ivan 07:38:53 q+ to say greg could probably do that 07:38:56 q- 07:39:01 ivan: in next week's PQR annoucement which will be on W3C website, a blog on the importance of QR work in W3C would be useful. Realize there is a problem, 1-2 paragraphs to explain this would be useful. Who would have the necessary knowledge to do this? 07:39:11 manu: Greg would probably be happy to do this. 07:39:40 ...He is capable of not being too technical and has the credibility for this. Try to talk to him next week. 07:46:20 Wip has joined #vcwg 07:46:39 q? 07:47:15 q+ to ask about compromise 07:47:36 q+ to ask about accumulators/merkle trees 07:48:08 IvoL has joined #vcwg 07:49:23 q+ 07:50:29 Wes: VC finderprint list. Same motivators (PQC, ..) Name will likely change as evokes tracking/surveillance but this is not what this technology is doing. Crypto fingerprints. Threat is key compromise, not a new threat. Keys can be stolen/lost/etc. PQC can consistently steal a signing key. Need mechanisms to distinguish keys created by the key 07:50:29 issuer from those that are stolen. Credentials are unfortunately identical. Publish a signed list of shot crypto fingerprints. A fingerprint is created for a credential, a list of these is made and signed independently of the signature of the credential itself. Cases where a VC siganture is not PQC safe but the fingerprint list is signed by a PQC 07:50:29 mechanism. So the security can be inherited, improving the security of the first scheme. Get the best of both worlds. Anti-forgery effect. Can detect if a VC was issued by the real issuer or by an issuer who stole the key. Can incurr a lot of web traffic. Privacy is important. Avoid tracking and information leak. anonymisation is needed. 07:50:29 Flexibility of use. backwards and forwards compatibility. Example given of a fingerprint credential. lenght of fingerprint list. VC is large in terms of bytecount but simple structure. Simple to compute fingerprints. Basically a truncated hash. Truncation depends on use cases. False positive rates should be zero is working assumption. 07:51:34 s/issuer from/... issuer from/ 07:51:46 s/mechanism/... mechanism/ 07:51:54 ... assumption is hash function is not broken by PQC and this is a common assumption. 07:52:02 s/Flexibility of/... Flexibility of/ 07:52:34 ...Three usage modes. implicit, explicit, standalone for both back and forwards compatibility. 07:53:03 q? 07:53:14 q+ to note where this technology is likely to be deployed 07:53:22 ...issuers take VC they have already issued and piggyback existing VC status entry and index to piggiback fingerprint list and index. 07:53:41 IvoL0 has joined #vcwg 07:53:53 ack brent 07:53:53 brent, you wanted to ask about compromise and to ask about accumulators/merkle trees 07:53:58 q+ 07:54:04 explicit is for the future, add a credential status field to a VC. Standalone is for custom or applications-defined deployments. 07:54:14 Wip has joined #vcwg 07:54:23 brent: accumulators or Merkle trees are being considered ? 07:54:29 +1 (one of my questtion is same) 07:56:02 wes: yes, but core problem is set membership. Very well understood information theoretical bounds. So we don't use Merkle trees for that reason. For accumulators, we are concerned about the way they are published and updated has information leaks. We have designed to avoid this. 07:56:38 brent: is this partial compromise assumption ? 07:57:09 q? 07:57:45 ack Wip 07:57:49 wes: yes. The fingerprint list can be signed by different schemes and different keys. If we compromise both, this indeed adds nothing. 07:58:49 wil: credential hash means C14N ? 07:59:01 wes: yes 07:59:55 q+ to note we are very interested in better solutions given the constraints 07:59:56 q+ 07:59:59 wil: did not understand explaination around merkle tree and accumulators. 08:02:29 ack manu 08:02:29 manu, you wanted to note where this technology is likely to be deployed and to note we are very interested in better solutions given the constraints 08:02:35 wes: designing goal is minimal data on the VC itself and minimal data leakage on issuer. "Is the VC in the set?" is the problem formulation. Other approaches were investigated but were found not to be applicable. Can't do better than things like a Merkle tree. 08:03:56 manu: why do we care ? California DMV has put digital signatures on the back of drivers licences but quantum break will break these and we have to propose something to protect these documents. Concerns around the size of the lists, publishing them in a useful ways, 08:04:50 q+ to confirm the two signing systems can also be operationally isolated (a a key difference rom the "pre-rotation" pattern) and the fingerprint list signature scheme can change over time 08:05:10 ack shigeya 08:05:10 ... if there is any way we can do better, we are open to doing better. We feel this is deployable. List only needs to be checked if PQC comes faster then expected, or breach suspicion. if merkle or if size can be smaller, we are open but time is ticking. 08:05:41 shigeya: what is the purpose of the seedbytes in the has ? 08:09:01 wes: if you are an issuer, you want the publication of this list to reveal anything of your processes. e.g. how many credentials have I issued ? How many do I issue each day ? This gives information to observers. In some cases this is a problem. We pad the list to make it a fixed size. only issuer knows which of the fingerprints corresponds to real 08:09:01 VCs. Dummy hashes can be diffed to discover how many VCs are issued each day. So everyfinger print is different every day. The seed is added in the fingerprint credential used that day. 08:09:08 ack KevinDean 08:09:27 q+ to suggest that if every VC includes that day's seed, I can look at all the VCs and see how many have that seed and therefore how many were issued 08:09:54 ack JoeAndrieu 08:09:54 JoeAndrieu, you wanted to confirm the two signing systems can also be operationally isolated (a a key difference rom the "pre-rotation" pattern) and the fingerprint list signature 08:09:57 ... scheme can change over time 08:10:00 KevinDean: merkle tree is a comparison to a root hash. If list of credentials is constantly changing, this will invalidate the possiblity to compare to a root hash 08:11:13 JoeAndrieu: both services are completely distinct. This is an advantage to key rotation. Other advantage is that mechanisms can be changed. 08:11:26 ack phila 08:11:26 phila, you wanted to suggest that if every VC includes that day's seed, I can look at all the VCs and see how many have that seed and therefore how many were issued 08:11:40 wes: the lists are short-lived, so many adaptations can be made on even a daily basis. 08:11:50 q+ to ask a chair question 08:12:11 ack brent 08:12:11 brent, you wanted to ask a chair question 08:12:45 brent: is this a seperate document, specification? where has this been incubated ? 08:13:33 manu has joined #vcwg 08:13:33 hyojin has joined #vcwg 08:13:33 hadleybeeman has joined #vcwg 08:13:33 jyasskin has joined #vcwg 08:13:33 dlehn has joined #vcwg 08:13:33 dlongley has joined #vcwg 08:13:33 shigeya has joined #vcwg 08:13:37 q+ to note security issue wrt charter 08:13:42 wes: where this fits is this is a form of credential status. The best place would be a rev on the bit string status spec. "was not forged" status. 08:13:43 dmitriz has joined #vcwg 08:13:56 q+ 08:13:59 q+ 08:14:13 brent: official charter designation is that no new features can be added to bitstring status. Justification needed. 08:14:32 wes: do this mean that the existing status list spec cannot be modified. 08:14:35 dmitriz has joined #vcwg 08:14:35 manu has joined #vcwg 08:14:35 hyojin has joined #vcwg 08:14:35 hadleybeeman has joined #vcwg 08:14:35 jyasskin has joined #vcwg 08:14:35 dlehn has joined #vcwg 08:14:35 dlongley has joined #vcwg 08:14:35 shigeya has joined #vcwg 08:14:42 q- 08:15:04 brent: reads the charter to try to clarify reasoning the justification. 08:15:07 ack manu 08:15:07 manu, you wanted to note security issue wrt charter 08:24:41 dmitriz has joined #vcwg 08:24:41 manu has joined #vcwg 08:24:41 hyojin has joined #vcwg 08:24:41 hadleybeeman has joined #vcwg 08:24:41 jyasskin has joined #vcwg 08:24:41 dlehn has joined #vcwg 08:24:41 dlongley has joined #vcwg 08:24:41 shigeya has joined #vcwg 08:45:04 SteveC has joined #vcwg 08:45:30 Testing IRC 08:47:16 Carolynn has joined #vcwg 08:47:21 manu: first reason is that this is a PQ key compromise so this is a security issue. d 08:47:39 The team had to break due to a fire alarm. 08:48:04 q+ 08:48:06 JoeAndrieu has joined #vcwg 08:48:27 Elaine has joined #vcwg 08:48:35 brent: preference is to move to recognized entity now 08:48:54 brent has joined #vcwg 08:49:08 wes-smith has joined #vcwg 08:49:28 Wip has joined #vcwg 08:49:34 scribe+ 08:49:38 scribe+ 08:50:01 Olvis has joined #vcwg 08:50:25 SteveC has joined #vcwg 08:51:01 Topic: Recognized Entities 08:51:15 Slides for this topic: https://docs.google.com/presentation/d/1o0zlQKuey26a-nAxTZ94R0FmGChM0mMg6Uy8N8pILEw/edit?slide=id.p1#slide=id.p1 08:51:17 gannan has joined #vcwg 08:51:27 IvoL0 has joined #vcwg 08:51:30 present+ 08:52:20 q? 08:52:25 ack phila 08:52:27 ack manu 08:53:16 https://w3c.github.io/vc-recognized-entities/ 08:53:17 manu: High level overview followed by threat modeling - link to spec in slide deck. 08:53:17 denkeni has joined #vcwg 08:54:17 Olvisgil has joined #vcwg 08:54:33 ... Compare to other technologies. Specification is about who can do what in the ecosystem. Determining if party is authorized to do a specific action. 08:54:41 present+ 08:55:23 q+ 08:55:26 q+ to advocate for avoidance of "allowed to" language and "who can do what" 08:55:33 q- 08:56:50 ... Number of people want this. US vital records have 1000s - book of possibilities. Try to make that easier. Currently, various proprietary bodies manage the data - may be available or not. Trying to do this in a decentralized way. Some governments trying to limit lists. Corner case - 08:57:14 ack JoeAndrieu 08:57:14 JoeAndrieu, you wanted to advocate for avoidance of "allowed to" language and "who can do what" 08:57:22 ... Tight group - tribal use case. 08:57:48 q+ 08:57:59 JoeAndrieu: Naming discussion is lost in these slides. I want to strongly argue against saying that these specs are about "allowed to" - it's about who is "recognized for" a purpose. You can issue whatever you want without recognition - this supports jurisdictional differences. 08:58:21 +1 recognized entities is a good name 08:58:22 manu: spec tries to be clean about addressing recognition. 08:58:35 ack KevinDean 08:59:20 kevin: structured way of saying "I recognize Joe's authority to issue a driver license". Still need root of trust. 08:59:30 s/kevin/KevinDean 09:01:04 manu: three things: RecognizedEntity list - each has RecognizedAction (free form/open) - with JSON schema which must match 09:01:20 q+ to ask why not just use existing web PKI 09:01:47 ... may require other than JSON schema, but using it for now. 09:02:27 ... use case - organization list - like universities - with name/address/contact and no actions 09:02:31 q+ To take co-chair hat off and talk about GS1 use case 09:02:32 q+ 09:02:41 ack phila 09:02:41 phila, you wanted to take co-chair hat off and talk about GS1 use case 09:02:46 q- later 09:02:55 q+ 09:03:57 q- later 09:04:14 ack wes-smith 09:04:19 phila: for GS1 - federated system which distributes licenses to specific GS1 office via a prefix - with multiple hops. Would like open source software to go in scanners. Ideally useful to more than GS1. 09:05:01 wes-smith: don't understand this use case. 09:06:09 q+ 09:06:26 manu: 1) should address GS1 use case at least. 2) how is this recognized entities? someone knows the entity based on some level of info - without any action (see MITDC) 09:07:48 manu: other use case: Joe/Kevin mentioned - any entity - even a single operator - should be able to use this spec. It's not just for big corporations or member states. Decentralized case is enabled. 09:07:52 q+ 09:08:02 ack KevinDean 09:08:54 -> GS1 Data Model for VCs https://ref.gs1.org/gs1/vc/data-model/ 09:09:19 KevinDean: as co-editor of use cases and original GS1 use case - my reading is that it will support those use case. You can add more JSON-LD data. One thing is missing - especially for chains of credentials - 09:09:49 ack brent 09:09:49 brent, you wanted to ask why not just use existing web PKI 09:09:50 ... back reference. 09:10:37 https://fidoalliance.org/fido-alliance-digital-credentials/ 09:10:51 ack shigeya 09:10:52 brent: FIDO has started a digital credential WG - verifier authentication via web PKI - so consider why isn't web PKI sufficient? 09:12:01 wes-smith has joined #vcwg 09:12:08 shigeya: question re slide #4 - bottom text - tons of implications. It's too large. Providing attributes about entity. Addresses trust but not with x509. 09:13:08 manu: started with ETSI but not good for decentralization - so trying to create a bridge to ETSI/x509 09:14:28 manu: text - if need something else for your trust model, you can. Or build a bridge. Serious implications for how you build your trust model. 09:14:43 ack SteveC 09:14:52 shigeya: additional use case to suggest - will provide later 09:15:45 s/provide later/provide later on Originator Profile (OP)/ 09:15:51 SteveC: spec started with "here's a list of things you trust". Scope is not what is in the list. Start with credential and discover the recognized list. 09:17:09 manu: delivering the recognized credential is in scope. 09:18:30 ... use case: cross border trade. (two: product conformity and cross border trade). Multiple disconnected entities and the ability to discover why importer/exporter should be allowed to bring goods in. asks Steve for input. 09:19:40 q+ 09:19:56 SteveC: multiple steps - how does customs verify identity of the entity. Numbers are quite high. Business register gives credential. 09:20:59 ack ivan 09:21:02 ... other related use case is certificate of compliance - national accreditation authority - then who accredits the accreditors. Keep going until arrive at sufficent trust root. 09:21:06 q+ 09:22:01 ivan: is there a verifiable presentation? how does it work? If I see a DID, what do I do with it? 09:22:08 q+ to ask about standardized issuer resolution 09:22:14 q+ 09:22:18 ack Carolynn 09:22:30 wes-smith has joined #vcwg 09:22:47 Carolynn: back and forth is not clear - how do you go up? 09:23:22 ... how do you get to the recognized entity? 09:23:26 q+ 09:23:59 q+ 09:24:14 q- 09:24:23 steveC: particular service endpoint - who is - point to another VC - check invoice then get DID, verify that, is the subject the same? Is the issuer on "the list", then move up. Via an established convention. 09:24:46 Carolynn: why is there not a link? 09:24:47 ack phila 09:24:59 manu: discussion for later 09:25:25 q+ 09:25:55 ack ivan 09:25:56 q+ 09:25:56 SteveC has joined #vcwg 09:26:09 q- 09:26:13 whois is a property of a DID document, and can be in any DID document, not a property of any particular method 09:26:26 ivan: side effect is that to use this, you have to use DIDs. Is this deliberate? 09:26:44 ack shigeya 09:26:45 +1 to the wrinkle about DID entanglement and working to avoid it 09:26:51 manu: group needs to decide - but don't need to entangle it with DIDs. Dangers of connecting VCs to DIDs. 09:27:26 SteveC5 has joined #vcwg 09:27:54 q+ to say the recognized entity credential can be delivered alongside the VC. No entanglement. 09:27:59 ack brent 09:28:12 shigeya: from verifier to accreditation, can create abstract method without using DIDs 09:29:18 brent: original model was fuzzy about issuers - v2 was more specific. Is Recognized Entities more specific? 09:29:46 manu: should not change core spec 09:30:27 q+ 09:30:29 brent: is the approach: controlled identifier document should have specific stuff and here's what it is? Or is that out of scope? 09:31:13 ack JoeAndrieu 09:31:13 JoeAndrieu, you wanted to say the recognized entity credential can be delivered alongside the VC. No entanglement. 09:31:25 manu: alternate - when you configure verifier, configure some Verified Entity lists 09:32:12 q+ 09:32:13 JoeAndrieu: every time you hit an endpoint, you create an opportunity to phone home. 09:32:26 ack SteveC 09:32:30 +1 to allowing but not enforcing both of those approaches, as there are practical tradeoffs in the implementations 09:33:10 SteveC: Could put info in VC but then exporter has to put link into every VC while if it's in their DID, it's there. 09:33:53 ack Carolynn 09:33:56 ... nothing technical keeping from sharing business license in addition to other items, but likely to "fall over constantly" 09:34:17 q+ 09:34:38 q+ 09:34:48 Carolynn: how many things to you have to bundle together before you get to the root of trust. Trust is difficult. Possibility to go up until you hit someone you trust. 09:34:49 ack shigeya 09:35:11 SteveC has joined #vcwg 09:35:36 +1 to talk about verification and validation 09:35:42 q+ to talk about verification and validation 09:35:50 ack wes-smith 09:35:53 shigeya: up to verifier. Verifier has the freedom to decide if they trust at the level they have reached. It's difficult. 09:35:57 s/+1 to talk about verification and validation// 09:36:26 q+ 09:37:06 +1 to Shigeya's observation that it's the verifier policy that prevails (holder doesn't know) and also Wes' comment about group privacy from holder providing what they can 09:37:07 ack phila 09:37:07 phila, you wanted to talk about verification and validation 09:37:11 wes-smith: Privacy/trust implicit sliding scale - tree-like structure. It's not a binary. Group privacy is also not binary. 09:38:13 phila: difference between verification v validation. If spec says check DID - may be forcing proof that is not necessary - less may be enough. It's a policy choice by the validator. 09:38:17 ack SteveC 09:39:04 SteveC: If ATO issues a license and verifier trusts ATO, it's sufficient. 09:39:33 q+ 09:40:04 ... with x509 - go to CA - create/embed chain of trust in advance while this is more flexible. 09:40:25 SteveC has joined #vcwg 09:40:36 brent2 has joined #vcwg 09:40:36 q? 09:40:40 ack shigeya 09:41:14 shigeya: PKI is structured - if you want to add an attribute it is not easily possible - need to create a policy 09:45:30 manu: comparison x.509 CA lists v Recognized Entities VC. Differences in slide chart re format, trust hierarchy, action semantics, onboarding. 09:47:55 ... comparison ETSI trust lists v RE VC. More regulated for ETSI - VC is more flexible. 09:50:58 ... Threat model. Have developed new threat model process for W3C. Applied to Recognized Entities. For various TFs, have done brainstorm for threat model. Example for RE using tool created by Joe - has five threats in three categories: target, implementation and dependency. 09:53:13 ... next, identity stakeholders. Then create a dictionary of all the things in the ecosystem - with coded categories (flow/objects/containers etc.) 09:53:54 q+ to talk about diagraming 09:55:28 I'm trying to understand the difference between process and data flows. In what was presented, after the first read we seem to duplicate VC Issuance. Should one look at data flows as the fundamental blocks for building processes? Or are data flows and processes not related at all? 09:55:35 ... create a flow diagram. I used AI to generate mermaid. Not like existing example but may be sufficient. see slides 09:57:12 ... correction - not slides. 09:57:56 ack JoeAndrieu 09:57:56 JoeAndrieu, you wanted to talk about diagraming 09:58:00 ... only worked on five threats - the group came up with 30+ during discussion - will be overwhelming level of work. 09:58:03 SteveC has joined #vcwg 09:59:24 JoeAndrieu: number of threats is about complexity of the system, not of the threat model. Job is to curate. Expect Mythos will be useful. WG should curate it's knowledge to focus threat info. Creating diagram changes 09:59:50 q+ 09:59:55 ... sensibility during process. 09:59:55 q+ 10:00:27 ack manu 10:00:29 ... can add to tool. 10:01:39 manu: ref something Simone said yesterday - every arrow should be a flow. Should do one for each letter of STRIDE. 10:01:54 JoeAndrieu: curate from that. 10:02:51 manu: won't get done unless we appoint one person for each TF - upfront group effort will take too long - do one person and then group will review. 10:03:29 ack Wip 10:03:55 JoeAndrieu: this actually makes things easier for security committee - they have to do their own TM currently 10:04:06 q+ 10:04:12 ack manu 10:04:22 wes-smith has joined #vcwg 10:04:26 Wip: should diagram system and then threats are revealed 10:05:11 q+ to single editor to wrestle the alligator to the ground 10:05:17 manu: out of the threats - must modify the diagram - but how to make the decision/judgement call. Especially if someone is doing the process independently. = 10:05:21 ack JoeAndrieu 10:05:21 JoeAndrieu, you wanted to single editor to wrestle the alligator to the ground 10:05:36 q+ 10:06:10 ack manu 10:06:16 JoeAndrieu: agree about finding an editor who will wrestle the alligator to the ground - instead of getting feedback in process, go as far as possible first 10:06:47 manu: volunteers to do TM for Recognized Entities - ready in about two weeks 10:07:10 Topic: DI and Barcodes 10:07:27 Topic: Barcodes and data Integrity (Part II) 10:08:13 wes-smith: will recap and continue re Fingerprint List - what can group do? review mechanism (packed hash) - glad to learn about other methods. 10:08:46 q+ to talk about slide 10 (when Wes has finished, no need to interrupt) 10:09:28 ... like bitstring status list - put data on the public web. Includes privacy and security issues so need to minimize data. Make clear in spec: if use bitstring status list, shrink size to smaller list. 10:10:54 ... issues with hashing: reuse absolute index from bitstring status list - is your credential an exact match? Good for group to engage re privacy and security. Need to get it right. 10:11:05 ack phila 10:11:05 phila, you wanted to talk about slide 10 (when Wes has finished, no need to interrupt) 10:11:20 wes-smith has joined #vcwg 10:11:23 https://github.com/wes-smith/vc-forgery-defense 10:11:56 phila: every design choice was made in response to the recognition of a threat. So threats are part of the process. 10:13:00 wes-smith: still useful to do threat model process. see draft github repository just linked. 10:13:03 q+ to how to publish 10:13:30 q+ 10:13:43 q+ to say why updating that way is a stretch 10:13:54 wes-smith: vc forgery defense fits best by doing rev of bitstring status list - rename it VC Status List 10:15:04 ... brent noted earlier that we can't change things except for certain reasons - and security risk is one reason. This meets that requirement. 10:15:15 q- 10:16:03 ivan: This proposed content fits in that requirement. Don't change the short name. 10:16:19 ack manu 10:16:19 manu, you wanted to how to publish 10:16:22 q- 10:16:30 ack brent 10:16:30 brent, you wanted to say why updating that way is a stretch 10:16:54 wes-smith: easy to defend given the increasing urgency of quantum timeline 10:17:19 q+ 10:17:28 q+ 10:17:40 q+ 10:17:54 q- 10:18:16 brent: security issues meant an actual spec is under threat. This scenario is a stretch. But it is a serious risk, therefore it's plausible. 10:18:38 q+ 10:19:11 ... go ahead and be ready if someone asks. 10:19:14 ack manu 10:19:19 brent has joined #vcwg 10:19:35 ack brent 10:19:43 q+ 10:20:09 q+ to propose another path 10:20:24 manu: other option is to put it in VC Barcodes - from DB customer perspective (CA) - potential harm would be catastrophic and W3C can address it 10:20:54 ... definitely not do something all new 10:21:29 ... this is defensible in whatever spec we choose. 10:21:29 ack wes-smith 10:21:38 q+ to offer a suggestion in case Brent hasn't already said it 10:22:27 ack ivan 10:22:27 wes-smith: reason we are accumulating issues via VC BC is because the implementation is happening 10:24:04 q+ 10:24:27 @ivan: consistency of the family matters - feature that isn't barcode dependent can be with cryptosuites - or bitstring status list 10:25:04 ... mitigate in the family, not the document. Also - need to issue a 1.1 for bitstring status list. 10:25:06 ack brent 10:25:06 brent, you wanted to propose another path 10:26:15 ack me 10:26:15 phila, you wanted to offer a suggestion in case Brent hasn't already said it 10:26:17 ack phila 10:26:21 brent: any of the current specs where this kind of fits can be split to include the forgery defense mechanism 10:26:22 q+ to note that a separate document would be the best option, imho 10:26:58 ack wes-smith 10:28:29 wes-smith: agree with brent that there are a lot of ways to do this - but right now we issue digital signatures with keys - that's compromise-able and will become more compromised over time. Perhaps this is part of lifecycle management. Not sure of the right place for this new content but needs to be somewhere. 10:28:54 ack manu 10:28:54 manu, you wanted to note that a separate document would be the best option, imho 10:29:19 ivan: maybe add general text to DI spec and then point to bitstring status list addition. 10:30:36 JoeAndrieu: need deployed VCs to discuss on podcast 10:30:54 brent: thanks! this was awesome. 10:30:58 rrsagent, draft minutes 10:31:00 I have made the request to generate https://www.w3.org/2026/06/04-vcwg-minutes.html ivan 10:31:24 rrsagent, bye 10:31:24 I see no action items