Meeting minutes
<Ivan Herman> Date: 2026-10-29
Welcome and intros
Brent Zundel: Reads guidance on meeting etiquette and rules
<morimori> morimori+
Brent Zundel: Not recording the presentations etc.
Brent Zundel: Kicks off Tour de Table
<Yasushi Minoya> This is Yasushi Minoya @ Sony . My mic is something wrong. Sorry .
progress Tracker
Brent Zundel: goes through https:/
Brent Zundel: Lots of green, but lots of yellow
The progress tracker is at https:/
Brent Zundel: Hope was to have a lot of resolutions to go to CR at this meeting. Not going to happen but how are we doing?
Manu Sporny: That is a conservative view of where we are
Manu Sporny: Things like feature freeze for render method is v close. Threat models missing for some but we do have a base TM for those but not yet integrated
… So it looks worse than where I think we are. After only 6 months, we're doing OK. But we need to pick up hte pace on the PRs
Manu Sporny: Horizontal reviews are slowing us down. It's been at least 3 months for some of them
… In other cases, they're really quick (i18n)
Brent Zundel: As we go through each TF, we can name names so we know who to go after
Manu Sporny: We have a summary of HR for each spec
Manu Sporny: So the tracker looks worse than it actually is.
Wesley Smith: A lot of the HRs are on new versions of existing docs with small deltas so we hoipe for progress
Group documents not covered by task forces
VCDM 2.1
Lucy (Qixue) Yang: I have a comment on the tracker - would it be helpful for someone like me to understand this... could be helpful in discussions with other groups
… Some sort of overview would be helpful
<Joe Andrieu> +1 for implementation guide with new specs integrated
Phil Archer: Offers to have a meeting with Lucy (Qixue) Yang to go through it
Joe Andrieu: Has anyone updated the implementation guide?
Ivan Herman: Find a volunteer!
Issue 1628 on Digest SRI - w3c/vc-data-model#1628
Manu Sporny: Offers apology to Shigeya Suzuki for some of the tone in some of his emails
Manu Sporny: We have 2 ways pf specifying a hash for an external resource, DigestSRI and DigestMultibase
… It is good to have one way rather than two
… Suggestion is to deprecate DigestSRI to leave DigestMultibase. Not remove, just deprecate.
… could be removed in version 2.
Manu Sporny: Being used in Japan and we don't know where else
… Where we got to in the spec... DigestSRI uses the sub resource integrity, another W3C spec, to say this is how we're doing it. However the SRI property as defined in that spec includes a load of stuff that the browser does that we don't.
… We're not using all those features in our work.
Manu Sporny: So the compromise might be to specify what DigestSRI means for VCs and state the rules that we're importing, not the whole thing.
Manu Sporny: If we don't deprecate, then DigestSRI can be used in any other VCDM-based spec. But those specs might also specify one or other
Manu Sporny: Compromise is not deprecate, but state the version of DigestSRI we're using and then let the Task Forces make their own decisions
Shigeya Suzuki: I think Manu capture what we're trying to do
… It's different from SRI in general. So that causes some confusion. So clarification is necessary and is a good compromise
Shigeya Suzuki: If it eliminates part of the processing rule, that's good enough.
Shigeya Suzuki: I'm not sure it's a good idea for a TF to select one or other. Especially... future discussion is closely related to the business wallet - relying on DigestSRI at the moment... Rec Ent spec [Hard to follow in detail, apologies to Shigeya]
Shigeya Suzuki: Limiting options in a spec is usually good but I don't see a need to do that here
… If there are reasons, OK, but I'm not sure
Brent Zundel: Allowed changes covers errata, but this sounds like a substantive change and we need to be careful within our charter.
… So the question to the group is do you agree this compromise is within our charter
Ivan Herman: I am also uncertain whether it's a good idea to allow TFs to make a restriction
Ivan Herman: We are making a coherent family of specs
… But we have already done that as we have talked about JWT as a key format in one spec and in contrast the crypto suites explicitly say they only use the multikey format, not JWT
Ivan Herman: So you can argue we've done it but I don't like it. I know we tend to keep away from JWT but spec-wise not allowing it is perhaps difficult.
Wesley Smith: I was going to say what Ivan Herman just said. Creating branches in the docs is architecturally not ideal
Wesley Smith: It hurst the accessibility of the doc as each one needs the same discussion each time
Manu Sporny: The "restriction" is that we will not create examples with DigestSRI, not make it unusable
<Wesley Smith> +1 to enabling both without requiring granular restrictions
Manu Sporny: If DigestSRI is in the VCDM, it can be used in any spec, we just won't have examples
… in all specs
Manu Sporny: If we start showing examples of every possible version, it gets complicated
… It's confusing if people see that there are 5 different ways to do the same thing. It gives opponents a stick to beat us with as it looks as if we can't make a decision
Manu Sporny: SO it helps if we minimize the number of differences in the examples
Brent Zundel: So it sounds as if we're close to a proposal
Brent Zundel: Discusses a draft proposal
Wesley Smith: What does normatively prefer mean?
Brent Zundel: We won't say SHOULD/MUST
Shigeya Suzuki: Does clarify mean what I proposed in the spec text?
Brent Zundel: Yes
… I'll clarify that in the proposal
<Brent Zundel> PROPOSAL: Moving forward, we will clarify the limitations on using DigestSRI (using the proposal Shigeya Suzuki made) in the core data model spec. Other specifications may choose to only provide examples of one of the digest methods, but won't normatively prefer one over the other.
<Manu Sporny> +1
<Brent Zundel> +1
<ElaineX> +1
<Shigeya Suzuki> +1
<Wesley Smith> +1
<Joe Andrieu> +1
<Phil Archer> +1
<Ivan Herman> +1
<Denken Chen> +1
<Ted Thibodeau Jr.> +1
<Jennie Meier> +1
<Will Abramson> +1
<Ivo Ladenius> +1
<Pierre-Antoine Champin> +1
Brent Zundel: I'm not hearing any objections
RESOLUTION: Moving forward, we will clarify the limitations on using DigestSRI (using the proposal Shigeya Suzuki made) in the core data model spec. Other specifications may choose to only provide examples of one of the digest methods, but won't normatively prefer one over the other.
Test Suite, any open PRs and Issues
Brent Zundel: We have 17 open issues on the test suite and want to get a sense of what this means for 2.1
Brent Zundel: IMO, the suite for 2.0 has served its purpose
Manu Sporny: To speak to the open issues. A number of them are nice to haves, some are important. Not expecting a trememdous change to the 2.1 test suite. The delta from 2.0 is very small
Manu Sporny: Main issue is getting people to update their implementation of 2.0 and re-run the test suite. We know of a lot but it will take time.
… About 6 months of work. We have a new hire starting at DB who will be focused on this.
Manu Sporny: It's going to take about 6 months to go through the whole process. We haven't asked for HR yet. It's work that needs to be done and we need to be on top of it.
Joe Andrieu: What's the relationship between the test suite and the task forces? Will TFs update it?
Brent Zundel: As far as the 2.1 is concerned, I think it would be OK just to test the delta
… W're maintining backwards compatibility
Ivan Herman: I wanted to say almost the same. We have the same thing in another group. WE can reuse the test results from the previous version. What was valid is still valid, we just need to loo at the delta. Don't forget what CR is for. It proves that the spec can be implemented - which we proved for 2.0
Manu Sporny: A delta might be more work than switching out the context. We run the test suite every week (unlike others) so we know which endpoints are up. All we need to do is swap out the context and send that new one and see if they pass the test, we don't even need to contact them
Manu Sporny: But I notice is currently passing 100% of the tests
Manu Sporny: We'll do a copy and paste and find out quickly the state of implemenations
… That's less work than a new delta-only test
Manu Sporny: The confidence method will have its own test suite
… Each TF needs to prepare for that. RE isn't a VCDM test, we need to test the chain
… For the confidence method... I don't think that TFs should assume that the core VCDM 2.1 is going to cover their work
Joe Andrieu: I would expect that if I got a context I didn't expect, it would fail.
Manu Sporny: Some people do fetch the context every time (although we advised against it)
Joe Andrieu: You said you could hit the same endpoints with a new context and expect it to work
Manu Sporny: A small number - we need two, not all
Benjamin Young: I'm trying to figure out what we're testing.
Manu Sporny: The URLs change, not different content at the same URL
Benjamin Young: It's a fishing expedition (not phishing)
Brent Zundel: Much better to talk to people then to just change the test suite without talking to them - that sounds like a recipe for more work than a delta would create
Brent Zundel: Notes that TFs are responsible for test suites for their work.
JOSE_COSE
Brent Zundel: Only open issue is out of scope for maintenance
Ivan Herman: I didn't want to touch the issue, we should label it somehow
Brent Zundel: It is labelled future
JOSE-COSE test suite
Brent Zundel: I don't think we even expect a 2.1 version of the spec so we're not going to touch the test suite
VC JSON schema
Brent Zundel: When we last looked at this, we entered CR and we have never left. There are some open issues, two already labelled future
… Do want to look at one we might cover in CR
… Looking at #248
… The don't call me Dom bot... these links are bad. We probably need to fix this.
Manu Sporny: It's a simple editorial change
Ivan Herman: No need to refer to 2.0, just the versionless URL
Brent Zundel: It is in scope for us, it's editorial, but note that we're not in any pressure to make the change. We can make the change if we hear of a 2nd imp so we could move out of CR
Manu Sporny: We have tooling to fetch the hash and calculate - shouldn't happen again (for SRI or multibase)
Brent Zundel: Discusses w3c/
Brent Zundel: We can close w3c/
Ivan Herman: There is no longer a Proposed Rec stage
… No open PRs for JSOn schema, issues triaged
Ivan Herman: If we want to do any work, do we need new editors?
Brent Zundel: If we get another implementation that would help us get out of CR then we can get it done
Manu Sporny: Is there anyone in the group who is going to implement this.
Brent Zundel: There are specs kept at CR for years deliberately
Manu Sporny: I thought we were better than that :-)
Brent Zundel: VC JSON schema is now fixed.
Brent Zundel: Since this session in the agenda is for docs not in Task Forces, can we look at use cases
Manu Sporny: As we have new people here and remote, perhaps we can ask our guests about their use cases?
Brent Zundel: That sounds like a better idea than jumping into the UCR doc
Joe Andrieu: Kevin Dean and I have been just wrapping up the changes. We had hoped to get it done a while ago. More help always welcome
new use cases
Chris Adams: I'm at the Green Web Foundation. We link domain names to owners who have purchased green energy to power their services. Google is a good example.
… There is an existing cert scheme. We are interested in the VC tech. We need a way to establish a link from a domain to a cert.
… Empowering Consumers in the Green Transition Directive (EU Reg) needs a regularized approach.
… So we're interested in using a Web tech to do this, so I'm exploring
Phil Archer: certification is a key use case for us
Chris Adams: there is a task force meeting tomorrow that tracks this
… UKAS accredits things in the UK, GS1 uses a federated identifier to do this. The Metrology folks are also around. We think we've probably done what you're looking for.
Chris Adams: We're based in NL. Want go through that accreditation process.
Ted Thibodeau Jr.: Several years ago we changed from verifiable claims tov credentials
… since nothing that we do tests the veracity of what we said
… we can prove that Joe Smith said these things, not that what he said is true
Brent Zundel: Any other use cases folks would like to talk about?
Joe Andrieu: There is one major new use case which is the GS1 delegated hierarchy
Kevin Dean: (working at 04:16)
Kevin Dean: If you go to the GS1 use case in section 5.4
Kevin Dean: I used to be with GS1. I was the primary author of the data model that GS1 developed for its VCs
Kevin Dean: Describes GS1. data model is at https:/
… federated system. 754 and 755 are the prefixes for GS1 Canada. GS1 Canada then assigned a prefix beginning with that 75412345
… The chain of credentials starts with GS1 Global Office as the "root of trust"
… What we liked about VCs when we investigated is that it is a self-assembling system
Phil Archer: The DID for GS1 Global Office is did:web:vc.gs1.org
Kevin Dean: Talks through the Healthy Tots use case in the VC UCR
Kevin Dean: Those in the RE TF will recognize this model
Kevin Dean: As I have the prefix from GS1 Utopia, I can create the actuals GS1 identifiers I need.
… We also have data associated with a product. I have to give you data about my product, not just the ID
<Joe Andrieu> https:/
Kevin Dean: There are more advanced concepts but the basic model is straightforward. Because I have this cred, I can issue this other cred
… So given the cred for the ID for a product, you can trace it back to Global Office, similar to X509 with a root of trust
Brent Zundel: In my previous job, we did exactly this flow with the US Customs and Border Protection people. It worked well
Joe Andrieu: I'm not sure where we are with the edits
<Kevin Dean> https:/
Joe Andrieu: The tamper-evident signature means it can't be amended but there is a use case that might need that.
Joe Andrieu: The problem of Mergers and Acquisitions is a big one as the brand is now owned by a different company
Kevin Dean: The nature of sigs means that amendment is not possible.
… But a recent text I wrote... there's a PR for it... I landed on amending a credential is really an indication is that there is an amendment
… This one is no longer valid but there is a new one to replace it
Kevin Dean: Talks through more detail of the use case
Manu Sporny: There's a diagram for the GS1 use case - might be directly relevant to Chris Adams
Manu Sporny: This is the sort of thing we can do with VCs today
<Kevin Dean> https:/
Manu Sporny: We have added a "refresh" status purpose in the status list version 1.1. It saus the VC hasn't been revoked but there's a new version
noting we're at time
Manu Sporny: There are people saying "that use case can be solved with X509, why use VCs?". In the digital cred API discussion 2 days ago - the verifier identity spec, why did you use X509. I asked why didn't you use a VC? Answer was that X509 does it. It would be nice to expand the GS1 use case to explain why you didn't use X509
Ivan Herman: Joe, you frightened me. Did you say there's a property called amend in the VCDM?
Joe Andrieu: No, it's in the UCR, not the VCDM
Brent Zundel: We're 2 minutes over.
… Break until 11:00 GMT
Phil Archer: Tomorrow our meeting will have a hard stop at the scheduled time. The rest of our time together will be spent going through the task forces.
Brent Zundel: This group splits our large number of deliverables into task forces, each of which has its own meetings, leadership, and work items.
<Joe Andrieu> https:/
Brent Zundel: The Confidence Method task force is led by Joe Andrieu and Denken Chen.
Joe Andrieu: We are not quite in horizontal review, which was a goal we had for TPAC. We'll talk about where we are and discuss some aspects of the test suite with the group.
… I will walk through some of the process that we have been going through with the threat model to give folks insight into process and challenges as well as give an update on how it's going.
… We have been tracking a checklist of items before horizontal review. We are working on threat model/security + privacy considerations.
Phil Archer: Could you briefly summarize what Confidence Method is?
Joe Andrieu: Confidence method is a property an issuer can add such that a verifier can increase their confidence that a party is the party in the credential. This could be proving in real time that a party interacting with a website is the person a credential is about.
… It could also be comparing what is in a log to what is in a VC - such as with Confidence Method using DIDs.
… There are two other properties we would like for the future - a key based mechanism, which is either a reference to a DID, a reference to a key in a DID, or embedding the key in the VC. We will use the VM from the DID spec, so if you have the VC you don't have to dereference a DID.
… There are also two biometric related confidence methods - a biometric template, where we have gone to a biometric template creator and created a template, then given that to an issuer who has embedded that in the VC.
… When someone presents the VC a biometric confirmation can be performed with the template.
… This is designed to be open-ended and not bottlenecked - ideally the holder of the credential can use any biometric evaluator that is acceptable to them and the verifier.
… Another is the biometric image confidence method, which does not do this templating, but just contains an image for a human or machine to match against.
… This is not particularly robust, but it is a very common mechanism.
… It allows a human to do the confidence without a machine, which is a use case we want to support.
… In addition we have defined an assurance level property which can be applied to any credential subject - an attestation that, before issuance, the issuer achieved some assurance level according to some external standard.
… The credential does not provide this evidence, but the issuer makes the assertion.
Ivan Herman: practical question - now that I have started to do v2.1 of the vocabulary. For Confidence Method we agreed that the new terms would be folded into the base vocabulary. Is the current work stable enough to start this work?
Joe Andrieu: You should wait, we have outstanding issues to work through.
Ivan Herman: Also, please create a clear URL into your specification for each term you define.
Joe Andrieu: The two confidence methods that we want to get in, but probably will be future are email and phone number as confidence methods.
… Another thing not in the spec but in an issue is that it is our intention to specify that confidence methods should be selectively disclosable.
… This should not be a MUST.
… There are some ways that we might do a test suite that would create PII problems, which suggests that we need to create synthetic data. We don't want to test the implementations or types of confidence methods - we don't want to be in the business of testing external companies' algorithms.
… We need to figure out how to test supporting a feature without testing external companies' logic.
Manu Sporny: It's a good question. One way to approach this is that it's a data model - can you express the properties in the model. However, we could easily test the cryptographic key based confidence methods using a presentation or something like that.
… Maybe we punt on testing the image and biometric template stuff, that can happen out of bounds, and we don't want to test specific implementations.
… I'd suggest the test suite tests the data model at a minimum, and we could do a presentation with a countersignature.
… We could just ask implementers for feedback on the biometric options.
… There are other companies that do this work that could test and contribute implementation reports - but we do not want to block on that and create delays.
Ivan Herman: It is fine IMO for some tests to describe what you should be able to do. The implementer can respond yes/no if that is the behavior they observe - where machines cannot replace human interactions.
… We are not making a judgement on the implementation.
Ivan Herman: Both for confidence method and render method there will be humans in the loop.
Manu Sporny: General point to the group, we steered away from doing biometrics for a very long time, since it comes with privacy risks. What we are trying to do is create a mechanism for privacy-preserving biometrics. We are trying to get to where an individual has the template on their device, matching is done on the device, and a ZKP is expressed that the user used a legitimate template, issued by a trusted authority, and the match happened. That proof is the thing that's sent to the verifier.
… There are vendors that argue that the biometric data and/or match data needs to be sent to a central server, but we know of companies that believe this can be done in a privacy preserving way.
… In the meantime, there will be a mechanism to send a video stream to a server - but selective disclosure makes this the individual's choice to share.
Joe Andrieu: I work on threat modeling efforts at W3C to help groups produce threat models. Threat modeling is different than risk analysis - it is about embodied systems. When you do a risk analysis, you may have concerns, say about weather - but you would mitigate different concerns differently. If you can identify risks clearly, you can address risks. But risks are not tied to embodied systems. In threat modeling, you start with a diagram, which represents the scope of the threat model.
… The diagram I am sharing right now is a dataflow diagram without any flows - I am trying to get components that allow realization of our core three confidence methods.
… Walking through the components, we have an issuer with a device that is running a process that will generate a VC with a confidence method in it.
… Ideally this document would be general across all confidence methods - but this is difficult to do, the language is hard to express in an appropriately general way.
… The big blue boxes up top are where you get evaluation done for issuance, and separately there is evaluation done on verification. A biometric template will be evaluated before issuance - and then in near-real time a verifier must get an evaluation done, but those do not need to be done by the same entity.
… On the bottom of this diagram we have the holder's device and a verifier's device - and since DIDs are involved we have a resolver and a data registry.
… I started adding flows about how these systems would talk to each other so we can talk about the threats that those individual flows create. This gets noisy and confusing, and conflicted with the generic language concept. Now we have the holder and the issuer in a flow where the holder is going to biometric template creation that is being provided somehow. Once of the tricks of what I am trying to do in this diagram is have a single diagram that works in different deployment architectures.
… Right now we are exploring four different kinds of deployments. One is everything on-device, in apps or platform tools - not far from putting your fingerprint on your iOS device. People who want better guarantees can have data capture on the phone but evaluation in the cloud.
… It also could be where you have to go into a facility, either with or without a backend service.
… Looking at the biometric template creation, whoever runs that controls that service.
… There are also security and trust boundaries at the phone application layer.
… I want to enable all these variations to tease out what could go wrong. This is complicated, and I struggled with the flows, since all we have are data models but not flows.
… I first tried this in 2D layout, a sequence diagram to anchor or language in terms of core entities and interactions.
… The idea is that in the spec I want to add these diagrams as descriptions of particular methods.
Manu Sporny: Did you say you expect that this diagram would go in the spec and not the threat model?
Joe Andrieu: Yes, I am not using this to analyze threats, but better model the use cases that need to be threat modeled.
Manu Sporny: I'm wondering about ramifications for other specs - it feels to me like the threat model expects the specification to talk about flows.
… It also embeds some of the talk of flows in there - Simone's review of Recognized Entities requested flows. This seems like an additional requirement on specifications to not only describe data models but also flow, which is not always what working groups have signed up to do.
… I am somewhat uncomfortable with the request to move flows into the main spec - that's my concern.
Phil Archer: I think this should go in the specification.
Brent Zundel: We are expanding beyond data models, I agree that this is a useful thing for the main document.
Manu Sporny: How normative is this?
… These considerations are important.
Phil Archer: My assumption is that there will be spec text that describe this, an illustration of the normative parts of the spec.
Ivan Herman: I believe we have a statement that figures are not normative.
… The description may be.
Wesley Smith: It sound near impossible to have these flows to be expressed normatively without being overly restrictive.
Wesley Smith: When we talked about testing and test suite, lots of these flows are happening out of band, some of which is proprietary logic/systems outside of scope of VC world. Strongly argues to note entities and relations in flows can't be normatively described.
Joe Andrieu: I disagree but acknowledge Ivan Herman's point - figures are not normative, do we want to describe flows. In our community work we have avoided flows and focused on data models. I am hoping this particular flow is normatively specified and at the right level of abstraction if we express it correctly in words.
<Denken Chen> +1 to Brent Zundel
Brent Zundel: when I say flows are good, I am saying I like this particular flow in the confidence method specification. I don't think it needs to be normative - here is an example flow is a useful thing. I don't know that making it normative increases the usefulness of it.
mori: As far as I have been deploying biometrics, the biometric template can be created in different ways - some privacy models impose restrictions here. There are multiple camps, which are both functional. We prioritize privacy at the W3C. I don't care if the content is normative or not, but the position for what this idea/protocol can be applied to could be described.
<Brent Zundel> +1 to sticking with the FIDO guidelines for biometrics (templates never leave the device)
Joe Andrieu: I think we should stick to the use cases listed, but lean into the more privacy preserving use cases, maybe using SHOULDs for the privacy perspective.
Manu Sporny: Out of all of the things said, I align with what Brent Zundel said, which is that this is an example - and the second we get into normative language I get concerned, primarily because we don't know what people are going to use this technology for.
Wesley Smith: This happens often. Putting the thought in someone's head to limit the technology is something to avoid.
… Inclusion of flows should be illustrative examples on a spec-by-spec decision. Normative language for flows is risky.
Denken Chen: +1 to what manu and Brent Zundel are saying, the figure should not be normative, but is important to build up the threat model. People can use data models different than we expect - this is valuable communication material, but normative language can be restrictive.
Phil Archer: Picking up on what manu was saying, a lot of the use cases/incentives for this work is the use case where an individual is proving their identity, so I share the slight concern - jars of jam do not have thumbprints, so a lot of use cases do not involve a mobile device.
Joe Andrieu: One thing I am trying too hard to do is find a single diagram to put all flows in - there are legitimate confidence methods that can be used without wallets. I want this language to be in there, making it not normative is a way to accomplish that.
… Trying to jump immediately to the big diagrams hurts accessibility - flow diagrams are useful intermediates.
… Another point - one of the challenges with DFDs, which is a challenge for all data model specifications, is that the threat model needs to deal with an embodiment in the real world so we can point to the elements that might be the source of the compromise.
<Ted Thibodeau Jr.> (RDF-star is no more. It long ago evolved into RDF 1.2.)
Joe Andrieu: In the RDF world, serialization is a point of compromise, even though the RDF work is largely abstract.
… The threat model is an embodiment, which should not be normative. Threat modeling makes a choice of what is the system under analysis.
Anthony Lopreiato: I was interested that mori suggested human vs nonhuman is a core decision point in these architectures - send to a server vs don't send to a server could be a normative decision point.
Joe Andrieu: I am a huge fan of figuring out the datagram and how it moves - see the IP protocol on which the web is built.
… Constraints on other technologies made them die out in comparison to IP.
Denken Chen: We are moving from physical ID to digital ID, our motivation is to migrate some of these use cases in the face of threats like ID photocopying.
… It's our strategy to move forward in this way.
… There are already images in passports, maybe fingerprints - it's everywhere. We are trying to build a model around that to make it privacy-preserving.
Manu Sporny: Anthony Lopreiato, to the question of "why are we not proposing the on-device biometrics only", you can't get on an airplane with a FIDO authenticator or cross a border. There are countries where video feeds are shared remotely as a non-optional verification step. We need to meet organizations where they are to get onto a set of technologies that move in the right direction.
Wesley Smith: Part of that strategy is naive, but it is our job to provide good options to less privacy-preserving options.
… Our spec will say how we think you should do this - local computation, ZKPs, etc.
ElaineX: I've been on the confidence method calls, I have been focused on people use cases, but was reminded that we need non-human use cases as well. In my forensic work I have exposure to security that relates to product, and there are methods for individualizing product that depict randomness that exists in the product or is injected into the product.
Joe Andrieu: I wanted to address Anthony Lopreiato's question - personal opinion, the W3C has gotten pressure from sovereign states to embed policy decisions in technologies. The best way to get interoperability is to enable policy flexibility. If you are aware that there might need to be policy flexibility, you can support it.
Brent Zundel: Is there an issue tracking this conversation? What decisions are we making?
Joe Andrieu: It would be great to add issues to track - I'll reflect my takeaways as editor. One is that this diagram and its description will not be normative, but the language will go in to make the DFD more accessible. I also like the proposal to lean into a recommendation that you SHOULD use the privacy forward version of this.
Wesley Smith: Brief note about spec writing and accessibility -- spec should mention we want privacy and not weaken technology, idealogical reason for normative language.
FYI: FIDO guidelines for biometrics usage intheir specs: https:/
Manu Sporny: There are interesting uses of confidence method, but we need to draw a line to get to CR - we don't need to raise issues about use cases that relate to future work.
Joe Andrieu: We are feature frozen, so I encourage folks to raise issues but new features will be tracked as future.
Ivan Herman: For me, feature frozen means properties are defined.
Joe Andrieu: I mean use case frozen.
… We are probably a month out of a fully fleshed out threat model, but we will get to horizontal review before the threat model is finalized.
Ivan Herman: all that you said has not yet been seen by the accessibility people - they will probably have good questions.
… i18n could be relevant as well.
Phil Archer: Closing the confidence method slot.
AB Discussion
Brent Zundel: we have synthesized feedback regarding W3C process into things we could change - but there is a process for change the process.
FYI: This is directed by the advisory board, and eventually the advisory committee.
… That is heavy handed for trials/experiments - the first change we would like to see to process is to allow experiments.
… There is a process PR right now that outlines methodology used to run experiments.
… I wanted to let folks know about this and would love to hear feedback on that idea - I will drop a link to the PR in IRC.
<Manu Sporny> Experimental AB Process proposal: https:/
FYI: we have tried to be sensible about the approach - the point is to be able to iterated quickly and move on things without overburdening process with process.
… There is language saying you cannot formally object to an experiment - but it cannot be fielded as an FO and deliberate for a year. This is antithetical to the goal of the experiment notion.
… We also generally want to hear feedback on what WGs are struggling with.
Phil Archer: Can you give an example of a process experiment?
Brent Zundel: The pain points we heard were horizontal review - for example, we could strictly limit the time in which horizontal review has to happen.
Process Experiment PR: w3c/
Joe Andrieu: I like the idea - how it maps for me is that you are talking about providing alternatives to the current process that are allowed, as opposed to experiments that are required. The threat modeling stuff has caused a reaction, in part because it was not approached as an alternative from the start.
Ivan Herman: +1 to the concept, but I am confused on what happens if I do something not per process and then publish the recommendation. Can the recommendation be attacked for improper process?
Brent Zundel: This is what the language attempts to address.
… The AC needs to approve experiments and will not approve egregious process violations.
Manu Sporny: Has the AB considered drafting volunteers (voluntolds) from WGs to serve in horizontal review groups?
Wesley Smith: There are two parts of horizontal review - reading the document and collecting thoughts around what the review should say, and there is getting agreement from groups on if they agree with the review. The blockages in HR are just in bandwidth to review a spec.
… Splitting this out into two parts, review and "review review", could be helpful. WGs could pick people to do reviews.
Phil Archer: On that conscription point, if you see members of the TAG, they need people - everyone complains about horizontal review takes, but we need more people.
Joe Andrieu: We are so oversubscribed with stuff, makes it hard to suggest reviewers. This reminds me of BBS exchange notions.
Wesley Smith: Yes, this is how academic review works, when you submit a paper, you are expected to do a review as well.
Wesley Smith: That is how it works and that is what we're proposing here.
Culture concerns
Brent Zundel: The AB has some concerns about W3C culture - we want it to be as positive as possible. The question to the group is - has the code of conduct been useful in creating positive culture in this group? What can the AB do to promote positive culture?
Joe Andrieu: Both formal objections and code violations are blunt and are hard to wield with nuance, getting action feels like declaring way. Nudges would be great.
Benjamin Young: Both things mentioned are very similar - strong responses that people reach for. Nuance would be great.
… I wonder if the formal objection timeline could be changed to minimize eleventh hour problems.
Phil Archer: We trialed this by signaling our intent to resolve a dispute here at TPAC, so in the lead to TPAC the necessary discussions happened.
Manu Sporny: This group has a good culture now - there was a point where this was not necessarily true. Past meetings have had philosophical divides that were hard to overcome.
Wesley Smith: It's unclear if people leaving the group is a failure mode or an acceptable resolution - W3C tooling did not kick in there, the bifurcation was too extreme.
… Maybe W3C should look at where groups have broken down, and did FOs help there?
… I will also mention that the code of conduct is useful as a reminder but not hugely useful when things are very problematic.
… Examining cases where FOs and the code have failed could help us.
sorry to here that, hope you feel better
Dmitri Zagidulin: I added some slides to the agenda. Thanks to recognized entity group for template to copy
Dmitri Zagidulin: sharing screen
… We will go over what the task force does, what the spec does, the current state of it
… Render method is an extension to the VCDM. It tells you how to display the VC
… Many examples of wallets and software that have come up with custom approaches to display VC data in there applications
… This spec is how the issuer can state in a standard way how they would like the VC to be rendered. Color, font, logo, etc
… The issuer expresses their preferences for rendering
… Issuer cannot and should not control consumer software for how a VC is displayed
… Should be overridable by consumer preferences
… To do so this involved no issuer provided templates. But this is likely beyond this version of the spec
… 3 basic mechanisms have been proposed
… The render method is dispatched off of specific render suites. Similar to how proof uses different cryptographic suites
… The 3 main suite types in this spec are static, summary and html
… Render method also supports community extensions
… Static render method is a way for the issuer to define a prerendered VC in the method. E.g. an image
… This is how open badges project handled this
… The issuer prerenders a payload and either embeds the payload statically into the VC itself. Or links to an externally hosted payload
Dmitri Zagidulin: There is an ongoing debate as to whether anything should be prerendered by the issuer
… A use case for this, has been from the VC over NFC. So that a tap to share VC flow can display some minimal representation
… A recurring theme is the trade offs between security and usability of these renderSuites
Manu Sporny: I wanted to point out, you might have meant NFC rather than bluetooth.
Dmitri Zagidulin: Yep
Manu Sporny: NFC usecases are important for us because of first responder use cases in emergency situations
Wesley Smith: The ability for first responders to tap to share VCs without relying on a network
Dmitri Zagidulin: Are you sending full credential or a subset
Manu Sporny: A subset. Another example are metro transit cards, which would also send over a subset via NFC
Wesley Smith: These are just some examples of where we are using VCs
Joe Andrieu: Could you unpack why the delivery mechanism, which feels protocolly, is in here?
Dmitri Zagidulin: Naming is hard and historical. This is intended as a dispatch mechanism for the protocol. It signals that the consuming client has some protocol in mind and needs to be able to select which suite to use
Dmitri Zagidulin: NFC for example have no media type. We needed a separate field as a dispatch mechansim
Joe Andrieu: To echo back, this is an advertisement to wallet software to select how to render
Dmitri Zagidulin: Diving into the main question with the static method
… How are we expected this to be implemented and what sort of payloads are we expecting
<swcurran> Might want to add to "limits" -- unilingual
Dmitri Zagidulin: This will help us frame our threat model analysis etc
First, lets look into how the other two render methods work
… Next is summary
This was initially named a card suite
… This should be familiar to anyone that has used the current generation of VC wallets, or apple/google wallets etc
… This is the representation of a VC as a virtual plastic card
… If you look at the data model for how apple / google wallet represent credentials. It is a static set of fields including name, color, image and other metadat about the credential
… This suite is unique in that it serves multiple purposes. It defines a constrained set of known fields that consumers rendering this card style format can use
… In addition, it serves as a general purpose bag of metadata about this displaying
… This includes field labels and field types
… Internationalization and any other display metadata
… The name itself is a tenuous compromise, we are not exactly satisfied
… Finalizing the name of this suite is one of the remaining items
Ivan Herman: Looking at it with my vocabulary hat on
… I am a bit bothered that we have payload as a property, whose behaviour is very different from the static renderSuite
… The static version of the payload, was a data URL
Dmitri Zagidulin: No, that was an artifact of the example
… In the JSONLD format, it is either a single URL, or this value object with this media type
Ivan Herman: I misunderstood what you said.
Dmitri Zagidulin: I could be a data URL or an external. There is the phone home mitigation that needs to be discussed
Joe Andrieu: Seems like you are using the ID as a URL so it is expected that people would hit that URL
Dmitri Zagidulin: Yep, this is somethingg the group needs to advise developers on
… All use the same pattern. And in all of them the phone home trade off comes into paly
… In many we can embed the data directly. No phone home. Works offline. However, in some cases these artifacts will be too large, so processors will not be able to load it in memory
… Issuers sometimes want the ability to change/update the payload. Either the bit string status list, or how the credentialis displayed
… This only works if it is externally hosted
… Of course, this brings in phone home and all of the associated concerns
… For some render methods the trade offs work better than others
… For the summary and HTML render method the payload is the same for everyone. However, with static the payload is unique to individual credentials
Manu Sporny: I dont think there is anything new here going on that is any different from bit string status list
except for the pre-rendered?
Wesley Smith: some things Dmitri Zagidulin made me think we need to give advice if there are unique strings
… There are mitigations we can use here. E.g. use oblivious HTTP
<Dmitri Zagidulin> right, except for pre-rendered
Wesley Smith: The generic guidance is, if there is a unique URL that can identify the individual credential do no do it. Embed the data
Joe Andrieu: I would like to see bit string status list change. With bit string status list, you could have the holder get the status list
Manu Sporny: You can. There is a mechsnism being added to presentation that would allow you to do this
Joe Andrieu: Utah may have an issue with this, this is a latent phone home capability. It assumes that the issuer will care
… We should not give issuers the ability to have this capability
Dmitri Zagidulin: This is not just a problem to render method. The entire WG has this issue. We need good answers and mitigations to the phone home problem
Dmitri Zagidulin: Continuing to the HTML iframe render suite
… short name HTML
… Other names considered are sandbox, sandbox iframe etc
… At the moment we are sticking with html
… Similar pattern to the others. A suite id. A payload, that is either embedded or external
… And a number of metadata that goes along with it
… Key difference is that a consuming client retrieves the payload and opens it in a sandboxed iframe
… This is sandboxed to turn off net access, JS, navigation etc
… This has both advantages and disadvantages that we will get into
… INcluding how you display linked credentials
… The summary render suite is great for displaying a bit long list of credentials, html suite is intended for displaying the detailed view of the VC
… It enables the issuer to flexibly define using HTML, CSS and JS in a sandboxed way how they want the VC to be rendered
… One of the issues we still need to figure out is how to mitigate data exfiltration
… It is possible to exfiltrate data using an image tag for example
… As a baseline, this follows the overall VCDM data model. It is really the reputation of the issuer and the issuer is being trusted here
… Data exfiltration and sandboxing is a key issue here
… We want to lock it down, but also want the flexibility of html, CSS and JS. Need to figure out how to balance this tension
… With the recognized entity taskforce, there is the notion that all credentials will be chained credentials. Where one VC links to others that then link to others
… how do we navigate what is essentially hypertext but in VC form
… Another example is in these nested records e.g. in health or education
… These have an overall top level VC where inside is embedded VCs with their own signatures
… How does render method work for this complex thing?
… What if each embedded credential has its own render method
Brent Zundel: 30 min remaining
Benjamin Young: For the chained stuff from UNTP, where there is just a link that someone is expected to click. Wouldnt the summary mechanism be better here
Dmitri Zagidulin: Yep, that is one of the mitigation methods that we need to decide as a group
… Patrick proposed another render suite. There is the ability for the rendered iframe to talk to the parent application
… E.g. for the user clicking to render a linked credential
Will Abramson: I wondered when we think about rendering for paper, would that be HTML?
Dmitri Zagidulin: On of the founding usecases/painpoints for render method was paper and pdf
… Lots of government initiatives are very careful to state that these digital VCs will be equivalent to the physical ones. E.g. paper and card credentials. How do you translate
… The HTML method is one of the possibilities
… There is a different renderSuite being explored that uses mustache and string substitution to fill in fields in a template.
… If the issuer has provided a paper layout for the credential, you can load the template and fill in the attributes to generate a pdf
… Others have argued that it is possible to generate a PDF in the iframe and then pass this back to the parent for printing
Dmitri Zagidulin: Yes, we need to be able to print this to paper. HTML method is one of the approaches. The other is a template/mustache method. This did not make the cut for the three suites in 1.0. It will be in the appendix
Brent Zundel: When the presentation started, I thought it was good that the group had picked three and settled
… Interested to hear what the plan is to fully constrain this, so everything is written that needs to be written so we can move it to CR
… Lets constrain the scope, so this work item can progress
Dmitri Zagidulin: Completely understand. Lots of things we can do, constrained by charter and getting 1.0 out the door
… We do think that between these three we can cover all the existing use cases
Manu Sporny: The way this is being presented makes it seem like less is locked down than it is. We are going to have to cut features aggressively
Wesley Smith: PDF is on the chopping board for 1.0, we can add it later
… static is locked down pretty well. HTML is locked down. What is not locked down right now is summary due to internationalization
… We have picked. It is those three. We need to cut features if anything is going to drag on
Dmitri Zagidulin: Agreed. We have a plan. Settled on three. A few issues to lock down. PDF will probably be on the chopping block
<George McEwan> PDF = Pretty Dead Format
Phil Archer: Sounds like a future version of this would have a lovely button to generate a PDF with barcode. Lets not do that this time
Phil Archer: What is the outputPreference access Mode option in the renderMethod object for html
Brent Zundel: It is serving as a dispatch mechism for consuming client. When I want to reach for this HTML render suite
Brent Zundel: You can have multiple render methods in the same VC
Dmitri Zagidulin: Yes and that is important.
… You could have a HTML, summary and static. Or a different renderMethod per locale
… That is why the issuer needs to signal for consumers which ones they should choose
Benjamin Young: If its a HTML one, accesMode and outputPreferences could be a big list e.g. audio
Dmitri Zagidulin: Same phone home considerations present. Embedded vs external. It is possible to embed html is one line data url, its just going to be large
… All three have similarities
Dmitri Zagidulin: Horizontal reviews. Internationalization in progress. Pro
… Privacy is complete. The rest we are waiting to hear back from. Apart from TAG review, this is not yet filed
Dmitri Zagidulin: I will file the TAG review this week
… The main topics are
… Topic 0, phone home mitigation. Embedded vs linked. Offline vs online use cases. Group privacy. In the case of the static method how to avoid external links as a one to one correspondence with a person and there credential
… We need to finalize the names, the localization and the question of whethere we have time for community supplied render methods. likely no
… We also need to finalize whats in scope for 1.0
… A main consideration about the static method that we need to get a sense of from the implementers. What exactly are the desired use cases for it
… manu brought up the NFC use case. Necessarily small. Great candidate for embedding
… If implementers have other use cases for larger static prerendered payloads, then we are going to have a problem. Either to embed, with size problems or link to issuer hosted with a phone home problem
… No mitigations from herd privacy. It is your credential hosted somewhere
… The phone home threat could be mitigated if the user is hosting there own rendering of the VC
… May not have time for this
Lucy (Qixue) Yang: Seems like the MVP features have not been finalized yet. Would you like a real world use case
Dmitri Zagidulin: We would love to hear them.
Lucy (Qixue) Yang: Lets take it offline
Dmitri Zagidulin: Usually caveats of late stage charter wg
Manu Sporny: I suggest that we don't give guidance this time around and see what implementers do during CR
Wesley Smith: I know to answer the question on the screen. We plan to implement static and only embed small payloads in there. We will not link to large external files
Dmitri Zagidulin: I agree with you. We probably dont have time to do other mitigations
Dmitri Zagidulin: Some issues need to be decided by the VCWG as a whole
… How are we going to do localization and internationalization for the VCDM as a whole. But specifically for these render methods
… Remaining discussion. We need to finalize the suite names. If no consensus reached, we will stick with static, summary and html. May be changes to summary or html, but only if we can reach consensus
… We are working to update the context and vocab
… Some editorial cleanup also needed
Dmitri Zagidulin: Overall plan is to address the PRs from internationalization reveiw
… Also a big one, how do we test this thing
… Testing data model specifications is hard
… render method has an extra challenge because its visual. How do you test visuals
… There is a body of work around this
… and questions?
Dmitri Zagidulin: The main issue to figure out is what will issuers want to do with the static suite. Can the group get away with saying embedded only for static?
… Question 2 is HTML apps have a rich history of internationalization and localization. How do we do this for static and summary
… We have the inherited JSONLD and VCDM mechanisms. Including language tag and language direction
… One of the debated issues is, do we use language content negotiation when fetching externally hosted resources or not
… What about embedded resources
… What do we do about noting which languages are given render method addresses
… There is some pushback that this may be duplicating the http accept language mechanism
… Internationalization flagged that accept language is not widely used. We may need to do something else
Phil Archer: Perfectly happy that static only has embedded
Brent Zundel: On the language side, I am struggling with the idea of fetching a set of localized set of strings.
… The VCs that we have been caring about, have been small. While they can be big, lets start with what we are familiar with
… There are multilingual countries. But in general they are one or two countries. Stick the localization data in the JSONLD
… That may be good enough. Dont have to support all languages in all VCs. VCs are likely to have a constrained set of languages to be handled
Benjamin Young: As render method is coming from the issuer, in theory they already know which languages are relevant to the people they are issuing to. Ideally have multi-language information at issuance time
… I dont think it makes sense to fetch it from the server
Dmitri Zagidulin: Thank you everyone. We will get this thing out the door. Please help with test suite
Brent Zundel: Thanks everyone, see you tomorrow at 9:45