Meeting minutes
<Ivan Herman> Date: 2026-06-04
Brent Zundel: Welcomes the group, thanks the host, asks everyone to follow code of conduct. Today first session is bar code and data integrity.
Barcodes and DI
Wesley Smith: will do something different today. Will talk about recent work not directly related to barcode but credential status. Was are the next steps
Wesley Smith: Work is a forgery defense technique for VCs
The group discusses internet connectivity issues
<Will Abramson> https:/
Joe Andrieu: A group is claiming that a DID method is standardised by W3C because they have registered in the DID registry.
Manu Sporny: Data integrity for VC barcodes. digital signatures should be added to barcodes. Need to get signature sizes small enough to fit in barcodes.
… 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 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 post-quantum content in a CR by TPAC. But Skisign may not be included.
<Joe Andrieu> FWIW, Apple's open source supports ML-KEM and ML-DSA,
Ivan Herman: 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 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.
Brent Zundel: 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 freaking out on this for us !
Phil Archer: TPAC is only 4 months away. Will PQR examples be added to the document ?
Joe Andrieu: apple's annoucement on PQ software libs.
Manu Sporny: 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 to let it drift. Something to consider for workload.
Ivan Herman: These are crypto-suites that we standardised, so this should not be a problem.
Manu Sporny: 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.
… examples ? Yes we need 8 hours or so to add another tab for examples, with gigantic signature for QR.
… 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.
Ivan Herman: 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?
Manu Sporny: Greg would probably be happy to do this.
… He is capable of not being too technical and has the credibility for this. Try to talk to him next week.
Wesley Smith: 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 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 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.
… 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.
… assumption is hash function is not broken by PQC and this is a common assumption.
… Three usage modes. implicit, explicit, standalone for both back and forwards compatibility.
… issuers take VC they have already issued and piggyback existing VC status entry and index to piggiback fingerprint list and index.
explicit is for the future, add a credential status field to a VC. Standalone is for custom or applications-defined deployments.
Brent Zundel: accumulators or Merkle trees are being considered ?
<Shigeya Suzuki> +1 (one of my questtion is same)
Wesley Smith: 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.
Brent Zundel: is this partial compromise assumption ?
Wesley Smith: yes. The fingerprint list can be signed by different schemes and different keys. If we compromise both, this indeed adds nothing.
wil: credential hash means C14N ?
Wesley Smith: yes
wil: did not understand explaination around merkle tree and accumulators.
Wesley Smith: 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.
Manu Sporny: 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,
… 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.
Shigeya Suzuki: what is the purpose of the seedbytes in the has ?
Wesley Smith: 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 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.
Kevin Dean: 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
Joe Andrieu: both services are completely distinct. This is an advantage to key rotation. Other advantage is that mechanisms can be changed.
Wesley Smith: the lists are short-lived, so many adaptations can be made on even a daily basis.
Brent Zundel: is this a seperate document, specification? where has this been incubated ?
Wesley Smith: 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.
Brent Zundel: official charter designation is that no new features can be added to bitstring status. Justification needed.
Wesley Smith: do this mean that the existing status list spec cannot be modified.
Brent Zundel: reads the charter to try to clarify reasoning the justification.
<Steve Capell> Testing IRC
Manu Sporny: first reason is that this is a PQ key compromise so this is a security issue. d
The team had to break due to a fire alarm.
Brent Zundel: preference is to move to recognized entity now
Recognized Entities
<Manu Sporny> Slides for this topic: https:/
<Ganesh Annan> https:/
Manu Sporny: High level overview followed by threat modeling - link to spec in slide deck.
… Compare to other technologies. Specification is about who can do what in the ecosystem. Determining if party is authorized to do a specific action.
… 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 -
Manu Sporny: Tight group - tribal use case.
Joe Andrieu: 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.
<Will Abramson> +1 recognized entities is a good name
Manu Sporny: spec tries to be clean about addressing recognition.
Kevin Dean: structured way of saying "I recognize Joe's authority to issue a driver license". Still need root of trust.
Manu Sporny: three things: RecognizedEntity list - each has RecognizedAction (free form/open) - with JSON schema which must match
… may require other than JSON schema, but using it for now.
… use case - organization list - like universities - with name/address/contact and no actions
Phil Archer: 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.
Wesley Smith-smith: don't understand this use case.
Manu Sporny: 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)
Manu Sporny: 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.
<Phil Archer> GS1 Data Model for VCs
Kevin Dean: 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 -
Kevin Dean: back reference.
<Ganesh Annan> https:/
Brent Zundel: FIDO has started a digital credential WG - verifier authentication via web PKI - so consider why isn't web PKI sufficient?
Shigeya Suzuki: question re slide #4 - bottom text - tons of implications. It's too large. Providing attributes about entity. Addresses trust but not with x509.
Manu Sporny: started with ETSI but not good for decentralization - so trying to create a bridge to ETSI/x509
Manu Sporny: text - if need something else for your trust model, you can. Or build a bridge. Serious implications for how you build your trust model.
Shigeya Suzuki: additional use case to suggest - will provide later on Originator Profile (OP)
Steve Capell: 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.
Manu Sporny: delivering the recognized credential is in scope.
… 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.
Steve Capell: multiple steps - how does customs verify identity of the entity. Numbers are quite high. Business register gives credential.
… other related use case is certificate of compliance - national accreditation authority - then who accredits the accreditors. Keep going until arrive at sufficent trust root.
Ivan Herman: is there a verifiable presentation? how does it work? If I see a DID, what do I do with it?
Carolynn Bernier: back and forth is not clear - how do you go up?
Brent Zundel: how do you get to the recognized entity?
Steve Capell: 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.
Carolynn Bernier: why is there not a link?
Manu Sporny: discussion for later
<Joe Andrieu> whois is a property of a DID document, and can be in any DID document, not a property of any particular method
Ivan Herman: side effect is that to use this, you have to use DIDs. Is this deliberate?
<Joe Andrieu> +1 to the wrinkle about DID entanglement and working to avoid it
Manu Sporny: group needs to decide - but don't need to entangle it with DIDs. Dangers of connecting VCs to DIDs.
Shigeya Suzuki: from verifier to accreditation, can create abstract method without using DIDs
Brent Zundel: original model was fuzzy about issuers - v2 was more specific. Is Recognized Entities more specific?
Manu Sporny: should not change core spec
Brent Zundel: is the approach: controlled identifier document should have specific stuff and here's what it is? Or is that out of scope?
Manu Sporny: alternate - when you configure verifier, configure some Verified Entity lists
Joe Andrieu: every time you hit an endpoint, you create an opportunity to phone home.
<Wesley Smith-smith> +1 to allowing but not enforcing both of those approaches, as there are practical tradeoffs in the implementations
Steve Capell: 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.
… nothing technical keeping from sharing business license in addition to other items, but likely to "fall over constantly"
Carolynn Bernier: 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.
Shigeya Suzuki: up to verifier. Verifier has the freedom to decide if they trust at the level they have reached. It's difficult.
<Joe Andrieu> +1 to Shigeya Suzuki's observation that it's the verifier policy that prevails (holder doesn't know) and also Wesley Smith' comment about group privacy from holder providing what they can
Wesley Smith-smith: Privacy/trust implicit sliding scale - tree-like structure. It's not a binary. Group privacy is also not binary.
Phil Archer: 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.
Steve Capell: If ATO issues a license and verifier trusts ATO, it's sufficient.
… with x509 - go to CA - create/embed chain of trust in advance while this is more flexible.
Shigeya Suzuki: PKI is structured - if you want to add an attribute it is not easily possible - need to create a policy
Manu Sporny: comparison x.509 CA lists v Recognized Entities VC. Differences in slide chart re format, trust hierarchy, action semantics, onboarding.
… comparison ETSI trust lists v RE VC. More regulated for ETSI - VC is more flexible.
… 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.
… next, identity stakeholders. Then create a dictionary of all the things in the ecosystem - with coded categories (flow/objects/containers etc.)
<Ganesh Annan> 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?
Manu Sporny: create a flow diagram. I used AI to generate mermaid. Not like existing example but may be sufficient. see slides
… correction - not slides.
Manu Sporny: only worked on five threats - the group came up with 30+ during discussion - will be overwhelming level of work.
Joe Andrieu: 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
… sensibility during process.
… can add to tool.
Manu Sporny: ref something Simone said yesterday - every arrow should be a flow. Should do one for each letter of STRIDE.
Joe Andrieu: curate from that.
Manu Sporny: 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.
Joe Andrieu: this actually makes things easier for security committee - they have to do their own TM currently
Will Abramson: should diagram system and then threats are revealed
Manu Sporny: out of the threats - must modify the diagram - but how to make the decision/judgement call. Especially if someone is doing the process independently. =
Joe Andrieu: 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
Manu Sporny: volunteers to do TM for Recognized Entities - ready in about two weeks
DI and Barcodes
Barcodes and data Integrity (Part II)
Wesley Smith-smith: will recap and continue re Fingerprint List - what can group do? review mechanism (packed hash) - glad to learn about other methods.
Joe Andrieu: 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.
… 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.
Wesley Smith/
Phil Archer: every design choice was made in response to the recognition of a threat. So threats are part of the process.
Wesley Smith-smith: still useful to do threat model process. see draft github repository just linked.
Wesley Smith-smith: vc forgery defense fits best by doing rev of bitstring status list - rename it VC Status List
… Brent Zundel noted earlier that we can't change things except for certain reasons - and security risk is one reason. This meets that requirement.
Ivan Herman: This proposed content fits in that requirement. Don't change the short name.
Wesley Smith-smith: easy to defend given the increasing urgency of quantum timeline
Brent Zundel: security issues meant an actual spec is under threat. This scenario is a stretch. But it is a serious risk, therefore it's plausible.
… go ahead and be ready if someone asks.
Manu Sporny: other option is to put it in VC Barcodes - from DB customer perspective (CA) - potential harm would be catastrophic and W3C can address it
… definitely not do something all new
… this is defensible in whatever spec we choose.
Wesley Smith-smith: reason we are accumulating issues via VC BC is because the implementation is happening
@Ivan Herman: consistency of the family matters - feature that isn't barcode dependent can be with cryptosuites - or bitstring status list
… mitigate in the family, not the document. Also - need to issue a 1.1 for bitstring status list.
Brent Zundel: any of the current specs where this kind of fits can be split to include the forgery defense mechanism
Wesley Smith-smith: agree with Brent Zundel 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.
Ivan Herman: maybe add general text to DI spec and then point to bitstring status list addition.
Joe Andrieu: need deployed VCs to discuss on podcast
Brent Zundel: thanks! this was aWesley Smithome.