Meeting minutes
Meeting Welcome And Agenda
Wesley_Smith: Morning folks. I'm going to give it a couple more minutes for people to trickle
Wesley_Smith: All right, folks. good morning everyone. welcome to the August 4th meeting of the VC barcodes data integrity and forgery defense task force. this meeting is being recorded and transcribed. If you're not comfortable with that, please let me know. The agenda for today is much the same as other weeks. We will go through process, announcement, and introduction items. Then we will spend some time talking about the BC barcodes work, the data integrity work, and the forgery defense work as needed. Craig Bernstein may or may not be able to make
Wesley_Smith: so I can give a brief update for data integrity in his place if he does anybody have any changes to the agenda they'd like to make or any process announcement or introduction items? Manu, go ahead.
Manu_Sporny: I've got some updates on the forgery defense and VC threat model work. so I've got a basic threat model created for the VC data model which we are going to depend on for the forgery defense and the bitstring status list threat model entries. so I'd want to spend a bit of time covering that. and then talk a bit about data integrity threat model additions as well.
Wesley_Smith: All that sounds good. We can go ahead and get into that first item now if you'd like. Manu, actually, does anybody else have any announcement, introduction, or process items they'd like to discuss today? All right, Monty, you can go ahead and get into your first item.
Threat Modeling Symbology And Process
Manu_Sporny: Sure thing. Sorry, I'm still bringing these documents up. Let me make sure I got them. recognized entities. Come on. model and let me share my screen okay so some updates Simony has taken a look at some of these threat models just to set some background the whole reason we're doing these threat models
Manu_Sporny: is that we can't go to candidate direct without doing them. we're trying to get some basic versions of the threat models done so that we can request horizontal review. it turns out that some of our specs we haven't figured out how to do threat modeling completely across the family of specifications. So, there's a bit of churn and work that's going into trying to get things operating correctly. I have got numerous suggestions on for example how the DFD should work. it's all conflicting advice. I am trying to do my best to pull those things together but I think the threat modeling community needs to figure out what they want. So, I've gotten some fairly vague advice on
Manu_Sporny: use the DFD symbology which is what nobody is doing across any of the threat models that I can tell. this is the closest I can get to it. I'm going to keep following this model until somebody tells us that we can't. entities are in blue flows have an arrow yeah in yellow and have an arrow. Processes are in green, storage is in red, objects are in whatever color this is, magenta-ish something. and the flows are kind of depicted so. I think this is the best I can do based on everybody's input. some of which is conflicting. so I'm going to do this treatment to every single one of the threat models.
Manu_Sporny: If folks have suggestions on making it better, please let me know. So, that's that item. in order to do the forgery defense, yes, Ted, just to be clear, the reason we're using shapes and colors is because colors in and of themselves is not good enough, even though there's debate on that currently happening. so each thing gets its own shape which can be converted into an accessible description of the thing. It is taking a lot of time to churn on this stuff. but I think this is where we're going to land for now. So that's it on the diagrams. So there's been progress there.
Manu_Sporny: recognized entities the latest one and I need to update all the other threat models to align with this. also for this work specifically barcodes work had to go in and establish a data integrity threat model. This threat model is not using the latest symbology but I just need to go in here and change some shapes. It's a fairly simple threat model that I think covers most of the stuff. Simony has asked that we turn every single arrow into a flow. I'm going to push back on that. It's an enormous amount of work and it doesn't really talk about the threats that we care about.
Manu_Sporny: So we may have some further discussion that we need with Simony on that, but the amount of work is ridiculous at this point. so this is the data integrity threat model. It only has five threats in it right now because I just wanted to get something into the spec and See, folks, we're okay with it. we need to add all the other threats. So, I can do that. here's the problem with all the threat models. I'm largely the person doing the work across most of them. We are not having a lot of engagement.
Manu_Sporny: folks are engaging like Ted and the folks that normally engage are engaging but we're not really seeing much over the last three months and it is putting us behind. I know Phil you did a great review of the threat model but the number of new threats that we have to add are in I think I'm counting 60 threats across the various specifications. I don't know how to get those in without just, pushing them in as a big giant pull request. they're largely being taken from the security and privacy consideration section. So it's not new content. but it has to be rewarded to fit into the way the threat models are done. We lose nuance when we do that.
Manu_Sporny: So I'm highlighting challenges as we move some of these things in here. go ahead, Wes.
Guidance Consistency And Moving Targets
Wesley_Smith: So, I'm curious about when you've received all of these different pieces of guidance from Simone. So, Simone did a fairly comprehensive review of the VC barcodes threat model. Let me pull up and drop a link to that in the chat. And he didn't include some of the requests that you mentioned. so I'm just curious on if this is guidance that you've received after Simony reviewed the barcodes work. maybe had changed his mind on some things.
Manu_Sporny: when he reviewed the other ones is when I got it. So, where is it? maybe it's in this PR. it's splattered across multiple repositories.
Wesley_Smith: Yeah. no.
Manu_Sporny: Hold on. let me see if I can find some of them. But sorry, keep going, Wes. I'm trying to I don't know…
Wesley_Smith: No, no, that's it. I want to it it seems like one of two things is true. Either this advice is newer and there needs to be changes to the barcode start model or that advice is older and some of it maybe doesn't need to be done because Simone's guidance has changed over time. this
Manu_Sporny: how to find his and I don't remember which one it was, under. let me open your Yeah.
Wesley_Smith: Scroll a little bit and there's a large comment from Simone. Yeah. So, he requested quite a lot of changes, but they were mostly content changes. He didn't request for the most part with a couple exceptions, the kind of large overarching format and structure changes that you were describing. I don't know. I think we just need to look at what you've seen and that and reconcile and look at time stamps and so on to figure out what to do going forward. but I just wanted to make that note because it seems that this stuff is a moving target. the VC working group are sort of guinea pigs for this work.
Manu_Sporny: Go ahead,
Wesley_Smith: The requirements are changing as we go. and I certainly don't want us to be doing more work than we need to…
Wesley_Smith: if Simone has moved away from some of his earlier guidance. That's it.
Ivan_Herman: Yeah. …
Threat Model Scope And Structure
Ivan_Herman: what I want to understand is the document that you showed money formally speaking makes the required security section so to say for the DI document obviously but does it cover all the crypto suites for example? I mean I mean put it another way when I look at the family of specifications that we have. Do we have one such document for each element of the family or we have only one for the whole family or somewhere in between?
Manu_Sporny: I think the answer is it depends entirely on Simone's feedback and…
Manu_Sporny: how we want to structure it as a group. So it's a negotiation.
Ivan_Herman: I would inverse the order of…
Ivan_Herman: what you say first. Let's see what the working group wants to do and then we can fight sim if it's necessary that's the problem with the whole modeling. Yes.
Manu_Sporny: Okay, sounds good. And it just to be clear, I want to be clear. Simona is being very helpful. He's giving us a lot of feedback and if we were to act on all of his feedback, we would spend the rest of the year doing threat models. That is my big concern. Yeah. so it is hard for me to understand where to stop. Vice it looks like he gave you much more specific feedback on content. That's great on some of the other and…
Wesley_Smith: Yep.
Manu_Sporny: I'm totally failing to find where this feedback has come in from our face toface meeting with Simone in Brussels and number of things he said there. review feedback that we've received on threat models from Simon side conversations I've had with Joe and Eric. And some of it's written down, some of it's, active discussions. Joe said that they need to have with the threat modeling group and so on and so forth.
Manu_Sporny: But specifically, I think what we're trying to do is stay away from having to do a new threat model for every single specification we have because that would mean we would have to create 20 threat models and it takes about a week to create these things with someone really focused on it full-time trying to, do stuff and that's only if one person, does it. So I think from Brussels the path we were going to go down is we were just going to have one person put something together and then the group was going to review it and see if the group agreed or not. That was the fastest way that we found forward. Phil to answer your questions that you put in chat is there any other standards group going to this level of depth? I don't know. I don't think so.
Manu_Sporny: So I don't know is the answer. I think there may be one or two groups maybe going through the process but certainly not to the degree that our group is doing. And to be clear we are doing this is the light version of the process. we could be way more thorough … and whatever. We're just trying to do kind of capture the top 20 20% most important things that we want to capture. go ahead, Wes. Manu Sporny:
Wesley_Smith: Yeah, a couple things.
Wesley_Smith: One, I want to reiterate the point which I think everybody knows, but I want to reiterate the point that I think this threat modeling work is really really valuable. and I think that having threat models that have gone through this rigorous of a process is a tremendously valuable thing for the technology and for the optics of the ecosystem and all that sort of thing. So I do think even though it is a lot of work it is really valuable work to be doing.
Wesley_Smith: And the second thing Manu just based on what you said about where this other guidance has come and looking back through exactly what Simone said on the barcodes threat model. I want to propose a path forward which is just essentially using what Simone has said in the barcodes pull request and using that threat model as a template because he reviewed it quite extensively. He made extensive change requests, but those were almost all content related. And most importantly, at the very end of his comment, he requested something which very much seems like it solves this problem exactly, which is he wanted a meta section in these threat models that tracks the state of the threat model and allows for improvements over time and down the line as opposed to, reaching some theoretical perfect state before merging or anything along those lines. So,
Wesley_Smith: So this was quite recent and he clearly put a lot of time into this review. so I would propose that we don't get too hung up on, side conversations from a face toface meeting and the like because there's very actionable sort of advice and suggestions in this review.
Wesley_Smith: But would welcome other people's thoughts on that. Ivon, go ahead.
Ivan_Herman: So I come back to the issue I was discussing with Mali.
Ivan_Herman: Manu if the goal is to have essentially one major threat model which personally I feel that it's more efficient but I'm not part of the work on it. So for example then why do we have a separate threat model for the barcode work with all my respect to what we did really don't take me wrong in saying that but shouldn't we essentially merge that and I think that threat model discussions in other task forces the similar ways so maybe this is something that we have to decide on a working group level probably should be decided on working group level. But I would be in favor to try to minimize the work.
Ivan_Herman: And it strikes me that if we do this work only once in one place and we collect the threats themselves into this threat model it might be more efficient.
Wesley_Smith: Phil, go ahead.
Phil_Archer: All I was going to say was this sounds like a breakout session at TAC.
Phil_Archer: So I did raise it on a members call a couple of weeks back. there weren't the people that is a WPC members call there weren't the right people on the call to discuss it but there was kind of a right yes so I think it does need to be discussed in a TAC session on the plus side I was on a call this morning with a bunch of people who are experts in conformity assessment and they're working on a section of the UN transparency protocol and they've had some feedback from one of their
Threat Modeling Workload And Sustainability
Phil_Archer: important community members saying, "What have you done to understand the threats that you're creating?" I did. They didn't use those phrases. That's my wording, but I said I pointed them to the threat modeling work that you've been doing, Manu, and said, "This is what it looks like to do that, you've created a standard. You're creating a method of doing something. What can go wrong, and what are you going to do about it?" And so I recognize of course there's a huge amount of work here and I know everyone is nothing but appreciative and thankful. I think it has value, but it clearly is unsustainable. And that's the difficulty.
Wesley_Smith: Manu, go ahead.
Manu_Sporny: Yeah, I mean plus one to that,…
Manu_Sporny: Hil. I wouldn't say it's unsustainable. I'm saying that I have now done five of these and my name's on all of them and that is not a good look, right? But it's not good to have one person have done the ver I mean I'm fine doing it and…
Phil_Archer: I did. Yes.
Manu_Sporny: I feel like I do have the skill set to do this properly but when somebody from the outside world comes in and looks and they're like every single one of these threat models only has one person's name on it as an editor and it has no authors that's not a good look right and Phil you reviewed the recognized entities threat model so you did read the thing and I think it made sense to you and so I'm wondering should we add your name to that in some way to signal to the outside world that there has been review on these things right that's my biggest concern here is it's like I'm fine to continue cranking these things out plus one to we're not trying to get something perfect it is a bit unclear to me when we're done other than we'll just
Manu_Sporny: say we're done and tell Simony that's it for this iteration. We need to actually work on the spec. that's the other thing. I mean this is completely sapped at least certainly my ability to do anything on the specs other than threat modeling work right so that means vocabulary updates classifying issues all that is back burner because of threat model anyway I'm just trying to highlight these are the problems right now we're moving forward but I want to make sure that everyone's aware
Manu_Sporny: of this is the current state okay and I can keep going through it I just wanted to make sure folks were aware Wes you said Simony wants us to do this did we do a good enough job this is one example I think this is a really bad idea to do this I don't think you should put point in time statements into a threat model because we know what happens. We won't come back to the document for 2 and 1/2 or 3 years and it's going to make it seem like I don't think that's a good idea. And so, we need to engage Simone on it. We need to talk in the threat modeling community group. We need to take time out of our schedule for yet another meeting that's going to take four weeks to resolve. Before we work on the technology
Manu_Sporny: that we're chartered to work on and get that stuff done because that's the thing that our customers care about. They don't really care all that much about these threat models. It's important for it to be done. I totally get your point, Phil. but I'm speaking just with my vendor hat on. This is not helping us sell solutions. This is just tying up work and preventing us getting features into specs that our customers want and our customers are getting very agitated about it. just to speak from a pure capitalist standpoint, our customers do not find a tremendous amount of value in the threat models except when it's a box ticking exercise. And of course, they don't understand the value of it. I'm not saying it's not a valuable thing. I'm just saying we're not shipping features. that's a problem for us. go ahead,
Phil_Archer: That makes sense. I think it's a very important point to make, Manu. so I can see depends who you're talking to whether this thing is valuable or not from an outside perspective. All I was going to say it is ludicrous to put my name down as an editor because I'm not and you did all the work. however, if it is politically useful to stick my name on it,… then do so. But it doesn't feel right to me.
Wesley_Smith: All right.
Wesley_Smith: Asking myself, yeah, with respect to the good enough job section, manu personally, individually, I agree that did we do a good enough job section sounds a whole lot like a GitHub issues section. but if you think that that's something that we can push back on, that sounds great.
Wesley_Smith: If you think it's something we can push back on, I'd be happy to. I agree with all of the concerns that you raised. Personally, but also I would understand if it were something that we had to do, especially given at the bottom of this P if you keep scrolling down, when Simone approves all the way at the bottom, keep going. Yeah, he says okay to merge. The most important thing is that it did do a good enough job section. so it might be non-negotiable. I agree with you in concept that it doesn't seem like something that should go directly in the document.
Wesley_Smith: Instead, it should be tracked as metadata such as in the repository through the issues mechanism that we already have. That's it. Ivon, go ahead.
Ivan_Herman: I didn't remember this remark of Simon.
Ivan_Herman: I wonder whether what he meant here is to put it into the document as of now. It doesn't necessarily say that when we finalize it and we publish everything this thing should be there. it's more like a placeholder on where we are. But maybe I am trying to find something which Simony didn't think All right.
Manu_Sporny: So, we should talk with Simony about what he meant here. I agree. This is why we have an issue tracker, and the question is misleading. Did we do a good enough job? We're not going to publish something that we don't feel we did a good enough job on. We need consensus from the entire group. And so, the question is completely not, we don't publish stuff even as a note that we don't feel like we did a good enough job on, I don't know any working group that's like, "Yeah, we kind of halfass this thing. We're still going to put it out." so I know that has happened in some groups, but we should talk with some money. so apologies for the digression. Let me get back to the specifics here. there is a data integrity threat model.
Manu_Sporny: Threat model and the way I've been doing this in each spec is you just go to the spec namethreat model and you get to the threat model. There is a basic set of threats now in there and merged. The next step here is to add all of the other threats. I believe there are probably going to be about 30 of them total because that's how many we have in privacy and security considerations across all the crypto suites. So von you asked the question it would be better if we had kind of one big threat model.
Manu_Sporny: I think we can only make the threat model so big meaning we can't have just credential one verifiable credential threat model because the protocol stuff has an enormous set of information in the threat model and so does I believe the core data model threat model will also have an enormous amount. So we don't want to end up with a threat model that has 150 threats listed because it'll be overwhelming to people.
Manu_Sporny: Similarly the recognized entity work is different enough in the way it works where it probably deserves its own threat model which it has versus the core data model. So I think the takeaway here is that it really depends on how we want to break up the work and you could break up the work in a variety of different ways and we just need to come to consensus on how we're breaking up the work. I think the people working on the threat model are doing their best to not create an enor they're trying to find the right balance right it's about finding the right balance so for data integrity we are going to have one data integrity threat model and it is going to cover all of the crypt the quantum resistant crypto suites ECDSA EDDDS
Manu_Sporny: that sort of thing, right? So, all of them are going to go into this threat model. We need to add threats for the core data model, we're going to have a core data threat model. That's what this poll request is about. I need to update the DFD. It's not good. but this is about our standard issuer f ecosystem we talk about issuer holder verifier and then the processes me see if I unfortunately issuer should be on the left holder should be on the middle and the verifier should be on the right but auto layout for graphs is difficult but this is our standard issuer holder verifier system there's a set of flows here that we've identified
Manu_Sporny: between the trust boundaries that we focus on. and I think that's kind of the threat model, but this threat model, for example, is also going to talk about status list stuff. and is probably going to talk about crypto suite obsolescence is what we call it here. And there's one about quantum supercomputers and whatnot. so the data integrity one might also talk about this stuff and the forgery defense spec will refer to both threat models and say hey by the way you should go and read about this threat this is the threat that this spec is supposed to address.
Manu_Sporny: So for the forgery defense spec, this spec was created specifically to address this threat in the VC data model and the data integrity threat models. And then we have outgoing links to those documents. And then we may want incoming links as well in the threat model. We say to the response to this threat is implement the forgery defense spec right as a way of kind of speaking to how we link these documents together and don't end up duplicating information between each of them. okay so all that to say I have created the BC model with a base set of threats as well as data integrity.
Manu_Sporny: I think that lays the groundwork for us to do the add items for forgery defense and add items for bitstring status list and point back to the BC data model or the data integrity the BC data model threat model or…
Manu_Sporny: the data integrity threat model instead of avon having to create new threat models for bitstring status list and a new threat model for forgery defense. Let me stop there.
Ivan_Herman: So I have two questions.
Ivan_Herman: One is not necessarily surely not now but at some point in time you should in your ample free time write on a few lines about the tooling that you use for all this because as I saw a bunch of YAML files here and there for the threat model of barcode that I looked at it at some point but I want to understand what the heck is going on behind the scenes to produce this document because I presume you didn't do
Ivan_Herman: everything like that and format it like that by hand because if anyone wants to help and contribute then at least we should understand the tooling behind it. as I said not now but at some point in time. the other question I was wondering about the reason why the render method and the confidence method are not in the VCDM spec was actually timing and then back then we decided to make them reserved and then there are now separate works for those.
Ivan_Herman: Is it possible that those two would fit into the VCDM thread model as well or do we want to do separate thread models for those two?
Wesley_Smith: want to go ahead.
Manu_Sporny: It's an excellent question. and I think those are difficult. So, recognized entity was different enough where we needed a different threat model for it, right? …
Ivan_Herman: That's great.
Manu_Sporny: confidence method could probably go into the VC threat model. Render method is probably different enough where it needs its own threat model. because there are all kinds of interesting attacks you can do visually, right? injecting script and running script and all that kind of stuff. I think the signal is if you work on a threat model and you only have four threats in it, it probably should be merged into another threat model. so we need to see, unfortunately, you don't know until you do the work and then you're like, I can only think of four threats for this thing. At that point, you need to merge it into the other thing.
Wesley_Smith: Heck myself. Yeah. on that note, and Ivonne, you brought this up earlier. You talked specifically about the VC barcodes threat model. I think that one at the end of the day will be a standalone threat model. However, with that said, when I wrote that thing, I went really conservative on recall over precision, I mean, there's 30 threats in that threat modelish 25 and 10 to 15 of them are probably going to be subsumed by other threat models. Stuff like status list, data integrity, all that sort of thing, right? So, in the kind of early days here when there aren't well-formed threat models for every document, I've been airing on the side of conservativism.
Wesley_Smith: and we can trim down the threat models and dduplicate once there are threat models that u make duplicates right but for right now I've just been sort of in the barcodes threat model specifically I was very conservative but I do think that threat model will be a standalone threat model at the end of the day the physical medium aspect of it introduces a non-trivial number of unique threats that wouldn't make sense to have anywhere else so on and so forth
Manu_Sporny: Yeah, plus one to what Wes said. I do think the barcode threat model is its own thing. and I think that's a good heristic to figure out whether or not the threat model stands on its own, the merging subsuming thing I think is going to be a bit of a pain. but I think that's going to require another pass but for now the guidance which is fine guidance right the guidance from Joe and Simony and the threat modeling group was just do your best and create the threat models on islands to start and then we will start migrating things between the islands after our first
Wesley_Smith: And duplication is not incorrect.
Manu_Sporny: Yes. All right.
Wesley_Smith: It's just inefficient. as long as things aren't duplicated incorrectly,
Manu_Sporny: Plus one of that. I think that's it. I just wanted to give folks a heads up. There is now VC data model threat model as a PR. that'll sit out there for about seven days gathering feedback. please provide feedback. It's a draft PR right now, but I think you can give feedback on it. The only thing I need to do to it is update this confusing diagram. the rest of the content should stay the same. And then data integrity. I'm going to add a ton of threats in a single pass in a single PR. I know that's typically not what we do, but I'm trying to get this stuff in shape so that we can get the other specs to be able to refer to them and get them into horizontal review before TPAC. I think that's it for these items. was
Wesley_Smith: All right, have your hand
Ivan_Herman: Yeah, it's still the practicality.
Ivan_Herman: So if I find the time and I want to review one of the threat models. And I put in comments into the YAML files. Is that the correct way to do that?
Wesley_Smith: Morning. That's
Manu_Sporny: Yes, for some of the threat models, the other ones are JavaScript files, and Joe and I seem to disagree on…
Ivan_Herman: Come on.
Manu_Sporny: what the best way to mark those things up is. So, the ones I'm working on are all YAML files. The ones Joe and Eric are working on are all JavaScript files. That's right.
Ivan_Herman: They are Each threat is a JavaScript.
Wesley_Smith: I would assert that…
Wesley_Smith: if you can understand one, you can understand the other trivially.
Manu_Sporny: It's true. it's my concern, Wes, is that the way that you…
Ivan_Herman: So do I understand it that within the group we don't have one tool set for the threat models we have four different tools
Manu_Sporny: then make comments is all on a single line of JavaScript, which is difficult. this goes to kind of on we have four tool sets. That's right. Yeah, because we keep changing everything because we're iterating of I think eventually the plan is sorry I'm being very cynical about this. eventually the plan is that we will merge everything into the library that Joe has respect- threats and he has asked me to add optional features for the YAML bits of it and we are going to do that.
Manu_Sporny: So eventually the tooling will be in respect threats and then we can kind of iterate on that software as long as we can get agreement to the general approach which we don't have agreement for the tooling the gap isn't super big I think it's just English sentences right now that you can comment on so you can go in there and you can modify the English sentences and you're either going to be working in a JavaScript file
Manu_Sporny: or you're going to be working in a YAML file and that's how you can make comments today. So everything that I'm doing is in a YAML file that has line breaks so that people can make edits to it like they would the HTML documents. I'm wondering if we should just move everything to HTML snippets and do it that way. because then it's just editing HTML like we do for the specs the downside is that we have yet another markup language that we need to use for the threats but that'll just be based on HTML classes and things like that. I don't think we're going to figure the tooling out for another
Manu_Sporny: year or so. but it's serviceable right now, Avon. so I Yeah.
Wesley_Smith: Yeah, plus one to it being serviceable and our time being better spent doing the work on these things than perfecting the tooling at the moment. For example, the barcodes one is JavaScript. I knew that there were other ones in YAML. I push it out as JavaScript. We can iterate down the line. yeah, I don't think we need to spend a tremendous amount of time trying to perfect the tooling at the moment when there's still so much work in using the tooling that we have to do.
Ivan_Herman: No comment.
Wesley_Smith: You really feel like you have no comment. All right. was there anything else? Monty, you had a second item on your list. Remind me what it was.
Manu_Sporny: I don't remember either.
Manu_Sporny: I think it was just those two things. Data integrity and VC data model threat model. So those are there.
Wesley_Smith: Right.
VC Barcodes Status Update
Wesley_Smith: Does anybody have any other points about threat modeling that they would like to make? All right. we'll go ahead and talk briefly about VC barcodes then. so I've begun the process of getting us ready still on track for end of the week, for the requests for horizontal review for VC barcodes to be out. We're not there yet, but We're on track. The, self-re materials are a fair amount of work. working through those.
Wesley_Smith: Other than that, Pl, there's a pull request that's sort of in version control hell. number 62, this is still flagging merge conflicts. Maybe that's a stale GitHub status that hasn't been refreshed. I don't really know. There's a merge commit in there.
Phil_Archer: Yes. Yes. Yep.
Wesley_Smith: Is there any way, and feel free to say no, but is there any way that you could just take the content of this PR and open a PR that would subsume this If you could do that, please make sure you credit as co-authors on that the people that you worked with in this one to get it done, TED and the like. But if you could open a separate PR, that would be simple. Manu, go ahead.
Manu_Sporny: I just tried to activate squash and merge and that's available to us. So you could just do that. Wes Yeah,…
Wesley_Smith: So why okay we don't have to talk about it here. I don't understand why that would be the case and rebase and merge would see conflicts but okay.
Manu_Sporny: there's a get answer to that we can talk about it offline, but yeah, you should be a So, Phil shouldn't need to do that.
Wesley_Smith: It's because the oldest commit was before.
Manu_Sporny: Yep, that's right.
Wesley_Smith: Okay, I got it. Yep. Right.
Manu_Sporny: And then we've got a multi-headed merge in here as well.
Phil_Archer: All right.
Manu_Sporny: So, yep.
Wesley_Smith: Understood. squash and merge will All right, I will go ahead and do that. Never mind on the ask, Phil. Thank you very much. Great.
Wesley_Smith: I think that's it for VC barcodes. data integrity. Greg Bernstein was not able to Give me one second. He sent me a brief update to share with the group. he sent an email. he said merged two PRs, copyright notice and adding cryptosweet common algorithms.
Wesley_Smith: he said there's work ongoing on a explaining selective disclosure PR and he is continuing to work on refactoring the selective disclosure algorithm content I will share a link here topic this is a preview of the selective disclosure algorithm refactor that he's working on if anyone is interested and that is his update for data integrity. anybody else have anything they want to mention for the data integrity work? All right. Mona,…
Wesley_Smith: go ahead.
Manu_Sporny: Sorry, this is a random thought.
Manu_Sporny: Phil noted his, concern about being listed as an editor and we usually have authors. maybe for threat models, we should change the author's thing to a reviewer's line. So there is an explicit mention of who reviewed this thing. Just as a thought threat models are slightly different. You want to make sure that you said people have reviewed this thing. don't know if that helps or not.
Phil_Archer: Definitely feels better for me. Yes, absolutely. Because it's just wrong to suggest I did anything else.
Wesley_Smith: All anything else on the data integrity topic or related? Does anybody have any items to share for VC forgery defense? I raised a PR. Let me go check that. want to go ahead.
Manu_Sporny: just sharing the plan for forgery defense. now that once the VC BC threat model goes in and we add all the I'm going to add status list related threats and responses and then point out to the forgery defense spec from the threat model and then in the forgery defense spec I mean it is highly like I think it tell me if you disagree here it is highly specific to kind of postquantum break or key loss both of those are going to be threats in the VC data model andor the data integrity
Manu_Sporny: you want to have figured out maybe both. and as a result, I think all forgery defense has to say is like, our threat model is the base VC threat model and the data integrity threat model specifically pay attention to these key loss,…
Manu_Sporny: key compromise and postquantum break threats. That's what this spec is meant to address. what are your thoughts on that?
Wesley_Smith: Yeah, if you want to be formal,…
Wesley_Smith: I would assert that the quantum break is a form of key compromise and that spec is just about key compromise. It's a way to assert using a different key that you were the one that issued some it's a way to distinguish between credentials that you used a key for versus credentials that others used a key for and you can make that assertion using a different key and even with a different cryptographic scheme.
Wesley_Smith: So that is what it is right. We could extend it to do other things but at the moment it is quite focused on that threat. yeah plus one I agree Ivon. Go ahead.
Ivan_Herman: The other direction money in the threat model is there a way to say explicitly yeah this is the threat etc etc … by the way for this specific thread. Look at the document that we published. Ivan Herman:
Wesley_Smith: Go ahead.
Manu_Sporny: So what we do in the recognized entities spec is sorry let me bring this up on screen so everyone can see it. there are two issues currently that recognized entities. All right, here we go. Screen share. And this one. and zoom. if we go downh there's a threat model section in the recognized entities spec and in there hey this is where we talk about security and privacy and market competition considerations please look at these other specs for base understanding.
Manu_Sporny: But these are the target threats in here, And we list them specifically and We can link to external threat models here. Avon I think is one way of addressing this. So in that spec we can say you should read more about this over here and…
Manu_Sporny: the link will take you to a different threat model document. so,…
Ivan_Herman: That is…
Ivan_Herman: what I asked figuratively speaking let's say in T1 this is the threat and…
Manu_Sporny: okay. What did you ask?
Ivan_Herman: look at the specification that we produced to at least partially answer to this threat. Perfect. Manu Sporny:
Manu_Sporny: Yes. Yeah. So you're saying if we go here and we look at in the responses, this is what I was trying to say earlier In the responses, we should probably link to the specifications that help you respond to the threat.
Ivan_Herman: That's what I was looking for. Manu Sporny:
Manu_Sporny: And so I don't know if we should do that in this paragraph or if we should have a section in all of the target threats that talk about a related specification.
Ivan_Herman: I think it probably I mean from a purely…
Manu_Sporny: Yes.
Ivan_Herman: how should I say presentation point of view I would go for the letter. I mean to make it gives more weight to our own work if we make it very visible that in some cases for some threats we actually have a partial answer with one of our other specifications.
Manu_Sporny: And to do that, we're going to have to negotiate with the threat modeling working group to add another thing here because this is a template that I think they said we should be using. so that's…
Ivan_Herman: Sorry. …
Manu_Sporny: why I was suggesting we do just mention it in the response…
Ivan_Herman: Okay.
Manu_Sporny: because not every response is going to have a spec that we can link to.
Ivan_Herman: You information. That's true.
Manu_Sporny: So my suggestion is we just say in the responses for more information section blah blah blah of spec XYZ and…
Manu_Sporny: that directly links Yeah,…
Ivan_Herman: But I want to be more outgoing to the general public to say
Ivan_Herman: that actually we do give a partial answer to this threat. I mean that's much stronger than what you just said. It's not more information.
Manu_Sporny: Yeah,…
Ivan_Herman: We reacted to a threat. We published the whole specification in reaction to a thread which we consider to be of a certain weight. I mean this is a public message I'm looking for not Yes. Manu Sporny:
Manu_Sporny: that's a good point. and that's what target threats are supposed to be. we thought about this threat and this specification absolutely addresses the threat, There are other threats where that are implementation threats where we don't say anything. We warn you about it in the specification, but it's really up to you as an implement to protect against this. and then what are the other threats? yeah,…
Wesley_Smith: Inherited dependency.
Manu_Sporny: external and we're just kind of like, yeah, that's not us, right?
Ivan_Herman: It's not for us to do.
Ivan_Herman: Yeah. I mean I think maybe working the way we do it first and when we negotiate later we add it to our threat model in the right slots and then there is this saying which I don't remember in English do it first and negotiate later or something like
Wesley_Smith: All right. folks need to really quick, on last point on forgery defense, there's a PR open that I would invite folks to look at and view. it's not super heavyweight. It's just generalizing one of the features. go ahead and take a look. It removes the restriction that you have to use a UID for randomness and instead of replaces it with a definition of how much entropy the process has to have in order for you to use a piece of random information as a seed. it's especially if you're mathematically inclined, take a look at how I've phrased that stuff. it seems like a lot of specifications in this area are pretty handwavy with that sort of text. So, we tried to be a bit more formal here. take a look and let me know what you think. Thanks everyone. Meeting ended after 00:56:44 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.