VCWG Recognized Entities

Benjamin_Young: Hey, Mono. I can remember if I was MCing this one or you were

Manu_Sporny: I can run it. Benjamin, don't worry.

Manu_Sporny: All right, we've got a good group of people here, so let's go ahead and get started. we've got some manner to welcome everyone. This is the recognized entities call for September 22nd, 2026. we do have a rough agenda for the call which is our typical agenda for all calls which is to do PR processing and issue processing and then utilize certain people being here to address some issues. So I note that Paul's here today. So we're going to probably take advantage of that and look at the GS1 use case. as far as pull requests are concerned, we don't have a backlog. we've processed all of them that we can.

Manu_Sporny: And so we're going to probably spend most of this call discussing the privacy review that we just got. So, another review came in. We just did internationalization privacy came in. and we also have a security review that I took an action to do an analysis on last week. so we have that. let's do the security thing at the very end because it's just going to eat up the entire call. if we don't do that, and then before that, we'll do the privacy review. There are two of those items.

Manu_Sporny: And then before that let's focus on seeing if we've been able to make any progress on the field match proposal from Paul and see if there are any further things we can do there. so that's the proposed agenda is the field match discussion followed by privacy review discussion followed by security review threat model discussion. Let me there and see if there are any other updates or changes to the agenda or anything else we need to discuss. go ahead, Steve.

New Data Model Field For Recognized Entities

Steve Capell: Yeah, I started to do a mapping to the UNDIA and realized there's one field that I think is important to add to the standard data model that I know these things are extensible and you can add whatever you want and that's fine but there's one in particular which is the identifier as known to the recognizing entity. So if I'm a business and I'm receiving a recognized entity credential from a business register there isn't a standard part of the data model where I say this is my identifier as I'm recorded in the business register.

Steve Capell: and I think that's something that is just so important it ought to be part of the san model. So I wanted to talk about that.

Manu_Sporny: All thank Steve, maybe we put that would you be okay with us doing a light pass over that this week and then a heavier pass next week just to time box it?

Steve Capell: Of course.

Manu_Sporny: All right. So, let's start off with that one and then we'll go into the other items. let's see. This is issue 132. please take us through it. Steve.

Steve Capell: Yeah.

Steve Capell: So in the UN stuff we have a very common frequent use for some register whether it be a business register, an IP register, a land register or whatever it is issuing its member, a land owner, a business owner, whatever with a recognized entity credential saying we've confirmed

Steve Capell: that you control your did and we know you as this whatever the registered ID is Australian business number for example and the purpose of that is because we want to be able to say here's for example a crossber invoice signed by some did and linked to the DID is a recognized entity credential and what the verifier really wants to know is what is the registered ID of this invoice issuer

Steve Capell: what is their Australian business number whatever the thing is right so there's two things to check what one is it the right recognized entity credential so is the subject of the recognized entity credential the same as the issuer of the invoice that's did match and that's already in there and part of the algorithms that man has written up but the other thing is and what Australian business number is it or what German business number is it or what landlock number is it IP registration number is it that natural ID of the entity as known to the register that's issuing the credential doesn't seem to have a home in the current data model.

Steve Capell: We could of course add it, but it feels to me like maybe it's something that ought to be part of the standard data model.

Manu_Sporny: Great.

Steve Capell: That's about it.

Manu_Sporny: Thank you, Steve. yeah, I don't have any objection to adding this, but I will note that, was it scam.org? or when I think there's a mechanism in schema.org where is identifier. I think it specifies what is it called? The type of identifier in is it a G10, is it a DUNS, is it a ASN, is it a skew?

Manu_Sporny: So this is…

Manu_Sporny: what it looks like in scheme.org. I believe. Yeah, that's right.

Steve Capell: I don't identify type coming in on the value.

Steve Capell: Yeah. Yeah.

Manu_Sporny: So it's got the name of the type of identifier and the value of the identifier as a property value. so I suggest we do something like that. this is kind of ugly the markup here, but I think that is because it's kind of like you don't know what scheme this identifier belongs to. And that's the benefit of having I guess…

Steve Capell: I agree. You can't say, the key value can't be Australian business number. It just has to be identifier, scheme, value. Yeah.

Steve Capell: Yes. Right.

Manu_Sporny: what I'm saying is the identifier scheme is ABN or Australian business number and then the identifier's value is 1 2 3 4 5 6 Right. they kind of split the difference in scheme.org and all of these G10 as account ID ISBN ISSN I think are sub subtypes of identifier. but schema.org does their identifiers kind of in a weird way. if you go to G10 here I mean it's a G10 right? It's got a certain number of digits.

Manu_Sporny: it's a G10 and they attach that onto a product here, and I don't know if the problem with this is that it's like there are hundreds if not tens of thousands of identifier schemes in the world. And so this is not a scalable way to do it. And so what we may want is identifier and then a identifier type and…

Steve Capell: Yes. Agreed.

Manu_Sporny: we've got a queue. rambling. Dave, you're

Dave Longley: Yeah, I put a comment on that issue, just as we were getting started as well. another thing that's used in some other places is reference ID and then a UR might be used that has a prefix that would identify the type of identifier the name space for it. even if we went and did something that has a type a structured object. Now we have to figure out whether all of those types are going to be present in an additional context or we're going to use URL values so there's some extensibility considerations if we take that approach as well. So either way I do think this needs to be more generalized.

Dave Longley: This isn't necessarily a registered ID,…

Dave Longley: but it is some reference ID that's important for the recognized entity for someone's business rules. And that ID needs to be appropriately namespaced somehow.

Steve Capell: Yes, we usually use scheme ID as a URL.

Steve Capell: Something like that. So

Manu_Sporny: All Thank you, Dave. Paul, you're up.

Paul_Dietrich: Yeah, just seconding what Dave said. I think there should be some identifier for the type and that's got to be globally unique. So, URI or something. GS1 has an object for organization ID details which tries to enumerate those types. I don't know if that's the right approach here, but it's something we can look at also. but there needs to be a description what for that numeric field otherwise we can't tell what kind of field that is.

Steve Capell: Yeah, there's a little bit more in this ticket which I was unsure whether to put the scheme ID as a property of the subject or a property of the issuer, right? Because it's the issuer who is the scheme owner, So, I think I can't quite read my own writing there because my eyes are too old. But, issuer ID type. Yeah, I'm not sure I like what I wrote there.

Steve Capell: I might change it a bit but the question for the group is it a object in the subject which is identifier scheme registered ID or whatever term we want to use and maybe a name and we've already got a name or is a property of the issuer because it is the scheme owner that is issuing the registry scheme owner that is issuing this thing in the First

Manu_Sporny: Thank you, Steve. let's go ahead just to keep to our time box. Paul, last word for this week and then we'll talk about next steps. Go ahead, Paul.

Paul_Dietrich: Yeah, I think that red the ID there has to be its own object because you could have more than one. For example, I could be referencing another entity above this And so the ID itself could be a list.

Paul_Dietrich: There could be I don't know a Dun's number and a GLN and whatever other number happens for other regulatory domains. Thanks. They spawn it.

Steve Capell: Okay.

Manu_Sporny: Plus one to that.

Steve Capell: I need to update this ticket then with that suggestion.

Manu_Sporny: Plus one to all that. Steve, I think you've got, generalled interest to add this and some suggestions on how we could add this in a way that is …

Steve Capell: Okay, thank you.

Manu_Sporny: extensible and interoperable. And so I think next step is to just update the ticket and we'll come back and discuss in a following week.

Steve Capell: Thank you for the time.

Discussing Field Match Proposal

Manu_Sporny: All right. Thanks, Steve, for raising that. all right. let's go ahead and since we've got Paul today, let's talk about any thinking we've been able to do on the field match topic. so as a reminder to everyone there is this need in the GS1 use case to try and restrict further down the recognition chain what credentials someone can issue or is it just kind of the fields that are in there?

Manu_Sporny: field match is presented as kind of the minimum viable semi-eneneralized way of doing this. there has been some concern about yes it'll solve the GS1 use case but is it How much of a general solution do we want? basically what do we want to do at this point with this feature I think there's been quite a bit of discussion here so maybe over to you Paul to provide if there's been any updated thinking I know Dave you've engaged here maybe we can talk a bit about that so go ahead Paul.

Paul_Dietrich: Yeah, I think the discussion's been just around that exact topic, how complete is this versus how much effort this puts on a burden on developers. I think in the end, I clarified Dave's suggestion here in the last kind of chat here. basically of how we could combine the two credentials. So just generically combine the parent and then the downstream child credentials and whether that's one or more than one. GS1 only needs one and then run some schema on that combination and that would allow us to compare the two fields across the credential.

Paul_Dietrich: credentials in a chain. I think we have to do it carefully because you can really only do a credential and the credential below it maybe because if you go too far then it conflicts with the rules of the validations where you only go up until you trust the issuer. I think that's in the re entities. and I was clarifying from Dave to make sure I understood what he was asking about for that whole chain. I just saw that today and so what I'll do next Manu is try to mock up examples using that. I would like to get some feedback from Dave on I know JSON or whatever can combine these things like what's the simplest way to combine these so I don't have to mock up that whole thing.

Dave Longley: Yeah, so as I put in my feedback in this issue, I Paul raised this as a sort of we're lacking transitivity to be able to apply a schema or know how to apply a schema transitively across effectively a whole chain. And in my comment, I noted that there's kind of two ways to look at that problem. they're both the same problem. But another way of looking at it is we're just missing inputs. We're not providing the entire chain at the mo wherever you are in the process in the algorithm of working through the chain of credentials that you're ate. We're not providing that whole chain to the validation rules engine. We're just providing one credential at a time or whatever it was.

Dave Longley: And from that perspective you have the same sort of problem. So instead we make it so that output validations can be run over the entire chain that you're currently processing then that enables you to do at least two things. One is you might have a schema that's just on a JSON schema that is on its own smart enough to know how to process an array of which that holds the chain of credentials. but you might also need an additional step to generate that schema based on for example maybe the length of the chain or what any other property that might exist in that chain. You might need to use that to generate your schema to then apply your schema.

Dave Longley: And GS1 might only care about the root of that chain and the next credential that follows right after that and maybe nothing after that. but other parties might care. And so, I think it's important that if we're going to solve this problem and we're going to solve it in a way that doesn't involve handing people like a touring machine to run in a sandbox, Then

Dave Longley: I think what we can say is an output validation can specify that runs on the whole chain and I think there's two ways that we can say that two different types of schemas that you can run one that is just here's the JSON schema it's already ready or you can use JSON auto to generate the schema and the variable you will pass into that JSON auto being a template language and a template engine that JSON allows it to generate JSON schema because JSON schema is JSON and what its inputs would be the template that are provided in the c recognize entity credential and that whole chain at that part wherever you are in the validation step and if you do that I think you can produce a JSON schema that then could run against whatever that chain is.

Dave Longley: I don't know if I'm answering your question, Paul. I'm imagining, and apologies for not just handing you a simple example of this, but I'm imagining a JSON template that sees the chain as a variable, measures its length, and then decides your reg x's or something on that basis. it outputs a JSON schema that is looking for an array of this length where the first one has, for example, a GS1 value that starts with some number and then the second one it starts with that number plus some other number and it's effectively just generating two rag X's.

Dave Longley: The other comment I want to make about this is highlighting to me something that I had in the back of my mind is as a software developer I don't want to run JSON schemas that haven't at least been I have two problems with running JSON schemas. the first one is they might be filled with DOS regaxes and the second one is I don't want to run them from untrusted sources. And so if our al algorithm doesn't already do this, I think that the way that the algorithm should be constructed is you find based on a list of you build the chain based on iteratively finding all the credentials until you hit your recognition anchor and then you run the validation rules and when you run the validation rules ideally any schema or JSON that you're running is also time boxed.

Dave Longley: resource boxed and I just added a bunch of stuff to what we were talking about. Apologies there, but just dumping it to get it out of my head.

Manu_Sporny: You're a head pole.

Paul_Dietrich: Yeah, thanks Dave. So I think what I would try first is just trying to treat the chain as a array of credentials and just checking with a straight JSON schema. I'm going to see if that works first, Dave, because I think the JSON auto seems more complicated than I'm ready to do at this point. If that doesn't work, I'll report back on this ticket of what's failing, and then maybe you can come in and provide a little help on how to properly use JSON auto to solve a problem if there is one. so that's my current plan is to go back and try and do that. Thanks. Oops.

Manu_Sporny: All right, that seems like kind of a good next step. have we solved the problem of the JSON stable specification thing? I don't know if we have really right.

Dave Longley: I don't know that we've sold it. There is an active discussion about that somewhere else or may I saw that come up on the issue tracker of one of the VCWG specs today or yesterday. Ted and Ivonne were discussing whether or not this can be normatively referenced. and so that discussion is happening somewhere.

Manu_Sporny: So that was three things came to mind. the first is the stable reference thing. the second is the complexity of putting the JSON stuff together with JSON schema. everything that you mentioned Dave. I mean, I think we're getting closer and closer to the complexity of a touring machine, we're doing kind of static templated languages and reasoning about that versus just running a chunk of JavaScript. It would probably be easier for most people to understand the chunk of JavaScript, ignoring the security and sandboxing and all that kind of stuff. just looking at understandability of what we're talking about.

Manu_Sporny: I think there are going to be not that many people on the planet that can put together a complex JSON to template rendering to chain verification flow versus could you give a chain of these credentials to someone that just understands JavaScript and they execute a function on it and get a true or false out of it. I think that second thing would be easier to kind of understand. and stable spec and all that kind of stuff. in that vein, I did take a look at where current V8 and JavaScript sandboxing is these days. it's pretty decent.

Manu_Sporny: but certainly not foolproof. so it is possible to do that in modern programming languages. the danger of course being that there can be ways to escape the sandbox in certain environments and you have to be very careful about how you put that together. It also means that executing anything like that just like executing HTML rendering code in a sandbox like we do for render method has its costs and attacks and all that kind of stuff which is why checking the chain and making sure you're anchored to somebody that you trust before you execute the JSON or the JSON schema or even the

Manu_Sporny: the JavaScript is vitally important. You do the execution at the very end when you're basically like, this code kind of sort of came from someone I trust or someone that they trust and so I'm willing to run it in a sandbox capacity with resource constraints on it. go ahead Dave.

Dave Longley: Yeah, I think it is easier to understand certainly I'm going to hand you some arbit JavaScript. You're going to run it in a sandbox and the end. but I don't think the primitives are as available. They're certainly not as available as what's happening in render method where every browser can hand you an I frame that you can sandbox now. and people they're not even running browsers to do this validation in a lot of cases. so I'd be concerned that primitive would be there at all in a sensible way for people to run this. and I think if we can cover most cases with static JSON schema, then we're in pretty good shape.

Dave Longley: And if we want to have a non-normative call out for optional here's an additional output validation thing that you can run that's JSON auto to generate your JSON schema. implementing I do think that's harder to think about because you have to get into the more details, but I do think it's much easier to implement than the alternative.

Manu_Sporny: Yeah, so I checked for sandboxing environments on Android, NodeJS, and they all exist in ways that are supported. So I don't know if I quite buy all the environments that I looked at had a mechanism because all it did was it used V8 and it did a sandboxing using V8 and V8 is the variations of that is what's used in on all these platforms. So I

Manu_Sporny: I think I was surprised by how much support there was out there for it. so I think we should question that the tooling isn't there. but even if we were to accept that the tooling isn't there, it is possible to execute this thing in an HTML sandbox, because you can have input into the sandbox, you can get output out of it.

Manu_Sporny: You can set up the sandbox with the code and so because render method it relies on sandbox stuff and because it's available on all the platforms we know it is possible again through the headless stuff as well to sandbox something provide the credential chain as input to the sandbox provide the code effectively the thing that you're running in the shut off sandbox escaping and then get a result value out of the sandbox.

Manu_Sporny: So again I think the tooling is there and given what are people going to more readily understand a JavaScript snippet that's run on a recognition chain or doing a whole bunch of effectively what amounts to excess transforms I'd put my money on the JavaScript sandbox thing. and I don't feel super great like saying that because we're getting into executable code that's associated with these verifiable credentials, which is a scary environment.

Manu_Sporny: But at the same time, if we look at some of the most useful features that organizations like GitHub deploy, it's GitHub actions where you get a sandbox and you run arbitrary stuff in there, very complex arbitrary stuff. and it has tremendous value being able to do that. So I'm not completely convinced that being able to execute arbitrary code against these chains or even against the verifiable credentials isn't somewhere we want to go. even to the point where it could be possible to externalize some of these validation checks. I think that would be a powerful thing to have in the ecosystem but clearly is way beyond what we're talking about here. so just some food for thought.

Manu_Sporny: I don't know if resonates with other people or not, but I'm not entirely convinced that JSON not and Jason schema is the right way to approach This. that's it. Go ahead, Steve.

Steve Capell: Yeah, I'm not sure if this is related, but we of course have this challenge in supply chain of validation across a arbitrarily large collection of credentials of which the relationship between an invoice and a recognized entity is only just one of hundreds of types of verifiable relationships that you care about and rules on top of them. And so yeah, we've separated that out completely and said the credentials just contain the nodes and edges. You drop them in your graph and then you verify your graph. And here and what we've identified is three layers of verification rules. So these are the common rules that probably any graph in a supply chain will care about.

Steve Capell: for example, is the subject of a recognized entity the same as the issuer of the credential that you founded from. I expressed that badly. and then there's another layer of rules that are industry specific and then there's like you do whatever you want on top of that in your particular organizational use case. So they're completely orthogonal to the data in the credentials. I'm not sure if this discussion is going towards let's put some of those rules inside the credential. That feels like the wrong place to put it.

Manu_Sporny: Thanks, go ahead, Dave.

Dave Longley: It hurts my sensibilities to suggest it, but a link to an API that can perform some kind of privacy preserving custom validation might also be a potential solution. but maybe that's something that could just be understood or done in the ecosystem. we're talking about all these different ways this validation stuff could be done, but maybe that doesn't have a place in this spec. It's just something the ecosystem can fill. And you can have, third parties that are going to treat the data appropriately apply these custom validation rules.

Manu_Sporny: All right. Thanks, Dave. Go ahead, Paul.

Paul_Dietrich: So we've had some experience in pilot with this that I can share. in one case basically there was no call out from the verifier. They basically couldn't call out. So they had to have whatever they had it simultaneously. They didn't want to take a library to do complex validation. so if we could do this as preloaded schemas that we give them ahead of time here's a set of schemas that define our business rules then that was acceptable. in a second pilot, it was the same situation. They couldn't call out and they couldn't load custom

Paul_Dietrich: code and so that's why we were looking towards is there a way through this standard where there's an approved way to go do this transitive output validation and we proposed field match because it was the simplest although Dave I just learned about reax denial of service attacks and so now I'm not sure that was a great idea but if there is a way to include that I think it would support these use cases which we've seen in our pilots it's more than half of them basically have those restrictions they don't want to take custom libraries. I don't need a custom library for every issuer. That doesn't work. And then we also don't want to call out and make outgoing calls. We need the content loaded ahead of time or embedded in the credential. Thanks,

Manu_Sporny: We can't make outgoing calls? I don't know where that came into the discussion.

Paul_Dietrich: I think what Dave mentioned in his idea that there could be an endpoint in here to go call out privately and…

Manu_Sporny: Okay.

Paul_Dietrich: conservatively to validate something. I think with that now you're making an outside call to actually verify the chain. You may have verified signatures and that it's coming from the right parties, but verifying authenticity of the chain, if there's that extra step, you would need to make a call to do that if it was an endpoint in the credential.

Manu_Sporny: Yeah. and that's a phone home thing. Dave, was that what you were saying or…

Manu_Sporny: I thought that you're was

Dave Longley: I was saying it's against my sensibilities to have such a thing in the spec,…

Dave Longley: but that doesn't preclude the ecosystem from setting things up where there are third-party validation services that you can hook up to do your validation and effectively I was saying maybe we should let the ecosystem solve this particular problem if there's reusable validation that people need to do so that they can keep that stuff internal to their own systems. So, rent used by the validation system that will do what you need it to do on the chain that you're getting for your use case and your business rules.

Manu_Sporny: All got all right. what are the next steps here? Paul, any thoughts on next steps? Mhm.

Paul_Dietrich: Mono, I said I'd go give Dave's proposal a try here. I'm just going to do it with regular schema validation, combining meaning 012 for the credentials below this one. U make that assumption that that's how they're combined. and then try to see what my schemas look like and if I can enforce the rules with that. if not,…

Paul_Dietrich: I said I'd come back with the challenges and see if Dave could recommend a JSON auto way to fix that. but I'm hopeful that won't be needed. And I should be able to do this week probably Manu and post some comments to this ticket.

Manu_Sporny: Okay, excellent.

Manu_Sporny: That sounds like a concrete set of next steps and thank you Paul for taking on the action to dig into that. okay, thank you everyone for the feedback on anything else that we should discuss on this item before moving on then to the next topic which is our privacy review that we got. there were two things raised in the privacy review.

Privacy Review Feedback Discussion

Manu_Sporny: So the first one was issue 130 and this is basically just so everyone is on the same page. We talked about this in the VCOM call but not the privacy reviewers came back and they were basic they basically said a threat model is not a sufficient replacement for privacy considerations. which the people working on threat modeling were a bit surprised by because they thought privacy had bought into this. So this is a discussion that is going to happen between the threat modeling community group and the security group and the privacy group because the it is a sufficient replacement. there are some things that seem to be misunderstood here.

Manu_Sporny: This is Nick Dodie who's great and has done a variety of security reviews for verifiable credentials before. and so I kind of provide some of the thinking and concerns here and tagged Simone. We've let Joe Andrew as well that there doesn't seem to be alignment between Ping and Singh at W3C and really needs to happen because it's making our job really difficult by there not being alignment there. So that's just this item. I don't know if folks have anything they'd like to add here.

Manu_Sporny: I think the proposed next step is for Joe and Simone to have a discussion with Nick, figure out how threat modeling is, relates to the privacy work and then get back to us on what our path forward should be. any thoughts, questions, concerns with this item? All right. So that's The worst case here is we just put the privacy considerations. We translate the threat model privacy items back into a privacy consideration.

Manu_Sporny: ation section and we put it in the spec and it will look ugly and out of place but it'll address their concerns. So that this was a meta comment on us having a threat model instead of privacy consideration section. the other item that was raised was 131 which is that we should talk about how to distribute recognized entity credentials which we do.

Manu_Sporny: it's in the threat model, but it doesn't seem like Nick found that in the threat model in the index. so I pointed him to where we explicitly talk about it in the threat model and where we also talk about it in the verifiable credential data model threat model. And so we'll see what he says there we definitely talk about it. In fact, we have a whole section on holderbased delivery here and how to use it and so on and so forth, so there's a lot that we write about this that I'm g so he may not have seen this because it wasn't merged into the spec yet. I'm guessing that's what happened.

Manu_Sporny: And so I think we have a response here. We'll just see what he has to say so that is the privacy review so far. I don't know if Nick's totally done with the privacy review. so we'll wait a couple more days to see if he's done. and if he's done, then I'm pretty confident that we've got good answers for at least one of these things. And the other one is just some consensus position. the privacy group and the security group need to come to any questions, concerns about the privacy review. The good news is they didn't find any major privacy issues.

Manu_Sporny: If that's the case, then we have the last item for today, which we're not going to get through, but we're going to try to get through as much of it as possible. is security did a review of our specification. It was a fairly large set of feedback on editorial changes and model changes that we should do.

Security Review Threat Model Discussion

Manu_Sporny: I took an action last week to do an analysis just using LLM and all that kind of stuff. which is here. And so what we can do on the call today is go item by item to see how we want to respond. the general form is if you want to know the details go and read what they wrote there. but each one of their bit of feedback has a letter and a number. E means editorial. M means model and then one is their first set of feedback. Two is their second set of feedback and so on.

Manu_Sporny: There's a sentence describing the change we would have to make to meet the thing that they asked for. There is a suggestion on the number of lines that would need to be changed and the total effort right so each one of these sections has that kind of written I will try to explain each one of these as we go through them. there were a couple of good catches. So there are a couple of things in here where it was like that is a security concern we should totally close that loophole around so this one was good.

Manu_Sporny: MO5 model change five they were basically like hey you put some bounds on the algorithm with max depth but it is possible to construct recognition chains that can escape those bounds. Right? So based on the way the algoth are written internally the algorithms bound are time and depthbound but taken together the algorithms are not and so you can do a resource exhaustion attack by running the algorithms. So that was a great catch right that was very helpful useful we should definitely make that change as an example.

Manu_Sporny: Okay. So, I think let's go from the top editorial. there's a little notes section here. I'm going to take notes as we go. so the first thing, was, they're basically saying, hey, you remove the security and privacy consideration section, put it back. and just refer to the threat model in the security and privacy consideration section. So the threat model isn't a replacement for the security and privacy consideration section. Just put it back and point to the threat model as you go through the security and privacy consideration section. the challenge here is that and I've asked this of the security group.

Manu_Sporny: I don't know what good looks like here. they kind of pointed at it. U Joe said, "Yeah, they need to talk about that and come back with a more concrete proposal." so my proposal at this point is like, let's not change anything until they tell us exactly what would make them happy because otherwise we're just going to be churning with you variations of stuff. So a thumbs up from Any other questions, comments, concerns? What should we do here? I saw thumbs up from Phil as any objections for us? Just asking them to tell us what good looks like and then we can do that. Manu Sporny:

Manu_Sporny: I'll just say we're going to wait on that. The second thing is editorial as well. they basically said, "Hey, you talk about components in the threat model." but you don't link back to the main spec for them. so let me show red model.

Manu_Sporny: So for example in this dictionary we talk about a list publisher but they are basically saying for every single one of these things you should link to a specification that defines the component or the flow or the process or the object or any of this stuff, so do that here and then for every threat every place there is a response you should link back to the spec as well.

Manu_Sporny: So fairly simple ask a significant amount of work. so again the AI analysis on this is that this is around changing 300 lines in the specification. We have to do 24 links to components if they even exist. we've got to split new entries.

Manu_Sporny: They asked us to redo the document flow diagram which is the basis of the entire threat model. You redo that thing that you have to change large swats of the threat model. this is a significant amount of work that could take and of itself will take an entire week of editing. likely even using an LLM you've got to cross check to make sure it's linking to all the appropriate places in the spec. So this is significant. Joe's suggestion is like that's what doing a good job on threat models is about doing all that cross referencing.

Manu_Sporny: I will note that as an editor that has had to handw write these specs, traditionally, without LLMs, this would be a nightmare to keep all of the links up to date and cross referenced and working and making sure that all the links don't break between publications of the specification and, making sure TR space doesn't break like it is just not good. it is doable with an LLM but again this is significant amount of work. So I have a feeling that pushing back on this will result then I guess you're not interested in doing a good job on the threat model given infinite time we would do it because it would be a improvement to the threat model.

Manu_Sporny: thoughts. What should we do here? go ahead, Dave.

Dave Longley: So there are always going to be things that we don't have the time, resources, to do. and so we have to prioritize different things. and there's always some way in which things can be improved. as it exists, this is still a useful threat model. It can be made even more useful by even more convenient by having the links that people can click on instead of them having to search in the document or feed this document to their own LLM and ask questions of it, which many future people might do anyway.

Dave Longley: And in that light, this is work that would be useful, but I don't think is super high priority for this group. And when I say this group, I also am considering the fact that a major editor on this specification is also an editor on many other specifications that all have to be done. And so I don't think this should be highly prioritized. and it's also something that can be done as an editorial fix in a later maintenance group. that's always left open when maintaining specs if there are people who want to come in especially as LLMs get even better and just ask LLMs, hey, can you improve this in some and then that can be reviewed and checked in a maintenance group to further incre improve the usability of the specification.

Manu_Sporny: Thanks, any other input on this item? how it is saying, maybe push back. go ahead,

Future Meeting Action Items

Phillip Long: Yeah, I don't think it's pushing back so much as saying we agree 100%. but this is something that can be a task for the maintenance group that follows since what it's doing is just clarifying what people would normally be doing on their own in the coming weeks and months and everybody's going to be using an LLM to do this. We can give them one pass at it when the maintenance group gets to it, but I don't think it's not having it. It doesn't mean that people aren't going to be able to do it. Thanks,

Manu_Sporny: Okay, thanks all right. So the group discussed this and determined that while the group agrees that this would enhance the specification the threat model it is doing so is not a higher priority than a complete

Manu_Sporny: ing the specification and so group will get it when has the perhaps staring only. Okay. All right.

Manu_Sporny: That is go ahead.

Phillip Long: You might Yeah,…

Phillip Long: you might suggest that in the interim people can in fact do what we would be doing anyway. Hey, which is run this through an LLM and have those pointers highlighted. And if they have any confusions about that, they can get a hold of the maintenance group.

Manu_Sporny: Okay, sounds good. thank you for that updated correction, Phil. All right, that is two of the 10 items. we will go through the rest of this list next time so that we can address the concerns. all right that is it for the call this week. thank you everyone for the discussion. as next steps we will Paul if you're able to show us a demo or see how the experiment goes we'll cover that next week.

Manu_Sporny: We can also come back and take a look, Steve, at the issue that you raised. and then, I'll see if there's some of these that I can just, address, by myself. and, for the ones that, we'll cover them next week as well. All right.

Paul_Dietrich: Nice. Bye-bye.

Manu_Sporny: Thanks everyone. Appreciate the chat and have a great rest of your week. Take care. Bye. Meeting ended after 01:10:45 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.