Meeting minutes
Patrick_St-Louis: Welcome everyone. We'll get started in a minute.
Patrick_St-Louis: Okay, we're going to get started. we have pretty good attendance. If people join, they will be able to catch up. So, welcome everyone to the VCOM call. this is a W3C meeting. All W3C policies are into effect. This call is recorded and it will be transcribed and made available publicly. today is September 1st, 2026. the VCOM meeting is a meeting during which we discuss the VCOM specification which is for life cycle managements of verifiable credential through an API.
Patrick_St-Louis: Today I did not list any topic on the agenda. I think things are going and most of the concerns we have will be able to be addressed in PR reviews. However, if anyone has suggestions, things they would like to discuss or follow us to do, please let us know and we'll add it to the topics. I will leave some time right now for introductions or reintroductions as well as relevant community updates. I will share a community update that can be somewhat related.
Open Wallet Foundation Transition
Patrick_St-Louis: So the open wallet foundation will be winding down its operations fairly soon. all the projects currently hosted at the open wallet foundation will migrate towards the Linux foundation decentralized trust LFDT. so this is being posed as a positive significant difference is that the open wallet foundation is hosted under as the Linux Foundation decentralized trust is not under that company. So we should see these change into effect in January 2027.
Patrick_St-Louis: most active project like Akapai and Credo will remain in operation. The maintainers will keep maintaining the project. The project will just be hosted under a different foundation. I don't have more details than that but more details is available. This was made public about four days ago. so nothing will change on this. It's just the sort of legal framework behind it will change. Again, I don't have many of the details as to the exact reasoning. I'm not part of the advisory board, but this is a decision that's been made. So, pretty exciting.
Patrick_St-Louis: there was a shift couple years ago from the Hyperledger Foundation towards open wallet foundation and now it's another similar shift and sort of organizational structure. so that's it for me. I'll leave a bit of time if other people want to share some updates. Yes, man.
Threat Model Publication Path
Manu_Sporny: This is kind of an agenda plus because Joe and Eric are on the call. I want to spend a bit of time talking about path forward with threat model. We were able to talk with Ivon a little bit this morning just when we don't have a verifiable credential working group call later this week because of GDC. So maybe if we can spend 10 minutes to figure out a plan for it there, I think that would be good.
Patrick_St-Louis: Yeah, we can definitely spend some time on the topics. Is this something we want to time box or take as much time as we want?
Manu_Sporny: I think 10 minutes hopefully we can come to a path forward. and…
Patrick_St-Louis: Okay, sounds good.
Manu_Sporny: if we don't, we've got other things to do in this call specifically.
Patrick_St-Louis: Let's put 15 minutes. Coyote,…
Horizontal Review Update
Kayode_Ezike: Yeah, another agenda plus was just to give an update on how horizontal review is going.
Patrick_St-Louis: Can you repeat that? I didn't understand.
Kayode_Ezike: Yeah, just to give an update on horizontal review requests for
Patrick_St-Louis: Horizontal review request. Yes, for sure.
Patrick_St-Louis: So threat model horizontal review very good other relevant committee updates I know there's an event in Geneva this week it's mostly around supply chain UNP
Patrick_St-Louis: which is sort of parallel not too far this related to verifiable credential there's no direct mention of VCOM in the UNP since they do not do exchanges but it's not too far okay so two topics were added we're going to start discussing the threat model. We're going to time box this to 15 minutes and then we'll discuss the residental review probably a similar time box. so Manu, do you want to just break the ice for this topic and then let other people talk?
Manu_Sporny: Just so everyone has some background, multiple task forces have been working on threat models. we had a plan to kind of publish them. it required some extra work and I think most recently Joe you raised the question of why don't we just use the current tooling we have and the current process and I think proposed can't we just publish this under a different TR space so we can I think to cut to the chase I think as long as PL H.
Manu_Sporny: gives us just blanket authority to publish threat models. So for every spec if it needs a threat model we can publish the threat model as a note then that gets us unstuck and is the least amount of effort. plus one to that approach to get us unstuck. Avon was I don't remember if he was pushing back or not on notes as the mechanism and I didn't really care one way or the other. We just needed to publish it. I agree that Threat models are not Rex. and so if Avon agrees to that then we can just go forward.
Manu_Sporny: So I think the things that we need now is for Avon and PLH and Francois and Denise and whoever else at W3C needs to agree that we can just blanket publish threat model so we don't have to keep making resolution after resolution and FPWD after do that whole process song and dance if we can get that out of the way then we can publish. I would like to at least for the specs that I'm an editor of keep the threat models in the same directory for now.
Joe Andrieu: Thanks.
Manu_Sporny: Joe, I know that you've got, plans for the future with respect to registries and how it's managed after the working group and all that kind of stuff. I would like to not pull all of that into the conversation just because we just need a static document, published on TR space so that we can link to it. there's one minor downside to publishing it in this way, but I think the editors can deal with it. I'm largely just trying to reduce the amount of W3C process and paperwork and paper pushing that we ended up would have to do.
Manu_Sporny: and Avon was suggesting that we would have to do an enormous amount of process and whatever. So I think that's the proposal is and then we can publish to TR space without it being in a different repo. There's respspec does support that so that can be decoupled from the future decision. So, I think that's sort of…
Manu_Sporny: what you proposed, Joe, in a thread. I just wanted to check in to make sure that That's it.
Joe Andrieu: Yeah, I thought so that mostly makes sense.
Joe Andrieu: where I'm not following is I thought part of the conversation with the new tooling that was needed was because publishing two specs from the same repo i multi-chapter specification caused
Joe Andrieu: Some problems.
Manu_Sporny: R space causes problems. Publishing two specs to two different TR locations is totally fine and is supported.
Joe Andrieu: Okay, cool.
Manu_Sporny: That's what Francois said. He was like, "Why don't you just do this?" And I was…
Manu_Sporny: "Okay, we'll do that." I guess it turns out they totally broke multi- chapter support. And maybe multi chapter support was never in there and people were just make files to do it before.
Joe Andrieu: Yeah. Right.
Joe Andrieu: So that all sounds good. I do appreciate the call out for, eventually it probably wants to live in a registry, but we're so far away from any registries that it feels like too much overhead to deal with that now.
Joe Andrieu: So what you propose looks great. and so the pattern then is still let's just use a folder. but we will publish to a unique location in TR space. So we'll need a short name, right, for each of these then. And so there's some process related to that, I guess.
Manu_Sporny: Yeah, I didn't know if I interrupted you.
Joe Andrieu: No, no, that was all. Good.
Manu_Sporny: The proposal I think that Francois said was if we can just settle on a pattern for those, we don't have to make it on a case-byase basis. And so if the spec is named, then the threat model would be threat. So if we can agree on a pattern like that, then it's just that blanket pattern applies to everything. It will result in long URLs. But I mean, I don't think we care that deeply. that's it.
Manu_Sporny: I think that was the main thing is that Avon was saying no we have to go through the W3C process for every single one of these things. The group has to decide that they're going to publish the document. They have to decide what format note or not. They have to decide what the short name is. They have to decide on the publishing date. They have to decide on the FB. It's just like no I don't want to do all that stuff let's just publish it. and so Francois said there is an option as long as PL agrees we can just make one resolution to publish all of our threat models using that pattern. that's
Patrick_St-Louis: If I don't understand correct as for immediate action, there's none. We keep going the way that we started. I'm assuming this is the threat model directory we were referring to. which was the original idea. So that's my first assumption. Is that correct, Manu? Okay.
Manu_Sporny: Yes, We keep everything kind of in the directories that we have right now.
Patrick_St-Louis: Is that why you raised your hand or did you have something else to say?
Manu_Sporny: No, I raised my hand because the next step is to get Avon and PL and Francois to work together to agree that is an acceptable approach. And if they agree then the step after that is get the verifiable credential working group to pass that resolution and then we can start publishing all these documents in space.
Patrick_St-Louis: And is this a step that you will take yourself to communicate with Ivonne and…
Patrick_St-Louis: France?
Manu_Sporny: Yes. Yep.
Patrick_St-Louis: Okay.
Manu_Sporny: Yeah. Yeah. Along with Joe and whoever else is on that thread. There are a number of people on that thread.
Patrick_St-Louis: Perfect. Joel
Joe Andrieu: Yeah. …
Joe Andrieu: I just want to note, and I was about to add it as an issue to the VCOM, which is probably the right place to follow it. This readme really doesn't belong here. and there may be still some more edits of that nature. this is a read me for the respect threats library. and so although it's useful for the folks who are working on this, it's not part of the threat model itself. it's how you use that library, not what should be published. so let me just make an issue and…
Joe Andrieu: we can get that in the queue to make an edit to bring that read me into something more reasonable.
Patrick_St-Louis: Just a question like so this index.html this is…
Patrick_St-Louis: what needs to be published. This is the spec. does it matter…
Patrick_St-Louis: if there's a readme here? it does. Okay. Yeah.
Joe Andrieu: It' probably be good to have it be a read me that's about threat modeling,…
Joe Andrieu: just to speak to,…
Joe Andrieu: hey, we've got this folder set up and that's where we're keeping track of threats, Yeah.
Patrick_St-Louis: Right, right,…
Patrick_St-Louis: right, right. Okay. Yeah. So, this readme should be its own kind of repo that just explains…
Patrick_St-Louis: how this model works and then it gets referred to in here. Eric
Eric_Schuh: Yeah, I mean I left this in originally…
Eric_Schuh: because the respect threats was new and if anyone else wanted to work with this from the VCOM, I thought this would be agree with Joe, this is not really relevant to this specification. and Joe, I think maybe what would be nice would be to have even a second readme of some type in the respect threats that's kind of a generic explainer that a group could use and, insert the specific specifications name and…
Patrick_St-Louis: …
Eric_Schuh: everything like a template of some kind.
Joe Andrieu: Yeah, agreed.
Joe Andrieu: We should also export I think there is a template somewhere that we created that's a GitHub template that we should also put in that library. But those are just notes for you and me to update that library.
Patrick_St-Louis: a bit of cleanup to do but nothing critical for what we want to achieve. And then the second assumption I want to say just to make sure I understand is that there's going to be some kind of engineext config somewhere that's going to publish both the VCOM spec here at the location and the VCOM threat model spec here at a adjacent location by just appending thread model to whatever the existing spec name in the URL.
Patrick_St-Louis: Just want to make sure I understood that correctly. Joe.
Joe Andrieu: Something you said didn't sound quite right,…
Joe Andrieu: but the general thing I believe is correct. it's just a different config file for the respect config properties in this index which then should pull in akidna and publish it to the short name. And that's the work that Manner just mentioned. We need to get a proposal formally adopted da yada.
Patrick_St-Louis: I mentioned engine X because I thought I remember there was a project somewhere that kind of puts an kind of proxy for all these repo but I'm not 100% familiar with the backend pipeline here. I have a vague memory of seeing that at some point in the past when looking at the test suites and stuff.
Joe Andrieu: Yeah, that there may or may not be engine X involved in the TR space, but for us it's just changing that respspec config and…
Joe Andrieu: getting staff to bless that this is the right place in TR space and getting Akidna set up then that should all take care of itself.
Patrick_St-Louis: Yeah. what's that term you said?
Patrick_St-Louis: Getting what set up?
Joe Andrieu: Akidna, it's E C H I DNA.
Patrick_St-Louis: Akidna. What is that? just Okay,…
Joe Andrieu: I don't know what it stands for. Thanks Dave. but it is the real time publishing to R space from GitHub that a lot of these specs already use. so that might have been an accident in it to be fair…
Patrick_St-Louis: Okay. okay.
Joe Andrieu: but who know I don't know Nice.
Patrick_St-Louis: Yeah, I'll make some research. I should be able to find mode most more information. Mu
Manu_Sporny: I'm just going to share a cute picture of an akidna. that's the akidna.
Patrick_St-Louis: A cute.
Manu_Sporny: That's what it stands for. It's cute, isn't it? going back to where is this is the kit file that we're talking about. there's not a lot here, So it's a GitHub workflow Patrick and…
Patrick_St-Louis: Okay. Yeah.
Manu_Sporny: it will publish a spec to a particular directory in W3CTR space. There's some extra options you can use to point it to a different file. And what we would do is we'd take, autopublish and we'd split it into two things. Autopublish the spec and autopublish the threat model. And I think that's Yeah,…
Patrick_St-Louis: And I guess the short name here is what ends up in the URL.
Patrick_St-Louis: 12. Awesome. Manu Sporny:
Manu_Sporny: So be like vom threat-model and there probably wouldn't be a version on it. that's effectively…
Patrick_St-Louis: Okay,…
Manu_Sporny: what we'd be doing.
Patrick_St-Louis: perfect. So, it doesn't sound too complicated. That sounds like a lot of the Yeah.
Manu_Sporny: Yeah, the spec status would be a dnote draft note and then when we're quote unquote done, which thread models are never done, we'd publish it as a note. So that's like to be figured out in the future though.
Patrick_St-Louis: Any other comments or closing thoughts for the threat model before we move on to the horizontal review discussion?
Patrick_St-Louis: In that case, let's move on to the horizontal review. Kyod, do you want to introduce us to this topic and get us started?
Kayode_Ezike: Just put a topic in a chat really quickly. so just as a reminder, I think maybe three or so weeks ago, we completed accessibility and internationalization reviews. rather submitted them. I'm still waiting for responses. Since the last week, I completed the self review we have to do for all of these reviews prior to when we submit them, right? So we have issues tracking all these in fcom. So the three that were remaining were for security obviously and tag which is a design architecture review that's managed by tag which is a technical architecture group.
Kayode_Ezike: So filled out the self- review questionnaire last week which basically covers all three of those security, privacy and architecture and I have basically created the text for the design the security and privacy ones. I'm ready to submit Modulo, one small thing that I need to do, which is the latest spec has not been deployed that I released today. The latest a push to main and that needs to be in there because there was a bunch of edits that we made recently. And also, we may want to I don't know if we do want to wait for this, but there's some stuff in Eric's most recent PR as well that may need to be included.
Kayode_Ezike: So that's the only thing holding up those two security and privacy and the tag one. I'm just completing the questionnaire or rather there's more to the tag one than the other one. So I'm just finalizing the content for that issue.
Patrick_St-Louis: Very good, man.
Kayode_Ezike: So that's the main update. I expect for all this to be resolved this week, next day or two at most. That's all.
Manu_Sporny: That's great, Thanks for working on that. did I hear you say that you might hold off on raising the horizontals until PRs are in? I think you can just do it. it's going to be months before they get to it.
Manu_Sporny: And I know it changes the self-review questionnaire, but you can always go in and revise it or update it so that they see the newest one whenever it happens.
Kayode_Ezike: Yeah, I guess I was mostly concerned about and…
Kayode_Ezike: maybe this would be resolved because I guess the URL based off of the date I suppose but there's the most recent one that I published that should have 91 in there it hasn't been published yet and
Kayode_Ezike: So I was wondering should I just put that date sort of presumptively and then you expect it to resolve eventually or u and maybe modify even in the future whenever Eric is in as well. is that what you suggest is just sort of guess…
Kayode_Ezike: what it's going to be.
Manu_Sporny: Spec prod has an outage coyote.
Manu_Sporny: So I wouldn't wait on that to resolve. all spec publishing is down at W3C the spec ref database is down…
Kayode_Ezike: Okay.
Manu_Sporny: because some deal with, Heroku or Cloudflare or something went south and they're trying to figure it out. So, I wouldn't speculate on it. Just use an existing URL and then you can come in and update it if a new URL exists. If that makes sense. it's way more important to establish a date early on what we requested for horizontal review especially because TAC is right around the corner versus waiting which might take a week or two or three to get Eric's PR in and…
Manu_Sporny: resolve the publication thing and just I think you just need to fire and forget for now and then we'll come back and clean it up
Kayode_Ezike: Okay. Yeah,…
Kayode_Ezike: I'll do that then. I'll submit the security and privacy one soon with the most recent published URLs and then just keep an eye on whenever a prod is resolved so that I can update them as soon as possible. so that's about it. I should be able to I think the only thing only real work that's left are just a few more questions on the tag issue for raising a horizontal review request. So, I'm going to hopefully finish that today and then that's all.
Patrick_St-Louis: Very good. Any other thoughts on this topic before we move to pull requests? that case, let's start reviewing our poll request. So, there's 11 poll requests opened. let's go unless people want to focus on a specific one. If there's a priority, I'm just going to go from the oldest to the newest one. this one here, I will close it and probably reopen it like I've been doing with the other ones.
VCOM Pull Request Review
Patrick_St-Louis: So yeah, I'm just going to go ahead go from the oldest to the newest. If there's a special PR you would like us to prioritize, just let us know and we'll be able to address that an appendex with issuance, verification, and presentation. This was open on July 28, so about a month ago.
Patrick_St-Louis: There's been several rounds of review. couple typos here to apply. and a comment from Dave that is yet to be addressed.
Patrick_St-Louis: So Eric, I don't know if you want to take us through this Okay, that's it.
Eric_Schuh: Yeah, sure.
Eric_Schuh: Yeah, I think the main thing I missed, Dave's comment. so I think I just need to handle that. yeah,…
Patrick_St-Louis: As simple as that.
Eric_Schuh: I think that's it. Yep.
Patrick_St-Louis: I'll let you apply these suggestions. I can do it now or I can let you just click the button here.
Patrick_St-Louis: they see in just fixing a very small typo. and I'll let you Seems to be mostly about the diagram. So, I'll let you decide what we do here, where to cut it off, and it's going to be that. Perfect. Next one. So, I remember There was a render error on some fields and I believe that there we were pending a respec fix meaning we need to update the respect what is the status for this? I think Eric you had opened the respect to fix this.
Patrick_St-Louis: I have some kind of recollection of seeing discussion about a new release being made.
Patrick_St-Louis: Where does the VCOM spec stand in relation to that? can you refresh Eric Okay,…
Eric_Schuh: Yeah.
Eric_Schuh: So I think there is another PR actually linked right below the update respspec OS to version 102 is published. I've been using it when I've been doing my local work so to fix the rendering issues. so I think it's ready to merge. It just updates from version 101 to 102 and 102 is published. So,
Patrick_St-Louis: there's one question you put in. it seems to just be a question about the spec.
Patrick_St-Louis: Unless there's any objection, I would go ahead and merge this and just have a look at these once it's merged in and see what gives. we skipped to 706. I'm just going to go ahead and merge this. I'm seeing a few thumbs up. I don't think there's any objection. It's going twice. Let's merge it. And I will just put myself a note here discussed after merge revisit the spec and see if this is still made up.
Patrick_St-Louis: So I'm just going to have a look what was done here and see if the update of the spec fixed the issue. from my understanding I'll make sure that it did. So fix one of required rendering. this was also I think kind of fixed to that. from my recollection one of the topic here is do we update the OS so that it looks right on the rendered spec or should it be faithful to what the spec says.
Patrick_St-Louis: We wanted to review the semantics here 706 I think is the one we just merged.
Patrick_St-Louis: Are you able to answer this question right now, Eric, or do you want to also kind of just have a look offline to resolve this? Yes, Eric.
Eric_Schuh: I can answer it now.
Eric_Schuh: This PR is independent of the 706 PR. and I don't believe it has anything to do with 691. one. …
Patrick_St-Louis: Okay, perfect.
Eric_Schuh: I have to look at 691 deeper to be 100% confident with that, but
Patrick_St-Louis: So let's get this in. I see.
Patrick_St-Louis: We would need some approval. yes, Dave. So,…
Dave Longley: I'm trying to remember Doesn't this do things like move? We used to have a pattern that said one of and we put required and then we said which combinations of properties you could use and then we kept the property definitions separate so that they were only expressed once. I think this PR is one of the ones that changed that to move the entire property definitions underneath one of instead of just what the possible combinations were.
Patrick_St-Louis: you're saying this might need to be changed?
Patrick_St-Louis: …
Dave Longley: Yeah, I think it potentially results in duplication of property definitions. putting it under one of instead of independently from that.
Eric_Schuh: A If…
Patrick_St-Louis: Eric Okay.
Eric_Schuh: if I remember correctly, I know that you had brought that up because I referenced what I had patterned things after, but I believe the duplication only occurred in of the object that I used as a pattern for the one of but I don't believe that I added any duplication. so the duplication that you're talking about does exist if I'm remembering correctly, but this PR shouldn't add any duplication and the duplication existed before this PR. but I would have to double check. Sorry, it's been a couple weeks since I've looked at this one.
Patrick_St-Louis: Yeah. Go ahead, Dave.
Dave Longley: Yeah. yeah,…
Dave Longley: we should take another look because I see things like lines that take out things like not required create authorization request and then I see the definition of that create authorization request getting nested somewhere. so even if we maybe don't add new duplication here we are changing that pattern and the pattern that seems to be in this PR if copied elsewhere would generate that duplication. So it seems like we're trying to express something with JSON schema. we have a set of properties and then we have a one-of- conditions that say what combinations there are. And one way of expressing that is Another way of expressing that is move the property definitions themselves underneath one of and then hope that no combination shares the same
Dave Longley: property because then you'll have duplication. So it is conceivable that you'll have situations where acceptable combination would share that property but as soon as you do you have duplication. So it seems like the better pattern is to just put the required flags underneath one of and then keep the properties separate.
Dave Longley: I don't know if that holds up for all combinations but it seems like that would work. So we're trying to write JSON schema…
Patrick_St-Louis: Can you repeat that?
Patrick_St-Louis: S
Dave Longley: which is always fun to express which combinations of different properties are acceptable and we can either define those properties independently of which combinations are acceptable and so we put just by referencing the property names under one of section for the different combinations or…
Dave Longley: under one of we can define everything and that includes all the property descriptions. Go ahead, Eric.
Eric_Schuh: Yeah, that makes sense.
Eric_Schuh: I guess one thing that did happen is that this required not pattern which is what I replaced was I think just superfluous in some ways at least the not part because one of in OAS is explicitly defined as an exor. so you don't have to say that the other one is not required if the first one is requ if you pick the first one.
Dave Longley: I think not required in JSON schema means you can't have it.
Eric_Schuh: Okay.
Dave Longley: It's not what you would expect from reading it as English, but I think that's actually what it might mean. So the requirement just to repeat that here on the call.
Eric_Schuh: Okay.
Dave Longley: Think when you say one of not required means it's required that you do not have it.
Eric_Schuh: I guess that is in terms of this duplication problem. Dave, I believe that this pattern exists not only in what this PR is addressing, but in a few other places at the very least in the spec.
Eric_Schuh: So I wonder if the best path forward might be to accept this PR with this pattern that we know we want to change and then come through and…
Patrick_St-Louis: We're safe.
Eric_Schuh: kind of do a more holistic check for the pattern across all of the OAS files and fix it more generally. so just a thought Yeah,…
Dave Longley: Yeah, that's totally fine with me. I just think it might be that we could just close I just don't know if the only thing this thing does to switch from one pattern to another. If it's also fixing something, that's fine.
Eric_Schuh: it's fixing the patterns that I moved away from currently have rendering issues with resp so that was the reason for moving away from those patterns and I believed that semantically
Eric_Schuh: the other pattern was saying the same thing. based on what you said, maybe I'm not as convinced of that at the moment. so another option would be to update respspec OAS to handle all of these patterns. when I was doing that, I think there were three different patterns I was going to end up having to update respec to handle and some of the complexities and how that was being dealt with in respec were kind of just chewing some time. So, this felt like the simpler way to get us through the rendering issues that are happening. which as I said, I thought semantically it was the same. So,
Patrick_St-Louis: Sorry, I'm trying to read. So, it was an ID credential template index were both listed on this object. But now we want to give one or the other.
Patrick_St-Louis: And if we give one or the other, they're required. is that right, Eric?
Eric_Schuh: so the original right was saying I believe either of the objects…
Eric_Schuh: but it was the way I read it was it was trying to say if you have one of these you cannot have the other one.
Patrick_St-Louis: Perfect. That's…
Eric_Schuh: But semantically when I looked it up one of in OAS is an exor. So just saying one of these two things is saying if you have one of these you cannot have the other. which is…
Patrick_St-Louis: what I think for Yeah. Mhm.
Eric_Schuh: why but that doesn't address Dave's duplication issue. so there might be a better pattern to use across all of this.
Patrick_St-Louis: Yeah, I think Nate put it right? It's says one of these. So, the biggest thing is we want to remain consistent with the OAS definitions when it comes to we want to have the same patterns to say the same things across the spec. So where are we landing here? I'm hearing two different proposal. One wants to merge this. The other one says let's not merge this and address this another PR. do we want to leave this one up a little bit?
Patrick_St-Louis: maybe reflect on it or do we want to just merge it and then have another pass or what would we like to do here? Dave
Dave Longley: my mental engine for processing JSON schema while looking at a diff it skill level is low. I'm happy for this to be merged and for us to sort out the duplication problem separately. I do think it is a problem that we have but maybe we holistically and separately handle
Patrick_St-Louis: is how you spell holistically?
Dave Longley: No W.
Patrick_St-Louis: Thought it was the whole thing. Maybe not. holistically.
Dave Longley: English is weird.
Manu_Sporny: It's English.
Manu_Sporny: It doesn't make any sense.
Patrick_St-Louis: Yeah, I think I got it. So, I captured the original intent. but now we're saying we're going to merge this. This fixes an immediate UI rendering issue. And then we'll need to review based on this.
Eric_Schuh: Yeah, just wanted to mention I'll add an issue to track the duplication problem.
Patrick_St-Louis: mostly for the duplication. Is that correct? And we might decide that it's fine. Doesn't need anything else if it lands correctly. if you can add an issue, feel free to come and link this issue on this PR that's going to be closed merge as well. and we can put that what would we classify this issue as just it sounds to me like it's just about aligning a little bit the OAS and won't have much of a big technical impact like this is not wrong it's just maybe we want to make it more consistent. Is that Any objection?
Patrick_St-Louis: Going three, two, one. Let's merge this. Perfect. We're closing PRs. I like it. Okay, let's refresh where we're at. we went from 11 to 9 the next one. So let's go into So these are two of my PRs. Let me see where we were at. so this one was adding a query by example matching and JSON pointer conversion algorithm. there is a suggestion here. I will approve this first of the example is present.
Query By Example Matching Algorithm
Patrick_St-Louis: Yeah, this is Update matching script text. Very good. And then Dave suggested a real code implementation to give us a tangible example to maybe refine the algorithm a little bit.
Patrick_St-Louis: So I will discuss have a look at the proposed to identify gaps in the other ribbon. Can we tag an organization? I don't know. Just here. I'll go. So, I'm just going to do that thing here. I I'll have a look at this.
Patrick_St-Louis: Make sure that the text matches this. And that's going to be any other comments here? I'll look what's going on with this. this is bothering me. Just want to have a quick look. Okay, I'll have to look. Maybe I need a respect version updates or think okay so this one is also sort of a algorithm but this one is more non-normative so it's the expected algorithm to process a workflow step the normative part of this is simply the input output the processing step itself is not really something we can be normative about it's not something we can really test but we can still provide
Patrick_St-Louis: a reference in context the ummary. Okay, so it looks like there's good feedback from Nate that I will need to come back and just have a look and provide response to. it's about adding a little bit of a summary. It's not going to appear. yeah, so I did try to carry the conversation here. It's a little bit messy.
Patrick_St-Louis: But I can review if we want to capture a bit more this actual PR. I tried in the PR description to be kind of transparent that it supersedes another one and point to it. So the history is not closed right the comments are still on the other PR. if we want to capture them here verbatim we can look at this if we feel it's necessary discussed okay needs to address comments so I will look at this and probably be able to close this next time okay let's try to go through at least two more the credential
Patrick_St-Louis: offer VPR. Let's see this one 51 line. So that's fairly small. the state of it, couple minor typos and tweaks proposed. Eric, do you want to talk to us a little bit about this PR?
Eric_Schuh: Yes. So, just open up the original issue real quick. yeah. So basically this feature is to allow someone to essentially advertise which types of credentials are they could provide during issuance. I think it's fairly straightforward in terms of the changes. I sorry apparently I have some email stuff I'm not getting notifications.
Eric_Schuh: …
Eric_Schuh: but yeah, I think we discussed this last week or two weeks ago. I think that there's some editorial comments from TED that we need to resolve and other than that I believe this is pretty good to go.
Patrick_St-Louis: Yeah. So this is about a VPR that is to do something like either a didoth or…
Patrick_St-Louis: a prerequisites to binding credential. So when you ask for a dot, you give a preview of what the data is for and what will be issued or in the case of I believe I saw some BBS example,…
Patrick_St-Louis: you want to give a preview of what will be the result after so that the user knows what they're signing up for. Is that correct?
Eric_Schuh: So I'm not sure.
Eric_Schuh: Something you just said made me think you might be talking about the PR I just pushed and not this one. but I believe that this was specifically so that during an exchange prior to issuing a credial a issuer could offer a list of available credentials so that the requesting whatever entity is coming to ask for a could select the credential that best matches the form that they wish. so…
Eric_Schuh: if you're offering three different types of equivalent credentials effectively you could pick the one that you want to use. yeah.
Patrick_St-Louis: Okay. Picks…
Patrick_St-Louis: what you support or what you prefer. So I'll leave this. I think if we agree since PR is in good state and these are just small editorial things. once you've approved this, we can just merge it. no need to wait for next meeting. unless there's any objection. Okay, This is good. this one I'm hoping we can just approve this today. I don't think we need to say more. This is just a typo link.
Patrick_St-Louis: So, I'm going to go ahead going to prove this and we're going to merge it. No condone. for this one. I think it's unnecessary. let's try one more if we can. All right, let's try this one. No, maybe not. There's 64 64 comment. If it's okay, I'm going to skip this one. there's 64 comment. I think that's going to take a lot of time. We can just dedicate time for this next time. Let's see if we can address this one here.
Patrick_St-Louis: This scares me for a or…
Patrick_St-Louis: minute left. can you do us a quick rundown of this I know it was just pushed one hour ago. So maybe just break the ice so next meeting we can focus on it.
Exchange Presentation Type Option
Eric_Schuh: Yep. Yeah.
Eric_Schuh: So, this was a long outstanding issue. but effectively what this PR does is it adds a new verifiable presentation type option called an exchange presentation which is now sorry it adds this as an option during the participation of an exchange steps and effectively the exchange data property that is added here is intended to allow for exchange specific data that is not contained in the VCs to be sent.
Eric_Schuh: So this is where you could have BBS support added. if Zcaps were being issued identifiers could be exchanged through any payment data that is needed and I suppose generically any exchange specific data that is not contained in one of the VCs could be added to this object.
Eric_Schuh: Yeah,…
Patrick_St-Louis: Okay.
Patrick_St-Louis: I think that's a good preview. We'll leave time to people to read it a little bit. I'm sure it's going to generate a lot of interesting conversations here. but I think this should be very useful. Yes, sir.
Eric_Schuh: I did just also want to mention for the group that I believe this was the last issue that had the version 1.0 0 CR blocker tag that did not have a PR. so unless there's something else outstanding, just let everyone know. theoretically once we get through the existing set of PRs,…
Eric_Schuh: we are past the CR1 blocker or the CR blockers.
Patrick_St-Louis: That's really good news.
Patrick_St-Louis: Thank you for bringing that to our attention. That's really really good news. so once we close the set of PR, we're in a good shape and we can start looking at our issues. But knowing that, we're in good shape for the CR. are so yeah that's all I have. Is there any closing thoughts before we finish the meeting?
Kayode_Ezike: Just a quick one.
Patrick_St-Louis: Okay. Awesome.
Kayode_Ezike: It just sense in the chat, but basically I submitted the re hard to review requests for security and privacy during this call. So only thing left now is the tag one. So wrapped that up soon.
Patrick_St-Louis: Really good.
Patrick_St-Louis: In that case, thank you everyone for Very productive meeting. We closed a few PRs and some are in a good shape. next meeting we're going to discuss the threat model again because we like doing that. so until then I hope you have a good week. And that's it. Meeting ended after 01:01:08 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.