Meeting minutes
Kayode_Ezike: Hello.
Parth_Bhatt: Hey Cody.
Kayode_Ezike: Hey everyone, we'll just wait another minute for folks to come in.
Kayode_Ezike: All right, we are 3 minutes past the hour. I think that we can get started here Hello everyone and welcome. Today is May 19th, 2026 and this is the weekly call for the task force convening discussing the verified credentials API for life cycle management aka becom. I'm Kyote as you can be leading the call today. please note that this call will be recorded and transcribed. So if you're opposed to that please speak up now otherwise we will continue.
Kayode_Ezike: It's important to note that this call is for affiliated W3C members invited experts. if you have any questions about that process, please feel free to reach out. We operate under standard W3C processes including patent policy and code of conduct. let me actually share my screen quickly. And as I do that, I'd like to open up the floor for folks to introduce Any introductions or reintroductions you'd like to have? We haven't seen a long time to give a quick status update. I think we're all familiar friends here. If not, then we can move on to any community updates that's relevant for you.
Kayode_Ezike: All right, Patrick.
Test Suite Scaffolding
Patrick_St-Louis: Yeah, not so much community updates but more an update regarding this call. So I just started to do a bit of an analysis on the normative statements in the VCOM and kind of scaffold just a general shape for some kind of test suite and I'd be happy if we have place on the agenda to slightly discuss that it's just sort of an overview the dispersion of normative statement across the spec section which section might require more attention and…
Patrick_St-Louis: bit of preparing the ground for how we want Tackle testing the specification should not take too long.
Kayode_Ezike: Okay, great.
Kayode_Ezike: Yeah, I did notice that Sounds good. thank you, Patrick. Anyone else? I know that a big part of this call will also be discussing threat models and processing pull requests and issues as well, but outside of that, any other additions to the agenda? Go ahead, Mon.
Threat Model Next Steps
Manu_Sporny: plus one on the threat model stuff. And since I see Joe and Eric here, I've got some thoughts on next steps. So, the good news is we're getting this approach of having everybody dump threats into the Google Doc stuff is working out really well in the other task forces. and so we're getting to the point where we kind of want to, figure out what the next steps are. It would be nice just because Joe and Eric are here if we could spend a little bit of time on all right we've got the threats we've got some of these things forming what's the best way for us to create these things across multiple task forces where we can reuse stuff across the task forces. So maybe if we could spend 10 minutes talking about concrete strategies today, that would be helpful to me at least.
Kayode_Ezike: All right. sounds good. So, then why don't we start? I know that there are a few PRs that are relatively quick to get through. but before I get into that, Joe and Eric, do you…
Kayode_Ezike: how would you all like to do this? Would you like us to start with the third modeling discussion or would you prefer that push that to go ahead?
Eric_Schuh: I guess for me as far as updates this week,…
Eric_Schuh: I didn't get as far as I was hoping last week. I was sick most of the week. so I do have some modest updates in terms of the diagramming work and the flow work that we discussed last week. that it wouldn't be bad to get the group's input on. I can definitely speak to some of the challenges I've started to face as I've gotten into the diagramming work. kind of beyond just indexing threats. and it's certainly something that I was hoping to get Joe's input on.
Eric_Schuh: But I do think it speaks to Manu's question of one step in the process is creating these diagrams and I think we as a community at the W3C probably need to figure out a good way and a good tool to use for that. right now I think Joe and I have been using visual paradigm. but you have to pay for that.
Kayode_Ezike: That's a good idea.
Eric_Schuh: So I don't know if it's the solution kind of long term. Joe
Joe Andrieu: Yeah.
Joe Andrieu: So, in terms of tools, we probably should look at Precogi. I've not used it. It is an open- source threat modeling tool so that might be a good alternative visual paradigm. I do Eric, I think it would be useful for you to walk through some of the challenges you've had with diagrams. but before he did that, I wanted to address Manny's question specifically. I think it is about the dance of the diagrams. Eric's going to talk to you about some of the challenges he's had.
Kayode_Ezike: Big
Joe Andrieu: I think the diagrams is the place where we get alignment and there are going to be components in different diagrams that don't show up in the other ones like the VCOM frankly has a bunch of elements that the confidence method doesn't need for example. and render method is going to have different elements in it than confidence method. But what we I think would benefit from is knowing that when we're all talking about the browser or whatever we call that component that we're using the same terminology. So there's a bit of a work to say, okay, here's a diagram that would work for confidence method. Here's a diagram that would work for render method. Here's a diagram that would work for barcodes.
Joe Andrieu: let's try and figure out how we synchronize the naming across all of those so that we can have an ontology that starts to work. and I think we can try and apply that sort of namespace sentiment to also how we talk about responses. signing things is a very common response that we have. So, it would be good if here's the signing thing term and how we talk about it and a description of it so we don't each separately come up with slightly different ways to talk about how signing something makes it a benefit. Right? So, I think that's the harmonization path.
Joe Andrieu: And to me once you get the diagram in place, which elements you're allowed to talk about. because if it's not in the diagram, it's really hard to talk about it. so I think in terms of logistics, harmonizing some diagrams together to have some name space. and then coming up with the threats relative to those diagrams, and then harmonizing the terms as we go to harmonizing responses or threats where they are reusable. I think that's going to be a process of comparing the different work. It's going to be like a refactoring kind of conversation.
Kayode_Ezike: Apologies. I was switching computers. Plus one to all what you just said. Joe seems like you had a few challenges you and Eric and…
Kayode_Ezike: that Eric would like to elaborate a bit on some of the ones that discussed as well. So would you like to share screen or is it better to just continue talking about it? All right. Thanks.
Diagramming Challenges and Tooling
Eric_Schuh: Yeah, I can share screen.
Eric_Schuh: So, just to kind of give an update of where I got to this last week. did I close the issue? No, here it so Joe and I took a look at the flow that we kind of talked about last week and simplified it quite a bit. I'd say the main removal here was the whole revocation cycle. but then also just to talk to some of the status discussions from last week instead of having explicit statuses which are about business rules. We did just call out that statuses are updated so that we can include those calls as part of the flow, but we're not going to specify necessarily what the status is updated to. and that did quite simplify this flow.
Eric_Schuh: So we basically have Sachin in this use case taking a credential to sorry one second I have a cat that is trying to step on the keyboard. sorry so basically this flow sin uses a single credential to go and receive and get issued a and then that secondary credential is then verified. Sorry, the cat is being persistent. Monu go ahead.
Manu_Sporny: Sorry, I don't have anything to say. I was just being snarky in the chat about your cat.
Joe Andrieu: I'll fix this.
Eric_Schuh: Okay. Okay. Sorry, I hand raised.
Manu_Sporny: Yeah, sorry.
Eric_Schuh: Yeah, got a couple kittens a few weeks ago and they're, still learning.
Joe Andrieu: cat as threat actor.
Joe Andrieu: I think we're missing that in the diagram.
Eric_Schuh: So this was kind of the general flow that I started working with. and then I did start some work on the diagram here. So this is kind of a full representation of I think all of the elements hopefully if not all 95% I might have missed one or two. but we have the issuer up here in the top and apparently it didn't save my updates to that's disappointing. this is part of the challenges I was having with this visual paradigm tool. and the holder down here in the bottom. but if you can imagine that this issuer was supposed to be a verifier. I'm not actually sure what happened there. this is effectively how large the diagram would be without the flows placed into it.
Eric_Schuh: And kind of where I had gotten was I started trying to place flows in this full diagram just to get a sense of the full set of interactions so that I could then try to peacemeal this diagram up so it's not so large. and honestly once you start adding flow arrows into here it gets fairly cluttered fairly quickly. so that was kind of the process I was starting with. but I did run into some questions that I got a little bit of input from Joe earlier, which is really about how abstract this diagram should be in terms of the flow arrows.
Eric_Schuh: If I pull up the DID resolution threat model just for a moment, you'll see that the flows here, these F-Zero, F1 are very much more of abstract names rather than explicit networking calls being shown. and I guess I was somewhat struggling with the trade-offs between essentially showing the explicit network calls and the API calls that are happening in this diagram and this abstraction. I do think Joe that your recommendation made a lot of sense which was basically try to abstract in terms of names for the flows that are in this diagram and then in the text description make explicit the API calls that are part of that particular flow. so that's basically the challenge I started to face.
Eric_Schuh: And…
Eric_Schuh: then I got into a bunch of challenges around visual paradigm because I think I chose some components in here that it doesn't allow arrows to be drawn because of box the way visual paradigm as a tool like handles boxes. So yeah. Joe and…
Joe Andrieu: Yep.
Joe Andrieu: Yeah, we should try pre-cogi.
Eric_Schuh: I have another call this afternoon.
Joe Andrieu: See if it helps. Eric Schuh:
Eric_Schuh: Yeah. Yeah.
Joe Andrieu: Actually, may as well.
Eric_Schuh: But yeah, so this should at least give an idea of kind of the full set of components that we need to handle in terms of this threat model. and then if anyone has any additional input on the flow, getting it in now is just helpful to, prevent more painful iterations in the future because once the flows go into this diagram or…
Eric_Schuh: into subp parts of this diagram, as I piece it up, things might get a lot harder to edit going forward. so that's where I got to. I'll open up the floor.
Joe Andrieu: yeah,…
Joe Andrieu: one of the things I think might be a useful way to sort of refactor this is and I don't know if you tried this Eric or not. I think we had talked about it but one diagram that is all the interparty calls so not distinguishing within the issuer what are the different components that the issuer has but rather just focusing on sort of when an issuer contacts something from the verifier or vice versa then have those flows because that simplifies a whole bunch of the actors and entities and then potent
Joe Andrieu: potentially a diagram for each of the three which would make it four diagrams. but each of the three dives into detail. So if you needed to talk about an issuer updating the status service different from talking to the storage service then that the diagram where the issuer has those things exposed is where you would find the flow that you could then talk to that threat. so that was just an idea Eric of
Joe Andrieu: how we might refactor this so that we can have a bird's eye view that deals with those flows but we can also get to detail in a different diagram
Eric_Schuh: Yeah, just to be clear that that is kind of…
Eric_Schuh: where I was heading. I think I was just trying to get a sense of the full set of complexity that I was dealing with. And there are some interesting crossovers I suppose if you take a look at our use case here kind of in this step three we have a single kind of entity acting as both a verifier and an issuer right and when you get into the questions about the workflow and different workflows I think if I come back to our kind of main architecture diagram
Eric_Schuh: here right we have workflows services index that kind of belong to each of the issuer verifier and holder and I definitely was trying to simplify that so from our use case we have a single entity which is kind of the state of California here acting as both an issuer and a verifier at different times so I wanted to only have one workflow service that represented that but then also right for this particular workflow that would be defined right which is receiving this incident activation credential workflow. you have the first step which is verification and the second step which is issuance and there' where do the boundary lines get drawn between what is considered the verifier and the issuer in terms of the diagramming
Eric_Schuh: right those types of questions. So go ahead
Kayode_Ezike: Yes, thank you for outlining this diagram. So, kind of to tie together a little bit with what Joe was saying and what you were asking earlier about whether you should use abstract names or not. I guess maybe it could help to give to make sure that we're aligned on the overall goal of these diagrams. From what I can recall when we first brought it up, it was so that we have a way from the diagram to see where the different threats could happen, the different interfaces and edges that those threats can be introduced. so we could take the exhaustive route where it's like, okay, we're not just concerned about these three different parties issue verify holder. We're also concerned about the coordinator to service interfaces and things of that sort.
Kayode_Ezike: I'm not sure if I guess the question is for the group is like…
Kayode_Ezike: how exhausted and do we want to be surfacing all these different types of I guess interfaces in order to capture them fully in the threats. Go ahead, Jen.
Joe Andrieu: yeah there's an interesting sensibility here that I want to help inculcate in terms of…
Joe Andrieu: how deep do we want to go the long-term something like mythos is going to be a better holistic exhaustive review of all the things that might possibly go wrong. And so I don't want us to think that being exhaustive is particularly helpful because other tools are going to be more exhaustive and that's just a matter of time and this specification and this threat model hopefully will last 10 years, right? five maybe.
Joe Andrieu: And so the value of us making a threat model is that the folks who argued over the trade-offs in the spec itself. So we know why we argued for different trade-offs and some of those reasons were security or privacy related. So the lens that I want to invite us all to put on is what are the threats I care about and let's make sure that we get the flows that let us talk about those threats and that we could talk about threats of your JSON parser being wrong but I don't think any of us got into much details and the trade-offs about that particular threat. So I don't care about enumerating the parsing of JSON any of those or SSL or TLS.
Joe Andrieu: but we will have some SSL and CLS in the flows. and so where it is appropriate,…
Joe Andrieu: we want to talk about it. So I guess the lens I'm inviting us to consider is what keeps us at night when we were working on this specification and how did we deal with the threats and risks that we knew about as we collaborated with others in this working group.
Kayode_Ezike: Okay. Thank you.
Eric_Schuh: Yeah,…
Eric_Schuh: I guess my topic was mostly trying to close up kind of next steps and give a sense of what's coming in the next steps of work. So if someone has a response to Joe, go ahead first.
Manu_Sporny: it's a general commentary on what's been said so Eric you said you rework the flow. that looks much better to me. so thank you for doing that plus one to that. as for the complexity of the diagram, yes, it's really complex and we're going to have to figure out some way of breaking it apart. plus one to all the things Joe's been saying on the benefits and what we want to focus on and sort that sort of thing. So I do want to get to the point where we talk about okay so what are we going to do based on all of this stuff.
Kayode_Ezike: Is your comment positive?
Manu_Sporny: I'm very focused on the concrete what do we do after we brainstorm how do we make sure that we do work that's not repetitive of each other and I'm particularly interested in making sure that it's not a side quest but we could definitely make it into a very long side quest. so what's kind of the minimum viable first iteration of this stuff.
Kayode_Ezike: Thanks.
Manu_Sporny: I've got some thoughts, but I didn't want to rush into that until Eric, you feel like you've gotten kind of what you needed out of the group and…
Manu_Sporny: and so on so forth. That's it.
Eric_Schuh: Sorry thank you.
Eric_Schuh: Yeah so let me just speak to kind of next steps that I have planned here. so I ran into obviously most of my struggles were around getting this diagram created and then as I started to place the flows. I was having a lot of tooling problems with visual paradigm that I wanted to talk to Joe about because I know he's worked with this tool before. but regardless this diagram needs to be finished in some form so that we can place the flows on it. Once that is done, I will return or a combination Joe of Joe and I will return to our document here and we'll transform each of these threats. so that there's a threat name, a description, responses, which that part will probably come back to the group on I imagine. and then also the components that the threat is affecting or is affected by.
Eric_Schuh: So essentially once we get done with the diagram a first pass on the diagram will come and clean up the threats add the components that the threat has a relationship to. and at that point that's probably when the group will want to come in and maybe do a similar thing as we did when we indexed all these threats and start indexing responses to each of these threats. and in general I would say that a lot of these threats will be reusable in other groups. so that's definitely something that we should keep an eye on and an eye to.
Eric_Schuh: And we have already a notion that if we identify threats in here that are not directly related to one of our flows or one of our components in this particular group, we'll add that as an appendix to be triaged to the appropriate place in the future. so yeah, that's kind of my next steps is first getting through the diagram and then returning to these threats here. What I am hoping is that I can get through the diagram and do a very quick first pass to clean up our list of threats here and get that into the repo as an actual document in a threat model so that we can choose to either move the discussion out of this Google doc or not.
Eric_Schuh: But mono I think that's mostly driving towards the requirement of having a threat model before we can move on to move the group to the next step. I'm not sure exactly where that needs to be. but that's kind of in my path. first the diagram then do a first pass to clean up our current list of threats and…
Kayode_Ezike: Thank you.
Eric_Schuh: get all of that into a document in the repo.
Manu_Sporny: Yeah, plus one. That sounds good. I want us to talk about pretty conly. So, Joe, you mentioned that, I don't want Eric, you to do a bunch of work that then you just kind of have to replace,…
Manu_Sporny: but at the same time, I don't want, us to have to, send you off on yet another side quest to see if PCOGY is going to work for you or not. …
Kayode_Ezike: you Joe that mentioned
Manu_Sporny: are we ready to talk about that or do we need to talk about anything else before we talk about kind of the tooling that we're going to use to move forward on some of this
Joe Andrieu: Yeah,… I think we can talk about pregly I think we've covered the more generic sort of perspectives and where we're at in the flow in the process. Joe Andrieu:
Precogly Tooling Discussion
Precogly
<Manu_Sporny> Precogly Documentation
Manu_Sporny: All right, great. I'm going to share hold on one second. Why can't I just There Here's the link to Precogley topic. here is the link to pre-cogi and yeah coyote if you want to share.
Manu_Sporny: So Joe specifically, I'm looking at these other groups that are doing this and I'm like, this really feels like something that we could break down into some kind of, codebase configuration files that then we could potentially reuse in the future, put them into libraries, figure out ways to import them, maybe do some respec magic to autogenerate a lot of the stuff from the base level components. So, pregly feels like so the first question I was gonna have is what's the format we should use and what goes in each one and that could turn into six-month engineering project. Luckily, I think Precogley already has the vast majority of the data structures already defined for us.
Manu_Sporny: And so at a minimum we could use those data structures and maybe use the tool to build some of this stuff. and it has a way of exporting it. we'll go through some of the details here. What I'm basically saying is I feel like precly would jump us forward by six or eight months or a year by just reusing the infrastructure that they already have specifically the data formats and then we could figure out tiny ways of expanding respspec to pull that stuff into a format that worked in respect using some kind of LLM generated extensions to respspec
Manu_Sporny: So let me start with that concrete proposal. I would like us to walk through the pre-cogi library packs and all the stuff it has and then hear from you Joe on any gaps you feel there are there.
Joe Andrieu: …
Manu_Sporny: Let me stop there. Go ahead Joe.
Joe Andrieu: so calcially is pretty cool. I think it's most valuable as a diagramming engine. because it's moving towards the level of simplicity that we want. one of the challenges with, Vizio or even using Figma to diagram is that you can put too much in there. And really in a DFD that's in the Adam Shaw stack sort of world, you want five components, maybe six. you just want to know that it's a process or that it's a indicating that something is a database or something's a server or something is a mobile device. those are extra details that you really don't want in the threat model. And so I like that pre-cogn seem to have a very dynamic editor that we could use.
Joe Andrieu: it's a bit overloaded in terms of they've done a lot of additional sort of both in their data model and in their tooling to support enterprise workflows which I'm sure is great if you are an enterprise and you've got OASP or you've got some other framework that your organization by policy has you using that's what these different library packs are which are pretty cool but my hesitancy with their data model it does bring in a bunch of corrupt. and to speak to some of the other things we were suggesting, we in fact have a rendering engine that goes off of what is effectively SON. I'm using a hack that they're JavaScript instead of JSON so that I can load them locally from a file context, which I can't do with JSON without a file server, but that's a weird technical detail I probably didn't need to mention.
Joe Andrieu: But the current DID resolution threat model has a rendering engine that gets that data model into respect in a way that respspec indexes it correctly, It has the right section numbers and definition links. And so that overhead pre-COGY doesn't deal with it all, but we have a system that does it. and I don't know if we'll get the grant, but I did just apply for the sovereign tech fund grant for open source for standards. So maybe we'll get some funding to support sort of growing that tool. I mean an obvious one I want to do is I like this weird JavaScript swizzle thing. but I think lots of working groups aren't going to like that. So supporting a pure JSON versus just that JavaScript. and adding validation tools and linting and that sort of thing would all be useful and important and I just haven't quite got around to that yet.
Joe Andrieu: So I do think the gap is, but I guess the other thing we can do is I think we can take the data out of pre-cogi and get it into whatever data model we want. And I think there are some things here that might suggest changing our terms just to be aligned because that would be easier. but we also have the threat modeling guide at the W3C. which is also something that we would want to pull along with us if we start changing terms. because that goal is to have language and practice that can be common across all the working groups of the W3C if we do it so we want to consider what the TMCG is doing. I'm sorry, the threat modeling guides, and fold that into this as well.
Manu_Sporny: All right. so yeah. Yeah. I mean, all that sounds good.
Manu_Sporny: I guess what you're saying is don't Use the stuff that you've put together for the other groups.
Joe Andrieu: I don't have a diagram editor and…
Joe Andrieu: so that's the biggest value prop I think that precognly gives us is it's hopefully a decent open-source, DFD editor that's at the right level of granularity for what we're looking for. yep.
Manu_Sporny: Got it. Yeah. And can it render into respec I guess is the other question? or maybe we just don't care and we just export it as an image whenever we have an update. I'm trying to get to something that is the normative references, right?
Manu_Sporny: the specre ref stuff that's built into respspec where you can just dynamically import subp parts of other specs and…
Manu_Sporny: refer to them and that kind of thing Joe right Yeah.
Joe Andrieu: Right. all that is essentially micro formats in the spec itself.
Joe Andrieu: And so it's data annotations in the W3C publish specs. And so that's sort of on the rendering side of the data model. and if we knew, in fact, that's part of what I proposed to the Sovereign Tech Fund is I want to figure that out. what is it that regardless of…
Manu_Sporny: Mh All right.
Joe Andrieu: what tooling you're using to generate your spec, because you could handw write your spec, and if you do the annotations, right, then we would want to have this thing that looks over W3C specs and can pull out threat actors, threats, responses, like that would be really useful.
Manu_Sporny: I guess what I'm saying is the way that happens. So yes, it's little microformatted or it's markup in the spec and there's a process that actually goes through each one of those specs and extracts it into I think it's a JSON style database. So there's this build process that goes through and lifts data from the spec itself and then injects it into a different thing that looks very much like the AML structure and the library packs for pre pre-cogi and then that thing is then used as the bibliography database that respspec loads in and then uses that to kind of process everything.
Manu_Sporny: So I think the thing that might be missing is what does the build process look like? And, as I was looking through the pre-cogi stuff, I was kind of like, these YAML files, the library packs that they have, right? So, if you go to the library pack stuff, Coyote, and then you look at, you keep going down, they're like pack descriptions. That's for each specish kind of thing, handwave. But then you've got components.yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyamel, you've got threats. You've got countermeasures. We don't need all of these things,…
Manu_Sporny: but there's a subset of them that feel useful and would be effectively I think where we end up if we pull stuff out of the spec and in kind of micro format style, markup in the spec.
Manu_Sporny: So that's what I'm trying to and it's easy enough to take…
Joe Andrieu: Yeah. … Joe Andrieu:
Manu_Sporny: what you have right now Joe and ask an LLM to convert it into pre-COGY or start with pre-COGY and ask them to convert it back into the other JavaScript. I'm just trying to get to something that we can parallelize sooner than later. That's not like we end up tearing the whole thing down in 12 months and doing something different. So I'm looking to you Joe because if you're going to build the tooling let's build it off of that…
Manu_Sporny: but we're going to parallelize very rapidly and we're going to probably oify the infrastructure that we have.
Joe Andrieu: So let me push back on…
Joe Andrieu: what you just said. You've introduced a fork that if you run down pre-cogi and you think about its data models now we're parallel. what I've done, I don't want to sound defensive, but we developed a threat model that worked with respect for the modeling We did an appendix in there that was the first pass at a web threat model. and that was tricky just to get the straight HTML to render something that was pretty and readable and workable. if you go down, it's appendix A or whatever that actually has the threat tables that were the sort of interesting and hard parts.
Joe Andrieu: And it doesn't work well in dark mode which is a different problem. actually we should make that a bug and go fix it. but this was figuring out how does respspec want to deal with this so that you can have the index on the left right and you can have links to these that work in the way that respspec references to link. And then in the did resolution threat model I've jsonified this. So there's a system to make this JSONification output.
Joe Andrieu: And that's what we're going to use in the did resolution threat model and it's my intention to use it for the confidence method threat model. and to help anyone else who wants to use that approach in their threat models. I think it would be extra work to convert this into pre-COGY and then come up with a pre-cogi based data model that renders into respect. but if I mean I guess pull requests are accepted. and I don't mean that in a snarky I mean that I would like to support additional in incoming data models. but it's a matter of who has the resources to do that. Go ahead M
Manu_Sporny: Yeah, I wasn't trying to suggest alternate or parallel path. I'm trying to understand is this tooling ready to go? So, if we pick this up and we started using it today, what rough sharp edges are there on it? I'm totally fine with using everything that you've built here, Joe. I just want to know if we start doing that in earnest, what are you concerned about? what are your concerns?
Manu_Sporny: Or you're like it is 100% version 1.0 ready to go, right?
Joe Andrieu: So that's a great question.
Joe Andrieu: I think where it breaks now is I really haven't isolated out the library. I mean it's sort of structurally it is by nature like I tried to isolate there's one file that you load and then there's the data files, so that's kind of structurally isolated, but I don't have a repo where I can say, "Hey, if you want to add a threat model, go to this repo and it'll explain to you how to do it. And here are the tests." and I think that's the other avenue where really I haven't done the test framework. which should include things like validating a PR that is supposed to be a new threat because we know what that data model should be and so we can check the schema or we can validate it with a llinter. Those kinds of things are not there.
Joe Andrieu: But I do believe that the did resolution threat model tooling could be used by anyone and I'd be happy to say, " we'll just plug this file in and then you use these data structures." We just haven't documented it or provided the unit tests or testing around it.
Manu_Sporny: Is there so I'm hearing you say it is not isolated into a respspec plugin that other people could use and if that were to be done…
Manu_Sporny: then we would have something that would be reusable. Are you saying something else?
Joe Andrieu: That is mostly…
Joe Andrieu: what I'm saying. I think you could reuse it today. that's not polished or tested. And so I'm sure there are going to be, things I didn't think of that people are going to use it and I'm going to realize, it's broken for that particular case.
Manu_Sporny: All right.
Joe Andrieu: Let's fix it.
Manu_Sporny: But by using it, are you saying copy what's in the did resolution repo into the I don't know render method threat model repo and…
Manu_Sporny: then go for it. I don't know. I Okay. All right. Okay.
Joe Andrieu: Yeah. That's right.
Manu_Sporny: And then that would create an instant like code diversion and we'd just have to make sure that we'd copy the code over versus if we had it isolated in a respect library at least we'd have a common version that we could continue to use. is that aligned?
Joe Andrieu: There are a handful of files here that you'll want to copy over and customize. in theory, threat modeljs doesn't need to be edited, but there might be bugs and that's where we might have the forking. Threat model CSS definitely feel free to customize. and then the way the threats exist is, they're all in JavaScript files using this and an outline, which is how you structure the ordering of the threats within the document.
Joe Andrieu: And then there was a request from you manu that I think would be easy to support…
<Joe Andrieu> GitHub - w3c/did-resolution-threat-model · GitHub
Manu_Sporny: Mhm.
Joe Andrieu: but right now I don't which is only having an outline in the document you want to render the TOC a table of contents and not rendering the whole details of the threats so that you could have in the main spec just a table of contexts of the threats that matter and then you point to an appendix or a note that's a separate document So if you look at the code, it's going to be easy to see what we need to change, but right now it's just a monolithic. Hey, go render all the things and we can break that up to make it more appropriate for that use that you were anticipating.
Manu_Sporny: All right.
Manu_Sporny: So, would you be opposed to this if I were to take the did resolution threat model and start an experimental threat-model repo that tried to genericize this and…
Manu_Sporny: then we end up pulling that into the entity resolution threat model? That would be a fine way. Okay. Okay.
Joe Andrieu: That would be awesome.
Joe Andrieu: Yeah. Yeah. Yeah. I had hoped this last weekend to make a repo like that to support the grant application I was doing and there's just too many things on my plate. So that I would consider that very productive advancement of the work.
Manu_Sporny: And I will work on it…
Manu_Sporny: if I find some free time. But I just wanted to make sure we were kind of, going in the same direction with the same kind of codebase. Okay, that sounds good. and that is what you would recommend that we do for every task force.
Joe Andrieu: Yes. Yeah.
Joe Andrieu: And I think having the separate repo that explains that, separate from the did resolution threat model would really help.
Manu_Sporny: All right.
Manu_Sporny: Sounds good. Thank you. Joe Andrieu:
Joe Andrieu: Yeah. let me know I'm happy to contribute to that once you get something up and…
Manu_Sporny: Yeah. I mean,…
Joe Andrieu: and editable.
Manu_Sporny: and anybody else should feel free to just move on that I'm happy to do it if I find some spare cycles, but hopefully somebody else with more spare cycles can do that. That's it.
Kayode_Ezike: Could you Ru or…
Kayode_Ezike: Joe create an issue so that it's documented and we can anyone who has the ability to pick up the detail? Yeah.
Manu_Sporny: I don't know …
Manu_Sporny: which repo would I open the issue in I think I have to create the threat model repo right and go from there maybe we could ask Avon to create a respspec thing I could create one in CC PCG,…
Manu_Sporny: but I', need to clear it with the chairs. I could create one in my personal GitHub repo and give Joe you access to it. Maybe that's the best way to start until maybe Von moves it over to W3C. Yeah.
Kayode_Ezike: At the very least,…
Kayode_Ezike: I'll probably just leave the comment and the threat model issue be gone just because that's dependency for it and scope Great.
Joe Andrieu: Yeah, I would just create a private repo manager.
Joe Andrieu: That's what I would have done with the anticipation of moving it somewhere somewhere.
Manu_Sporny: Okay.
Manu_Sporny: I'm going to do that now and link to it.
Kayode_Ezike: Thank you, Eric and Joe. It's a lot of great progress so far. and is just before we move on to anything else, just let us know either now or as you're working on this if there's anything you need from this group while you're working just to help guide you all through that process. Great. Let's move on. Let me share my screen really quickly. Just want to get through the item that Patrick wanted to discuss related to nominated items. So Patrick, would you like to elaborate a little bit on the number statement overview that she wanted to discuss
Normative Statement Overview
Patrick_St-Louis: Yeah definitely I can time box this to five 10 minutes. I'm just going to share my screen quickly. So I made some charts for so basically the thing I wanted to look at was how many normative statements are in the spec and what's the scope of what we need to test here. so with W3C VC specs we usually have one test suite per specification. The u exception to the rule is the data integrity suite. We kind of folded the data integrity test into the respective crypto suites. so some complaint that there has been before was that test suite weren't extensive enough. They weren't testing everything in the spec. So we kind of adopted the approach of making sure that every normative tastement has at least one test case.
Patrick_St-Louis: For VCOM this is surely still an option. however I'm just going to share now. VCOM is kind of a special specification. the main reason is because we have a open API request body response model and these reflect verifiable credential. So the spec kind of inherits a lot of the normative statement from the VC data model right. So if we just go on here and if we just look for must if we quickly go through a lot of these are in these kind of credential so we have an extensive BCDM test suite.
normative statement overview
Patrick_St-Louis: I don't think it would be a good idea to again test every single data model. We do want to test that the API return a good valid credential but I don't think we want to go back to the extent that we've created in the VCDM u test suite and they are repeated in a few different place. so I'm going to take you just through this kind of summary. So a while ago I made a Python project based on beautiful soup that would scrape the specification and kind of divide the normative statements by their section. so this tool was kind of an upgraded version of that. I've kind of transformed it into a skill. so make up that information what you will. so there's 418 funny HTTP joke insert here.
Patrick_St-Louis: total statement in the first thing right away I wanted to do was to kind of divide the normative statement that are part of the open API spec the description like that inherited from the AS field. and it's a vast majority of these right I don't think it makes sense for us to have 418 individual tests for this specification. usually from what I've seen most W3C spec they have less than 100 and even 100 is a lot so obviously we don't want to recreate this so there was this idea that's been proposed we can start by just doing an API test use some kind of open API tool to just send request and inspect the response and make sure that this works.
Patrick_St-Louis: so I think this is good and we can see here the representation right most of the normative statements or in the HTTP API there is a little bit in the other sections which we'll read them more in detail but these might warrant some special handling for testing but these are very minimal a lot of them are so the statement
<Manu_Sporny> HTTP 418 ("I'm a teapot")
Patrick_St-Louis: type. So requests are response normative statements that are included in the respond description field. So what I would suggest is as we discussed before all these could just be handled by some kind of test tooling for API. I started recently using this one. So it's Shima thesis. You give it an open API.json. you give it an endpoint and it will do some kind of fuzzy testing on the endpoint and it's good to catch differences from the implementation and the open API spec.
Patrick_St-Louis: So this is what I was thinking of starting with to kind of get 90% of the normative statements out of the way and see how far we can get with this by testing the different endpoints that we specify in and the spec. so I kind of divided it so we want to test the required and the musts right we previously did not really test them if there's a should but that you do implement it then this comes with a must. This creates a sort of situation that you have an optional feature but that if you implement it you need to do it a certain way. So these cases they kind of need to be tested as well.
Patrick_St-Louis: So what gets interesting is So this is really breaking down the HTTP section. So these sections they follow right the different section we have on the menu here. This is what these sections are dividing us. and we can say that the biggest part is in workflows and exchange. I think this will probably be the part that we'll need to put a bit more attention of how can we make sure that an in exchangeable workflow makes its way until the end.
Patrick_St-Louis: and the rest verifying, presenting. Not only we have the VC data model test suite but we also have the old VC API issuer and VC API verifiers test suite on the CCG that we could probably archive and converge into the VCOM test suite and kind of recreate these tests there because these are the individual issue and verify endpoints. and again we have all these different test suite for integrity proofs data model etc. So here I think we want to focus on the sort of happy path testing here's a VC let's make sure you can issue it and make sure you can exchange it. so this is just wanted to share a bit where my brain is at. I've been starting to scaffold a little something.
Patrick_St-Louis: I want to start by you give an verifier endpoint and maybe a workflow service endpoint and try to probe the API. and then the second phase I would like to look into more testing can you testing two things like can you successfully exchange a verifiable credential and can you successfully exchange a verifiable presentation. And I think these two things would cover most of what we need. And yeah, so I just wanted to share this I added some kind of prompted the AI here to give an analysis of what the challenges could be and a lot of it was very similar to what I was expecting. Meaning a lot of it is kind of the HTTP API, definition.
Patrick_St-Louis: Another reason why VCOM is so interesting I think is the only spec that actually involves different parties communicating with each other as part of a specification. The only other spec I could think of was the traceability API that was being worked at that went through a cycle. other than that most spec they talk about how one implementation should implement things so I think sort of interrupt per implementation will fit very well here so yeah there's a lot of text at the end I can share this if you want but I just wanted a little summary of really to put the spec in perspective of a test suite and maybe the implementation challenge that people can have so this is not like to
Patrick_St-Louis: give a score to the test suite is just to maybe highlight from a normative standpoint what's the representation of respect we can clearly see that we have a lot of statements and these example bodies here yeah so that's all I wanted to show probably in the next few weeks I could maybe show if I get some sort of testing done on the issuance endpoint
Patrick_St-Louis: and take the discussion from there. yeah, that's all I wanted to show. Thank you very much.
Kayode_Ezike: This is awesome.
Kayode_Ezike: Could you share the link before we forget so that we can celebrate?
Patrick_St-Louis: It's just an HTML file, I can just share the file. It's a standalone HTML sort of report type file. I could probably share this on Slack. I don't think or I could maybe just host it at the GitHub page somewhere and share this link.
Kayode_Ezike: Problem. Thanks.
Manu_Sporny: Yeah, plus one. This is awesome work, Patrick. Thank you so much for doing it. yep. plus one, I think it's very much aligned with what we were thinking. I think as you kind of move forward on kind of the implementation and everything, it would be wonderful if you could see if you could align with the other test suites. I think you mentioned that, in there somewhere, but Benjamin's put a lot of work into KIVVC and ensuring that, the output is, compatible and we can run regular tests on endpoints and all that kind of stuff. So, that's item one. And then item two is, we're happy to put up some endpoints that you can test against, meaning digital bazaar's implementation. I think we implement almost all of what's in the spec.
Manu_Sporny: And so we're happy to be a guinea pig when it comes to the test infrastructure that you're writing.
Patrick_St-Louis: yeah so I was looking at that so the first thing I want to keep the same is how people submit an implementation right so we have this implementation configuration file we'll probably just want to add a workflow service endpoint something like this keep the current verifier issuers just add workflows maybe status if you want to go there but I think workflow is really the important one here. the second thing is obviously it's going to use the reporter right the reporter that we had this test suite is going to be modeled after there is a significant difference in that we want to test the open API thing so probably the test suite will be kind of split into two I don't think we want to show 418 individual statements that people conform to we will probably bundle all the HTTP one as the one
Patrick_St-Louis: thing that's being tested and it's going to be reported and then show individual statements for the 60 or something that are left like we normally do with the other one. I'll have question I think it's a bit early for these questions but to conduct the workflow most probably the client will play the holder or maybe we can and then for interup we can just have two instance exchanging with each other although I'm not sure how that would look like from the holder perspective but we can because I know for some of the other tests with the BB
Patrick_St-Louis: Yes, there was some holder endpoints provided for the selective disclosure sort of derived proof. so maybe we can explore this a little bit this was definitely a limiting factor in some of the spec meaning we didn't require holder endpoints from people. So it was very difficult to test their derive operation or their presentation proof for specifically selective disclosure. It works really well for non- selective disclosure point because it's very simple but for some of the specific test in the workflows normative statements like the sort of behavior that holders should have this would probably require a bit more discussion in the meantime but as I mentioned we can definitely get started with the API stuff plug this in with the current reporter and I'm sure there's some of the endpoints already in the configuration
Patrick_St-Louis: file that people could just add the VCOM tag and it would kind of run this little bit. So that's where I would start and I can kind of reach out to Ben to make sure we are aligned on making this basically I just want this to appear can C in a very seamless way. so just need to address the little challenge that this spec has a lot of statements right it's quite different than the other ones…
Patrick_St-Louis: but I think we can tackle this and shouldn't be too hard to deal with
Kayode_Ezike: Thanks. Thanks a lot,…
Kayode_Ezike: Patrick. I feel similar to what I said to you and Eric, anything you need from us, let us know. Maybe if there's a repo you're creating that could receive issues, things of that sort, that' be useful as well. But thanks, thanks for getting this work started. we are at time. We don't have time to process any issues or PRs today. It's okay. We feel that time for other useful things. So, thank you all for contributing to this call today and I will see you next week.
Joe Andrieu: Thanks, Krie.
Call Ending Issues
Kayode_Ezike: Hey, Brent, are you still there?
Nate_Otto: Yeah, for no reason. Sorry.
Kayode_Ezike: No. I was just asking the question.
Kayode_Ezike: going to ask other year Brent there was this issue where I tried to end the call for everyone but it says that unless I stop recording and transcription first which I haven't seen before. So wondering if any of y'all had ide
Nate_Otto: Good luck with that. I've never encountered that specifically, but I'll go ahead and leave, so hopefully I'm not in All right. Cheers. Meeting ended after 01:01:59 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.