Meeting minutes
Patrick_St-Louis: Welcome everyone. We'll get started in a couple minutes.
Patrick_St-Louis: before we get started. So I can see in the message individual name all this has added a AI bot to attend the meeting. while we don't formally have policies for AI participation, we usually require that we know who the person registering the AI does anyone know who all this E is?
Patrick_St-Louis: Okay, it looks like they have left the meeting.
Manu_Sporny: I booted it.
AI Participation Policy
Patrick_St-Louis: I was just going to ask in case somebody knew who they were. let's adjust to the topic for today. how we should treat AI script software. okay let's get started. it's past the hour. we have pretty good attendance. as people come in they will be able to catch up. so today is the 7th of July 2026.
Patrick_St-Louis: This is the W3C verifiable credential working group VCOM call during which we discuss verifiable credential API for life cycle management. This is a W3C meeting so all W3C policies and contribution agreements are into effect. before we get into the agenda, we're going to leave room for introductions and community announcements as well as any additional topics, users would like to cover.
Patrick_St-Louis: I will add a small topic to start which is just to refresh how we want to manage AI software that attends the meeting. It should be a very quick discussion. So I will leave the floor open for introductions or community announcement. Very good. yeah. So my current understanding for AI participation is that it would be allowed if it's from a known person that is known in the ecosystem and we have an agreed upon understanding.
Patrick_St-Louis: if there is a unknown participant which refused to identify themselves we will unfortunately have to remove them. that is this along with what everyone is thinking here are these some decision we can agree on okay this is what we've been doing I don't think there's official guidelines for this but this seems like a pretty reasonable take we don't want to prevent people from leveraging AI tools but this needs to be done in agreement and in good faith
Patrick_St-Louis: Yes, Joe. Yes.
Joe Andrieu: I want to suggest one writer on that…
Joe Andrieu: which is and that the person is a legitimate contributor either they're a member of the work group or they're an invited expert. I think it's going to be too easy to pretend that you represent some person that we don't actually know. I think in other words, from public people that we don't know is hard to validate. so that feels like a threshold that we should pay attention to.
Ted_Thibodeau_Jr: along similar lines. I don't think I've seen Rodrigo Menéndez before and there's nobody listed in the group as a participant with that name.
Rodrigo Menéndez: I actually applied a few days ago. I've introduced myself sometimes. I work in the Spanish University in Madrid and we are currently studying self identity but applied for data spaces. I have a question I don't know when…
Patrick_St-Louis: Man, want to reply.
Rodrigo Menéndez: but I applied and I don't know when I'm getting an answer from it. I don't know if there's a problem with it anything like that.
Manu_Sporny: Are Rodrigo Menéndez you're referring to your invited expert request?
Rodrigo Menéndez: Okay. Yes.
Manu_Sporny: I guess the question is which request? So, this is an official working group of the worldwide web consortium. This is not a community group. and to join and participate in this you need to be either a member of the verifiable credential working group or an invited expert and there's a way to get an invited expert form and get that filled out. Is that the thing that you're referring to or are you referring to the credentials community group thing?
Rodrigo Menéndez: Erh, I'm kind of young and new into this, so if you could guide me a little bit. Okay.
Manu_Sporny: Yes, happy to. let's put you in touch with the chairs and the staff contact to see if we can invite you in as an invited expert because we don't have participation from people in your area of the world and I think it would be good for that to happen. and then of course the standard you can't contribute or participate to anything that we're doing until that happens and it is up to the organizers of this group whether to allow you to participate in the group until your invited expert form goes through. So, I'll keep it there.
Rodrigo Menéndez: All right.
Manu_Sporny: And then hand it over to you, Patrick. I do have something else to, talk about, from an AI perspective, though. but go ahead, Patrick.
Patrick_St-Louis: Yeah. …
Patrick_St-Louis: I just wanted to know is there a weekly credential community group that Rodrigo Menéndez could go and introduce himself and have this as a first kind of introduction pathway to the verifiable credential community group.
Manu_Sporny: That would be a good thing for you to do Rodrigo Menéndez to kind of present your work to the credentials community group.
Rodrigo Menéndez: Okay.
Manu_Sporny: That group is open to anyone from the general public. you can sign up yourself. You don't need to be approved, all that kind of stuff. So I think that that would be one good thing for you to consider doing.
Manu_Sporny: But separately and in parallel, I don't think Patrick that's required for Rodrigo Menéndez to apply for an invited expert position in this group.
Patrick_St-Louis: definitely not was just proposing a way again like to introduce himself.
Patrick_St-Louis: As for this group I personally have no problem if Rodrigo Menéndez want to attend. if there's any objection we can discuss this but yeah I think the credential community group is a very nice place to be especially if you're new to the community you'll find a lot more sort of incubation specifications and there's some very interesting discussions that happen on that side as far as the verifiable credential working
Patrick_St-Louis: group we are mostly focused on bringing different specification to a recommendation status. So often time what will happen is that some specification will be proposed and incubated at the CCG and then once they reach some level of maturity they will apply to be promoted to the verifiable credential working group which is discussed with more of a production mindset and we take more time to go into the different details security considerations and whatnot.
Patrick_St-Louis: So yeah that could be a good place for you to join…
Patrick_St-Louis: but I personally have no issue with you attending this call again unless there's objection from any of the other organizers.
Rodrigo Menéndez: Okay.
Rodrigo Menéndez: All right. I'll join the community group.
Patrick_St-Louis: Other than that, thank you for the introduction and welcome Manuel
Manu_Sporny: To follow up on one of Ted's comments about the use of recorders and everything, agree with everything that's been said to date. The one only caveat is there it is possible for us to go off the record by going into another room using this stuff. those AI tools will follow us into the other room and keep recording if we're not careful. Just pointing that out as that's the only place where I can think of an AI tooling kind of going wrong. in addition if they're meeting summarizers and things like that, it's kind of like we already record this stuff and we already put transcriptions out and we put it out there.
Manu_Sporny: I think my in and in and there are times where those AI bots have messed up the recording where I've had to kind of recover it. I haven't seen that happen in the last year. So that's good. I think they're behaving themselves mostly. But that's another kind of like, I'm a bit skeptical that pulling an AI tool into one of these meetings is going to actually provide useful is going to be better than worse. But I think what's been said today is fine and we can deal with special cases as they come up. That's it.
VC Test Suite Progress
Patrick_St-Louis: Yeah, I think I agree with this talking about it but no need to make it a big issue until it is one which it is not currently. I think the way we deal with it is swift and very reasonable. any other comments before we get started with today's agenda? Great. so I want to start with the test suite progress. So I've been putting a lot of work into this. I do have the first initialization PR to the VCOM test suite repo.
Patrick_St-Louis: I do have a lot more work than what is in this PR covering most of the sections and I want to take some time today to discuss a little bit so the PR that's open there I'll open it in a second it's more a scaffolding of the repo so put in the required reporter making sure all configuration file are there and an initial readme that explains a little bit the approach for the test suite there are a couple topics I want to address mostly for how will an submit their implementation configuration file and how should the test a little bit talking about how should this happen in conjunction with the other test suites.
Patrick_St-Louis: Because the way the test suite work is there's a centralized implementations repository and then you just tag which test suite that you want to run. up until this time we have been sort of unofficially using vcom defined service endpoints to test specific feature. but this being the VCOM test suite there's a few things that we need to consider and probably a few decision point I have of course a proposition I reflected on this came up with a proposition which I'd like to share with the group get some feedback and then I can think about this some more so I will open the PR I've tagged a few people in
Patrick_St-Louis: Okay, so this is a brand new test suite. The way that we've been usually building test suite is to have a look at the spec, break down the normative requirements only including what is required. So these include must not and required statements for may or should.
Patrick_St-Louis: They are only included if the spec is written in a way that if you choose to include this optional statement, there is a normative statement following it. trying to think of an example for example in the verifiable credential data model there's a should for people may use verifiable credential for envelope proof if they choose to do so. there's a strict data model that they need to adhere by. so in those situation we want to make sure that if people do not support envelope verify credential they're not penalized on the test suite reporting side. So they're not getting showed up as they don't support it because it's not required. However, if they do we want to ensure that they've implemented in the correct way.
Patrick_St-Louis: For how this test suite is scaffolded. so since here we have a blank slate I wanted to create this pipeline of how we designed the test suite what's the matic so in this initial PR I've included a file that contains all the normative statements that are to be tested. so before we had some Excel spreadsheet that contained these and we always had to kind of cross reference. so I think for here I'd like to have these. So this is a sort of here what your spec needs to be tested.
Patrick_St-Louis: This should be generated with some kind of script parsing that parses the spec and extract the must statement. So this parser needs to be respect aware. respspec already tags these keywords in the spec itself with some specific ID in the HTML itself. So it's very convenient to parse. and then we want to kind of, just arrange them by section. So, this allows us at any moment to see if what is covered in the test suite reflects the current version of the spec. Yes, it means that if there's a change to the spec, we'll need to come and change this file. but by centralizing everything here, from experience, it makes this a little bit better.
Patrick_St-Louis: And for Ted's answer, you should be looking at the M test suite. The UPSC ID is my fork. it's where the PR is coming from. so if we go into the W3CVOM test suite, there is one pull request which is coming from my fork into the W3C main. this is usually how I contribute to open source project. if we prefer that we only create branches on the W3C repo, I'm happy to change to that behavior. so if you see the diff up here, is there? Yes, Manu.
Manu_Sporny: Yeah, plus one to doing that. I mean, we should just give you admin and maintenance access to this repo and you should be able to just raise pull requests directly on it. yeah.
Patrick_St-Louis: Yeah, I can do that.
Patrick_St-Louis: I believe I have the rights already. This is just how I've been kind ofuting to project.
Manu_Sporny: No, I could totally understand why you did it the way you did,…
Patrick_St-Louis: Yeah,…
Manu_Sporny: but I think it's better to just keep it all in the BCOM test suite.
Patrick_St-Louis: that makes a lot of sense. so I'm happy to, instead of merging to main, I can just merge create a new branch on VCOM and recreate this PR. So yeah so this is the tally we have now from experience it's been the reason why we adopted this way of just focusing on the must statement is because we need to think suite right the purpose of this test suite is really to say is there enough implementers of this spec right so we want to stay as much black and white as we can only covering what is normatively required
Patrick_St-Louis: And if we come up we see there's a statement which cannot be tested. There's no way to test this statement. we can then rethink should this really be a normative statement so far all the normative statement I've identified are testable and usually with each of the statement we need to include at least one positive test and one negative test right so the goal for this is just so that we don't have an implementation that just returns 200 at every single request and they can cheat so it's finding this balance
Patrick_St-Louis: of making sure it accurately represents the spec right there's always going to be if someone really wants to go to extra miles and really cheat the test suite go ahead be my guest we'll do a reasonable effort to make sure that it is accurate so in the vcom it's a bit interesting thing because we have a OAS specification along with it. usually most of the other test suite are really either data model based or algorithmic based right.
Patrick_St-Louis: So whenever we talk about the data model obviously we want to make sure that the response are whether their software accepts reject incorrect bodies and returns correct bodies right with any kind of crypto suite test we want to ensure that the solution can actually verify the crypto suite and detect bad misformed proof and also that they can issue credential with their selected crypto street that can be verified by our test client. so this means that in things like the verifiable credential data model test suite, we do not make sure that the solution generates a valid proof. We make sure that the body of the credential is correct. The proof verification is done with our crypto suite test suite.
Patrick_St-Louis: So usually what people will do is they'll have an endpoint tagged with verifiable credential 2.0 and whatever crypto suite that issuer service is meant to issue and this will run both test suite. The test suite will ensure that the data model The crypto suite will ensure that the securing mechanism is well implemented and then when you mix both together you end up with a comprehensive test suite. we made this because otherwise we would just have every test suite repeat everything and it gets a bit convoluted. So in this approach this VCOM test suite will not focus on testing the data model of the credential and it will not focus on ensuring that credential have a valid signature mechanism in them.
Patrick_St-Louis: Instead it will focus on testing I endpoints and API behavior. the only part that will have more extensive testing will be ensuring that workflows can be conducted end to end. so we can foresee someone tagging an endpoint with VCOM data model 2.0 and a specific crypto suite, right? And this will run all three test suite on that endpoint. Each test suite kind of testing their own respective things. for the layout of the test suite, so we're going to have, our normative taste statement file, which is what all the test description will be based on.
Patrick_St-Louis: And then we're going to have directories kind of matching the specification. It should be very easy when we look at the project and the test to see what it corresponds to in the spec, We shouldn't have to guess it's talking about issuing credential it must be the issuing service. No right you're going to have the section 3.2 two issuing service and then you're going to have the normative statements and series of tests. so that when we want to answer the question do we have enough coverage it should be fairly straightforward to get the answer right it should be able to do that with a script or a program. for the configuration file. So this is where things get a bit interesting.
Patrick_St-Louis: So I think it's fair to say for things tag vcom we want to give them service instance endpoints. this makes a big change because previously our issuers we gave the credential issue endpoint. Now in the vcom spec when we think about issuers there's actually three endpoints that they need to support credentials issue being one of them I think credential get is another one and credential delete for verifiers right verifiers are meant to support credential verify and credentials presentation and then holders workflows service right they define the different
Patrick_St-Louis: end points they have and interaction that maybe we'll keep maybe not. So this creates a interesting dilemma of do we still want the issuers to point to a specific credential issuance endpoint or do we want issuers to point to the issuing servicebased endpoint and have the test suite infer that the issuer service must have this and must have the other endpoints. we have the benefit of having a tag. So we can tell existing test suite that if you have a tag vcom you need to interpret the endpoint as an issuer service and not an issuance endpoint. if that makes sense. So that's kind of the way I've approached it.
Patrick_St-Louis: Yes, manu. So the biggest difference is so we add verifiers and…
Manu_Sporny: I mean, I think it's fine to go with that approach for now and see if implementers complain about it, if we get an implementer's like, I didn't set my thing up and I don't know how to get it to work. I think at that point we can revisit it. but I think this should work for most of the implementations that I know of anyway.
Patrick_St-Louis: VP verifiers So by doing this approach we're condensing both and the verifiers meaning if you have a verifier with VCOM you are normatively expected to support both credentials and presentation verification. that's one of the normative requirement for the verifier service.
Patrick_St-Louis: Where this causes problem is if someone already has an issuance endpoint and they just want to add the VCOM tag, this will likely not work. but I don't think that's something we want to encourage. I think we want to encourage if you already have an issue endpoint with this suite, leave this one as is and if you want to support VCOM, just add, your new issuer VCOM endpoint. otherwise, we're going to get into all sort of backward compatibility. weird artifact. So what you have now needs to keep running. Basically that's my own focus when we define this test suite and we had implementation we shouldn't require anyone to change what they have in there to support it. We should just require if they want to support this new tag to present this new issuer service.
Patrick_St-Louis: Yes madam.
Manu_Sporny: Plus one to that. I think that's exactly the right thing to do. and I'm wondering yeah I totally forget that I think the issuance and verification of the previous test suites that we had for this those were preliminary first attempts at it, And I think that the VCOM test suite is going to effectively deprecate those old things if I remember correctly. So I think we should expect those things to go away in time and it's but I agree with you let's not break the ecosystem while we're doing this upgrade.
Manu_Sporny: Let's go ahead and upgrade. let's get a nice healthy set of implementations for VCOM and then once we feel pretty comfortable that there's enough broad implementation of VCOM we can kind of let those other implement implementers say hey we're going to start deprecating this and we're probably going to end up removing it in a year or…
Patrick_St-Louis: Yeah. Yeah.
Manu_Sporny: so right give them plenty of heads up to migrate that's
Patrick_St-Louis: I was going to touch on that. So the two test suite you're referring is the VC API issuer and API verifier test suite. And from what I've heard, these were originally kind of put there as a C playground integration step. Meaning if you wanted to integrate with VC playground, just run this test suite as a first step. and yes, that's one of the first. So there's the two next PR I'm going to open on there. The first one is going to be some open API testing, which I'll get to in a minute.
Patrick_St-Louis: And the second one will be essentially porting this VC API issuer issuer and verifier service tests right which should cover the equivalent of what these test suites do. one last thing I wanted to add the challenge we have for this. So let's say I have an endpoint I want to tag VCOM VC 2.0 and a specific crypto suite. one thing we could look at doing if we want to support this in the future is that for the crypto suite test suite or data model 2.0 test suite, they can look has the current implementation has a VCOM tag on it. If I'm going to append credentials issue to the base endpoint. Right?
Patrick_St-Louis: So then people they don't need to have two separate entries if they want to test VCOM and VCDM 2.0 they can just do the same. that's going to be maybe later on because currently if we have VCOM and 2.0 the 2.0 is going to pull that domain expect that it has credential issue send the credential to sign and the endpoint is going to be like it's not the right endpoint it's just the base service endpoint so since we have the vcom tag I think that's a backward compatibility path that can exist for people that want to tag more than just the vcom service that's going to have minimal footprint
Patrick_St-Louis: and all the other test suite right I think we just need to add a vcom handler that means if you have an issue with vcom and you want to test 2.0 I'm just going to add credentials issue at the end simple as that yes man Yes.
Manu_Sporny: Yeah, I think that's okay. I'm wondering if we might be kind of overdesigning it, meaning the alternative is they just duplicate the entry, right? They just put another thing. And I think that's okay, I mean, it's not super great. And I get what you're saying. but we're talking about designing for a group of 10 or 20 people on the planet, right? I think they can copy and…
Patrick_St-Louis: Yeah. Yeah. Yeah. Yeah.
Manu_Sporny: paste in the very worst case and in the best case, it's output. Yeah, that's
Patrick_St-Louis: I think that makes sense, right?
Patrick_St-Louis: This idea was really at the end because some of the implement they have already quite a few endpoints but yeah you can just serve add another issuer entry same base you just add in the entry the credentials issue and it's going to be sorted so definitely not priority but yeah it's just kind of what I was thinking about the first goal we just want to have something that ts vCom and then tests vcom and then we can think
Patrick_St-Louis: about how we can improve it. yeah, so the last thing I wanted to mention so initially I had this idea of using a thing called schema thesis for testing after some more research so there is a chai open API testing it's a little bit less extensive but I think it's going to fit a lot better more seamlessly into the current reporter. So we use mocha and chai as kind of part of it.
Patrick_St-Louis: schematasis was fun. it's very comprehensive. It does a lot of fuzzy kind of testing but it's very I want to say parasitic to this it's kind of its own thing. It doesn't fit well in the reporter as the chai open API I think is going to be a lot more seamless. we can just kind of give it the OAS file and ask it to test whatever is relevant to the endpoint we're testing. I think that's probably the best solution here. it's also less involvement, less configuration and everything. Schemais you had to do your own configuration file. So that's yet another thing people would have to do. yes, Mario.
Manu_Sporny: Yeah, a plus one to that. That sounds good as well. are you this fits in…
Manu_Sporny: what you're proposing fits into the way that we're doing reporting for all the other test suites. Is that correct? Did I hear you correctly?
Patrick_St-Louis: Yeah. Yeah,…
Patrick_St-Louis: that's…
Manu_Sporny: Okay, that's good.
Patrick_St-Louis: what I meant. the digital bazaar reporter that feeds into So I got as far as generating a test suite page,…
Manu_Sporny: I think you mean the Can I VC site?
Patrick_St-Louis: the report page that test it renders nicely. I've obviously not tested all the way to VC playground, but if we get a nice conformant respspec test result page, I'm assuming it's going to translate nicely to the VC playground. because it Sorry. the KIVC,…
Manu_Sporny: Yeah. Yeah, that's right.
Patrick_St-Louis: Because it's the same JSON.
Manu_Sporny: Yep. Yep.
Patrick_St-Louis: I have a few suggestions to make some change there.
Patrick_St-Louis: Might as well. It's going to be the last thing I show there. Then we can kind of go on somewhere else. So, I kind of just wanted to propose maybe on the reporter, we can kind of have a test title, Instead of showing the statement here, it would still be tagged in the spec. the conformant could appear when you hover it would still be tied to it but maybe just give a nice test title that I can read because when I read this it's like okay what is this doing because this could be securing mechanism right okay yeah this is a test for securing mechanism I think this can be done without issue so that'd be kind of one thing I'd propose yes manu
Manu_Sporny: Yeah, plus one to that. none of that reporting infrastructure is precious. we want to, greatly improve it's kind of ugly. It's all smashed together. we definitely want to make those improvements you mentioned to make readability better. plus one to that. the most important thing of course is that it fits in some way to the KIVVC site so that people that are implementers can show whoever they're trying to convince to use their software hey this is how I'm doing and as you can see it it does very well across these tests that the customer care about.
Manu_Sporny: So I definitely want to make sure that we don't lose that and you're saying absolutely we're not going to lose that all that continues to work.
Patrick_St-Louis: Yeah. Yeah.
Manu_Sporny: So all that's great. but yeah, I mean the test reports are ugly right now. It would be really, really nice to give them a refresher.
Patrick_St-Louis: And I think kind of does that, right? Because when you see here, it's nice. so here, the test name, we could have a shorter test name with a little when you hover over it, it shows the normative test statement that corresponds to it. It will maintain this link. here, it already looks a lot better.
Patrick_St-Louis: But things like this it's a lot to read just to know what is this doing right we could summarize this in a short name that explain what it is and then if you want more detail exactly how this test was normatively requested in the spec you can kind of read this I think a small name with an information bubble is pretty standard HTML thing so I can talk with Ben and we should be able to just put this in small addition. It's not changing anything. It's just adding this little test name and like it says test name. That's not a name, right? That's a statement. yeah. So, that's kind of where I'm at. So, I'd encourage people to read this PR. I'll open a new one from the W3C.
Patrick_St-Louis: mostly read me if there's anything that seems problematic here or any suggestion to comment on it and then once this is in I'll submit two new PR one for open API testing for the services and the other one for covering the VC issuer verifier test suite and then after that I'll do other probably divide
Patrick_St-Louis: service and we'll probably leave workflows for last. I think that's going to be the main thing we'll want to test here. All the other service are pretty lowhanging fruit, right? the status update, issuer endpoint. this should be easy to test and then we'll finish by working on workflows and think about interop testing. If you want to have two services kind of do workflow things. yeah, that's as much as I have. Is there any comments?
Patrick_St-Louis: Yes, man.
Manu_Sporny: Yeah, this is all great. Patrick, thank you so much for working on it. I mean people should I did, read all the sections as you were going through them and they look good to me. my preference would be to merge this sooner than later. maybe give it a week for folks take a look at it. But this is very much aligned with, what I think we were at least I was hoping for and it looks like it slots in really well and can get us in really good shape to go into candidate w.
Manu_Sporny: Plus one emerge from me. my suggestion is we give it another week for people to provide any comments they want to and then we just go forward with what you've done. Patrick.
Patrick_St-Louis: Perfect. So,…
Patrick_St-Louis: what I'll do, I'll close this squash the comments, reopen one from a branch at W3C. I'll send a message on Slack, and then next week we can merge it, if there's no objection. Perfect. So, this took way longer than I expected, but I think it was, significant, to discuss this.
Patrick_St-Louis: So the next thing I don't know if we want to take time to discuss threat model because I saw there's a PR open so maybe we want to fold this discussion in the PR review. is there any kind of updates discussion that's not covered by the PR that someone would like to discuss.
Threat Model PR Review
Patrick_St-Louis: looking at you, Eric and Joe. Don't want to put you on the spot, but yes, Eric.
Eric_Schuh: Yeah, I guess I can just talk a little bit about maybe the path forward and…
Eric_Schuh: see what the group thinks. I missed last week's call, but I see that especially Manu and Ted have started commenting on the PR. I'm not sure how long we want to give that. I guess I was tentatively planning on, maybe giving it to the end of this week and before next week's call, I'll go through and, basically accept any of the proposed changes that seem uncontroversial, so there's no discussions happening around them. a lot of TED's editorial changes would fall into that category. as well as a few of Manu's, suggestions around, different responses. And then I guess where I'm not as sure how the group would like to handle it is for some of the I guess controversial changes in that I know there were a number of responses that Manu disagreed with.
Eric_Schuh: And I think my general sense was the cleanest way to do this might be to simply remove a number of those since there's clearly disagreement about what the content I provided. which is all fine and and then open up individual issues after we kind of merge the massive PR in to respond to any of the threats that are missing responses in that manner. So basically accept anything that seems uncontroversial. strip out the responses that were causing controversy and then open up individual issues so that we can deal with things more peace meal rather than in the large file.
Eric_Schuh: But happy to take suggestions. So I think that's kind of where my head's at. So I'll leave it there.
Patrick_St-Louis: Thank you.
Patrick_St-Louis: Manuel
Manu_Sporny: Yeah, I mean I appreciate the care that you're taking in processing but I don't want to slow it down. I mean, I don't know if we need to remove things. I'm fine with it being merged with those kind of things that are I don't think not quite accurate, being in there. I think it's less at stake, Because threat model is a living document. We're going to be modifying it as things go on and I've made it very clear, where I think the misalignments are.
Manu_Sporny: I don't think it's the end of the world if we just merge it and iterate on it quickly. So, I would much rather we iterate on it rapidly instead of kind of waiting for, something more perfect to happen. plus one to leave it till the end of the week and then just basically merge in a way that you feel is appropriate. that's certainly what my preference would be. because I would much rather us get to the point…
Patrick_St-Louis: Joe.
Manu_Sporny: where we're firing off the horizontal review and actively moving towards
Manu_Sporny: then trying to polish the threat model more than we need to at this point. that's it.
Joe Andrieu: Yeah,…
Joe Andrieu: plus one for managed comments. I think we can move this a little faster than maybe you were thinking, ic, I have already merged in a bunch of things that I deem to be editorial. so a lot of tall Ted's comments I pulled in already. there are some things where also I said hey that's interesting manu but do you have text and manu did in fact come back and…
Patrick_St-Louis: Eric. My
Joe Andrieu: provide some suggestions so I think we are getting some good healthy back and forth in the comment thread itself. So please engage there and I think to the extent that there are things that don't resolve with that back and forth in comments then definitely next week we should have some time on agenda to see…
Joe Andrieu: what they are and try and clear them out.
Eric_Schuh: Yeah,…
Eric_Schuh: that sounds good. And then I think what my plan and this is partly for Joe as well in case you're doing more work through this week will be to come through this on Monday or Tuesday morning before the call here and try to clean up anything that is uncontroversial. I'll leave anything open that the group might want to look at before we merge and then we can hopefully deal with a few outstanding things and merge this next week.
Patrick_St-Louis: Yeah. Heat.
Manu_Sporny: And again, I appreciate the care, but'm not as long as if it's just my comments, merge it on Monday. and then we can talk about it, on the follow-ups on Tuesday.
Manu_Sporny: But clearly, if other people are objecting have an issue with it, then that's fine. we can discuss. But just underscoring my desire to see this thing merged and in there and for us to have a base to work that's
Patrick_St-Louis: That's okay.
Ted_Thibodeau_Jr: Yeah, I'll just suggest that anything that seems to be controversial that remains including manage comments. If they just get turned into fresh issues and then this gets merged,…
Ted_Thibodeau_Jr: it means that we don't lose any of the comments and all the material that's there is useful. That's it.
Patrick_St-Louis: Thank you.
Patrick_St-Louis: Yeah, I think this all makes sense. what I would propose? So to ensure that by the time we start the meeting next week, everything here is addressed, issues are created, it's in a good place to be merged and we focus on getting it merged at the meeting. that leaves you the time to have other things prepared and we can start with this and ideally we should be able to merge it right away and then branch off in the other issues.
Patrick_St-Louis: does that work with what we discuss? it's not clear to me if we wanted to add this merge before the meeting after I would propose getting it in the place that we can basically click the button on the meeting and present the issues that have come out of it.
Patrick_St-Louis: Is that reasonable with everyone? yes, Okay.
Eric_Schuh: Yeah,…
Eric_Schuh: I was going to just say I'll plan on trying to getting through kind of my review having all the issues created by the end of the day Monday and then I'll ping you Patrick in Slack and if you want to choose to merge it before the call you can do that and if you want to leave it to the call for a quick review we can do that as well.
Patrick_St-Louis: Does that work with what you said, is that fast enough or you'd really like this to be merged before the next call?
Manu_Sporny: Nope, that works just fine.
Patrick_St-Louis: We'll make sure to put a pin on it.
Patrick_St-Louis: I'll make sure it's the first topic we discuss. Any other closing comments on threat I put a little topic. We can skip this for today. Maybe talk about this the next time. So I think Maned some of it about our goals to get horizontal review. So I just wanted to have a quick chat about kind of where we are at what's next. it sounds like we are on a good track. So maybe we can just being mindful of the time there is a PR I'd like to get us to kind of leave this for another time. Yes. Okay.
Manu_Sporny: Never mind. I didn't know there was a PR to get to. So, let's get to that.
Patrick_St-Louis: Yeah. This was just sort of making sure we're all on the same page. Different people working on different things.
OpenAPI Specification Simplification
Patrick_St-Louis: but it was not a necessary thing. so there's a big one I'd like to take time to decide this one that's going to have impact on the test suite. some people have already reviewed it. I have addressed some of the comments. So this is about not the response bodies themselves but whenever we want to refer as a credential in the spec whether that's an input to an endpoint to be signed a response a verifiable credential a workflow item.
Patrick_St-Louis: So currently the way it's made is that we define what the credential is in a verifiable credential very extensively in the OAS file. and this includes a lot of normative statement about what the body of the credential is. some of the things we discussed is we wanted to simplify this in the same aspect that the data model spec already defines all of these in its own spec and it's not the primary candidate we want to highlight in the VCOM spec right we want to highlight the VC API the interactions between parties and the security around this by kind of copying over what's in the VC data model spec just adds
Patrick_St-Louis: a lot of normative statement and a lot of things and then we say yeah it's normative but it's only in description so we don't actually enforce it so this is an attempt to address this so what it does it only leaves the context and the type define and the spec so the spec longer mentions fields like issuer credential subject groove move it only defines the context and the type and it clearly explains the relationship between this and the VC data model 2.0. this makes it that we primarily focus here on verifiable credential and envelope verifiable credential and presentations.
Patrick_St-Louis: and we'll simplify a lot the OAS spec simplify testing and yeah so I still kept the terms credential and verifiable credential even though if they are exactly the same as a logic signaling that when you have an issue endpoint you give a credential and when you have the response you give a verifiable credential. They are essentially the same thing. it's in the spec we can infer that well as a result of the issuance endpoint you've secured the credential with a securing mechanism but we don't require it to be either a data integrity or a envelope verifiable credential I've also updated some things as coyote pointed out update to 1.0
Patrick_St-Louis: So this was open it's been reviewed a little bit so if people could have a look and that's like something else we could merge in early on next week. yeah so this removes a lot of these fields because we had issue is it VCDM 1.0 2.0 No. instead the spec just says your context and your type will define what should be and the rest of the body. But the VCOM spec itself will not test this it will not test to make sure that you have a valid credential subject and so on. It will make sure you have a context and a type. We may if we want to test it must be either a ential or envelope verifiable credential.
Patrick_St-Louis: But I would probably not even go there. it gets rid of things like unsecured it add this thing called credential document which both credential and verifiable credential with outline from and this can be either a verifiable credential or verifiable red Same thing for presentation. yeah so this is just a attempt at making this a little bit s simpler to test u there is a section so this is probably the section that will need the most review to make sure that the informative note that we added here captures this well and is easy to understand.
OAuth 2.0 Authorization Flow
ZCAPS Support in Specification
Patrick_St-Louis: it's really to highlight that this open API specification focuses on the endpoint request body and response mostly at the first layer but not the semantic of the credential and presentation themselves and it tries to explain how it relates to the VCDM 2.0 know spec. yeah. So, that's pretty much what I wanted to present. so at least we had this discussion so we can be in a good place to merge next week. I'm not going to merge until next week. yes, Chaotic.
Kayode_Ezike: Yeah, I just wanted to propose if we could quickly look at 656 and 657 just because they were also open for a week now. all so this one is for basically adding more detail to the scope requirements for oath 20 authorization flow.
Patrick_St-Louis: we can have a really quick view. there four minutes left, but yes, so these are your PR. So I'll let you go over both try to make it fairly quick.
Kayode_Ezike: So what we had at the time you needed a little bit more explanation as to what the format needed to be. and so did that and also improve the examples that were provided. so it's gotten some review from David and Ted and as an approval on it now. I'm not sure if we need anyone else to review it, but it's just …
Patrick_St-Louis: Is that it for this one? And this one. So the same thing I assume similar kind of vein.
Kayode_Ezike: yeah, difference is that there was no section at all for authorization capabilities. So, I have to add a section for that because I mean we do refer to it in this back and I think now that we're spinning up the capability storage task force, we're more comfortable using these things. And so added a new section for ZCAPS and basically defined what the format of them should be and examples of what they would look like for different endpoints. Kayode Ezike:
Patrick_St-Louis: Okay, good. So,
Ted_Thibodeau_Jr: By this one, what do we mean? 656 or 662 the right one we're talking about.
Kayode_Ezike: No 656 for the first one. This is 657. Yeah. Yeah,…
Ted_Thibodeau_Jr: Okay. Thank you.
Manu_Sporny: The only challenge with the Zcap one coyote is that we cannot normatively reference it. and you took that into account. I take it. the 70 line 870 looks like a normative.
Kayode_Ezike: that's right.
Patrick_St-Louis: Yeah. …
Manu_Sporny: It's going to create a normative reference is the only reason I'm bringing it up.
Kayode_Ezike: Even if I'm not using any of the verbs or…
Patrick_St-Louis: I think required is a norative verb.
Kayode_Ezike: verbs. Okay.
Patrick_St-Louis: Yeah,…
Manu_Sporny: And…
Manu_Sporny: and if you just square bracketed, you have to use a question mark to make it non-normative ref or you need to make mark the section as informative. either one of those should do it. Just a heads up to you, what to do. I think just look at the rendered version and see if it puts zcap in the normative references section. And if it does then you have to prepend it with It's a square bracket question mark and…
Kayode_Ezike: Yeah. I think we also agreed last week that we would also leave the OOTH one as non-normative…
Manu_Sporny: then the ref correct.
Kayode_Ezike: because of the confusion. So, I guess maybe I'll have to take one more look at these two PRs then just to make sure. That's all.
Patrick_St-Louis: I think this looks good. So, we'll make sure to lube back this in next week along with thre model and the OS a simplification. awesome.
Patrick_St-Louis: Any closing thoughts anyone would like to share before we adjourn the meeting? In that case, thank you very much for attending and I'll see you all in a week. Meeting ended after 00:59:55 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.