Meeting minutes
Introduction Of New Attendees
Kayode_Ezike's_Presentation: Let's see.
Kayode_Ezike's_Presentation: Everyone just one more minute before we get started here.
Kayode_Ezike's_Presentation: Right, I think we can get started now. Hello and welcome everyone. Today is August 25th, 2026. and this is the weekly verifiable credentials API for life cycle management task force call. My name is Ka Zik and I'll be leading us through our discussion today. before we dive into the topics, just wanted to remind everyone that this is a call that is governed by W3C IPR protections and contribution protections. So keep in mind that these calls are transcribed and recorded. yeah, that's about it.
Kayode_Ezike's_Presentation: And before we get started, any introductions or reintroductions from think anybody here? And if not, are there any community announcements that this group should be made aware of? And if not, are there any topics that folks would like to add to the agenda that's not currently listed on the screen here? Go ahead.
W3C Threat Model Publishing
Manu_Sporny: Just a real quick note about something that we're going to try and do with the threat models to make them publishing compatible with W3C.
Kayode_Ezike's_Presentation: Is that any chance later to the MP PR open up today or…
Manu_Sporny: Just five minutes on that at some point at your discretion. Coyote don't know.
Kayode_Ezike's_Presentation: is that different the one you approved earlier today for inlining the threat model or…
Kayode_Ezike's_Presentation: something else.
Manu_Sporny: I think it might be something else.
Manu_Sporny: I can't remember.
Interaction URI Schemes Registration
Kayode_Ezike's_Presentation: Okay, no worries. yeah. So, we can get to that soon. that's going to be one of the first PRs we review anyway, so we can discuss it at that point. great. I wanted to start by giving a quick update on just tying the knot on the interaction URI schemes that we've been working on.
Kayode_Ezike's_Presentation: So the news is that we've officially gotten these registered with Ayanna. So as you see my screen this is the registry for item for interaction scheme. This is the one for web plus interaction and you can find both of them in the URI registry by just searching for interaction here. so we have provisional URI scheme registrations for both of these you can see here. So we're all set to start using this in VCOM and as well as for any other sort of vertical that could make use of having this way of retrieving protocols and engaging in incredial interactions. I heard a few pings in the chat. Was that a hand raise?
Kayode_Ezike's_Presentation: Okay, go ahead, man.
Manu_Sporny: Plus one of this great job Coyote kind of prosecuting that through the whole system. I think it went very smoothly. thank you for doing that. we got a provisional registration which is great. we will want to turn it into a permanent registration in the future and I think the timing for that is around the time we publish VCOM as a 1.1.0 is official global standard.
Manu_Sporny: So just noting that as something we'll want to do but much later multiple months from now.
Kayode_Ezike's_Presentation: Good point.
Kayode_Ezike's_Presentation: Yeah, actually I was wondering about that because I noticed that some of the mature ones, for example, even the data one I think is still provisional if I'm not mistaken. So I wonder what the what's the process or the differences materially for that? Go ahead. Okay.
Manu_Sporny: We just forgot to make it permanent. That's the only reason. Manu Sporny:
Kayode_Ezike's_Presentation: All right.
Horizontal Review And Threat Models
Kayode_Ezike's_Presentation: So, we'll work towards that bit later. But yeah, thanks for the support with that registration as so, the next thing I want to do is give a quick update on horizontal review. last week it reported that we had done the internationalization and accessibility reviews. I had the goal of getting through the privacy and security and tag ones this week. but got held up by a PR that was essentially preparing our spec for the newer design where we're kind of jettisoning the privacy and security consideration sections in favor of a new sort of approach that W3C is championing for it specs to use unified threat model instead.
Kayode_Ezike's_Presentation: And so we already have the, third model. Thanks to Joe and Eric, maybe I had a link to that from the spec, which I put in a PR for last week. But we also wanted to inline those threats. And I'll show you what I mean by that if possible. But basically, not just link to them to the external doc, but also enumerate those threats inside the main spec document. So there's a PR that I put up for that you can get into soon. And then when we get to the issue part of this call, I wanted to take a look at this ZCAP issue that I've raised that got some attention today from Bango.
Kayode_Ezike's_Presentation: Essentially the idea is we had mentioned or basically we put together the set of allowed actions and targets that we need for VCOM sort of just to be at par with the OOTH section which laid out all the scopes that we need for VCOM but it looks like there might be some disagreement about the way we did it and so I think it's worth discussing especially now that Zcap is taking off in the capabilities working group. So, sorry, work item. So, we'll get to that when we get to the issue part of the agenda. Any questions before we di If not, we will dive into PRs here. Okay.
Kayode_Ezike's_Presentation: So, why don't we get straight to the one cuz this also made me mon relates maybe what you were talking about. There's another one that was added too. Anyways, we'll get to this one first. So, is there a question? Is that Mon Patrick?
Kayode_Ezike's_Presentation: Go ahead, Patrick. You didn't miss that.
Patrick_St-Louis: I saw an issue about ZCAP.
Patrick_St-Louis: Did I miss that?
Kayode_Ezike's_Presentation: basically it's an issue where I was asking that we make it be clear about who gets to define the space of the range of values that is in one second that's in the allowed actions field as well as the caveat that type fields and I just brought it up because there's not a lot of
Kayode_Ezike's_Presentation: explanatory text around it in the Zcap spec. And the only reason why I put it to VCOM is because we had just done a similar exercise with the off Zcap section of VCOM where we defined a set of allowed actions. And so as I was creating that issue, I linked to the VCOM and what we're doing there and then that led to the discussion there. Yeah. So it could be worth discussing that.
Patrick_St-Louis: Okay.
Patrick_St-Louis: Thank you.
PR: Inlining Threats And Tags
Kayode_Ezike's_Presentation: So yes, Joe, really quickly. yes, thank you ve. So we're discussing this issue. So this PR essentially is just lining up or inlining all of the different threats that we define in threat model. As I was doing this, I also noticed a few issues that needed to be cleaned up. So I just decided to do that. There's a few things that are broken here and there as far as response formats and anchor tags, things of that sort. So I took care of that.
Kayode_Ezike's_Presentation: And there was also some things around the actual classification of some of the targets as well the threats as well. So wasn't too many of those but there were some things that didn't seem to line up from my understanding. So the main changes here are the inlining of those threats and also I should mention that there these new security privacy tags. and some other tags as well, but those are the main two that have been added to other specs recognized entities and VC barcodes essentially tagging each of the threats with basically the area that it targets or that it's a concerns and so I think it was done as a way to basically more make more ironclad the claim that we don't need privacy and security considerations is like yes even though
Kayode_Ezike's_Presentation: we're removing these sections. We still have these tags to make it clear that this is the area that it targets. And so basically for all the threats I added tags that are relevant for those threats. and so won't go through all these, but some of them touch security, some of them touch privacy, some of them touch both. And so that's essentially another big part of this PR. So I can leave time for folks to review. There's a few approvals so maybe a few more days. it is kind of a dependency for a security and privacy horizontal review self questionnaire and so it' be nice to get this in with the next few days but I wanted to at least present it here for folks to have a high level view of it any questions comments concerns about this Eric go ahead
Kayode_Ezike's_Presentation: Oops. Amen.
Eric_Schuh: Yeah, I mean most of the edits I think look fine and thank you for taking a second pass at all the tags and all of that because I think for the most part that had just been my input so it's great to have someone else put their opinions So happy with all of that. I think my only concern is I have just submitted I thought I'd done it about a half hour ago, but I had another that is effectively the work to transform the existing privacy and security considerations into threats and remove those sections. So the inlining was great.
Eric_Schuh: I think it was just a little bit out of order from what I had planned in that I just added about another 11 threatsish.
Eric_Schuh: So there's some tension there in terms of,…
Kayode_Ezike's_Presentation: …
Eric_Schuh: what you did here I think is fine and looks good. but then we'll need to merge it with the PR I just submitted. in terms of adding or transforming the existing privacy and security consideration sections into threats themselves.
Kayode_Ezike's_Presentation: So the one thing I'll say that's great about that news it's not as bad as you think is so this is important to do that I have here essentially is that we have so I didn't remove that section from the existing privacy and…
Eric_Schuh: Yep. Yeah,…
Kayode_Ezike's_Presentation: security consideration sections because there was some useful stuff there that I didn't want to get rid of so I had this question of okay what do we do with those sections and it sounds to me like what you've done is that work to turn those into threats and so
Kayode_Ezike's_Presentation: I think it could actually work pretty well. I haven't got a chance to look at that PR yet, but maybe what we can do is Right. Eric Schuh:
Eric_Schuh: I don't expect anyone Yeah,…
Kayode_Ezike's_Presentation: But maybe what we can do is maybe offline we can try to reconcile the differences between these and figure out the right sequencing of getting it in. But that's good news because wasn't sure what to do with that.
Eric_Schuh: I think Dave's suggestion mostly should work. it might need a little bit of massaging in terms of the inline threat model section and some additions. but I think maybe the cleanest path for forward coyote would be to get this PR in.
Eric_Schuh: Because I don't think much of what I touched in the subsequent should change what you did here. we could talk offline and figure out the best way to merge these two if you want.
Kayode_Ezike's_Presentation: Okay, sounds good.
Kayode_Ezike's_Presentation: Yeah, I won't put you offline. Thanks, go ahead, Joe.
Joe Andrieu: Yeah. it looks like what you've done in line is a little bit the opposite of what respspec threats what's trying to do. So, I would like to encourage figuring out…
Joe Andrieu: how to dynamically generate those instead of hard coding as HTML from the data objects that we have. and that will probably need an adjustment to the library, but otherwise we're going to have issues of keeping your inline stuff in sync with the data files.
Kayode_Ezike's_Presentation: Yeah, I mean I will say that as I was doing it,…
Kayode_Ezike's_Presentation: I felt a little nasty doing it because it felt like there's a better way to do it. I was following the same pattern that I recognized entities MVC barcodes was doing. so there just that consistency but if there's a better way to do this dynamically at the very least in the steady state of this I'd like to adopt that. go ahead.
Manu_Sporny: Yeah, it also Joe follows what I've been doing in the other specs with threat models. I tried to use respspec threats to autogenerate the table and I hit issues with that approach. one of the issues was that just generating a table of threats doesn't help the reader understand just a real quick one-s sentence description of what that threat is and whether or not I want to click through on it. the previous table code is just like it just puts the name of the threat and sometimes you need a little bit more than the name of the threat to go through to it. So that was issue one.
Manu_Sporny: The second issue was that I have needed to in other specifications point to different threat models to note that there are certain threats that are in scope specifically around dependency threats sometimes it is useful to point to a variety of different threat models and respspec threats doesn't let you do that nor does it provide an easy way to make that happen. So those two reasons I'm fine if we can update the library to support those things but that's the reason at least I had to fall back to a much more manual way of doing this.
Manu_Sporny: I do agree that keeping them synced is a challenge. I think issue number three is n numbering these threats is not working out both in the anchors and the numbers because they end up getting renumbered and that is something that went through respspec itself used to number sections in the anchor tags and we removed it because it was leading to breaking inter spec links. So I think there are a number of issues Joe that we need to work through to get this right with respect threats.
Manu_Sporny: But just wanted to say what those challenges were out loud and why it's being done in the way it is just now, which is hopefully temporary. That's it.
Kayode_Ezike's_Presentation: Thank you,…
Kayode_Ezike's_Presentation: Go ahead, Joe.
Joe Andrieu: Great. So,…
Joe Andrieu: I'd love to get those issues into respect threats because we can address them over there. the one sentence description the approach I would take to that is add another function that is expanded talk or some other name that's just some version of the current render talk that in includes a description because in fact every thread has a coherent short description and that should address your need and then it would be integrated with the data also you can put a tag in any of your descriptions and it will render so I'm not
Joe Andrieu: sure why you thought you couldn't point to different threat models, you could. It's pretty trivial to do that. You just put in the tag in your JSON and…
Kayode_Ezike's_Presentation: All right.
Joe Andrieu: RSpec will deal with it properly.
Kayode_Ezike's_Presentation: So, go ahead, min
Manu_Sporny: I didn't understand the last point, plus one to adding it to respec …
Manu_Sporny: and moving some of this stuff into the definitions like the one sentence description. I didn't understand your last thing on how to reference.
Joe Andrieu: you use a link like a href equals destination of link the title you want to use for that link…
Joe Andrieu: if you put that in your JSON description you will have a link Right.
Manu_Sporny: I'm still not following. I'm trying. in the JSON description. So, you mean in the JavaScript file if you put
Joe Andrieu: That's in the JavaScript swizzle that is the data file that is the heart of respec threats which I think you've converted to YAML but I don't want to get into that right now. But if you put a link in your description field,…
Kayode_Ezike's_Presentation: Go ahead, man.
Joe Andrieu: it will render as a link.
Manu_Sporny: Yeah, I don't know…
Manu_Sporny: if this is the place to kind of discuss this at length.
Manu_Sporny: I don't So are we having a dis discussion about respect threats now or are we I don't Yeah.
Joe Andrieu: I'm just telling …
Joe Andrieu: so it is straightforward to do. We can take it offline if you don't want to talk about it now, but literally just put a close that element.
Manu_Sporny: Yeah. Yeah,…
Joe Andrieu: So, you have a tag and put the link if it's defined in your file and closing and respspec will turn that into a properly formatted reference.
Manu_Sporny: I think we're miscommunicating on the requirement.
Manu_Sporny: So, let's take it offline.
Kayode_Ezike's_Presentation: Yeah,…
Manu_Sporny: I'll try to raise a issue in respect threats. all right. And then we can discuss it
Joe Andrieu: Okay, great.
Kayode_Ezike's_Presentation: I did notice that at least with references to definitions that were made within the threat itself. that seems to be working. It seems like there might be a slightly different nuance there with what M describing. Any event, the question here is we want to do put the work into dynamically generating those before we merge this PR or do we just want to follow that up with the actual dynamic processing? Go ahead.
Manu_Sporny: Yeah, I prefer separate PR because this thing needs to get into horizontal review.
Manu_Sporny: I don't want to block that on respec threats, discussions.
Kayode_Ezike's_Presentation: Okay,…
Kayode_Ezike's_Presentation: so like I said, since I just opened this earlier today, I think it' be fair to at least give a few more days for this. Maybe by Thursday or so start. We can assume that we can merge this in if there's no other comments and we'll move forward with that. Go ahead, Eric.
Eric_Schuh: That sounds good to me. And Coyote, I guess, either this afternoon or maybe tomorrow morning, I'll take a look at my PR and your PR and maybe, just propose, the path forward to handle both of these.
Eric_Schuh: I think it should be pretty straightforward. there's a few files that we change in the same spot. So, we just have to decide which we want to go with.
Kayode_Ezike's_Presentation: Mhm. Got you.
PR: Transforming Privacy Security Sections
Kayode_Ezike's_Presentation: Okay, that makes a little sense. And on that note, why don't we then go to your up here really quickly and then we'll get to Manu's greater point around threat model approach with W3C specs.
Kayode_Ezike's_Presentation: Good topic for this first. And feel free to take the floor when you're ready.
Eric_Schuh: Sure.
Eric_Schuh: Didn't mean to do that. yeah. So, as I said, this PR basically, transforms the existing security and privacy consideration sections into threats. so I think I ended up with 11 new threats, which you can see, have been sorted here. Coyote, they could probably these 11 use a similar pass as you did to the prior ones on the other PR. might be cleanest to just do that in this PR before we accept these. but I know that I didn't add tags to any of these. so at the very least, if one of us could do that, that might be nice.
Eric_Schuh: Otherwise the only other thing that happened was I removed the existing privacy and security consideration sections and replaced them with the unindexed stubs following the pattern that Monu had been using. and then there were a couple of the security consideration sections that didn't seem to have threats that directly applied to this specification.
Eric_Schuh: So those couple of sections have been moved to an appendix of the threat model rather than in the main document. that's it.
Kayode_Ezike's_Presentation: Got you.
Kayode_Ezike's_Presentation: Okay, great. Thank you very much, Go ahead, whoever that was. Sorry. I'm on you. Good.
Manu_Sporny: This is great, Thank plus one for doing a couple of questions. how confident are you that we captured what the existing privacy and security consideration sections were saying? I know that I struggled quite a bit with feeling like whether or not the right things were captured with the VC data model when I did this conversion. So that's one. question two is you did move a plus one the no talked security and privacy consideration sections. it will generate anchors so that you can point to those sections and then those sections point back to the threat model and then from the threat model you can go and read about it.
Manu_Sporny: You do also have a new appendix called security considerations that has the secure coding practices and then the other security considerations bits in there. I think that'll generate a double anchor. I'm plus one we need to talk about stuff like that. I guess I'm wondering one should we call it security considerations might not be and then I mean sort of is and then two I'm wondering why this doesn't fit in the threat model although I have other specs where I'm struggling with the same thing where I'm like I don't think this guidance really belongs in the threat model and so for those things how are we expressing them in the spec having two sections called security considerations
Manu_Sporny: is probably not what we want to do. So, I'm wondering what other considerations or I don't know…
Manu_Sporny: what to call it, just two questions there. plus one in general to the PR.
Kayode_Ezike's_Presentation: Come on.
Eric_Schuh: Sorry.
Kayode_Ezike's_Presentation: Go ahead.
Eric_Schuh: Yeah. So, I would say for all of these sections that were in the privacy and security considerations that aren't the two that are left in that appendix, I think I was able to capture I don't know, it's hard to put, percentage, but 80 to 90% of what was trying to be said. I will say that there was a very clear change in form in the way that the information was presented. and I think if I were to call it out, I think the old B3 deletion under security considerations I think was the one I struggled the most with.
Eric_Schuh: It had some interesting regulatory threats that were effectively being discussed in the difference between why you would partially rs completely delete a record. but for most the rest of them I think they were transformed fairly easy to the point that many of them used the existing text just in different formats. Right? Some of the text became a description and other text became responses. to the threat that was being indexed. so it was definitely work and some of them were harder than others. the two that were left out I left out because when I was trying to transform them into threats, I think that's a doable problem, but I was having a hard time identifying which components those threats might apply to in this specification.
Kayode_Ezike's_Presentation: Press.
Eric_Schuh: So, it's like they are absolutely threats, but they felt like threats that weren't directly applicable to this application, but were more general. and of course, I'm open to renaming that security consideration sections. I didn't put much thought into that, just copied the name over. so if those types of recommendations want to still be kept around, whatever name the group decides on, I would be fine with or, I could think about it some more and come up with something myself either way. but I do think that kind of bigger picture.
Eric_Schuh: There's probably a set of recommendations that many specifications want to make and it's probably more of a broader question for the W3C of…
Kayode_Ezike's_Presentation: Perfect. Wait,…
Eric_Schuh: how do you want to link to those more common threats or recommendations that you want to highlight for the specification but don't necessarily apply directly to a component in the data flow diagram created for the threat model for this specification. so yeah, I guess that's where I'll leave it.
Kayode_Ezike's_Presentation: go ahead. Morning.
Manu_Sporny: Plus one to all that Eric that is very much the same kind of thought process that I struggled through in trying to convert thing things that used to be in the old security and privacy consideration section into threats. it felt like it was losing a bit of what we were trying to say the security and the old security and privacy consideration section were much more pros in the way that they discussed a particular thing and the responses to it. both good and bad, the new threat model thing is a little more tur and structured. which again I think more good than bad there.
Kayode_Ezike's_Presentation: Oops.
Manu_Sporny: Plus one to that. what you said resonated quite a bit. For the second question which was we have this new appendix and it's called security considerations. I just took a read through it and it feels like we can get rid of the appendix and put the content elsewhere in the specification. So for example where we talk about other security considerations where we're basically like hey you should go and you should look at the threat model for the VC data model and you should go and look at the threat model for data integrity and those things apply as well right so go and read those things that chunk of text could go up into the actual section that threat model and it could be kind of a preface to it where we were hey by the way this exists
Publishing Threat Models To W3C
Manu_Sporny: this in an ecosystem, go read about the other threat models. you should be aware of those before kind of reading about these ones. so that's one thought there and where we could move this other security considerations thing And then, for the secure coding best practices, it feels like we may want to put this in the conformance section because that's where we talk about what implementers must do. and we should probably say something about it is one thing to conform to this specification and implement it. It's another thing to do it securely and you really should think about security and the OASP secure coding practices and…
Manu_Sporny: web security testing guides and things like that when you're putting your implementation together. and then I added these as comments to the PR. that's
Kayode_Ezike's_Presentation: Yeah, I totally agree with that.
Kayode_Ezike's_Presentation: I think maybe one wrinkle to the first or maybe second thing you said about linking to other threat models is if for example there's a dependency spec like the VC data model which I believe doesn't currently have one that could be a challenge…
Kayode_Ezike's_Presentation: but as far as at least the ones that we're not adding thread models to I can see that working. go ahead Joe and then Manu
Joe Andrieu: Yeah,…
Joe Andrieu: I think what is being talked about here in terms of dependency threats, it's meant to be addressable by listing these as dependency threats as a category of type of threats and you point to the resource which you can go to learn more. It may be that hey we're dependent on TLS this is something that the did resolution threats are going to have to reference as a dependency threat because we're securing our endpoint with TLS. And if there's a threat model you can point to that threat model. If all we have is the TLS spec that's being used, we can point to that. but that was a design goal of that category of threats. and it should be able to address all the use cases that you've been talking about. but I wanted to push back maybe more of a gentle nudge, Manu.
Joe Andrieu: I don't think there's any useful guidance from telling people it's legitimate to implement this insecurely. I think we need to up our game and say look, in order for the web to be secure, your implementation should be secure. These are the things you need to pay extra attention because if you don't, then your implementation will be insecure.
Joe Andrieu: So I think we should be encouraging security at all levels and not suggesting that hey, you can implement this in a way that's not secure and that's okay.
Kayode_Ezike's_Presentation: Thanks, Joe.
Kayode_Ezike's_Presentation: I guess quickly for the dependency threat one. I'm glad you said that. I think some of the ones we currently have under dependency threats don't seem to fit under that characterization. So, we may have to revisit that and be I'll create an issue for that. But, thanks for that context, Joe. Go ahead, Money.
Manu_Sporny: Yeah, on taking Joe your second thing, I didn't mean to comply that we allow say people that they can implement things insecurely. So huge minus one to that. That is not what I was saying is that where is the text I'm looking at right now is line 752. and that says implementers are urged to use industry standard secure coding practices when implementing this specification. I am saying don't bury that in an appendix. Put it up in the conformance section at the front of the spec and tell them that they need to pay attention to that. I think you and I are agreeing Joe that I think we should be very upfront and tell people just because you read this spec doesn't mean that it has everything you need to think about and do when doing an implementation.
Manu_Sporny: here are some other things that you should look at to make sure that you're implementing securely. so that's the first point. on the second one, just going back to how do we call out other threat models, I think we have two use cases here. One of them where we're like, hey, a threat model exists for, an important threat model exists and you should look at that thing holistically, right? I guess we can put it in the dependency threat section, but it feels like too much of a footnote. I'd rather it be said kind of upfront as a general you should be very aware of these other threat models because we kind of build on top of them for the dependency threat stuff.
Manu_Sporny: So use case one is broadly you really should go and look at this threat Coyote, both the ones listed here, both VC data model and data integrity both have threat models. So, we're pointing to the wrong thing with the links here. So, Eric, heads up, we have threat models for both of those things. They're published and out there. We should be pointing to those things. as far as the dependency threat section, Joe, I was hoping that we could surgically point out very specific dependency threats that we are concerned about in that section. I realize we can do both, but I don't know how we can do both kind of in a …
Manu_Sporny: so yes, plus one of that. I don't know, Joe, if you're saying take that paragraph of text and move it into the dependency threats section title header underneath there or you're listed out as a T53 and T-54 and T-56 entry. That's a
Kayode_Ezike's_Presentation: Then…
Kayode_Ezike's_Presentation: why don't we ask him then? Go ahead, Joe.
Joe Andrieu: Yeah,…
Joe Andrieu: I think what you just described as the latter option. and so let me echo that back just so we're actually talking to each other instead of guessing. my thought would be that you do identify hey it's T-53 or whatever the number is and for example right in did resolution TLS is going to be a threat and we're going to say there are threats related to the TLS specification which does this stuff for our spec and the point of that is specifically to link to something rather than enumerate everything. because it's not the job of the did resolution spec to enumerate all the threats of TLS like I think that way is too much.
Joe Andrieu: In fact, it's also my push back to your use case number one, which is there are dozens of specifications that people need to read in order to understand any particular one. And I think it's overwhelming to say, hey, in order to understand this spec, go read these other 12 things. I think it's far more useful to say, hey, we depend on this thing. and in the threat considerations whether it's security considerations or the threat model proper to say hey here's a specific threat if you're concerned about people messing with the transit between again I'm going to use resolver because that's where my head's at right now between the client and the resolver then that's secured by TLS you should go look over there and…
Joe Andrieu: I think we need to have a thin slice of what's happening otherwise it becomes difficult who consume it.
Kayode_Ezike's_Presentation: Okay, thank you Joe.
Kayode_Ezike's_Presentation: So yeah, a number of decisions need to be made. Go ahead.
Manu_Sporny: Yeah, I think we're circling around a solution and we don't need to come to it today. there are plus one to what you said, with these modulations, I think there are some specs that you need to pay more attention to than others,…
Joe Andrieu: Heat.
Manu_Sporny: And it's calling those out that I want to make sure we do if you're implementing VCOM you should definitely know about the VC data model, You should like and not in here are three threats you need to think about. It's like you should probably really absorb that spec and the threat model before you start working on VCOM. So there's that kind of guidance which should be obvious, right?
Manu_Sporny: But that kind of call out just a general make sure you read this spec before you read this spec. and then there are other ones where for example there is the M entirely depends on the VC data model to prevent the forgery attacks. It's an external dependency that and in that case we do talk very specifically about it.
Manu_Sporny: it's got a very specific en model threat number in the VC data model threat model and I want to be able to point to that directly and that's what I was using the external threats thing to do that is where we explicitly say hey you really should think about anti-forgery stuff and it is this in this specific threat model that you should take a look at so it's macro point at the general thing you should just be very aware of. I know you have to read tons and tons of specs but some of them are more important than the other ones. Want to point out which ones are more important and…
Kayode_Ezike's_Presentation: Go ahead Joe to give us the final thoughts on this topic. Okay.
Manu_Sporny: then be able to point very specifically in a way that shows up in the index list to a very specific external dependency threat.
Manu_Sporny: That's it.
Joe Andrieu: Yeah.
Joe Andrieu: I forgot to say something that I think we just bumped into again that that might be helpful, which I think it's entirely appropriate to have some pros in a security consideration section that speaks to these highle things. So maybe that's a good place to anchor the kinds of things you're talking about hey VCOM is based on the VC data model and so you should go familiarize yourself with that rather than as part of a set of enumerated threats this introduction to security considerations which is also I think where we should put the language about security best practices. I don't think it goes in conformance because I think you can have a conformant implementation that doesn't necessarily meet those security standards and I think if we wanted conformant language around the security standards we would have to write things into the spec to say what that means literally.
Joe Andrieu: So I would suggest not putting in conformance but I think it's front and center on security considerations like this these are the things that you should go look at and…
Joe Andrieu: understand whether we mention OASP or we have some other I think we don't have to replace the security considerations with a tur list we can have some pros that highlights these high level Thanks.
Kayode_Ezike's_Presentation: Thank you,…
Kayode_Ezike's_Presentation: Yeah, this is I think the nature of the fact that we're migrating to a different sort of format for these considerations. Obviously, it's not a perfect mapping from those sections to threat model, but I do believe that it's going to be a good one for us. We have to figure out these kinks. So, Eric and I will take this feedback into account for our two PRs. we'll try to figure out the best way to incorporate all this feedback. and one other thing I forgot to mention from my last PR is that there were other issues I discovered with the threat model.
Kayode_Ezike's_Presentation: Not too many but some that I discovered that I'll create issues for as well so we can track those. really quickly Manu you mentioned at the top of the call you wanted to talk about the new model for thread model. was it covered from the discussion or…
Kayode_Ezike's_Presentation: is there something else you wanted to say about that? Okay go ahead. Give us a few minutes on that.
Manu_Sporny: No, it's something else entirely.
Manu_Sporny: …
Kayode_Ezike's_Presentation: Okay then.
Manu_Sporny: so, one of the things that we bumped into with the new, threat model, the way we're, putting threat models in subdirectories. is that just to review what we have today. So we have our It's index.html. It's at the top level of the repository. We publish that with GitHub actions. It goes out to GitHub pages so that every commit that we make goes live. And we've got kind of like a live editor's draft of that.
Manu_Sporny: And when we also do that, the working groups can configure themselves to also publish to the technical report space in W3C so that you have date stamped snapshots of every specification that you want the public to see. It used to be that W3C would only snapshot a spec once every 3 months or once every six months and that was not good. we then set up this tool called Akidna and Akidna will automatically publish any commit domain as a new snapshot for that day. and then that means
Manu_Sporny: means that the public gets to see much more recent updates and they get to see the spec as it goes through the publication process and there's this paper trail that is created on what we put in the spec and on what dates and that can also be used for IPR and patent protection and a variety of different things like that. so when that process happens and you push it to Akidna, we have a whole bunch of specification production tooling at W3C that kicks in and creates static copies and date stamps and changes the thing to a working draft and moves it into a CVS. I think it's powered by GitHub now finally. and there's a huge backend system that does its thing and we create a static snapshot.
Manu_Sporny: In the late 2000s, early 20110s, W3C had the capability to do multi-chapter specifications and, that was, in there. I just found this past weekend that they removed that functionality in 20, I don't know, 2018 or whatever. So I was thinking that we would be able to easily publish multi- document specifications. That is not the case. Respec only works on a single file. and they've been waiting to add the multi- document feature. So what does that mean for us?
Manu_Sporny: It means that we need to add a multi-chapter publication, feature to respspec so that we can publish the index.html files in the thread model directory. we have a solution for this. we just need to implement it. and when we do that, we'll just need another GitHub action step to do that. So what that means is that when the specification and the threat model is published on a date stamped currently right now what's happening is the spec is published at a date stamp URL and…
Manu_Sporny: the threat model is published as a dynamic respspec document and that's the thing that we need to fix. so that's what we're working on. I just wanted to make sure that everyone was aware of this. in the meantime, it doesn't really affect anything we're doing, but we have to, solve this problem before we get to wreck. That's it.
Kayode_Ezike's_Presentation: And just so I'm clear,…
Kayode_Ezike's_Presentation: this is an issue, a solution that will be implemented in the respect OS repo, not the VCOM one.
Manu_Sporny: No, this is an issue that has to be fixed at their tooling level. The tooling doesn't work.
Kayode_Ezike's_Presentation: Okay. Okay. …
Kayode_Ezike's_Presentation: I wanted to track it somewhere. I'm not sure if I should create an issue here maybe it's just Yeah.
Manu_Sporny: Abon's got it in his head.
Manu_Sporny: I've gotten his head in my head. The knee is working on it.
Kayode_Ezike's_Presentation: Okay.
Kayode_Ezike's_Presentation: Great. go ahead, John.
Joe Andrieu: Yeah,…
Joe Andrieu: I've been following some of this conversation about email and I'll put some of my thoughts into that thread. but why don't we just use separate repos? because we have the tooling that works for that and where we do need tooling is something like in my opinion PR preview is more important to get fixed than figure out how to have multi-page specs. and perhaps more long-term the expectation that I have and I think Simone has is that these threat models really deserve to become registries so they can be maintained independent of the working group.
Joe Andrieu: And having that be distinctly separate from the specification I think is valuable. it like updating the registry with new threats or whatever isn't going to change any normative language in the spec. So it feels like they are separate domains of authority.
Kayode_Ezike's_Presentation: Go ahead, Mon.
Joe Andrieu: So maybe we could avoid the retooling on that and just use separate repos.
Manu_Sporny: We so just to be clear, the PRP preview thing is a totally separate topic, Joe. We figured out what was going wrong there and it had nothing to do with what I'm talking about right now. So, those are separable problems. We understand kind of what's happening with preview. the challenge with multiple repositories is that Avon is of the opinion that if we do that then W3C process kicks in. So, we need to now figure out what that thing is being published and we may need to go through official W3C process publication steps to even publish it as an editor's draft or a note, meaning that it would not show up on TR space at all.
Manu_Sporny: And then that calls in the question whether or not this threat model is something that the working group has agreed to approved of that sort of thing. The lightest process that we can think of at W3C would require us to put in to run it through the entire painful W3C process. Which means that we would effectively add, I don't know, eight new specifications to VCWG's workload, including the editor's workload and the staff workload. And that just felt like an enormous amount of work for us to do. versus put in 10 lines of code and solve this across the board for everything, that's the thing that we're trying to do now. I think the thing that you're talking about, Joe, is a much larger discussion. aspects of it are a much larger discussion and we're trying to and
Manu_Sporny: We're trying to reduce the workload just so that we can get to something that, we can move forward rather than getting mired up in W3C process pain. Hopefully that was helpful. I'm sure it's not a great answer for everything, but only so many hours in the day and we're already completely overworked. So adding yet another thing that we have to maintain and…
Manu_Sporny: deal with and W3C process around just does not feel I would not look forward to that path. that's
Kayode_Ezike's_Presentation: Yeah, neither would I.
Kayode_Ezike's_Presentation: So thanks for that update, I trust that you and Ivon will keep us posted as that's developing and we will integrated as it's ready. there were some PRs here that I wanted to get to. They're really small and dimminitive, but I wanted to get through an issue instead just since I wanted to do it while Demetri was on the call cuz I think it would be great to have his input on that. But go ahead, Mon.
Manu_Sporny: Yeah, plus one. just to make sure, Joe, I wasn't dismissing your concerns or what you want to do in the future. I plus one to all of that stuff, but in the meantime, we need to publish these things in a way that…
Kayode_Ezike's_Presentation: Gosh, thanks.
Manu_Sporny: because W3C is basically like you can't publish it in the way that you're doing it right now. you need to create a static copy and that's the minimum bar they're trying to hit.
Kayode_Ezike's_Presentation: Go ahead, John.
Joe Andrieu: We do have a way to do it, which is why I'm confused the notion that we need some work so that we can publish registries. I have a threat model that's in TR space right now and all that process was approved and it's all working. So, it feels weird that we're adding this extra workound when we have something that works today without changes in process.
Joe Andrieu: So I'll unpack that in the email and we can take it offline from this call.
Kayode_Ezike's_Presentation: Thanks and…
Kayode_Ezike's_Presentation: Really quickly in the time we have left, I'm going to for some of these PRs, they're really tiny. I think I'll just merge these in offline. This is just like a wrong link, for example. And then Eric had a great PR for the new version of respect OS that fixes some issues. I had a small comment there, but we can discuss that offline. I wanted to in the time we have left get through at least one issue here. I'll topic it in a second if you will let me. Okay.
ZCAP Allowed Actions And Caveats
Kayode_Ezike's_Presentation: All right. So, this issue is an issue I created last week. the idea is that currently in the ZCAP spec which has been getting a lot more traction lately there's the need for more explanation as to how or what the range of acceptable values is for allowed action and caveat that type. and for the case of caveat not just a type but also the other fields in that caveat object. this came up just because I was thinking about a little bit and it relates to something that we did in VCOM where we actually needed to specify the set of allowed actions because without guidance from the spec there's no way for you to know what those are.
Kayode_Ezike's_Presentation: Kind it came from a discussion I had with Demetri offline some months ago as we were discussing this and the need to specify this further. and because of the fact that if ZCAP covered all the different possible actions for example then I think that might be untenable and unscalable. Beno had his own disagreements with that, but I wanted to put it out to the group as to what do we think is the best way for now that we're, planning to put this out for horizontal review and it's happening really in parallel with the rapid iteration on ZCAP spec. I thought it could be good to kind of align on this sooner than later. So, any thoughts on this?
Kayode_Ezike's_Presentation: I think what Bango was saying is that he's a little uncomfortable with the fact that there's no name spacing for it. I think he's looking maybe for something like a vocab or something. I had to better understand this, but any gut reactions about the way that we are currently doing it and if we should adopt another approach that's different from this. and…
Kayode_Ezike's_Presentation: I think also …
Dave Longley: I've got my hand up,…
Dave Longley: but you probably can't see it.
Kayode_Ezike's_Presentation: I didn't see that. Go ahead, Dave.
Dave Longley: I think what we're doing is fine. I think that authorization is a two-party model and that whenever you're invoking a Zcap, it's like calling a function pointer. You need to know what you're doing, exactly what it is, and then it's targeted at where it is. you're invoking the ZCAP. And I think some of the confusion or questions that are coming up over on the Zcap spec are coming from something that was put in the ZCAP spec and never implemented by anyone which was the caveat and caveat extension section. which I don't think that's actually really implementable. and I think the problem over there is that was never really going to work. and I don't think you can sensibly extend anything in the way that is happening over there. because you can't be given some extension that you don't fully
Dave Longley: understand and then use in some way that the verifier also fully understands the model is just not set up to work with expressing information for parties who don't know it know what it is and then have it be self-describing. I think that model over there copied verifiable credentials where that sort of thing makes sense where you can be a digital wallet and hold a credential that an issuer gave you and then present that information to a verifier and that's a three-party model where that sort of thing can make sense and I don't think it makes sense for the authorization model and I think the confusion and questions are coming from something that nobody ever implemented.
Dave Longley: when we dive or dig into it, we might find that that idea just wasn't going to work. which means that what we're doing here, works just fine. and so any one of these names or allowed actions you put into a Zcap is already scoped to exactly the invocation target for which you were invoking your Zcap anyway.
Dave Longley: So there is already name spacing in that sense or scoping in that sense. it could not possibly be used somewhere else.
Kayode_Ezike's_Presentation: Got you.
Kayode_Ezike's_Presentation: And so just to make sure I capture your sentiment entirely, you don't think that there's a need to exhaustively or even give default action allowed actions in the core Zcap spec and that it's really just the profiling specs and applications that are responsible for doing that VCOM for example.
Dave Longley: I don't think there's any problem with offering people recipes for good ideas that they might want to reuse in their API. maybe you want to use read and…
Dave Longley: write actions, but the point is those things are always going to be scoped at the invocation target. It's never that you're going to create that in the absence of knowing what the invocation target is and then pass that data around like a three-part model. That won't work.
Kayode_Ezike's_Presentation: Mhm. Okay.
Kayode_Ezike's_Presentation: Last thing I'll ask you before I jump ahead. do you mind commenting what you just said in the ZCAP issue here that's linked here just so that we can get that discussion going.
Dave Longley: Yeah, I plan on getting to that eventually.
Kayode_Ezike's_Presentation: Awesome. Thank you.
Kayode_Ezike's_Presentation: I saw Mon your hand was up fleetingly. Was that still there or…
Manu_Sporny: Yeah, we're out of time,…
Kayode_Ezike's_Presentation: Yeah, it's fine.
Manu_Sporny: but heads up, if we would have subtopic it would have automatically showed up in the minutes when the call ended.
Kayode_Ezike's_Presentation: Yeah, I topicked it. I don't think I subtopicked it though.
Manu_Sporny: No.
Kayode_Ezike's_Presentation: Okay.
Manu_Sporny: Yeah, if you topicked it. Perfect. Nope, that's good. Nobody has to do anything.
Kayode_Ezike's_Presentation: Okay, awesome. Manu Sporny:
Manu_Sporny: It's going to show up in that issue. of onrod's script.
Kayode_Ezike's_Presentation: Thank you, On that note, I'll let you all go. Thanks for a great meeting today and we'll see you next week. Cheers. Meeting ended after 00:59:59 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.