06:47:59 RRSAgent has joined #vcwg 06:48:04 logging to https://www.w3.org/2026/10/29-vcwg-irc 06:48:04 RRSAgent, make logs Public 06:48:05 please title this meeting ("meeting: ..."), ivan 06:48:46 Meeting: Verifiable Credentials Working Group F2F @ TPAC 2026, Dublin, 1st day 06:48:46 Date: 2026-10-29 06:48:46 Agenda: https://docs.google.com/presentation/d/19vlKzO5nZjsVMVPmuI40jdSGW3kGUtAC1ngW-yQOC6g/edit?slide=id.p#slide=id.p 06:48:46 chair: brent, phila 06:48:47 ivan has changed the topic to: Meeting Agenda 2026-10-29: https://docs.google.com/presentation/d/19vlKzO5nZjsVMVPmuI40jdSGW3kGUtAC1ngW-yQOC6g/edit?slide=id.p#slide=id.p 08:49:39 manu-tpac has joined #vcwg 08:51:36 present+ 08:51:52 present+ manu, phila, brent, shigeya, joe 08:53:45 phila has joined #vcwg 08:58:43 TallTed has joined #vcwg 09:01:31 present+ wip, lucy, ivo 09:01:50 present+ TallTed 09:02:48 Wip has joined #vcwg 09:02:54 present+ 09:03:06 present+ 09:03:08 scribe+ 09:03:37 wes-smith has joined #vcwg 09:03:38 Lucy has joined #vcwg 09:03:51 present+ ingo 09:03:55 brent has joined #vcwg 09:04:01 present+ elaine 09:04:02 taki has joined #vcwg 09:04:08 present+ 09:04:10 Topic: Welcome and intros 09:04:12 JoeAndrieu has joined #vcwg 09:04:16 chair: brent 09:04:22 IvoL has joined #vcwg 09:04:24 swcurran has joined #vcwg 09:04:34 present+ 09:04:41 JennieM has joined #vcwg 09:04:41 present+ 09:04:44 present+ 09:04:45 present+ 09:04:46 present+ 09:04:47 Yas has joined #vcwg 09:04:54 present+ 09:05:00 present+ 09:05:04 RRSAgent, make logs public 09:05:10 RRSAgent, draft minutes 09:05:11 I have made the request to generate https://www.w3.org/2026/10/29-vcwg-minutes.html phila 09:05:14 morimori has joined #vcwg 09:05:14 George has joined #vcwg 09:05:23 KevinDean has joined #vcwg 09:05:26 present+ 09:05:36 present+ 09:05:36 bumblefudge has joined #vcwg 09:05:39 present+ 09:05:40 brent: Reads guidance on meeting etiquette and rules 09:05:41 kseufer has joined #vcwg 09:05:49 morimori+ 09:05:57 brent: Not recording the presentations etc. 09:06:04 present+ morimori 09:06:07 present+ 09:06:10 s/morimori/present 09:06:16 brent: Kicks off Tour de Table 09:06:20 present+ bigbluehat 09:06:26 present+ wesley 09:07:03 ElaineX has joined #vcwg 09:08:20 present+ curran, pchampin 09:08:36 present+ denkeni 09:11:29 present+ jennie 09:12:01 present+ kevin 09:12:15 This is Yasushi Minoya @ Sony . My mic is something wrong. Sorry . 09:12:22 ngwlf has joined #vcwg 09:12:32 KevinDean has joined #vcwg 09:12:35 present+ 09:12:41 ReinaldoFerraz has joined #vcwg 09:13:10 present+ yas 09:13:13 present+ 09:13:18 Topic: Agenda review 09:13:28 ingo has joined #vcwg 09:13:30 brent: goes through https://docs.google.com/presentation/d/19vlKzO5nZjsVMVPmuI40jdSGW3kGUtAC1ngW-yQOC6g/edit?slide=id.h13f76a469fd9a353_0_0#slide=id.h13f76a469fd9a353_0_0 09:15:17 Topic: progress Tracker 09:15:26 brent: Lots of green, but lots of yellow 09:15:47 The progress tracker is at https://docs.google.com/spreadsheets/d/1OM-UsLnOZKywcy1eSGZsi_laCHBIy5wmQFOer0a7kYI/edit?pli=1&gid=67467047#gid=67467047 09:16:21 brent: Hope was to have a lot of resolutions to go to CR at this meeting. Not going to happen but how are we doing? 09:16:34 q+ to speak to the up to dateness 09:17:00 ack manu-tpac 09:17:00 manu-tpac, you wanted to speak to the up to dateness 09:17:02 manu-tpac: That is a conservative view of where we are 09:17:04 present+ 09:17:36 manu-tpac: 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 09:17:49 q+ 09:18:03 ... 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 09:18:23 manu-tpac: Horizontal reviews are slowing us down. It's been at least 3 months for some of them 09:18:42 ... In other cases, they're really quick (i18n) 09:19:07 brent: As we go through each TF, we can name names so we know who to go after 09:19:17 manu-tpac: We have a summary of HR for each spec 09:19:28 ack wes-smith 09:19:28 manu-tpac: So the tracker looks worse than it actually is. 09:19:50 taki has joined #vcwg 09:19:55 wes-smith: A lot of the HRs are on new versions of existing docs with small deltas so we hoipe for progress 09:20:16 Topic: Group documents not covered by task forces 09:20:26 Subtopic: VCDM 2.1 09:21:10 Lucy: 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 09:21:29 ... Some sort of overview would be helpful 09:21:33 q+ 09:21:43 ack phila 09:21:46 +1 for implementation guide with new specs integrated 09:22:17 q+ 09:22:25 ack JoeAndrieu 09:22:34 phila: Offers to have a meeting with Lucy to go through it 09:22:46 JoeAndrieu: Has anyone updated the implementation guide? 09:22:53 ivan: Find a volunteer! 09:23:13 q+ for an apology to shigeya on this issue. 09:23:15 Subtopic: Issue 1628 on Digest SRI 09:23:30 ack manu-tpac 09:23:31 manu-tpac, you wanted to discuss an apology to shigeya on this issue. 09:23:49 manu-tpac: Offers apology to Shigeya for some of the tone in some of his emails 09:24:11 manu-tpac: We have 2 ways pf specifying a hash for an external resource, DigestSRI and DigestMultibase 09:24:18 ... It is good to have one way rather than two 09:24:50 ... Suggestion is to deprecate DigestSRI to leave DigestMultibase. Not remove, just deprecate. 09:25:04 ... could be removed in version 2. 09:25:14 manu-tpac: Being used in Japan and we don't know where else 09:26:13 ... 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. 09:26:33 ... We're not using all those features in our work. 09:27:02 manu-tpac: So the compromise might be to specify what DigestSRI means for VCs and state the rules that we're importing, not the whole thing. 09:27:39 manu-tpac: 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 09:28:07 manu-tpac: Compromise is not deprecate, but state the version of DigestSRI we're using and then let the Task Forces make their own decisions 09:28:14 q+ 09:28:21 shigeya: I think Manu capture what we're trying to do 09:28:25 ack shigeya 09:29:01 ... It's different from SRI in general. So that causes some confusion. So clarification is necessary and is a good compromise 09:29:11 q+ to talk about allowed changes 09:29:29 shigeya: If it eliminates part of the processing rule, that's good enough. 09:29:42 q+ 09:30:49 shigeya: 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 Shegeya] 09:31:18 shigeya: Limiting options in a spec is usually good but I don't see a need to do that here 09:31:29 ... If there are reasons, OK, but I'm not sure 09:31:40 ack brent 09:31:40 brent, you wanted to talk about allowed changes 09:31:42 s/Shegeya/Shigeya/ 09:32:15 brent: Allowed changes covers errata, but this sounds like a substantive change and we need to be careful within our charter. 09:32:17 q+ 09:32:40 ack ivan 09:33:01 ... So the question to the group is do you agree this compromise is within our charter 09:33:15 q+ 09:33:22 ivan: I am also uncertain whether it's a good idea to allow TFs to make a restriction 09:33:31 q+ to say perhaps recommend and may 09:33:32 q+ to speak to the "restriction". 09:33:36 ivan: We are making a coherent family of specs 09:34:17 ... 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 09:34:58 ack wes-smith 09:34:58 ivan: 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. 09:35:23 wes-smith: I was going to say what Ivan just said. Creating branches in the docs is architecturally not ideal 09:35:27 q+ to say all JWT is already supported, so it doesn't need to be in DI 09:35:46 wes-smith: It hurst the accessibility of the doc as each one needs the same discussion each time 09:35:53 ack manu-tpac 09:35:53 manu-tpac, you wanted to speak to the "restriction". 09:36:31 manu-tpac: The "restriction" is that we will not create examples with DigestSRI, not make it unusable 09:36:35 +1 to enabling both without requiring granular restrictions 09:36:50 ... If DigestSRI is in the VCDM, it can be used in any spec, we just won't have examples 09:37:01 ... in all specs 09:37:23 manu-tpac: If we start showing examples of every possible version, it gets complicated 09:38:16 ... 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 09:38:22 ack brent 09:38:22 brent, you wanted to say perhaps recommend and may and to say all JWT is already supported, so it doesn't need to be in DI 09:38:35 ... SO it helps if we minimize the number of differences in the examples 09:38:47 brent: So it sounds as if we're close to a proposal 09:41:49 brent: Discusses a draft proposal 09:42:19 Michiko has joined #vcwg 09:42:19 wes-smith: What does normatively prefer mean? 09:42:28 q+ 09:42:28 brent: We won't say SHOULD/MUST 09:43:06 shigeya: Does clarify mean what I proposed in the spec text? 09:43:09 brent: Yes 09:43:23 ... I'll clarify that in the proposal 09:44:11 PROPOSAL: Moving forward, we will clarify the limitations on using DigestSRI (using the proposal Shigeya 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. 09:44:13 +1 09:44:14 +1 09:44:15 +1 09:44:16 +1 09:44:16 +1 09:44:17 +1 09:44:17 +1 09:44:17 +1 09:44:18 +1 09:44:18 +1 09:44:20 +1 09:44:21 +1 09:44:24 +1 09:44:29 +1 09:44:56 bigbluehat has joined #vcwg 09:45:08 brent: I'm not hearing any objections 09:45:11 RESOLVED: Moving forward, we will clarify the limitations on using DigestSRI (using the proposal Shigeya 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. 09:46:06 michiko has joined #vcwg 09:46:13 Subtopic: Test Suite, any open PRs and Issues 09:46:33 brent: We have 17 open issues on the test suite and want to get a sense of what this means for 2.1 09:46:33 q+ 09:46:43 q+ to ask about new specs and the test suite 09:46:45 brent: IMO, the suite for 2.0 has served its purpose 09:46:55 ack shigeya 09:46:59 ack manu-tpac 09:47:30 manu-tpac: 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 09:47:49 q+ to ask about a true delta test suite 09:48:01 manu-tpac: 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. 09:48:01 q+ 09:48:26 ... About 6 months of work. We have a new hire starting at DB who will be focused on this. 09:49:00 manu-tpac: 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. 09:49:01 ack JoeAndrieu 09:49:01 JoeAndrieu, you wanted to ask about new specs and the test suite 09:49:19 q+ to speak to test suites 09:49:22 ack brent 09:49:22 brent, you wanted to ask about a true delta test suite 09:49:25 JoeAndrieu: What's the relationship between the test suite and the task forces? Will TFs update it? 09:49:42 brent: As far as the 2.1 is concerned, I think it would be OK just to test the delta 09:49:53 ... W're maintining backwards compatibility 09:49:53 ack ivan 09:51:03 ivan: 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 09:51:03 ack manu-tpac 09:51:03 manu-tpac, you wanted to speak to test suites 09:52:00 q+ 09:52:08 manu-tpac: 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 09:52:22 manu-tpac: But I notice is currently passing 100% of the tests 09:52:42 manu-tpac: We'll do a copy and paste and find out quickly the state of implemenations 09:52:52 ... That's less work than a new delta-only test 09:53:12 manu-tpac: The confidence method will have its own test suite 09:53:33 ... Each TF needs to prepare for that. RE isn't a VCDM test, we need to test the chain 09:53:59 ack JoeAndrieu 09:54:07 ... For the confidence method... I don't think that TFs should assume that the core VCDM 2.1 is going to cover their work 09:54:37 JoeAndrieu: I would expect that if I got a context I didn't expect, it would fail. 09:54:40 q+ 09:54:54 ingo has joined #vcwg 09:55:06 manu-tpac: Some people do fetch the context every time (although we advised against it) 09:55:12 q+ 09:55:19 JoeAndrieu: You said you could hit the same endpoints with a new context and expect it to work 09:55:29 manu-tpac: A small number - we need two, not all 09:55:39 ack bigbluehat 09:56:00 bigbluehat: I'm trying to figure out what we're testing. 09:56:18 manu-tpac: The URLs change, not different content at the same URL 09:56:34 q- 09:56:43 bigbluehat: It's a fishing expedition (not phishing) 09:57:22 brent: 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 09:57:37 brent: Notes that TFs are responsible for test suites for their work. 09:57:43 Subtopic: JOSE_COSE 09:57:56 q+ 09:57:56 brent: Only open issue is out of scope for maintenance 09:58:16 ack ivan 09:58:30 ivan: I didn't want to touch the issue, we should label it somehow 09:58:35 brent: It ius labelled future 09:58:44 subtopic: JOSE-COSE test suite 09:58:51 s/ius/is/ 09:59:29 brent: I don't think we even expect a 2.1 version of the spec so we're not going to touch the test suite 09:59:36 subtopic: VC JSON schema 10:00:01 brent: When we last looked at this, we entered CR and we have never left. There are some open issues, two already labelled future 10:00:15 ... Do want to look at one we might cover in CR 10:00:27 swcurran has joined #vcwg 10:00:31 ... Looking at #248 10:00:52 ... The don't call me Dom bot... these links are bad. We probably need to fix this. 10:01:00 manu-tpac: It's a simple editorial change 10:01:18 ivan: No need to refer to 2.0, just the versionless URL 10:01:57 brent: 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 10:01:58 swcurran has left #vcwg 10:02:04 swcurran has joined #vcwg 10:02:40 q+ 10:03:20 manu-tpac: We have tooling to fetch the hash and calculate - shouldn't happen again (for SRI or multibase) 10:04:04 brent: Discusses https://github.com/w3c/vc-json-schema/pull/246 and agrees to merge 10:04:20 q- 10:04:51 q+ to ask if there is anyone that wants to implement this in the group? 10:04:52 brent: We can close https://github.com/w3c/vc-json-schema/pull/247 as it has been overtaken by events 10:05:11 ivan: There is no longer a Proposed Rec stage 10:05:28 ... No open PRs for JSOn schema, issues triaged 10:05:46 ivan: If we want to do any work, do we need new editors? 10:06:07 brent: If we get another implementation that would help us get out of CR then we can get it dones 10:06:12 s/dones/done/ 10:06:29 manu-tpac: Is there anyone in the group who is going to implement this. 10:06:42 brent: There are specs kept at CR for years deliberately 10:06:49 manu-tpac: I thought we were better than that :-) 10:07:18 brent: VC JSON schema is now fixed. 10:07:26 q+ 10:07:41 brent: Since this session in the agenda is for docs not in Task Forces, can we look at use cases 10:07:49 ack manu-tpac 10:07:49 manu-tpac, you wanted to ask if there is anyone that wants to implement this in the group? and to 10:08:03 manu-tpac: As we have new people here and remote, perhaps we can ask our guests about their use cases? 10:08:19 brent: That sounds like a better idea than jumping into the UCR doc 10:08:58 JoeAndrieu: KevinDean and I have been just wrapping up the changes. We had hoped to get it done a while ago. More help always welcome 10:09:08 Subtopic: new use cases 10:09:23 q+ chris 10:09:25 mrchrisadams has joined #vcwg 10:09:30 ack ch 10:10:09 mrchrisadams: 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. 10:10:36 ... 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. 10:11:08 ... Empowering Consumers in the Green Transition Directive (EU Reg) needs a regularized approach. 10:11:29 ... So we're interested in using a Web tech to do this, so I'm exploring 10:11:31 q+ 10:11:38 ack phila 10:11:45 scribe+ 10:11:50 present+ mrchrisadams 10:11:54 phila: certification is a key use case for us 10:11:56 q+ 10:12:04 ... there is a task force meeting tomorrow that tracks this 10:12:52 ... 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. 10:13:17 mrchrisadams: We're based in NL. Want go through that accreditation process. 10:13:27 ack TallTed 10:13:48 TallTed: Several years ago we changed from verifiable claims tov credentials 10:14:02 ... since nothing that we do tests the veracity of what we said 10:14:27 ... we can prove that Joe Smith said these things, not that what he said is true 10:15:00 brent: Any other use cases folks would like to talk about? 10:15:09 q+ 10:15:19 ack JoeAndrieu 10:15:50 JoeAndrieu: There is one major new use case which is the GS1 delegated hierarchy 10:16:07 KevinDean: (working at 04:16) 10:17:02 KevinDean: If you go to the GS1 use case in section 5.4 10:17:26 KevinDean: I used to be with GS1. I was the primary author of the data model that GS1 developed for its VCs 10:17:52 KevinDean: Describes GS1. data model is at https://ref.gs1.org/gs1/vc/data-model/ 10:18:53 ... federated system. 754 and 755 are the prefixes for GS1 Canada. GS1 Canada then assigned a prefix beginning with that 75412345 10:19:22 ... The chain of credentials starts with GS1 Global Office as the "root of trust" 10:19:44 ... What we liked about VCs when we investigated is that it is a self-assembling system 10:20:09 phila: The DID for GS1 Global Office is did:web:vc.gs1.org 10:20:28 KevinDean: Talks through the Healthy Tots use case in the VC UCR 10:21:06 q+ 10:21:09 KevinDean: Those in the RE TF will recognize this model 10:21:41 KevinDean: As I have the prefix from GS1 Utopia, I can create the actuals GS1 identifiers I need. 10:22:11 ... We also have data associated with a product. I have to give you data about my product, not just the ID 10:22:34 https://www.w3.org/TR/vc-use-cases/#chain-of-gs1-credentials-to-identify-a-trade-item 10:23:17 q+ to mention "Amend" action, and the GS1 motivation for it 10:23:23 KevinDean: There are more advanced concepts but the basic model is straightforward. Because I have this cred, I can issue this other cred 10:23:57 ack brent 10:24:02 ... 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 10:24:29 ack JoeAndrieu 10:24:29 JoeAndrieu, you wanted to mention "Amend" action, and the GS1 motivation for it 10:24:32 q+ to draw analogy to Green Web Foundation use case 10:24:35 brent: In my previous job, we did exactly this flow with the US Customs and Border Protection people. It worked well 10:24:40 q+ to ask about x509 as a solution? 10:24:53 JoeAndrieu: I'm not sure where we are with the edits 10:24:59 https://ref.gs1.org/gs1/vc/ 10:25:25 ... The tamper-evident signature means it can't be amended but there is a use case that might need that. 10:25:57 JoeAndrieu: The problem of Mergers and Acquisitions is a big one as the brand is now owned by a different company 10:26:12 KevinDean: The nature of sigs means that amendment is not possible. 10:26:36 q+ 10:26:47 ... 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 10:27:03 ... This one is no longer valid but there is a new one to replace it 10:27:12 q+ to note "update available" in most recent bitstring status list specification 10:28:04 KevinDean: Talks through more detail of the use case 10:28:20 ack manu-tpac 10:28:20 manu-tpac, you wanted to draw analogy to Green Web Foundation use case and to ask about x509 as a solution? and to note "update available" in most recent bitstring status list 10:28:23 ... specification 10:28:47 manu-tpac: There's a diagram for the GS1 use case - might be directly relevant to mrchrisadams 10:29:30 manu-tpac: This is the sort of thing we can do with VCs today 10:29:57 https://www.youtube.com/watch?v=iDkANArgdKI 10:30:28 manu-tpac: 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 10:30:31 noting we're at time 10:32:04 ack ivan 10:32:08 manu-tpac: 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 10:32:25 ivan: Joe, you frightened me. Did you say there's a property called amend in the VCDM? 10:32:37 JoeAndrieu: No, it's in the UCR, not the VCDM 10:32:47 brent: We're 2 minutes over. 10:32:54 ... Break until 11:00 GMT 10:33:02 RRSAgent, draft minutes 10:33:03 I have made the request to generate https://www.w3.org/2026/10/29-vcwg-minutes.html phila 10:55:07 brent has joined #vcwg 10:55:14 wes-smith has joined #vcwg 11:02:17 Wip has joined #vcwg 11:02:18 phila has joined #vcwg 11:02:37 scribe+ 11:03:20 phila: 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. 11:03:26 JoeAndrieu has joined #vcwg 11:03:42 ... This group splits our large number of deliverables into task forces, each of which has its own meetings, leadership, and work items. 11:03:48 https://www.w3.org/TR/vc-confidence-method/ 11:03:53 ... The Confidence Method task force is led by JoeAndrieu and denkeni. 11:04:15 ingo has joined #vcwg 11:04:21 JoeAndrieu: 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. 11:04:22 Lucy has joined #vcwg 11:04:47 ... 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. 11:07:25 ... We have been tracking a checklist of items before horizontal review. We are working on threat model/security + privacy considerations. 11:08:46 phila: Could you briefly summarize what Confidence Method is? 11:09:25 JoeAndrieu: 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. 11:09:44 ... It could also be comparing what is in a log to what is in a VC - such as with Confidence Method using DIDs. 11:10:01 q+ 11:10:31 ... 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. 11:10:56 ... 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. 11:11:06 ... When someone presents the VC a biometric confirmation can be performed with the template. 11:11:27 ... 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. 11:11:46 ... 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. 11:11:59 ... This is not particularly robust, but it is a very common mechanism. 11:12:10 michiko has joined #vcwg 11:12:10 ... It allows a human to do the confidence without a machine, which is a use case we want to support. 11:12:39 ... 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. 11:12:54 ... The credential does not provide this evidence, but the issuer makes the assertion. 11:13:06 ack ivan 11:13:48 ivan: 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? 11:14:03 JoeAndrieu: You should wait, we have outstanding issues to work through. 11:14:26 ivan: Also, please create a clear URL into your specification for each term you define. 11:14:55 JoeAndrieu: The two confidence methods that we want to get in, but probably will be future are email and phone number as confidence methods. 11:15:30 ... 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. 11:15:44 ... This should not be a MUST. 11:17:09 ... 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. 11:17:26 ... We need to figure out how to test supporting a feature without testing external companies' logic. 11:17:31 q+ 11:17:35 q+ 11:17:39 ack manu-tpac 11:18:10 manu-tpac: 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. 11:18:41 ... 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. 11:18:59 ... I'd suggest the test suite tests the data model at a minimum, and we could do a presentation with a countersignature. 11:19:32 ... We could just ask implementers for feedback on the biometric options. 11:19:45 q- 11:20:00 q+ 11:21:11 ack ivan 11:21:12 ... 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. 11:21:36 q+ to note that biometrics are meant to be privacy preserving. 11:21:59 ivan: 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. 11:22:07 ... We are not making a judgement on the implementation. 11:22:34 ack manu-tpac 11:22:34 manu-tpac, you wanted to note that biometrics are meant to be privacy preserving. 11:22:39 ... Both for confidence method and render method there will be humans in the loop. 11:24:03 manu-tpac: 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 11:24:03 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. 11:24:46 ... 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. 11:25:23 ... 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. 11:27:57 JoeAndrieu: 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 11:27:57 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. 11:28:30 ... 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. 11:29:04 ... 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. 11:29:56 ... 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. 11:31:24 ... 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. 11:31:47 ... 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. 11:33:17 ... 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 11:33:17 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. 11:34:12 ... 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. 11:35:13 ... It also could be where you have to go into a facility, either with or without a backend service. 11:35:46 ... Looking at the biometric template creation, whoever runs that controls that service. 11:36:22 ... There are also security and trust boundaries at the phone application layer. 11:36:49 ... 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. 11:37:17 ... I first tried this in 2D layout, a sequence diagram to anchor or language in terms of core entities and interactions. 11:37:39 ... The idea is that in the spec I want to add these diagrams as descriptions of particular methods. 11:37:42 q+ 11:37:50 ack manu-tpac 11:37:59 manu-tpac: Did you say you expect that this diagram would go in the spec and not the threat model? 11:38:22 JoeAndrieu: Yes, I am not using this to analyze threats, but better model the use cases that need to be threat modeled. 11:38:45 manu-tpac: I'm wondering about ramifications for other specs - it feels to me like the threat model expects the specification to talk about flows. 11:39:29 ... 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. 11:40:00 ... I am somewhat uncomfortable with the request to move flows into the main spec - that's my concern. 11:40:06 q+ 11:40:21 ack me 11:40:24 q+ 11:40:42 phila: I think this should go in the specification. 11:40:44 q+ is this normative? 11:40:47 ack brent 11:40:51 q+ to say "is this normative"? 11:41:08 ack manu-tpac 11:41:08 manu-tpac, you wanted to say "is this normative"? 11:41:12 brent: We are expanding beyond data models, I agree that this is a useful thing for the main document. 11:41:16 q+ 11:41:19 manu-tpac: How normative is this? 11:41:35 ... These considerations are important. 11:41:36 q+ 11:41:55 q+ JoeAndrieu 11:42:08 q+ to say just this flow 11:42:17 ack ivan 11:42:17 phila: My assumption is that there will be spec text that describe this, an illustration of the normative parts of the spec. 11:42:25 q+ mori,ori 11:42:32 q+ to note as long as we say that this is one way this can be done, but is not the only way, we're good 11:42:35 q- ori 11:42:48 scribe+ 11:42:50 ivan: I believe we have a statement that figures are not normative. 11:42:55 ack wes-smith 11:42:56 ... The description may be. 11:42:58 q+ 11:43:18 wes-smith: It sound near impossible to have these flows to be expressed normatively without being overly restrictive. 11:43:56 ack JoeAndrieu 11:43:56 wes-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. 11:44:01 scribe- 11:44:57 ack brent 11:44:57 brent, you wanted to say just this flow 11:45:01 JoeAndrieu: I disagree but acknowledge ivan'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. 11:45:37 ack mori 11:45:39 +1 to brent 11:45:40 brent: 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. 11:47:04 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 11:47:04 to could be described. 11:47:06 +1 to sticking with the FIDO guidelines for biometrics (templates never leave the device) 11:47:48 JoeAndrieu: 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. 11:47:50 ack manu-tpac 11:47:50 manu-tpac, you wanted to note as long as we say that this is one way this can be done, but is not the only way, we're good 11:47:51 Jem_ has joined #vcwg 11:48:31 manu-tpac: Out of all of the things said, I align with what brent 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. 11:48:55 ... This happens often. Putting the thought in someone's head to limit the technology is something to avoid. 11:48:56 q+ 11:49:23 q+ 11:49:27 ... Inclusion of flows should be illustrative examples on a spec-by-spec decision. Normative language for flows is risky. 11:49:28 ack denkeni 11:49:40 q- 11:50:00 q+ JoeAndrieu 11:51:18 denkeni: +1 to what manu and brent 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. 11:51:21 q+ Anthony 11:51:24 ack me 11:51:52 present+ antony 11:52:20 phila: 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. 11:52:40 ack JoeAndrieu 11:53:03 Antony has joined #vcwg 11:53:14 +present 11:53:15 present+ 11:53:20 present+ 11:53:20 s/+present// 11:53:40 JoeAndrieu: 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. 11:53:46 ElaineX has joined #vcwg 11:54:04 ... Trying to jump immediately to the big diagrams hurts accessibility - flow diagrams are useful intermediates. 11:54:26 ack next 11:55:09 ... 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. 11:55:17 (RDF-star is no more. It long ago evolved into RDF 1.2.) 11:55:28 ... In the RDF world, serialization is a point of compromise, even though the RDF work is largely abstract. 11:55:48 ... The threat model is an embodiment, which should not be normative. Threat modeling makes a choice of what is the system under analysis. 11:57:23 Anthony: 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. 11:57:23 q+ 11:58:04 JoeAndrieu: I am a huge fan of figuring out the datagram and how it moves - see the IP protocol on which the web is built. 11:58:17 ... Constraints on other technologies made them die out in comparison to IP. 11:58:34 q+ to speak to "why server-side biometrics"? 11:59:08 ack denkeni 11:59:42 denkeni: 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. 12:00:00 q+ 12:00:10 ... It's our strategy to move forward in this way. 12:00:37 ... 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. 12:00:48 ack manu-tpac 12:00:48 manu-tpac, you wanted to speak to "why server-side biometrics"? 12:02:02 manu-tpac: Anthony, 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 12:02:02 move in the right direction. 12:02:56 q+ JoeAndrieu 12:02:59 ... Part of that strategy is naive, but it is our job to provide good options to less privacy-preserving options. 12:03:27 ... Our spec will say how we think you should do this - local computation, ZKPs, etc. 12:03:39 q+ to ask a chairy q 12:03:51 ack ElaineX 12:05:07 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 12:05:07 product. 12:05:25 ack JoeAndrieu 12:05:38 q+ to talk about birth certificates for horses and tanks. 12:06:20 JoeAndrieu: I wanted to address Anthony'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. 12:06:36 ack brent 12:06:36 brent, you wanted to ask a chairy q 12:06:52 brent: Is there an issue tracking this conversation? What decisions are we making? 12:07:23 q- 12:07:55 JoeAndrieu: 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. 12:08:02 q+ 12:08:04 q+ to talk about birth certificates for horses and tanks and how we should push that to v1.1 12:08:11 ack wes-smith 12:08:13 scribe+ 12:08:45 ack manu-tpac 12:08:45 manu-tpac, you wanted to talk about birth certificates for horses and tanks and how we should push that to v1.1 12:08:46 wes-smith: Brief note about spec writing and accessibility -- spec should mention we want privacy and not weaken technology, idealogical reason for normative language. 12:08:50 scribe- 12:09:38 FYI: FIDO guidelines for biometrics usage intheir specs: https://fidoalliance.org/specs/biometric/requirements/Biometrics-Requirements-v4.0-fd-20240522.html 12:09:41 q+ JoeAndrieu 12:10:26 manu-tpac: 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. 12:11:00 ack JoeAndrieu 12:11:27 JoeAndrieu: We are feature frozen, so I encourage folks to raise issues but new features will be tracked as future. 12:11:29 q+ 12:11:52 ack ivan 12:12:26 ivan: For me, feature frozen means properties are defined. 12:12:35 JoeAndrieu: I mean use case frozen. 12:13:17 ... 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. 12:13:41 ivan: all that you said has not yet been seen by the accessibility people - they will probably have good questions. 12:13:49 ... i18n could be relevant as well. 12:14:08 phila: Closing the confidence method slot. 12:14:08 Topic: AB Discussion 12:14:55 brent: we have synthesized feedback regarding W3C process into things we could change - but there is a process for change the process. 12:15:07 ... This is directed by the advisory board, and eventually the advisory committee. 12:15:31 ... That is heavy handed for trials/experiments - the first change we would like to see to process is to allow experiments. 12:15:44 ... There is a process PR right now that outlines methodology used to run experiments. 12:16:02 q+ 12:16:12 ... 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. 12:16:28 q+ to ask for an example of a process experiment 12:16:43 Experimental AB Process proposal: https://github.com/w3c/process/pull/1189/changes 12:16:46 q+ to ask about alternatives v required 12:16:54 ... 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. 12:17:21 q+ 12:17:45 ... 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. 12:18:01 ... We also generally want to hear feedback on what WGs are struggling with. 12:18:09 ack me 12:18:09 phila, you wanted to ask for an example of a process experiment 12:18:50 q+ to ask if "all WGs get a TAG Member" has been discussed to help horizontal review? 12:18:51 phila: Can you give an example of a process experiment? 12:19:15 brent: The pain points we heard were horizontal review - for example, we could strictly limit the time in which horizontal review has to happen. 12:19:34 ack JoeAndrieu 12:19:34 JoeAndrieu, you wanted to ask about alternatives v required 12:20:24 Process Experiment PR: https://github.com/w3c/process/pull/1189 12:20:38 JoeAndrieu: 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. 12:21:00 ack ivan 12:21:40 ivan: +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? 12:21:50 brent: This is what the language attempts to address. 12:22:22 ... The AC needs to approve experiments and will not approve egregious process violations. 12:22:31 ack manu-tpac 12:22:31 manu-tpac, you wanted to ask if "all WGs get a TAG Member" has been discussed to help horizontal review? 12:23:03 manu-tpac: Has the AB considered drafting volunteers (voluntolds) from WGs to serve in horizontal review groups? 12:23:43 ... 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. 12:24:23 ... Splitting this out into two parts, review and "review review", could be helpful. WGs could pick people to do reviews. 12:24:28 q+ 12:24:29 q+ 12:24:51 q+ for BBS upload quid-pro-quo mechanism 12:25:08 q- 12:25:12 ack me 12:25:47 phila: 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. 12:25:53 ack JoeAndrieu 12:25:53 JoeAndrieu, you wanted to discuss BBS upload quid-pro-quo mechanism 12:26:17 JoeAndrieu: We are so oversubscribed with stuff, makes it hard to suggest reviewers. This reminds me of BBS exchange notions. 12:26:18 q+ 12:26:37 ack wes-smith 12:26:40 scribe+ 12:26:57 wes-smith: Yes, this is how academic review works, when you submit a paper, you are expected to do a review as well. 12:27:05 wes-smith: That is how it works and that is what we're proposing here. 12:27:21 Topic: Culture concerns 12:27:56 brent: 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? 12:28:12 q+ 12:28:22 ack jo 12:28:43 q+ 12:28:56 JoeAndrieu: 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. 12:28:58 ACK bigbluehat 12:29:27 bigbluehat: Both things mentioned are very similar - strong responses that people reach for. Nuance would be great. 12:29:40 q+ 12:29:58 ... I wonder if the formal objection timeline could be changed to minimize eleventh hour problems. 12:30:15 ack me 12:30:32 q+ to speak to when this group didn't necessarily have a good culture... and figure out what happened there. 12:31:04 phila: We trialed this by signaling our intent to resolve a dispute here at TPAC, so in the lead to TPAC the necessary discussions happened. 12:31:05 ack manu-tpac 12:31:05 manu-tpac, you wanted to speak to when this group didn't necessarily have a good culture... and figure out what happened there. 12:31:38 manu-tpac: 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. 12:31:46 zakim, close the queue 12:31:46 ok, phila, the speaker queue is closed 12:32:09 ... 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. 12:32:34 ... Maybe W3C should look at where groups have broken down, and did FOs help there? 12:33:21 ... I will also mention that the code of conduct is useful as a reminder but not hugely useful when things are very problematic. 12:33:31 ... Examining cases where FOs and the code have failed could help us. 12:33:50 rrsagent, draft minutes 12:33:52 I have made the request to generate https://www.w3.org/2026/10/29-vcwg-minutes.html ivan 12:49:04 dmitriz has joined #vcwg 13:28:33 dmitriz has joined #vcwg 13:34:19 dmitriz has joined #vcwg 13:43:13 wes-smith has joined #vcwg 13:45:56 manu-tpac has joined #vcwg 13:46:29 brent has joined #vcwg 13:47:03 present- shigeya 13:47:35 sorry to here that, hope you feel better 13:49:44 phila has joined #vcwg 13:51:21 Wip has joined #vcwg 13:51:26 scribe+ 13:51:44 dmitriz: I added some slides to the agenda. Thanks to recognized entity group for template to copy 13:52:09 JoeAndrieu has joined #vcwg 13:52:13 dmitriz: sharing screen 13:52:50 ... We will go over what the task force does, what the spec does, the current state of it 13:53:20 ... Render method is an extension to the VCDM. It tells you how to display the VC 13:53:46 ... Many examples of wallets and software that have come up with custom approaches to display VC data in there applications 13:54:31 ... 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 13:54:55 ... The issuer expresses their preferences for rendering 13:55:12 ... Issuer cannot and should not control consumer software for how a VC is displayed 13:55:21 ... Should be overridable by consumer preferences 13:55:49 ... To do so this involved no issuer provided templates. But this is likely beyond this version of the spec 13:55:55 kezike has joined #vcwg 13:56:02 ... 3 basic mechanisms have been proposed 13:56:31 ... The render method is dispatched off of specific render suites. Similar to how proof uses different cryptographic suites 13:57:25 ... The 3 main suite types in this spec are static, summary and html 13:57:39 ... Render method also supports community extensions 13:58:25 ... Static render method is a way for the issuer to define a prerendered VC in the method. E.g. an image 13:58:42 ... This is how open badges project handled this 13:59:12 ... The issuer prerenders a payload and either embeds the payload statically into the VC itself. Or links to an externally hosted payload 14:00:13 dmitriz: There is an ongoing debate as to whether anything should be prerendered by the issuer 14:00:46 ... 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 14:01:04 q+ 14:01:15 ... A recurring theme is the trade offs between security and usability of these renderSuites 14:01:32 zakim, open queue 14:01:32 ok, phila, the speaker queue is open 14:01:37 q+ manu-tpac 14:01:39 q+ 14:01:49 q+ to note NFC use cases 14:01:54 ack manu-tpac 14:01:54 manu-tpac, you wanted to note NFC use cases 14:02:17 manu-tpac: I wanted to point out, you might have meant NFC rather than bluetooth. 14:02:21 dmitriz: Yep 14:02:41 manu-tpac: NFC usecases are important for us because of first responder use cases in emergency situations 14:02:59 ... The ability for first responders to tap to share VCs without relying on a network 14:03:06 q+ to ask why delivery is in there 14:03:06 dmitriz: Are you sending full credential or a subset 14:03:31 manu-tpac: A subset. Another example are metro transit cards, which would also send over a subset via NFC 14:03:39 q+ 14:03:45 ack JoeAndrieu 14:03:45 JoeAndrieu, you wanted to ask why delivery is in there 14:03:45 ... These are just some examples of where we are using VCs 14:04:02 JoeAndrieu: Could you unpack why the delivery mechanism, which feels protocolly, is in here? 14:04:46 dmitriz: 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 14:05:15 dmitriz: NFC for example have no media type. We needed a separate field as a dispatch mechansim 14:05:31 q- 14:05:31 ack phila 14:05:44 JoeAndrieu: To echo back, this is an advertisement to wallet software to select how to render 14:05:59 dmitriz: Diving into the main question with the static method 14:06:14 q+ to answer the NFC payload sizes 14:06:20 ... How are we expected this to be implemented and what sort of payloads are we expecting 14:06:22 Might want to add to "limits" -- unilingual 14:06:33 ... This will help us frame our threat model analysis etc 14:06:42 q- 14:06:51 First, lets look into how the other two render methods work 14:06:55 ... Next is summary 14:07:04 This was initially named a card suite 14:07:23 ... This should be familiar to anyone that has used the current generation of VC wallets, or apple/google wallets etc 14:07:34 ... This is the representation of a VC as a virtual plastic card 14:08:20 wes-smith has joined #vcwg 14:08:21 ... 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 14:09:02 ... 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 14:09:17 ... In addition, it serves as a general purpose bag of metadata about this displaying 14:09:26 ... This includes field labels and field types 14:09:37 ... Internationalization and any other display metadata 14:09:52 q+ 14:10:21 ... The name itself is a tenuous compromise, we are not exactly satisfied 14:10:25 q+ to ask about phone home 14:10:30 ack ivan 14:10:31 ... Finalizing the name of this suite is one of the remaining items 14:10:41 ivan: Looking at it with my vocabulary hat on 14:11:01 ... I am a bit bothered that we have payload as a property, whose behaviour is very different from the static renderSuite 14:11:35 ... The static version of the payload, was a data URL 14:11:45 dmitriz: No, that was an artifact of the example 14:12:05 ... In the JSONLD format, it is either a single URL, or this value object with this media type 14:12:16 ivan: I misunderstood what you said. 14:12:30 ack JoeAndrieu 14:12:30 JoeAndrieu, you wanted to ask about phone home 14:12:33 dmitriz: I could be a data URL or an external. There is the phone home mitigation that needs to be discussed 14:12:54 q+ 14:13:15 JoeAndrieu: Seems like you are using the ID as a URL so it is expected that people would hit that URL 14:13:28 ack manu-tpac 14:13:29 dmitriz: Yep, this is somethingg the group needs to advise developers on 14:13:49 q- 14:13:59 ... All use the same pattern. And in all of them the phone home trade off comes into paly 14:14:32 ElaineX has joined #vcwg 14:14:45 ... 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 14:15:13 ... Issuers sometimes want the ability to change/update the payload. Either the bit string status list, or how the credentialis displayed 14:15:33 ... This only works if it is externally hosted 14:15:34 q+ to say seems like just as private as bitstring status list? 14:15:44 ... Of course, this brings in phone home and all of the associated concerns 14:16:00 ... For some render methods the trade offs work better than others 14:16:06 q- 14:16:22 q+ 14:16:27 ack manu-tpac 14:16:27 q- 14:16:29 ... For the summary and HTML render method the payload is the same for everyone. However, with static the payload is unique to individual credentials 14:16:37 q+ 14:16:46 manu-tpac: I dont think there is anything new here going on that is any different from bit string status list 14:16:57 except for the pre-rendered? 14:17:00 ... some things dmitriz made me think we need to give advice if there are unique strings 14:17:10 ... There are mitigations we can use here. E.g. use oblivious HTTP 14:17:10 right, except for pre-rendered 14:17:29 ack JoeAndrieu 14:17:37 ... The generic guidance is, if there is a unique URL that can identify the individual credential do no do it. Embed the data 14:17:56 JoeAndrieu: I would like to see bit string status list change. With bit string status list, you could have the holder get the status list 14:18:12 manu-tpac: You can. There is a mechsnism being added to presentation that would allow you to do this 14:18:40 JoeAndrieu: Utah may have an issue with this, this is a latent phone home capability. It assumes that the issuer will care 14:18:57 ... We should not give issuers the ability to have this capability 14:19:25 dmitriz: 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 14:19:32 wes-smith has joined #vcwg 14:19:46 dmitriz: Continuing to the HTML iframe render suite 14:19:53 ... short name HTML 14:20:11 ... Other names considered are sandbox, sandbox iframe etc 14:20:20 ... At the moment we are sticking with html 14:20:43 ... Similar pattern to the others. A suite id. A payload, that is either embedded or external 14:20:51 ... And a number of metadata that goes along with it 14:21:09 ... Key difference is that a consuming client retrieves the payload and opens it in a sandboxed iframe 14:21:24 ... This is sandboxed to turn off net access, JS, navigation etc 14:21:36 ... This has both advantages and disadvantages that we will get into 14:21:47 ... INcluding how you display linked credentials 14:22:18 ... 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 14:23:01 ... It enables the issuer to flexibly define using HTML, CSS and JS in a sandboxed way how they want the VC to be rendered 14:23:45 ... One of the issues we still need to figure out is how to mitigate data exfiltration 14:24:14 ... It is possible to exfiltrate data using an image tag for example 14:24:37 ... 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 14:24:48 ... Data exfiltration and sandboxing is a key issue here 14:25:16 ... 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 14:25:45 wes-smith has joined #vcwg 14:25:51 ... 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 14:26:04 ... how do we navigate what is essentially hypertext but in VC form 14:26:18 ... Another example is in these nested records e.g. in health or education 14:26:39 ... These have an overall top level VC where inside is embedded VCs with their own signations 14:26:51 s/signations/signatures/ 14:27:02 ... How does render method work for this complex thing? 14:27:19 ... What if each embedded credential has its own render method 14:27:29 q+ 14:27:32 q+ 14:27:38 q+ 14:27:41 brent: 30 min remaining 14:27:51 ack bigbluehat 14:28:13 bigbluehat: 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 14:28:28 dmitriz: Yep, that is one of the mitigation methods that we need to decide as a group 14:29:07 ... Patrick proposed another render suite. There is the ability for the rendered iframe to talk to the parent application 14:29:29 ... E.g. for the user clicking to render a linked credential 14:29:30 scribe+ 14:29:32 ack Wip 14:29:57 Wip: I wondered when we think about rendering for paper, would that be HTML? 14:30:17 q+ to say we need to pull a confidence method and just pick a small subset 14:30:21 dmitriz: On of the founding usecases/painpoints for render method was paper and pdf 14:30:31 q- later 14:31:06 ... 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 14:31:17 ... The HTML method is one of the possibilities 14:31:52 ... There is a different renderSuite being explored that uses mustache and string substitution to fill in fields in a template. 14:32:22 ... 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 14:32:45 ... Others have argued that it is possible to generate a PDF in the iframe and then pass this back to the parent for printing 14:33:18 ack brent 14:33:18 brent, you wanted to say we need to pull a confidence method and just pick a small subset 14:33:21 dmitriz: 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 14:33:44 q+ 14:33:51 brent: When the presentation started, I thought it was good that the group had picked three and settled 14:34:12 ... 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 14:34:33 ... Lets constrain the scope, so this work item can progress 14:34:55 dmitriz: Completely understand. Lots of things we can do, constrained by charter and getting 1.0 out the door 14:35:11 ... We do think that between these three we can cover all the existing use cases 14:35:16 q- later 14:35:20 ack manu-tpac 14:35:53 manu-tpac: 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 14:36:06 ... PDF is on the chopping board for 1.0, we can add it later 14:36:27 ... static is locked down pretty well. HTML is locked down. What is not locked down right now is summary due to internationalization 14:36:40 ... We have picked. It is those three. We need to cut features if anything is going to drag on 14:36:50 q- 14:37:02 ack phila 14:37:02 dmitriz: Agreed. We have a plan. Settled on three. A few issues to lock down. PDF will probably be on the chopping block 14:37:07 George has joined #vcwg 14:37:21 PDF = Pretty Dead Format 14:37:33 phila: Sounds like a future version of this would have a lovely button to generate a PDF with barcode. Lets not do that this time 14:38:00 phila: What is the outputPreference access Mode option in the renderMethod object for html 14:38:36 ... It is serving as a dispatch mechism for consuming client. When I want to reach for this HTML render suite 14:38:48 q+ 14:38:54 brent: You can have multiple render methods in the same VC 14:39:02 dmitriz: Yes and that is important. 14:39:17 ... You could have a HTML, summary and static. Or a different renderMethod per locale 14:39:34 ... That is why the issuer needs to signal for consumers which ones they should choose 14:39:38 ack bigbluehat 14:40:06 bigbluehat: If its a HTML one, accesMode and outputPreferences could be a big list e.g. audio 14:40:33 dmitriz: 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 14:41:05 ... All three have similarities 14:41:19 dmitriz: Horizontal reviews. Internationalization in progress. Pro 14:41:43 ... Privacy is complete. The rest we are waiting to hear back from. Apart from TAG review, this is not yet filed 14:41:56 dmitriz: I will file the TAG review this week 14:42:13 ... The main topics are 14:42:55 ... 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 14:43:46 ... We need to finalize the names, the localization and the question of whethere we have time for community supplied render methods. likely no 14:43:53 ... We also need to finalize whats in scope for 1.0 14:44:17 Lucy has joined #vcwg 14:44:19 ... 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 14:44:46 ... manu brought up the NFC use case. Necessarily small. Great candidate for embedding 14:45:18 ... 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 14:45:31 ... No mitigations from herd privacy. It is your credential hosted somewhere 14:45:33 zakim, who is here? 14:45:35 Present: ivan, manu, phila, brent, joe, wip, lucy, ivo, TallTed, ingo, elaine, swcurran, wes-smith, JennieM, IvoL, JoeAndrieu, KevinDean, denkeni, George, morimori, kseufer, 14:45:35 ... bigbluehat, wesley, curran, pchampin, yas, ReinaldoFerraz, mrchrisadams, antony, present 14:45:35 On IRC I see Lucy, George, wes-smith, ElaineX, kezike, Wip, phila, brent, manu-tpac, dmitriz, mrchrisadams, swcurran, bigbluehat, KevinDean, Yas, JennieM, IvoL, TallTed, RRSAgent, 14:45:40 ... Zakim, dlehn2, rbyers, denkeni, klea, simone, pchampin, hadleybeeman, jyasskin, ivan, shigeya, manu, dlongley 14:46:00 q+ 14:46:05 present+ dmitriz 14:46:24 ... The phone home threat could be mitigated if the user is hosting there own rendering of the VC 14:46:25 ack Lucy 14:46:32 ... May not have time for this 14:46:38 present- curran 14:46:47 Lucy: Seems like the MVP features have not been finalized yet. Would you like a real world use case 14:46:56 dmitriz: We would love to hear them. 14:47:00 q+ 14:47:01 Lucy: Lets take it offline 14:47:11 ack manu-tpac 14:47:12 dmitriz: Usually caveats of late stage charter wg 14:47:31 manu-tpac: I suggest that we don't give guidance this time around and see what implementers do during CR 14:48:12 ... 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 14:48:40 dmitriz: I agree with you. We probably dont have time to do other mitigations 14:49:00 dmitriz: Some issues need to be decided by the VCWG as a whole 14:49:19 ... How are we going to do localization and internationalization for the VCDM as a whole. But specifically for these render methods 14:50:18 ... 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 14:50:35 ... We are working to update the context and vocab 14:50:42 ... Some editorial cleanup also needed 14:51:01 dmitriz: Overall plan is to address the PRs from internationalization reveiw 14:51:10 ... Also a big one, how do we test this thing 14:51:16 ... Testing data model specifications is hard 14:51:31 ... render method has an extra challenge because its visual. How do you test visuals 14:51:38 ... There is a body of work around this 14:51:48 ... and questions? 14:52:39 dmitriz: 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? 14:53:09 ... Question 2 is HTML apps have a rich history of internationalization and localization. How do we do this for static and summary 14:53:26 ... We have the inherited JSONLD and VCDM mechanisms. Including language tag and language direction 14:53:51 ... One of the debated issues is, do we use language content negotiation when fetching externally hosted resources or not 14:53:55 ... What about embedded resources 14:54:10 q+ 14:54:10 ... What do we do about noting which languages are given render method addresses 14:54:33 ... There is some pushback that this may be duplicating the http accept language mechanism 14:54:54 ack phila 14:54:55 ... Internationalization flagged that accept language is not widely used. We may need to do something else 14:55:03 phila: Perfectly happy that static only has embedded 14:55:30 ... On the language side, I am struggling with the idea of fetching a set of localized set of strings. 14:55:49 ... The VCs that we have been caring about, have been small. While they can be big, lets start with what we are familiar with 14:56:34 ... There are multilingual countries. But in general they are one or two countries. Stick the localization data in the JSONLD 14:56:48 q+ 14:56:59 ... 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 14:57:06 ack bigbluehat 14:57:37 bigbluehat: 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 14:57:48 ... I dont think it makes sense to fetch it from the server 14:58:10 dmitriz: Thank you everyone. We will get this thing out the door. Please help with test suite 14:58:25 brent: Thanks everyone, see you tomorrow at 9:45 14:59:40 rrsagent, draft minutes 14:59:41 I have made the request to generate https://www.w3.org/2026/10/29-vcwg-minutes.html ivan 15:00:28 rrsagent, bye 15:00:28 I see no action items