Meeting minutes
Kayode_Ezike: Hey everyone, just gonna minute or so. I know this week is sort of a lot going on with conferences, but just wait another minute. We'll get started.
Kayode_Ezike: Okay, it's okay Hello everyone, Today is July 14th, 2026 and this is the weekly call for the verifiers API life cycle management task force call. excited to get started today. We have a lot to discuss. but before we dive in, just wanted to remind folks that this call is governed by the W3C policies u of the conduct and disclosure. And before we dive in, any community updates, announcements from anybody on the call here today. And just I'll just ask too I think everyone here is familiar but any reintroductions updates you want to share with us?
Kayode_Ezike: I see that we have a noteaker I believe. So do we know John and…
Kayode_Ezike: this noteaker? Is he safe to say?
Dave Longley: We do,…
Dave Longley: but we usually turn off any AIs that are in here recording things.
Kayode_Ezike: So I'm going to get started. I'm going to ask Patrick if you could share your screen. I don't mind still driving, but it's just that my computer today is a little bit slow. So, can you pull up the agenda really quickly now?
Patrick_St-Louis: Yeah, I can certainly do that. please just give me one second. let me log in.
Kayode_Ezike: Problem. In the meantime, I guess I'll just give a brief up some overview.
Kayode_Ezike: So essentially today just wanted to get a quick update regarding the test suite and then I also have a set of targeted a bunch of PRs that I want for us to ideally close today that have been sitting around for a bit and then there are some targeted issues that I pinpointed about five of them that I think there's important decisions to make with them that we should make sooner than later. So, I'd like to go through each of those as well. so for starters, we can go to the no, that's not P request view. For starters, I'd like to open the floor for either Eric or Drew.
Kayode_Ezike: I noticed that there was a proliferation of issues about 12 or 13 or so the last week that's related to the threat model and I had questions around…
Threat Model Issues Discussion
Kayode_Ezike: how we should deal with any actions you need from any of us so that we can pair those down. Go ahead Eric.
Eric_Schuh: Yeah,…
Eric_Schuh: I think I could probably address most of that and then we'll see if you have any questions. so I went through as I said last week yesterday and basically resolved if not all of the suggestions on the threat model PR. the two that I left outstanding in terms of conversations were questions about licensing. and that was the main reason I did not push forward in terms of merging directly. I wasn't sure if it was appropriate until we get those license files and I wasn't sure exactly what content was supposed to go in those or if they were necessarily needed since we have a license file at the top level.
Eric_Schuh: But in terms of issues, basically anything that I didn't directly edit into the PR in terms of making updates because there were either outstanding conversations that were unresolved That into issues and I think it was 11 or so. and my general plan with that is next week when I get back from my travels Joe and I have some time on the calendar to sit down and I think probably the most prudent path forward is for the two of us to try to tackle most of those issues.
Eric_Schuh: hopefully once the PR has been merged and basically open up a series of PRs to address most of them and then any that are left after Joe and I get a chance to review it that we want to bubble up to the group we'll do so probably not next week but maybe the week after if we want to allocate the time for that. I know we've spent a lot of time on this so if we want to let it settle for a few weeks I think that's reasonable as well.
Eric_Schuh: But per Manu's point I think today the only kind of goal that I had was to resolve the questions about the license file that is currently part of the PR and the copyright file and hopefully be able to push the merge button assuming those questions are easily resolved. So I'll leave it there.
Kayode_Ezike: Thank you very Cool. is there anyone here who has a cogent response to how to handle the license from experience in the past? Go ahead, V. …
Benjamin_Young: Yeah, I signed on late. What's the PR number? I'm happy to take a look.
Kayode_Ezike: this is the threat model. so this would be the yeah.
Eric_Schuh: 655.
Benjamin_Young: Or just drop the link in chat. It's probably better.
Eric_Schuh: Yeah. Yes,…
Kayode_Ezike: Right. Yes. Good.
Benjamin_Young: Thank you.
Patrick_St-Louis: can drop it if it's not done. One second. Where is the chat? Okay, it's hidden. Is this one correct?
Eric_Schuh: that's it.
Patrick_St-Louis: I'm going to actually tag you, Ben, in my question is this PR blocked by this licensing issue or…
Benjamin_Young: Okay. Yeah,…
Benjamin_Young: happy to take a look.
Patrick_St-Louis: is it something we can kind of have a look subsequently is there a quick answer to that?
Patrick_St-Louis: Yeah, man.
Benjamin_Young: Yeah.
Benjamin_Young: So, the, Mono just says There is several of those. I think he means the, W3C documentation license, which Apache can be used, but it does cover content unlike some others. but I'm just clicking through the code.
Kayode_Ezike: Nothing.
Benjamin_Young: These are all just the more or less JSON configs, are they not? It is documentation, but it's bundled in JavaScript files. let me get a link to the W3C document license. I would go ahead and make that change. it doesn't need to be a blocker though. So if you guys want to get it in the W3C for code tends to prefer BSD3 clause.
Benjamin_Young: But that's also shifting around. essentially the way for full expression of this …
Patrick_St-Louis: Yeah. I mean,…
Patrick_St-Louis: if it's just to add a link or a file, might as well get it in.
Benjamin_Young: because legendary is still an active entity still alive Joe's here sometimes they can change the license so merging this as Apache and they have exclusive copyright over this piece they could change it later in accordance with W3C policy.
Benjamin_Young: So, nobody needs to fall over about this right now, but if you want to go ahead and make the change, I don't know, where the urgency is. I put the license in chat for anybody…
Patrick_St-Louis: Okay. …
Patrick_St-Louis: so it sounds to me like we are okay with merging this today and just opening an issue for this license that can be resolved quickly. perfect. Yeah.
Kayode_Ezike: Yeah, I agree.
Kayode_Ezike: Let's do that.
Eric_Schuh: Yeah, I will just yeah,…
Benjamin_Young: who wants to see it and I'm adding it to the review as well, but I'm also going to approve it…
Kayode_Ezike: Thank you.
Benjamin_Young: because I think it's fine either way as long as Eric's willing. to send in a PR later. should it be a must?
Patrick_St-Louis: just the issue number.
Kayode_Ezike: What's that Eric?
Eric_Schuh: that all sounds fine to me. And I just wanted to note I do already have an issue open. One of the 11 issues was about this licensing issue question. So we should be good for that. let me one second. I'll get it for you. I linked it in that last comment actually that I left.
Eric_Schuh: It is 674 I believe. I'll put the link in chat here.
Joe Andrieu: Eric, when we do merge it, we should list all those issues,…
Patrick_St-Louis: Is there any other issues than 674 that you would like to list?
Joe Andrieu: just in the merge comment, we should just site the ones that you created so people have continuity with the discussion. Couple
Eric_Schuh: Yeah, my last comment on the PR, I believe It's
Kayode_Ezike: Oh. Yeah.
Eric_Schuh: Let me just take a quick look.
Eric_Schuh: It's issues 667 through 678 were all and…
Eric_Schuh: I did create a tag for threat model in the issues. So, if we don't want to be looking at them, you should be able to omit the threat model tag and not see any of the issues related to threat model. yes.
Patrick_St-Louis: Okay. Sorry.
Patrick_St-Louis: Can you repeat the issue numbers? I'm just going to list them here.
Eric_Schuh: 667 through 678.
Eric_Schuh: So it's 11 of them. Is the last one correct?
Patrick_St-Louis: 678. Okay.
Patrick_St-Louis: So that includes 674 is related to licensing. So the group has agreed to mer we didn't agree yet. is there any objection to merging this today? with the condition that we acknowledge that issue through 678 needs to be addressed and…
Kayode_Ezike: All right.
Patrick_St-Louis: special mention that 674 is related to ing. Perfect. I'm going to comment this. I believe here we will want to do a squash because there's a lot of comets with the same name and there's only one commit before. So as per a discussion any objection to use the squash and merge for this one since a lot of the comments they just mentioned apply suggestion. We'll go ahead and squash and rge. There we go.
Patrick_St-Louis: I will let you Eric go and make sure that all relevant issues are closed or open depending what's still needed. And back to you, Cutie.
Kayode_Ezike: Thank you,…
Test Suite Update
Kayode_Ezike: Patrick. U for the next topic before we go through the rest of the PR about four or five of them that I'd like to merge today, but wanted you Patrick to give an update on the test suite PR that you put up yesterday.
Patrick_St-Louis: Yes. Yes, I'd be happy to. so the last time I presented this scaffolding PR so what I've done since then is I basically just copied the content on a branch on the WTC repo and re reopened the PR from there. I believe it's the same PR. You can see the history. So I closed my PR from my fork. and then just pushed what was on here. So I invite you to read this. So this one here has no tests. it only sort of describes the approach that's going to be taken.
Kayode_Ezike: Hey,
Patrick_St-Louis: There's a list of the normative statements. and the read me is probably the thing we should have a look and make sure we are in accordance with. so once this is done, I believe it's not open but I have another branch ready for open and draft PR that's going to be subsequent here. This other branch covers the test needed for let me just go. So it adds a few sections. So this is divided by section. So that PR focuses on the conformance for the issuer service and the verifier service.
Patrick_St-Louis: So it includes partial of section 1.3 and it includes 2.2 3.2.1 and 3.3.1. I have not included section 3 I've not included these optional endpoints. we can review as mentioned if these endpoints they are optional but in the case that you do want to implement it there's some normative statement so we will be able to make these sort of a opt in the spec without negatively impacting those…
Kayode_Ezike: Make sure it's funny.
Patrick_St-Louis: who choose not to do it meaning it won't count as a failed test and it won't count as a not implemented you will just get more points if you implement it. yeah. So, this following PR should put us in a position that we can start deprecating the VC API issuer and verifier test suite from the CCG. since they will cover these. something I would like to do also is to for now while we test this create a small implementations JSON in here that we can start I have an implementation I'm developing at the same time as I'm building this test suite. So I'll put it out there and I believe Digital Bazaar mentioned they would have one.
Patrick_St-Louis: So just until we have a test suite then we can add it into the official implementations directory.
Patrick_St-Louis: Yes, Ben. Yeah.
Benjamin_Young: Yeah. …
Benjamin_Young: one thing we did locally in the other test suites was to have a local config.cjs file. I'm trying to find you a link to where that gets explained.
Patrick_St-Louis: So, this is here.
Benjamin_Young: And you could do something like that maybe.
Patrick_St-Louis: The reason I wanted implementations that Jason was just …
Patrick_St-Louis: if there's test suite that is more like interrupt related to make that it needs to implementation we can just slowly try to make sure that the pipelines are functional and if we start with one or two implementation it's a small scope it's just a suggestion I had before we put it in the other one the pipelines
Benjamin_Young: Sure.
Benjamin_Young: Yeah. If you…
Benjamin_Young: if you take a look at the thing I just linked to for testing locally, the local config.cjs file is basically just exactly what you described. It's a list of multiple implementations potentially with talk for turning interop tests on and…
Patrick_St-Louis: guy. …
Patrick_St-Louis: yes. Okay.
Benjamin_Young: I don't know that there's a whole lot of code around that.
Patrick_St-Louis: Okay. Yeah,…
Benjamin_Young: I think we just check for it and then load it in place of the implementations list and the settings. But it might be useful if they all kind of match.
Patrick_St-Louis: let's start with this and it should cover our needs. Perfect.
Benjamin_Young: Yeah, let me know if it doesn't. I'm doing a lot more with the test suites in the next couple weeks. happy to help.
Patrick_St-Louis: And I'll probably reach you for information if there's a digital bazaar implementation I can try to just inter up with for some basic stuff.
Patrick_St-Louis: Yeah for the issuing verifying stuff not too worried. I think the workflows is where it's going to get interesting. so yeah that's all I have. Is there any questions? Perfect. back to you, Coyote.
Kayode_Ezike: Thank you very much.
OAUTH Scope PR
Kayode_Ezike: Yes. So, I have several PRs that were from previous calls. This one I'm going to put in chat right now is for the OOTH scope. and so this is So, this is 656. The only thing that needed to be done from the last week was that I needed to make sure that the references were informative and not normative.
Kayode_Ezike: Turns out that the way I wrote it,…
Kayode_Ezike: it was normative. So I updated that for this R over here. That's the only diff from last week.
Patrick_St-Louis: Yes.
Patrick_St-Louis: I remember. Yeah, the question perfect. I'm happy with Any objection to merging this PR? I think we were all pretty much on agreement. I'm going to put this back to rebase.
Kayode_Ezike: Great.
Patrick_St-Louis: Since this is fairly clean, I'm going to merge this. Awesome. Are you okay with doing that?
Kayode_Ezike: And then the next one just I guess before we move on, we should close the issue associated with this which should be linked in there somewhere. should have caught it before he closed it, but it should be in the French and…
Patrick_St-Louis: 643.
Kayode_Ezike: yeah 643.
Patrick_St-Louis: Okay. PR 66 and I think you add some Zcap stuff also right in the PR.
Kayode_Ezike: Yeah, that one's next. I'm going to that one soon.
Patrick_St-Louis: Okay.
Kayode_Ezike: Not you. Patrick St-Louis:
Patrick_St-Louis: Okay. Oops. There we go.
Kayode_Ezike: Yeah. All right.
Patrick_St-Louis: Can I close this with the comment? Okay. So,…
Kayode_Ezike: Thank you.
Patrick_St-Louis: Let me try to guess which one's going to be next. There's something…
ZCAP PR
Kayode_Ezike: Sorry for spoiling the surprise. This topic is a 657. go ahead.
Patrick_St-Louis: because I got the closed PR.
Kayode_Ezike: All right.
Patrick_St-Louis: Yes, Ted.
Ted_Thibodeau_Jr: Just a going forward best practices.
Ted_Thibodeau_Jr: These applied and recent commit messages do not make it easy to check and see what got applied. there's generally a one-click button on these that will let you either apply a single suggestion or…
Kayode_Ezike: Got you. Come. Speed back.
Ted_Thibodeau_Jr: start a batch commit. either one of those takes the suggestion and applies it. So you don't have to type or anything like that. and once it's applied, we know that it review is very easy.
Kayode_Ezike: Thank you. Better mind.
Ted_Thibodeau_Jr: That's it.
Kayode_Ezike: So I put the next subtopic in have it open.
Patrick_St-Louis: Okay, thank you.
Kayode_Ezike: Same thing informative reference for ZCAP as well.
Patrick_St-Louis: Was there something to do Is there a change you did since last time or this one was pretty much good?
Kayode_Ezike: if you go back to the main page to see the commit says, but the last commit should been for informative update for CC reference.
Patrick_St-Louis: Yeah, there It was one curly square bracket too much. This looks good. Any objection to merging this PR? Is that you objecting, Dave, or just a support?
Dave Longley: And that was a support.
Patrick_St-Louis: I thought we were going to have a conflict.
Dave Longley: I'll have to find some other way to object with a thumbs up someday.
Patrick_St-Louis: Okay. I'm kidding. and then 644.
Kayode_Ezike: That's issue 644.
Patrick_St-Louis: Address Which one is it? Authentication or authorization? Perfect.
Kayode_Ezike: I think authorization probably more appropriate.
Dave Longley: Yes. Authorization.
Patrick_St-Louis: Okay, I'm going to close this issue.
Acceptance Issuer Examples PR
Patrick_St-Louis: That's really good. Okay, what's next? 659. Okay.
Kayode_Ezike: Next one is this one in chat 659.
Kayode_Ezike: This one is from Benjamin. So feel free to take the floor Benjamin regarding the accepted issuers examples.
Benjamin_Young: Yeah, just reloading this into my head. yeah, so as this example shows can be a string or…
Benjamin_Young: an object and the surrounding text in one place sort of said that and in another place didn't. So the example only showing one of them made it seem like it had to be an object.
Patrick_St-Louis: Perfect. Okay,…
Kayode_Ezike: My god.
Benjamin_Young: And in any case, issuer was never the right key name because it's JSON LD. So either way, you're passing in an identifier. but the issuer key name was wrong. So while fixing that, I went ahead and put another example where you don't pass in an object and show two different issuers. it wouldn't validate in safe mode for sure…
Patrick_St-Louis: that's good. I'm trying to think if I've seen this in the wild somewhere. I don't think so. but yeah,…
Benjamin_Young: if somebody tried to do that. it shouldn't anyway.
Patrick_St-Louis: but is there a context for this? I don't
Benjamin_Young: That's a good point.
Dave Longley: Yeah, we're getting wires crossed a little. This is just JSON,…
Benjamin_Young: Yeah, you are. Or I am. Yep.
Dave Longley: but the whole idea is that you could query on any number of properties in a JSONLDD credential. So, you'd be matching against that.
Patrick_St-Louis: Mhm. Yeah,…
Dave Longley: You wouldn't match against issuer.
Kayode_Ezike: Here we come.
Dave Longley: viewed match against its ID.
Patrick_St-Louis: I this direction because you basically treat this array as an array of issuer fields, Which themselves can be either a string or an object. let's just hope that nobody implemented this. and if they did, I'm sure we can play nice.
Dave Longley: Yeah, I think that example was only added a couple weeks ago by accident. So, I doubt anyone's implemented that.
Patrick_St-Louis: And did we make sure that it doesn't say anywhere that it's an object with the issuer key field? Perfect.
Dave Longley: It I do think I checked that when this PR came in. and this PR matches the text.
Patrick_St-Louis: Perfect. Is that okay?
Benjamin_Young: Yeah, it does not say anything about an issuer key. it talks about an object identifying the issuer or something like that. So, you could see how it got read wrong,…
Kayode_Ezike: Yes, it could be.
Benjamin_Young: but yeah.
Patrick_St-Louis: Any objection to merging this? fairly nonsubstantial R but really good to have. We like examples. Was there an issue for this or 658
Patrick_St-Louis: Okay. …
Patrick_St-Louis: what's next?
Expression PR
Kayode_Ezike: Next is in chat 661.
Patrick_St-Louis: I mean, are we just going in order? yeah.
Kayode_Ezike: All one I guess. Yeah, pretty much. So, this one is yours. I don't know if you have any updates with this one.
Patrick_St-Louis: No, I believe this one is done. did you put any comments since last time? we got some review to apply. So let's put into practice what that suggested here.
Kayode_Ezike: Come on. Okay.
Patrick_St-Louis: And we're going to do a batch. this one resolve This one has been resolved. and then this was about expressions
Patrick_St-Louis: for something.
Patrick_St-Louis: Okay, I think I did this correctly. any objection to merging this PR? I don't know if you wanted to change your review, Kyote, before we merge or…
Kayode_Ezike: I think it's probably fine.
Patrick_St-Louis: Okay, you're fine if we leave you as change requested.
Kayode_Ezike: Is there a way to guess I don't have it open right now to update it,…
Patrick_St-Louis: I'll put you in like this.
Kayode_Ezike: but you can Yeah, it's fine.
Patrick_St-Louis: And I believe I'll just make sure everything is resolved. I'm just letting all your comments have been resolved. at least the best of my knowledge.
Patrick_St-Louis: It was mostly for the version. Okay.
Kayode_Ezike: I think the issue is 653.
Patrick_St-Louis: I kicked off a perfect. Rebase and merge. can't get two for 653. Okay.
Kayode_Ezike: This is sad.
Kayode_Ezike: Jesus.
Patrick_St-Louis: Okay.
Kayode_Ezike: Next topic 62. So, this one is relatively It's relatively simple. So, this issue has been sort of lingering around and languishing for I feel like over a year now. There was a young man who made a comment about the way that we were defining the export for domain and challenge would have created a duplicate entry that we can just reuse or that we should scope out the actual scope for the domain of these fields. And so a relatively minor editorial fix update
Patrick_St-Louis: What does this do?
Patrick_St-Louis: Sorry. What does this do concretely?
Kayode_Ezike: So my understanding is that essentially there's a reference to a database that maintains the definitions.
Kayode_Ezike: And if you have multiple of these links this when there's already another reference to it in a different section of database it creates a duplicate that's problematic in some way. That's essentially the description that was given by T doduce. if he goes to the issue, he can find the guy who commented on it. But that's roughly my understanding is that it's better to scope it to the actual schema that we're working with.
Patrick_St-Louis: Okay, I see.
Patrick_St-Louis: Any objection to merging this I do I don't believe Tedus is on the call with us. So I'm going to reply.
Kayode_Ezike: No. Yeah,…
Patrick_St-Louis: However, we'll let him a chance to make sure that this resolves is concerned.
Kayode_Ezike: I did respond to the issue.
Kayode_Ezike: a couple of weeks ago hasn't responded yet, but was in agreement with the approach that I proposed and so it's probably okay to inform issue.
Patrick_St-Louis: Okay. okay.
Patrick_St-Louis: So as on the rest need to reopen this issue.
Patrick_St-Louis: Perfect. Okay.
Kayode_Ezike: This one is 63 and…
Kayode_Ezike: So, this is a new one. essentially we want to be cognizant of the fact that there are some specs out there specifically for example a the credentials API where there's a need to know either the initial or…
Kayode_Ezike: the current VPR request that would be sent out to the wallet before they actually send it out to them. And so essentially that adds an endpoint slash request at the end of an exchange.
Kayode_Ezike: And what you get back is the current sort of DPR that would be returned if you were to continue at that state.
Patrick_St-Louis: And we do want to make this normatively required…
Patrick_St-Louis: because I vaguely remember this discussion not sure if we finded that you need to implement this or if you want to be compatible with DC API one could do it like this Dave Yeah.
Dave Longley: So I think we would have normative requirements in here, but we might decide that in order to be a conformant workflow service, you don't have to implement this endpoint. Sort of that middle ground that you talked about in that other do.
Patrick_St-Louis: What about we do like to be compatible with this API you may implement this and if you do are the must is that sort of what you're
Dave Longley: We might find that this is useful beyond DC API and we might find that it's really easy for impleers to add this. so maybe we just leave it as is right now and we decide later it's optional. we should probably try and get some implementation experience with it and if it's really easy to do just leave it. It seems like would be a helpful thing.
Dave Longley: potentially to know that it's available.
Patrick_St-Louis: So we do want to make this a normative requirement or…
Patrick_St-Louis: make it optional.
Dave Longley: Why don't we start with making it a requirement and…
Dave Longley: then we dial it back if we were like this could really be optional.
Patrick_St-Louis: Okay. to me.
Kayode_Ezike: I'm back.
Patrick_St-Louis: I'm going to approve and I'm just going to capture what we discussed on it. We're not going to merge it today. it was just open three days ago. So, we'll let it discussed I want to say this All right. Wait, just if
Kayode_Ezike: So, let's
Patrick_St-Louis: So the group decided that this might be preferred as an optional endpoint with normative instructions…
Patrick_St-Louis: if implemented leaving it as required for the time being. We may revisit and make it optional. does this reflect what we feel? Is there anyone that wants to object to this comment here?
Kayode_Ezike: That's good.
Patrick_St-Louis: Going to comment we leave this open. It's just been open three days ago. we'll circle back on this next week and if we still feel the same way, we can go ahead and merge it. If we suddenly all realize that this is a bad idea, we can't talk about it. Okay.
Kayode_Ezike: Great. Thank you.
Kayode_Ezike: And this is a nice subtopic five. Yeah. So the thing here is pretty simple. There was a missing component in a mermaid diagram. Basically the holder is supposed to interact with a workflow service whenever it participates in an exchange and the current one interacts directly with the coordinator which is not correct. So I updated that you can actually see the image in the comments So that extra service there is needed to for the bottom half but also I guess the top one as well before you generate the QR code. I started to add that interaction between the issue colonator and workflow service.
Patrick_St-Louis: Yeah. Yeah. Yeah. So, yeah, you're adding the workflow service and…
Patrick_St-Louis: adding this kind of backend communication. I zoomed in too much.
Kayode_Ezike: That's for issue 631.
Patrick_St-Louis: So, I'll approve. same thing. We'll let it brew for a week. but we'll make sure to get this right at the beginning next week.
Kayode_Ezike: That's good. Next one is oops everybody.
Patrick_St-Louis: 666 this one number of the devil. All right.
Kayode_Ezike: But yeah, so essentially this has to do with the fact that we didn't want to lock ourselves out of the possibility that there may be some protocols where you do need to return multiple VPs in a single round trip for whatever reason either because this has different security mechanisms or a number of other reasons. So I basically…
Kayode_Ezike: what this does is it allows for the verify representation property to be both an object either an object or an array type. So that's essentially what
Patrick_St-Louis: Mhm. or…
Patrick_St-Louis: an array. Yeah. I'm just trying to think how this affects the OS restructuring we did earlier, but I don't think it matters because we, point to this schema and that's what's changed. So, I think it should be fine. I will personally approve. I think this is good.
Patrick_St-Louis: We'll leave it open and I'll let a chance for Dave to review this. he already approved yesterday actually.
Patrick_St-Louis: So same thing. Let's leave it open for next week, but we'll remember that this one if nothing changed and there's no objection we'll be able to merge it.
Kayode_Ezike: Sounds good.
Kayode_Ezike: And the last one which is 679 pretty quickly. And what we have here is sorry basically the idea here is that we wanted to enable an inter rather directory URL that comes back from a message between client and server to possibly be an interaction URL.
Kayode_Ezike: And so basically up until now the assumption generally has been that it would be a URL that you have to visit in browser even though we did already have language that said you can use interaction I wanted to just make it more abundantly clear that you can use interaction URL and…
Kayode_Ezike: if you do include it and the client understands what to do with an interaction URL you can just automatically start the next exchange that associated with that essentially exchange chaining is the concept to you.
Patrick_St-Louis: Please. Yeah,…
Patrick_St-Louis: it's really interesting. I've been working a bit with the DICCOM workflow protocol and that's definitely like something that's possible. it's less chaining as you just start a new workflow, but here it sounds like it's more of a chaining option. something we are also looking at is this concept of subworkflow. So in the middle of a workflow there's a requirement for you to let's say you need a certain credential and they need to send you to another service to get it right these sort of ideas. would this be possible with VCOM or it's more of a you really chain the workflow so once you move to this new workflow like you can't really come back or how would this be managed?
Patrick_St-Louis: Yes, Dave.
Dave Longley: So to implement something like that, the redirection URL, you would still use chaining, but the redirection URL could carry along with it an interaction URL to come back when you're done.
Patrick_St-Louis: Mhm. Yeah.
Dave Longley: That's generally how it would be done and that keeps it to a single primitive. We could explore doing something more complicated than that, but I think you might even lose the state or…
Patrick_St-Louis: Yeah. Yeah.
Dave Longley: have trouble with that. So we might again this is a good PR that we have these extra notes in the OAS…
Dave Longley: but we might really even want a section on interaction URL changing that's just text that says hey you can combine these things in these ways. including what you just said, Patrick, and give some guideposts for how they can compose these pieces
Patrick_St-Louis: interesting. …
Patrick_St-Louis: I'm going to go ahead and improve this one. I think it looks good. I like this idea. I could see this being useful maybe in some case where someone has engaged with the VCOM protocol and…
Kayode_Ezike: Are you serious?
Patrick_St-Louis: then you need to redirect it with another service that they use oid for VCI right so you give them this interaction this next part you're going to inte you're going to engage in a workflow with this other instance that for some reason we need to issue this credential over another protocol or could see this interesting even maybe to bootstrap a didcom connection right at the end of a workflow. that could be interesting. So you just give an interaction URL with the didcom invitation for persistent notifications and So yeah, I definitely see a lot of use for this.
Patrick_St-Louis: And it allows for some interesting idea of if you implement this in a wallet it allows you to chain these exchange without leaving the wallet right you stay in the wallet the wallet knows how to handle this and you don't need to send a user to some external page which can have inconsistent behavior and so on. yes, Dave.
Dave Longley: Yes, that's one of the most important features about it and is another reason why we probably should really highlight it. and wallet implementers would be particularly interested in knowing that,…
Dave Longley: when they get that redirect URL back, hey, check to see if it's an interaction URL and you can keep going without taking the user out of where they
Patrick_St-Louis: Something that's really interesting about work especially with the didcom workflows and…
Patrick_St-Louis: I think it would be possible to also build this with these vcom workflow the workflow almost becomes a mini application in itself right you can serve different content and you can serve workflows from different instance so we can create this interesting the wallet becomes more than an application in itself but it becomes a sort of a application renderer of some sort right they can add with this different work I know with the workflow they get into display hints and stuff like that so they give hints about…
Kayode_Ezike: All right.
Patrick_St-Louis: how to display the workflow to the user and what actions they can do and interact with. but I don't see why this couldn't be implemented with VCOM workflow as well. Even if it's in the spec a wallet can very well define their own sort of display hints for different type of actions. Yes, Dave.
Dave Longley: Yeah, that's right.
Dave Longley: And with interaction else the wallet if it really doesn't understand a protocol or wants to offer a user a different path forward they can kick them out back to a browser because the interaction an HTML can render any arbitrary page to keep the user going and so it's a good unified way to compose these
Patrick_St-Louis: Yep. Yeah.
Patrick_St-Louis: So this looks really good. I think this is really promising. I'll leave it open for review next week as well. But I think with the size and the scope feature is really good and we can reiterate after if we want to
Dave Longley: So, we might not want to close the issue though, Coyote…
Dave Longley: because we might want a interaction chaining or some informative text that better, explains that people can use this feature.
Kayode_Ezike: Yeah, we did also mention I think in there that…
Kayode_Ezike: because of the fact that PC API is evolving that I'm not sure if it was this sorry PRs but I think it was this one where it's like we can't make a definitive decision around what to do until we have a
Kayode_Ezike: better sense of how that aspect is evolving which sorry that's difficult but I agree
Patrick_St-Louis: What do I call this? Workflow exchange chaining or just workflow chaining.
Patrick_St-Louis: Workflow exchange. Chaining. Okay. I'll just comment this so we get reminded next time.
Dave Longley: Yeah, we might end up just calling it interaction chaining…
Patrick_St-Louis: Very good. Sure. Yeah.
Dave Longley: since it occurs at that layer. But a workflow exchange. Yeah.
Patrick_St-Louis: No, it's true. No, you have a good point because like you said you could just be redirected to a HTTP page, It's not always about interaction chaining.
Patrick_St-Louis: And if it's on one line, I like it. Back to you, Coyote.
Kayode_Ezike: Thank you.
Kayode_Ezike: Yeah, so the next piece I have I don't know we won't be able to get through all of them, but I had five different issues that I wanted to discuss that still have open comments on or questions on them. so maybe you can at least go through one or two of them. First of them is 642 which I linked in the chat as Yeah. so I think Ben Benjamin made this comment where wanted to know basically
Kayode_Ezike: what we should do around the registration of the protocols that we've introduced into the spec. I'm not sure Benjamin you were suggesting that we have a different document for this or a different section. Trying to figure out what you wanted to do there. Go ahead Ben.
Benjamin_Young: Yeah, it was mostly just to call out that we needed to do something…
Benjamin_Young: because are currently undefined and just people do whatever in their implementations there. Some of them are just in examples and not even in a list of this means at this version or leak with these specification mappings and it's essentially the front door to getting to a whole lot of stuff. So it needs to be, treated as important essentially as a context URL with a hash because you need it to be dependable and mapped ideally to where whatever that protocol value is coming from in terms of a written standard. whoever's reading VC column and expecting interaction URLs to be more than just a guessing game of JSON.
Benjamin_Young: then we're going to have to say, these are the keys and…
Kayode_Ezike: Thank you.
Benjamin_Young: they map to this stuff. And there's also, the obvious embarrassing flip gun that VC API is our key for VCOM. So, we'll shoot all that out, but that was it.
Patrick_St-Louis: Yeah, that's interesting.
Patrick_St-Louis: I'm curious where do you land for so I'm thinking for example There's two versions of didcom. would you want to express versioning and these things? I know IDC for VC there was this whole draft issue and things and at one point maybe we'll change some of the VCOM stuff maybe when VCOM 2.0 …
Patrick_St-Louis: right in many many years, we'll want to change this. do you have any, thoughts about how we should potentially handle this? Mhm.
Benjamin_Young: I think that's exactly…
Benjamin_Young: what needs to be discussed. I don't personally have a way to do it. I'm of course only ever half joking about using JSON LD because then you would know what the terms were and you could change them over time. and it is exactly the sort of sand that we're building on by not defining them.
Patrick_St-Louis: And Yeah,…
Benjamin_Young: Another related one is that the examples that use oid, they're all uppercase and implementers need to know whether or not it's case sensitive. So that's another piece
Patrick_St-Louis: that's really good. Then to the same kind of idea like some protocol they implicitly handle versioning while other it's just to version and…
Kayode_Ezike: There we go.
Patrick_St-Louis: you just need to know which version to expect beforehand. so that's some kind of thing we'll need to normalize I guess. Dave
Dave Longley: Yeah, having nothing but examples in the spec is a problem right now. So I'd say we should get started with at least a table that says these are some already in use ones and then we can take the discussion further.
Dave Longley: There's always a big discussion around registries and things like that. just start small.
Patrick_St-Louis: any preference for what to do with the VC API? Do we want to create an alias for VCOM saying you can use mini? Patrick St-Louis:
Dave Longley: No, I think I mean V vcom is the VC API for life cycle management. so it's still in the title and there are already implementations using it.
Dave Longley: I don't think there's a lot of value in changing that name.
Patrick_St-Louis: No, I meant because right now one thing that Ben was explaining is it's VCAPI the protocol key for VCOM.
Dave Longley: Yeah, I don't think we should define yet another one.
Dave Longley: You're suggesting there could be an alias and you could check for either one. Let's just use VC API. That's what implementations are already using and clearly note it. Yeah. I don't know that really buys us
Patrick_St-Louis: We don't want Okay.
Patrick_St-Louis: I think it's like when you want to explain this to someone that's always like what I come to like yeah it's this API but it's actually VCOM but it was called VC API before. So that's what is VCOM right and…
Kayode_Ezike: This is good.
Patrick_St-Louis: I think it adds because we had thought does the interaction URL protocol belongs in VCOM or is it its own thing what kind of discussion I think at least from what I've experienced showing BCOM to people. so that would be the side.
Dave Longley: heard. We could, discuss that
Patrick_St-Louis: Are we okay with these three? Is there anything else we'd want in a first table version? I know there was HTTP, I think. Okay.
Kayode_Ezike: I think invite requests. there's a few others that are already inside the spec that we have to just include here to double check.
Kayode_Ezike: we are at time but yeah thank thanks everyone for the contribution I had maybe four other issues we can get through maybe next week u things like for example interaction scheme registration was still an open question around that and also web plus interaction as well so what I'll do I think is just make comments on some of these issues maybe ask questions and…
Patrick_St-Louis: Bye-bye.
Kayode_Ezike: potentially reach out individually to some folks wherever necessary but thanks again I think you've Patrick for leading the browser navigation and thanks everyone for contributing. See you next week. Meeting ended after 00:59:56 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.