W3C

VCWG VCALM

29 September 2026

Attendees

Present
benjamin_young, Dave Longley, eric_schuh, Joe Andrieu, john's_notetaker, kayode_ezike, manu_sporny, parth_bhatt, patrick_st-louis, read.ai_meeting_notes, Rodrigo Menéndez, ted_thibodeau_jr
Regrets
-
Chair
-
Scribe
transcriber

Meeting minutes

Patrick_St-Louis: Hey everyone, welcome to the call today. We'll get started in about two or three minutes. Let people join it. So hang on tight.

Patrick_St-Louis: Okay, going to get started nice and slowly. Let me just open the meeting page.

Patrick_St-Louis: Okay, welcome everybody to this week's VCAPI for life cycle management call, also known as VCOM. Today is the 29th of September, 2026. This is a W3C meeting. So all W3C policies are into effect. The meeting is recorded and transcribed. so if you would prefer not to just be aware of this. The VCOM is a meeting in which we discuss API specification for managing credential and credential exchange.

Patrick_St-Louis: We have a small agenda today but small but with important topics that we need to make sure we follow along. Before I present the topics and agenda, I would like to leave some time if anyone would like to introduce themselves or reintroduce themselves, share some community updates and add any topics they would like to discuss. so I will let you right now. yes, man.

Manu_Sporny: Just wanted mention the threat model and of course maybe some discussion with both Eric and Joe over that. I put one out for VC data model taking some preliminary input from Simone and Nick Dodie to refactor it into something hopefully both of them I know doing that's risky because things are still in discussion there. but we also need to prep this threat model for publication in two weeks by the end of this week. Avon has asked us to get everything ready and so I just want to make sure that you've got everything that you need to make that happen.

Manu_Sporny: So maybe a agenda plus 10 minutes, maybe up to 15 minutes, Patrick, for that topic.

BC Supply Chain Verifiable Credentials

Patrick_St-Louis: Yeah, I'm sure we can fit that. So, I had a global threat model discussion. I have the feeling this can fit into that. Perfect. thank you very much for this. I do have a small community updates I can share which is pretty fun. so this is some work we're doing in British Columbia. it has to do with supply chain and the mines act permit and the UNP so unfortunately British Columbia announced the surprise election I think last week. So all the work is kind of on ice right now.

Patrick_St-Louis: So we were planning to go with production but it was unfortunate timing but I can still share some more of our development work because it's now in a place that can be finished. so this touches a couple different things that's related to this group. First of all this is all using W3C verifiable credential 2.0 data model. it's using both enveloped and embedded securing mechanism. So the idea is that we sign with the data integrity proof and then we wrap this document and with VC Jose cos and serve it as a envelope verifiable credential. so the way it works we have a service here that can ingest data and then publish it as verifiable credential.

Patrick_St-Louis: So these are more proof of permit issuance and ownership. It does not represent the mine permit. It's just more of a proof that you do have a valid permit and give some information to where you can get it. so we have a model that it can update and manage the life cycle of many different versions. so for example unfortunately The dates are all the same here because this was just a dev batch upload. But if there's a change on the permit, we can revoke previous one and enable the new one. we had proposed in the bitst string status list of the refresh status mechanism and this is what we use for this.

Patrick_St-Louis: So this is a status that only says is this the latest version of this credential or is there a new one available and it's usually tied with a refresh service. and then the fun part is the rendering and the verification that we did here. so for this we used kind of where the VC render method is at and we just add a render suite. we can see here a bit of the different OCA bundle semantics that are used to fill this information.

Patrick_St-Louis: It does support multi- language at least when it comes to labels and field description. Obviously values they stay intact. this is a bit of a sideline with VC render method but we are having internal review and we are currently comparing our OCA bundle approach with the card render suite. we want to identify the differences and we believe that the direction the VC card rendering method could suffice for these use case. the thing that is holding it back is and it seems to come up quite a lot is multi- language support.

Patrick_St-Louis: I've seen a lot of discussion about this and it sound like there is still some discussion to be had around how this can be supported because obviously it's critical at least in BC to be able to represent these credential for various communities yeah so we added kind of a list of different checks that happens verify the envelop UNTP data model the JSON LD

Patrick_St-Louis: the data integrated proof we validate that the issuer is in a trust registry validity period this one is revoked this is one question I would have eventually for the VC render method what should the behavior be when you have a credential that's revoked should you still render the credential but show that it's revoke or should you refuse to render the credential or is this kind of up to the implementation things to decide. At the moment, we captured this in the checks.

Patrick_St-Louis: but I say I didn't feel the need to show this on this page because when we think about purely rendering a credential it's mostly about the information in the credential and in the credential itself you have the status index and thing but to get the actual status this require another process right and you don't have a direct value in the credential to point for the status it's kind of derived from a process

Patrick_St-Louis: is so it sits at an interesting place when it comes to showing the credential right same thing I'm showing is the proof valid and so on because when you render a credential it's mostly to show the information and the credential but kind of validation that happens part of it where does that sit in that process should I just say the proof doesn't verify I don't even want to render this should I render it but with a big warning

Patrick_St-Louis: that says proof doesn't verify and if the proof doesn't verify you cannot know what is you basically can't trust anything in the credential revocations it's a bit usually would depend on the reason for the revocation if it's revoked just because there's a new version available there's still some historical value that's interesting you might still want to see the credentials just to see a past version but if it's been revoked because it contained fake information. in that case, you might not want to show it. But the revocation reason is not really part of the status. I think maybe the message status could carry this. But I just wanted to show this. I've been working on some time for this. we have the PDF version that can be downloaded. I showed some snippets over the time.

Patrick_St-Louis: It's fully compliant with UNTP 0.7. there are some bugs in UNTP0.7 that I had to make concession. for example, the status index needs to be represented as a string and they look for an integer. So I had to unfortunately make a concession put an integer. So it's technically not 100% conformant with bitstring status list. but as soon as they fix this upstream we will fix it in here. This is purely a limitation of their JSON schema that enforces it. yeah so I just wanted to share this we have the JSON version that's available here. obviously this is a envelope verifiable credential.

Patrick_St-Louis: So if I copy my URL, it would render me the envelope version. so yeah, that's all. menu. So it's a thing that happens.

Manu_Sporny: This is awesome stuff. Patrick, could you zoom in? It's super tiny on my screen and I can't see anything. awesome. And then, could you go through the checks again? And it'd be neat to see. Yeah.

Patrick_St-Louis: So the first thing after it verifies the envelope, it just runs a VCD DM2.0 JSON schema check, then a UNP7.0

Patrick_St-Louis: schema check. It validates the context, right? Make sure it's safe. It checks the data integrity proof. It looks up the issuer in a trust registry, make sure it's resolved. A lot of this is a bit, obviously when you check the proof, you make sure the issuer is It checks the validity period. It checks the status. And then this one, so there same kind of thing. their spec is a bit behind. So they point to the VC render method but the JSON schema expects one of the older things. So it doesn't allow the render suite field for example. so in this case the render method is not in the credential. It's kind of in the software right so this is the software hosting the credential. So we just comment it out for now.

Patrick_St-Louis: Obviously, we just needed to demonstrate to the people that we are fully conformant with UNP 0.7. That was the main thing. And we use this exercise to report to them, these small misalignment. And they're small things, but that, at the end of the day is just you need to change it. even if this should be a string, not an integer or you should allow these fields. it sounds minor but it's very important because if you build software that is conformant to the spec technically would not be able to check the status here right we can check it because we're like okay we're going to allow the integer in this case but it's not right right and we don't want to propagate these kind of thing in the ecosystem but if we don't do this we're not compatible with UNP 0.7 and that was kind of our goal so it's a bit of a unfort

Patrick_St-Louis: fortunate situation. Yes, man.

Manu_Sporny: The next question is around the proof. So it's a VC jot at the top level and then you also did an embedded proof. Why? I'm wondering…

Patrick_St-Louis: So a few people came this up.

Manu_Sporny: what the thought process was

Patrick_St-Louis: The reason is so we need to support They make jot a must and they also say may support data integrity.

Patrick_St-Louis: So I'm like okay I'm talking the UNP specification right I just added this…

Manu_Sporny: Who's we?

Manu_Sporny: Who's they? the Got it.

Patrick_St-Louis: because we already have the setup for it.

Patrick_St-Louis: This is the crypto suite for webvh right we did web here however this has it also known as relationship with webvh UNP does recommend webv as well at did web we just did web here because they're kind of test suite playground cannot verify did webvh at the moment but this is backed by a webv log history right and you can make sure that the content of this document is backed by this log. We just don't have the skid part in this identifier. so yeah the principle is that we want to issue with eddsa GCS in the credential and wrap this in adding the proof in the credential I think it shouldn't affect anything.

Patrick_St-Louis: And it allows us down the line if we just want to get rid of the wrapper, we still just have, the credential itself and we can return it. And I didn't want to remove data integrity completely from our process. I don't know, it was just an idea. A lot of people have questioned it. They say there's no point. I'm like, yeah, I don't know. So, it was kind of a gut feeling that, we should probably keep that integrity in the process. Does that answer your question?

Manu_Sporny: It does. Thank you. Yeah. I mean, another argument for it is it allows you to strip off the VC jot and still have data integrity or the payload and then you can dump it directly in databases, any kind of document-based database and work with it. He's

Patrick_St-Louis: Yeah, exactly. You do that and for me it's just like you're going to need proof sets, right?

Patrick_St-Louis: for proof chains especially for supply chain it does feel like something that will be very relevant when you have audits and some of these things having kind of self attested credentials that you get an auditor to attest right and endorse so anyway we wanted to keep the mechanism there so we don't lose it and we also do the same thing with our bitstring status list credential right so we have boat mechanism there and it allows us down the line if we want to move away from VC Jot because we need proof set or something we just need to comment out the envelope part we don't need to redesign the whole pipeline because we put quite a few validation and checks in place for the transformation of the data.

Patrick_St-Louis: Yeah, and this is going to be linked directly from it's not out yet because we can't put it live right now because of the political situation in BC. but we will have this site with the mines and the authorizations here and the mines act we're going to put a link to the credential right so it's going to add because here is where you have all the mining information you have the actual permits and we're going to put a link so that if a mine operator of this mine they want to issue a product passport as well they're going to be able to come in here grab their permit and include that in their

Patrick_St-Louis: product passport, right? So, it kind of speaks to provenence of critical raw material. That's kind of the angle that is happening here. and there's all this nice data and it's very fascinating because all the data is there right to put on credential on top of it it just made sense everything was very naturally fit in there. They have the legal act in place that we can reference. They have a clear identified issuer entity, right?

Joe Andrieu: Thank you.

Patrick_St-Louis: chief permitting officer. So, putting all these things together and building a sort of trust registry layer with WebVH just kind of made sense here. so yeah, that's what I wanted to show. I believe Nancy presented some of this in Geneva a couple weeks ago. Okay, any question before we move on?

Patrick_St-Louis: Just I would love to try my best to make some time to attend that call.

Manu_Sporny: I did have questions around render method and…

Manu_Sporny: the printing thing, but I think we could probably leave that till later. I do want to come back around to that to make sure that the render method folks are hearing from Patrick, you and the Minds folks to make sure that whatever we're doing there works for you long term. Mhm.

Patrick_St-Louis: Cuz I did go on a tangent and I think there's a lot of thing about language and what I would really like to do is to make this comparison between OCA bundle and the render card or render I don't know there was a new name for it highlights I want to present just a very neutral opinion of what matches and what's missing and just have a discussion if we

Patrick_St-Louis: find that it supports everything we need. I think at this point we're ready to get rid of OCA. it is super powerful, but I was talking with Stephen a little bit and he did mention that he had to fight a bit with the authors of the OCA to kind of use it for rendering. So he was pretty keen on looking at the VC card and if there are some features that are not there just kind of discuss can we put them in? Should we look at OCA bundle? Should we put it in or so on? And it kind of closed the page on that. Yes.

Manu_Sporny: Yeah, and now is definitely the time to engage on that because that is exactly what we're talking about in the group. today's call was around that. It was around internationalization and how complex, should we make it and what features are missing. So, if you can join us, next week it's at 11:00 a.m. Eastern every week.

Patrick_St-Louis: Yeah, on Tuesdays.

Manu_Sporny: I guess I'm going to be traveling, but the rest of the group will be meeting. You should definitely on Tuesdays at 11:00 a.m. Eastern. Okay.

Patrick_St-Louis: Yeah, it's just such a Okay, I'll see what I can do. Manu Sporny:

Manu_Sporny: All right.

Patrick_St-Louis: It's just been very difficult for me to I wanted to…

Manu_Sporny: Yeah.

Patrick_St-Louis: because I signed up for it, but it's just, one of these unfortunate things. yeah, that's good. I mean, I have a lot more I could say, but I think it's better to talk about that in that call. we're gonna spend a lot of time on this. so I wanted to give an update on the test suite and the update is that there's no update. I still have a lot of work I need to commit. So I had a pretty good blitz a while ago. I broke down the work, open a few PRs. I just need to take the time and get this work in.

Patrick_St-Louis: So I had the test for the issuer and verifiers. I had an implementation that was passing. so yeah that's pretty much the update. I just wanted to say still in my mind I'm still thinking about it. I just need to take some time and it doesn't even take a lot of time. Just need to take a couple hours clean up and send that so we can push this forward. but I still feel good about the test suite. Do we have kind of a timeline we want to aim for these or it's just kind of whenever we can how does this fit within we're talking about horizontal review threat model how does this fit in the process was yesterday is the time coming or is it now? Yes.

Manu_Sporny: the time was yesterday. typically you want to have a test suite before you go into candidate wreck. You don't have to like we could stretch it out for another year, and it would still be within process. However, when you go into candidate recommendation, it's good to have a good idea of what you need to get out of candidate recommendation and the test suite is kind of the clearest signal of that. all of the tests that you have, if you have impleers that run against the test suite and they're like, we, succeed against 95% of the tests and you've got two impleers saying that, you have a very good chance of getting out of candidate wreck quickly. it's us almost never the case, right?

Manu_Sporny: Usually you have people that are at 50% or 60% and the test suite's halfway done. but it's better to have a test suite it's better to have the test suite as soon as you have feature stability in the spec.

Manu_Sporny: So I mean the sooner the better, but it's not going to stop us from going into candidate wreck.

Patrick_St-Louis: Yeah. Yeah.

Patrick_St-Louis: Okay, that sounds good. Thanks. I'll make sure I set some time aside to do this. It's really just a matter of putting the time in.

VC Data Model Threat Model Publication

Patrick_St-Louis: Any other questions or comments about test suite? anyone have something they'd like to share? Tourett model. So this is becoming our favorite topic. So I will turn it over. I don't know if you want to start, Manuel. I know you mentioned something or I don't know if Joe or Eric would like to chime in. So maybe I'll turn it over to you, Manuel, and you can get the ball rolling.

Manu_Sporny: Sure thing. Thanks. And I'm going to grab the screen real quick. we have published verifiable credential data model threat model version 2.1. This is based on a whole bunch of kind of consensus based decisions we've made over the past couple of weeks. to basically, name the threat model after the spec. So VC data threat model to put oops a version on the threat model that matches the spec to have date stamped releases and things of that nature.

Manu_Sporny: So this document is out there and follows the same kind of format here DFD and things like that. so this for the VC data model is published and it's on Akidna and it's autopublishing and we have a new publication scripts that run in the main spec we got some feedback from ping that basically said a threat model is not a replacement for privacy considerations please put privacy considerations back and we went back and forth on how could we structure it taken a new cut at structuring it so I've put security considerations and privacy considerations back.

Manu_Sporny: I've taken all mentions of the threat model out except in the security considerations section we're like hey we talk about we summarize some security threat considerations here …

Ted_Thibodeau_Jr: It's okay.

Manu_Sporny: but really look at the threat model if you want detail and for each section we basically say here's a single sentence threat description of it is and if you want to learn go over to the threat model which explains it in more detail here. And so that's how I've done the new linking. It seems to work fineish, but I still have not heard back from Ping or Singh on if this works for them. go ahead, Joe. You might be double muted.

Joe Andrieu: Yeah, thanks. I did have a brief chat with Simone. He's encouraged by this particular version. and he thinks it does address privacy's issues and he's had some conversations with them. So hopefully that will bubble up and we'll get a commentary. he and I both looked at this today and I agree. I think this addresses what Ping has said frustrated them. Both Simone and I are a little frustrated with Ping right now, but I think this is pretty good. Although I had thought that the short name of the threat model was going to have the version of the spec in the URL,…

Joe Andrieu: which this does not have. So that's just a question, Ted, I guess.

Ted_Thibodeau_Jr: Yeah, that's the direction my question was in.

Ted_Thibodeau_Jr: We've got versioning on two things and I think that both are important. the threat model is a version but it's based on a spec version. So I think we have to say data threat model 2.1 or whatever

Patrick_St-Louis: Run it.

Manu_Sporny: We explored that, My understanding is the group said no, we should not do that. because having two versions in the title would confuse people possibly.

Manu_Sporny: to so let's talk about the short name there's an alias which is this URL right yeah there's an alias and…

Joe Andrieu: I see.

Joe Andrieu: Yep. That's great. That does map to what I was expecting. It was that the short run didn't have it. So,

Manu_Sporny: the alias is supposed to redirect they keep changing this at W3C but it does bring up the 21 and the actual URL is

Manu_Sporny: the versioned one. so I think it's set up correctly based on what the group came to consensus on. Ted, I'm pretty sure we discussed the VC data model-2.1 threat model-10 potential and…

Manu_Sporny: the group was like, "No, that's too confusing to have two versions in a single short name." If that's what you meant. Okay,…

Ted_Thibodeau_Jr: that is…

Ted_Thibodeau_Jr: what I meant lacking that I think there needs to be some more detail in the content that says this applies to data model 1.0 0 which is and not a problem in 2.1 or whatever.

Patrick_St-Louis: Yeah,…

Manu_Sporny: we'll bring that up in the main call, I

Patrick_St-Louis: That's one thing I thought was confusing this to two, thread model 2.0 over Fal Crucial data model. There's the data model 2.0 0 itself that's being worked on and if 2.1 is for VC data model 2.0 and then when 2.1's going to come out there's going to be 2.2 or I could see this maybe becoming confusing.

Patrick_St-Louis: Okay.

Manu_Sporny: H hold on.

Manu_Sporny: Yes, that is confusing. But the version of the threat model always tracks the version of the spec. they should never deviate.

Joe Andrieu: No No sir.

Patrick_St-Louis: Okay.,

Joe Andrieu: But I'm on the queue to speak to that if you want me to. So this was explicitly talked about. The threat model is actually going to outs survive the specification. We're going to have iterations on this threat model while the spec is staying static. And so we do need a version within the contents of this spec saying this is threat model 1.1 that applies to the VC data model 2.1. so I mean our group is not going to resolve this but that was my understanding man. Yeah.

Manu_Sporny: We should talk about it on the main call. putting that to the background because as you said, we're not going to resolve it here. There are a couple of other updates that I did that I thought might be useful to others. And one of them was this concept of mixing in some of the threat model stuff with some basically handwritten bits. So in VC data model the privacy considerations these three did not move over to the threat model because they weren't necessarily threat model stuff like talking about the spectrum of privacy that VCs are trying to address wasn't really a threat model thing but it was a privacy considerations thing and in the spec what we do here is partially I'm gonna have to

Manu_Sporny: There is some respect additional stuff that hold on one second. Let me see if I can try and find it. Not that. It's down here at the bottom. Okay, this thing will basically pull in the threat section as data. So the summary and the title and all that kind of stuff, it'll pull it in by reference.

Manu_Sporny: What that lets you do is it lets you put content around it if you want to the spectrum of privacy thing here is we talk about it here but then when you get down into the other things in the threat model they're just included in this way. again respspec editions and again apologies Joe and Eric I continue to have to refactor the code here to try and get some of these things working quickly. desire still to put it into respect threats once it stabilizes but it just continues to not stabilize. just thought I'd mention that that's so with all that said, Eric, do you have enough to put it into this general shape?

Manu_Sporny: Noting,…

Manu_Sporny: the concern Joe mentioned,

Eric_Schuh: Yeah,…

Eric_Schuh: I mean I can certainly, somewhat undo the work I did to get rid of the security and privacy consideration sections. reorder that and transform, the relevant parts to be closer to this in terms of instead of maybe the whole section that we had previously, a shorter description that links to the threat model. that doesn't sound too difficult. I guess outside of that is that the work that needs to happen by I guess Friday in its totality or is there other process related things I would need to also do since

Manu_Sporny: So all of the instructions are typed up on the VCWG mailing list. So there's a list of things you have to do.

Eric_Schuh: Okay. …

Manu_Sporny: You do not have to modify the main spec. You don't have to touch the VCOM spec at all. The only thing that we're trying to do is just publish the threat model under its own R space and for that you don't have to rewrite this threat model security privacy consideration section in the BCOM spec.

Eric_Schuh: That's for the future CR.

Manu_Sporny: Yeah, that's right. I mean, it's an editorial change that you can basically do at any point,…

Manu_Sporny: right? but the threat model itself is the thing that we need to publish and that has the instructions on how to do that. It's just like publishing an FPWD. And so the instructions on how to do that step by step is on the BCWG mailing list.

Eric_Schuh: Okay. …

Eric_Schuh: then yeah, I believe the only work that is really needed is to make sure those links up at the top are correct.

Eric_Schuh: I think the form of the threat model is already in the form that you've shown. There might be an extra section here or there that we included but I don't think it's any breaking changes in terms of the content. I guess my final question is in terms of content this isn't cons like this is just a publication we can do it again in the future right so I don't need to worry about any of we have a few threats that still don't have responses and…

Ted_Thibodeau_Jr: That's it.

Eric_Schuh: things of that nature that I have a PR that is working on that started but I don't know that I'd get through it by Friday and regardless the group wouldn't have time to discuss

Eric_Schuh: and approve the content by Friday. So, as long as we're good with the content that's currently in there going into this first published version, then I think I have what I need or I can find what I need in terms of the mailing list.

Manu_Sporny: The content doesn't matter as much. It's going to be published as a draft node. And the main reason we're doing all of this stuff is because the W3C tooling is weird. we're just putting it out there so that we can turn Akidna on so we can get continuous static publishing working.

Eric_Schuh: Then I think I have what I need or I can reach out to relevant parties if I get stuck somewhere.

Exchange Data Feature PR Review

Patrick_St-Louis: Any further comments on this topic before we move on to reviews. You'll see our pull request. Trying to collapse look So, let me review this one we did talk about the last time.

Patrick_St-Louis: I do remember that there was some outstanding thing to do. Yes,…

Eric_Schuh: Yeah, if you just wanted me to go through what's happened…

Eric_Schuh: since last week real quick.

Patrick_St-Louis: I would love that.

Eric_Schuh: That's easier.

Patrick_St-Louis: Can you quick

Eric_Schuh: Yeah. So last week we talked about this exchange data feature there were a couple of items on the list that needed to be updated. I believe Dave had put in corrections to the context and definition urls. so those were accepted. there were some minor editorial changes by TED. and then I also moved the JSON LD file in the context folder to point to the specified location that Manu mentioned in the comments. So, I believe in terms of the to-do list from

Eric_Schuh: past week. everything here is done. and then we do have an issue open over in the credentials working group or…

Eric_Schuh: sorry the data model working group to get this added over there I guess when that happens.

Patrick_St-Louis: This one here,…

Patrick_St-Louis: my concern is the test failing.

Eric_Schuh: So I believe as far as to list from last week everything has been done for this issue. and if I remember correctly Monu you had said that there's no reason to hold up this PR in terms of waiting for the VC data model group to resolve that other issue. so I believe it's ready for merge unless someone has a new concern. hard for me to say.

Patrick_St-Louis: Is this okay?

Eric_Schuh: I took a look at these I guess with the akidna issues I guess yeah monu…

Eric_Schuh: if you have something please go ahead.

Manu_Sporny: Don't worry about it. It'll be an editorial fix if we need to fix What errors get throwing? yeah,…

Patrick_St-Louis: something about the broken local reference.

Manu_Sporny: don't worry about that. We would have to fix it, but that's an editorial change. I don't know which local reference it's talking about, but Akidna tries to make sure that your HTML is wellformed.

Patrick_St-Louis: And then we're here.

Manu_Sporny: In some runs that it does, and that's what it's doing here. And so there is something probably syntactically wrong with the spec. yeah.

Patrick_St-Louis: It seems to be looking for Exchange verifiable presentation.

Patrick_St-Louis: which this PR should be including.

Manu_Sporny: It's there.

Patrick_St-Louis: Are we okay? Any objection that we merge and if something goes wrong we address it. Want a quick edit?

Patrick_St-Louis: I think not a big fan but I think we all in agreement content seems correct. perfect.

Eric_Schuh: Yeah, I will say everything looks pretty rendering fine and…

Eric_Schuh: linking fine when I run it locally.

Patrick_St-Louis: Let's give it a good shot.

Manu_Sporny: Yeah, plus one emerge. And I think' the GitHub actions on here are ancient.

Manu_Sporny: We may want to take a look at them and give them a refresh.

Patrick_St-Louis: Yeah, maybe some updates.

Patrick_St-Louis: It's cuz we don't have dependabot or anything like this. Sometime they kind of let you know if your actions need to be updated but that's a good thing to do. So this is merge. We'll keep an eye. I'm assuming it's going to kick off some stuff. So we'll keep an eye on this. if there's a problem, we'll need to come and address it. Okay.

Patrick_St-Louis: This is the issue I opened. This is the same thing. This is the actions. The appendex with the swim lane example.

Patrick_St-Louis: What's the update on this one? Eric, there's a few suggestion from Ted.

Eric_Schuh: Yeah, I missed those.

Eric_Schuh: I mean, assuming these are mostly editorial in nature,…

Eric_Schuh: I think I can probably accept these on this call.

Ted_Thibodeau_Jr: Yeah, most of my

Eric_Schuh: Yeah.

Patrick_St-Louis: Yeah, they were requested yesterday. So

Eric_Schuh: Content wise I think this has been stable for a couple of weeks now. so it adds four sequence diagrams to show basic examples of issuing verifying and…

Eric_Schuh: presenting a credential in person as well as presenting a presentation in person.

Patrick_St-Louis: Perfect. So,…

Document QR Code Shoulder Surfing

Patrick_St-Louis: I'll let you go through these suggestions, apply them or reject them and argue with Ted and we'll be able to merge this after. So, we'll come back in the last couple minutes of the call. document cure code shoulder surfing. have you had a chance manually to have a look at this a little bit?

Manu_Sporny: Unfortunately, no.

Patrick_St-Louis: Yeah, let's see if there's been any update on the last week.

Patrick_St-Louis: Yeah, I think everything was a couple weeks ago, some editorial stuff, but it seems like there are some question that needs resolving from Eric Simony. do we want to discuss about this where it's at or just put it on bright log a little bit for another week?

Manu_Sporny: Let me make a pass because there's a lot to review here and I don't know what's open. I think last was the numbering was off. and Eric, you took an action to update the numbering to fix that. thank you for doing that. I forget if there was anything other than that that was outstanding. on that topic though, I will note that and Joe, you might not like this, Joe and Eric. I went to an auto numbering scheme on the other threat models and it worked out really nicely. meaning that, the thrashing on the numbering kind of went away when I did that. we can discuss that at some other point, but just a heads up like that prevents Eric having to do the type of PR here that he did. that's it.

Patrick_St-Louis: Anything else to add? you're good. replace first name with given name. yes, I think that's good. Can someone tell me why is given name more correct to use?

Ted_Thibodeau_Jr: Because first or rather family names are not always fast.

Patrick_St-Louis: Okay, interesting. That makes sense.

Patrick_St-Louis: But doesn't given name and family name cuz this is replacing first name with given name and…

Ted_Thibodeau_Jr: Right. Yeah.

Patrick_St-Louis: I believe that if I look on schema.org they use given name and family name correct?

Ted_Thibodeau_Jr: Schema.org is not a source of truth. Your first name is Patrick.

Patrick_St-Louis: Yes. Yeah.

Ted_Thibodeau_Jr: But if you were in China, then your last name would be Patrick and…

Ted_Thibodeau_Jr: your given name would still be Patrick.

Patrick_St-Louis: That's very interesting.

Patrick_St-Louis: Okay. I absolutely love that. thanks.

Ted_Thibodeau_Jr: Yeah, somewhere around here there's a link to that fabulous list of things programmers believe about human identity.

Patrick_St-Louis: Okay.

Ted_Thibodeau_Jr: Put it to good use.

Patrick_St-Louis: because I definitely know that I see given name and family name used together and first name and last name used together, but I didn't know the reason why. And what you just explained to me makes a lot of sense. what's the state here? I think it looks pretty good. It should be a very small change.

Name Ontology Change

Kayode_Ezike: I think you had Benjamin on the queue.

Kayode_Ezike: I'm not sure.

Patrick_St-Louis: Benjamin.

Patrick_St-Louis: Sorry. Yeah.

Benjamin_Young: Yeah. No,…

Benjamin_Young: I was just going to hear one comment about should first name be given at this point it's just an ontology change for something we haven't really yet shipped. But if you had data, it's going to depend on who you are and where you're sitting, whether or not you cared about the ordinality of the naming in terms of if you were in Japan and…

Benjamin_Young: was working with Japanese data and you did first name and you put it in the order that you use in Japan, then you'd have a data migration problem,…

Patrick_St-Louis: Yeah, it's going corrupt hackers.

Benjamin_Young: which is why getting this right is so important. And yeah, it's still a mystery why most people refuse to get it right.

Patrick_St-Louis: Yeah, because I do see both in the wild in various official documents, It seems like there is no alignment, but I think a given name sounds to me is probably the best option. Any objection to merging this?

Patrick_St-Louis: So, I think it's fairly straightforward. Good. I learned something today.

Adding Credential Offer Parameter

Patrick_St-Louis: Adding credential offer parameter to the verifiable presentation request. This is a new one. can you take me through this, okay.

Eric_Schuh: It's actually not a new one.

Eric_Schuh: This is the, replacement PR for the End of line issue. I put end file there, crossed my wires a little bit. But, I think the, only new thing here is that Dave, you had suggested that we could add possibly this group feature to, the credential offer. I don't think I have an issue with that. I was looking through this before the call. didn't quite get around to updating, but Dave, I was wondering in terms of where that parameter should go, is that part of the credential object that goes inside of the credential offers? yeah, go ahead.

Dave Longley: No, it would just go underneath the credential offer, not in the credential itself. So, it's already optional in a VPR to include a group property if you want to group things together and…

Dave Longley: you could tag the offer with those that same group so that those things are related to each other. So, it's a way of connecting this credential offer to things in the query that are also grouped.

Eric_Schuh: So each credential offer would…

Eric_Schuh: then have a single group property.

Dave Longley: Optionally have a group property.

Dave Longley: Yep.

Eric_Schuh: Does that feel right? because it feels like what you would actually want to be able to say with that type of feature would be to say I have a credential offer. It can be, using the andor logic, right?

Eric_Schuh: one of this group and one of this group type of logic which It would just be advertising that we have a set of credentials that all belong to this one group.

Dave Longley: I couldn't sorry I would have hit the button I didn't know you were going to get on the queue coyote I didn't quite follow in a VPR you can optionally tag different queries with a group indicating that whole group needs to be satisfied and…

Eric_Schuh: Yeah. Sorry.

Dave Longley: you can choose any one of the groups to fy. and tagging the offer with the same group would indicate that if you satisfy that query that offer is associated with that group and so you should get the same logic that you also get out of the queries. So every different group in a VPR is and everything within the same group is and the same would apply to credential offers.

Ted_Thibodeau_Jr: Thank you.

Patrick_St-Louis: Hey, So…

Eric_Schuh: Yeah, I guess my confusion comes that right now I would believe the way this is structured the credential offer is a singular parameter,…

Eric_Schuh: That would imply that there would be an array of credential offers or…

Eric_Schuh: something that you could yeah I wrong level.

Dave Longley: It's currently an array and…

Dave Longley: you can put as many in there as you would like in the same way that the query is. Yep.

Eric_Schuh: Yep. Sorry. I think…

Patrick_St-Louis: where does that leave this PR? Is it in a good state or do you need to make some adjustment based on this conversation?

Dave Longley: I was just going to say we could either merge this and…

Eric_Schuh: if Go ahead. I think now that I better understand…

Dave Longley: could have a se another PR that adds the group optionally or we could just put it in here. It's up to Eric.

Eric_Schuh: what this is asking for, it would be a fairly simple update to this PR.

Eric_Schuh: But if we just want to clear this out, I'd be fine merging and opening up a new one.

Patrick_St-Louis: That's …

Patrick_St-Louis: but I propose to add it in this PR so it's nice and close the loop. is that And let's add the group feature completed. okay, there we are running out of time. were you able to get the recommendation from Ted in

Eric_Schuh: Yep. Works for me.

Eric_Schuh: on the other PR.

Eric_Schuh: Yes. Y

Patrick_St-Louis: So I think it was this one,…

Patrick_St-Louis: Yeah. Any objection to merging the new swim lane example And I think that's going to be our last one for today. Maybe we can just have a quick look at the other ones. Probably not going to engage in. So the only last one was this specify proper format for datetime properties. Actually we might be able to merge this in KOD. Do you want to take us quickly through this?

Kayode_Ezike: Yeah, this is a fairly simple one. This was the results of the internationalization review or one of the three that were outstanding which is just that we never really specified the format for one of the date fields. I forget which one valid till or something. And so I decided to just apply it to all the date fields that it could apply to which turned out to not be that many.

Kayode_Ezike: And so yeah, it's really just making sure that we specified that it's the date timestamp format which is the same format that is used in VC data model. That's all Yeah,…

Patrick_St-Louis: And when we say…

Patrick_St-Louis: if not provide. sorry Go ahead.

Manu_Sporny: No, no problem.

Manu_Sporny: Coyote, did you check to see what we said in the VC data model? Because I think we go beyond saying it's just a date timestamp. I think we have other requirements on top of it and we may need to explicitly state go and read about, X Y and Z.

Kayode_Ezike: I actually did refer to it. I mean I noticed one thing that was interesting which is that it referenced the date time like fragment of the source of XML schema sorry and I guess I just made sure that I was referencing a daytime standpoint. Beyond that, I'm not sure if there was anything else that I may have missed. I can double check to see, but yeah, I didn't notice anything else beyond that.

Patrick_St-Louis: I'm confused about this part here if not provided what will make it default to the current system.

Kayode_Ezike: I think this was just a carryover from what was removed current system some time. So just saying if a value for this is not provided it would just use whatever the date now right the current time for that value.

Patrick_St-Louis: Which shouldn't this be a separate must like saying…

Kayode_Ezike: Yeah. No,…

Patrick_St-Louis: if you don't provide the created timestamp you must include the default to the current system.

Kayode_Ezike: no, it's more so saying how the system will interpret a missing created value.

Patrick_St-Louis: But I believe created in itself is optional in data integrity, right? Kayode Ezike:

Kayode_Ezike: It's not specifying. It's saying you could leave that value out if you want to but the default behavior of a VCOM I guess component that's consuming this would be to use the current day time so it's not a specification on what it is basically this last sentence that was removed above I'm pretty much just putting that last thing that was there default current system time in the red 34 it's just re rename re stating that in a sentence

Kayode_Ezike: This is basically saying this is…

Kayode_Ezike: this is how you should interpret a missing created value is you should use the current date.

Patrick_St-Louis: That's it.

Patrick_St-Louis: Okay. Thank you.

Kayode_Ezike: Yeah I guess I could double check.

Patrick_St-Louis: At time. I'm not going to ver we just had a question about looking at the other spec and…

Kayode_Ezike: Yeah. Yeah.

Patrick_St-Louis: let's just look back in this at the next meeting. just make sure that it matches the other spec and stuff. Should be quick. other than that, we're at time. Thank you a lot for attending. good progress today. Closed a few PRs and we'll talk again next week. Thank you very much. Meeting ended after 01:01:20 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.

This transcription was generated by a large language model (LLM) and might contain errors. When in doubt, check the audio recording. This page was formatted by scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).