Meeting minutes
Meeting Introduction
Steve Capell: Okay.
Manu_Sporny: All right, I think we have quorums. So, let's go ahead and get started. welcome everyone. This is the recognized entities task force of the verifiable credential working group. it is May 19th, a reminder to everyone that this call is recorded and transcribed. so if you're not okay with that please let us know otherwise we'll presume that you're fine with that. also reminder that we operate under W3C verifiable credential working group. You have to be a member or an invited expert to participate in this group. Let us know if you're not one of those. I think everyone on the call is.
Manu_Sporny: And we operate under the W3C code of conduct which effectively is be nice to each other and be accepting of what others have to say and behave yourselves which everyone always does on this call. okay, we do have an agenda today. the agenda is to go over pull requests, process any new issues that we might have. and we plan to spend a significant amount of time on the call today on threat model brainstorming for the recognized entities specification. there we know as part of the poll request process, we're going to get into use cases that you raised. Thank you very much, Steve.
Digest SRRI Pull Request
Manu_Sporny: for raising and I think that's the agenda for today. Are there any other updates or changes to the agenda or anything else that we would like to discuss? All right. If not, let's go ahead and get started on we have two pull requests to process. One of them is the digest SRRI pull request. that has not been resolved in the VC data model call. but we need to process that soon. There are no objections to deprecating a digest SRRI right now on the main spec.
Manu_Sporny: And we have passed our open review period for it. I will check once again but my presumption is that's going to be merged this week resulting in the digests SRRI property being deprecated but not removed it's going to be just marked as deprecated please go ahead okay okay all right we'll wait for that before processing that.
Shigeya_S: Yeah, I will provide the feedback on the BCDM issue. maybe today. Yeah.
Use Cases Pull Request Discussion
Manu_Sporny: Okay, so this one issue 69 is waiting on the digest SRRI issue to be resolved on the main call. issue 80 is the use cases PR that we discussed earlier over the past month. let me put a subtopic in and then I'm going to hand the floor over to you Steve to take us through all right over to you help us understand…
Manu_Sporny: what the PR is about and take us through it and so on and so forth.
Steve Capell: Okay, thanks man.
Steve Capell: Can you hear me? All right.
Manu_Sporny: Yes. One clear.
Steve Capell: Yeah, Darling works I'm on a little boat in the Italian coast and I was hoping that the connection would be so this PR is really just a reflection of the issue raised few weeks ago with two use cases in it for trust chains from some sort of transactional document through to some sort of authority and even to a second level of authority. I wasn't sure where to put it but I did find that use cases separate document. It's not in the spec right.
Steve Capell: it's a separate document and when I had a quick look at the second document it had a bunch of use cases and they were sort of broken into two patterns verifiable issuer lists and verifiable verifier lists and I thought which pattern am I in elected right or wrong to call it a third pattern which is really a linked trust graph pattern and so
Steve Capell: the PR does conclude a kind of a little bit of a few words about that pattern which is less about a list and more about a recognition of a single entity from a list by the authority that's discoverable from their DI and the two use cases are commercial invoicing crossber trade and product inform
Steve Capell: And one goes from an invoice VC signed by some bid to discover a recognized entity VC from a national business expert this time signed by a authority did and then from there to a list of recognized authorities in one case held by the UN and another case held
Steve Capell: a global organization called Gaki, GACI, I forget what it stands for. they're a merger of if which are if you like global member associations of national accredititation authorities. but they're two different use cases, but they follow the same pattern. So I just thought I'd put those in there to kind of reflect that the pattern is ubiquitous even if the use cases are different. I also found in the repository a place where there seem to be some sample snippets and cred full cials, just data snippets. So I also put in a probably wrong first stab at these four recognized entity credentials. The one from the business register to the exporter and from the UN to the business register.
Steve Capell: And then also similarly for the product conformity and also some dids for the same entities to kind of show this idea of discovering the recognized entity credential from the did service endpoint. So that's basically the gist of any thoughts questions? First time I raised the PR to W3C. So we probably haven't observed protocol now.
Manu_Sporny: No, I mean it looks good to me. I do have a number of kind of comments on the PR and I'll add them over time, but wanted to kind of raise them here.
Manu_Sporny: So going from the top down, I think Steve you used some claw or…
Steve Capell: I did whatever this is.
Manu_Sporny: whatever to generate this. which is fine. It's a little wordy. I don't know…
Steve Capell: Yeah. Yeah.
Manu_Sporny: if you want to I don't know if we can cut down on the wordiness. That's the only thing I'm a bit concerned about. what we ideally want in use cases is fairly short single paragraph to get people to kind of understand the use case. But if you're look this is as small as it gets this is fairly complex set of use cases then that's so of
Steve Capell: No, I think make I did use a bit of clawed assistance because I only had a limited time and I wanted to generate some sample credentials as well, but I'm happy to cut it down a bit.
Steve Capell: I've never yet met a claw generated. I mean I didn't just generate and then ignore it. I had a quick look, but you're right.
Steve Capell: It's a bit long and happy to if you don't want to merge it now, I can revisit it and make it shorter.
Manu_Sporny: Yeah, I think that that would be the kind of the first set of feedback.
Manu_Sporny: The examples are good.
Steve Capell: Second.
Manu_Sporny: But let's see. it's not expressed in the spec itself in the appendex and I think it should be. So, for example, let me look at VC data integrity. I think let's do the one. DC DI ECDSA and…
Steve Capell: for It's happening before.
Manu_Sporny: we have a section at the end here that has test vectors and we go through excruciating detail explaining here are all the examples and this is what it looks like and it feels like what you have done would be useful to put in an appendix in the spec itself maybe so the other thing is you added it to the use cases document which is good I think we as a group need to decide if we're going to try and revise the use cases document like Revit or if we want to put some core use cases in the core document.
Manu_Sporny: there benefits and drawbacks to each one of those things. I think that's largely it.
Steve Capell: Hard to look at me.
Manu_Sporny: The only other thing, I'm a bit the JWK versus public key multibase. I'd prefer that we try to keep the examples kind of tur. So, Steve, I've got a lot of echo from you. I'm gonna mute. Yep, there we go. and then let's see. But the rest of it looks pretty solid. I think we'd need to look a little closer at kind of the expressions here, but the rest of the examples look good. So I think at a high level maybe let's try to make it a little more tur if decide if we want this in the use cases document or the main spec.
Manu_Sporny: I feel like it might be better to have a core set of use cases in the main spec. I think the use cases document was, created a very long time ago and it has a lot of content in it that probably needs to be cleaned up. so we should either clean it up or we should say that was a good base document, but we've narrowed the use cases down to a restricted set. and then the examples should probably go in an appendix to explain what each one of these code examples are. I do think it's nice to have these code examples and it would be good if we exposed it in the main spec. that's it as far as my feedback's concerned. Dave,…
Manu_Sporny: you're up
Dave Longley: How much do we care about…
Dave Longley: how the AI made small mistakes in the examples and put a service type as a credential missing context for certain key types just random stuff like that that's so the examples are a little bit off. How much do we care about that?
Manu_Sporny: a lot…
Manu_Sporny: because people are going to copy it,…
Steve Capell: Yes. I agree.
Manu_Sporny: And we don't want them to copy the wrong thing a lot.
Dave Longley: Yeah, let me modify…
Steve Capell: Let me And I'm
Dave Longley: what I said. How much do we care about it before we merge the PR? Okay. Manu Sporny:
Manu_Sporny: I think we should get it right before it goes into spec because we all know that once something gets into spec, it's really hard to take it out. is
Steve Capell: Yeah, just a quick disclaimer. I was in a way kind of relieved to see a separate use case document because it meant that we could chuck some stuff in there and talk about it before it moves to the specs. As I was going to say, it's probably nice to have some in the spec. And I 100% agree we shouldn't put anything in there that we're not collectively happy is good, Particularly at this stage. And I'm sure I can make it shorter and I'm sure there's some bugs in the code.
Steve Capell: And I thought, chuck it in there and put it in this non-spec document so that we can talk about it and then figure out how do we make it good for the spec. That was basically my strategy here. Hope it works for you.
Manu_Sporny: Yeah, I mean that is certainly one way to do it. I guess my concern is that people are going to take the use cases document as a that is also up to date and…
Steve Capell: Yes. Yes. Okay.
Manu_Sporny: also correct and it's definitely not right I mean, it's got a whole bunch of stuff in it that I don't think is aligned with consensus in the group currently. so that's my only concern, Steve, about just chucking it in the use cases document is that it's either,…
Steve Capell: That would be bad. Yes.
Manu_Sporny: that document is getting more and more it's deviating more and more from con consensus and we're going to end up deleting it at some point, right? or we need to align it with consensus which means we need to spend the time to revise it which is a non-trivial amount of work for somebody or bunch of people to do. and I don't want either one of those to slow down the thing you've done which is explain the concrete use cases that you have and get that into the spec and so into potentially the main spec.
Manu_Sporny: So, one thing I thought we might do is have a use cases specification in the main spec that only has the use cases and the patterns that the group has consensus on. what that means is it means a little more work for you to just, get it down into a, concise form that we can all agree to that is right and correct and we can move it into the main spec. and this is just My personal preference is that we get your use cases into the main spec because I think we have consensus on them, And we don't want them confused with things that, are just a document from a long time ago that isn't up to date.
Manu_Sporny: The other way that we could break this up,…
Steve Capell: They
Manu_Sporny: Steve, is that we could take your examples and shift them into a separate PR. And we could take the use cases language, that's TUR, and put that in a separate PR and get the use cases language in and then get the examples in once we've got a whole bunch of commentary on how they should be updated and fixed and so looking for feedback from the group on which direction they want to go and of course you Steve on what you would be comfortable with moving on Dave Longley's comment about the service description this felt very much like who is service.
Manu_Sporny: So Stephen Curran's here this is to me just screams who is service and would be a great use of it and it's kind of like should we model it as that I'll stop talking. what are folks preferences Steve? Do you have a preference on let's just continue to chuck it in the use cases.
Manu_Sporny: Do you want to split it into two PRs? Do you want to try and, pair it down?
Steve Capell: Look, I accept everything that has been said that the words of the use cases should be more precise,…
Steve Capell: shorter, and that it probably does make sense to separate the words of the use case from the samples. Happy to make two separate PRs. I wonder how to collaborate with the much greater expertise in the room about getting the samples right particularly around the use of who is and things like that.
Steve Capell: Would you prefer that I break these into two PRs and have my best stab at it and then probably get the words all right. I'm reasonably confident I can do that. The samples may still have some bugs that you don't like in which case do I just have my best stab and then you fix it how should we approach the sample?
Manu_Sporny: Yes. Yeah.
Manu_Sporny: The sample stuff is just take your best stab at it and…
Steve Capell: Yeah. All right.
Manu_Sporny: then we will put commentary in the PRs to fix it. we could start doing that today. but if you're going to split it into two PRs, let's wait until you do that and then we'll start, giving you u feedback there. split it into two PRs first and…
Steve Capell: Okay. No,…
Manu_Sporny: then get the tur language in the use cases in the main spec. So make a PR against the main spec. Add a use cases section. Do we have one? Do we have a No, we don't have Yeah.
Steve Capell: you don't yet.
Manu_Sporny: So let's you create a use cases section and just add your turf use cases to it. that's one PR and the other PR is add an appendix B or something that has the examples in it.
Steve Capell: Okay. I think it Yeah.
Manu_Sporny: And you could either, inline the examples or there's a way for you to import, JSON or whatever. Just I think inlining is just faster way to do it.
Steve Capell: Yeah. We only need the minimal amount of inline that makes it clear…
Steve Capell: what it means, right?
Steve Capell: Where do you have a convention about where you use cases after the overview and after the data model or near the end or…
Manu_Sporny: Yeah, exactly.
Manu_Sporny: After the introduction and…
Steve Capell: where okay
Manu_Sporny: before the data model, make a new section called use cases or you hold on. There's no solid convention. Steve, let me look at I'm trying to figure out if I'm trying to think of another document where we do that. give me half a second to find a good example for you. Maybe BC data model has its own use cases. can anyone remember a spec where we use cases? yeah, here we go. The SIDS spec has use cases.
Manu_Sporny: So here's the link and these might be a little too short, Steve. So use your best judgment, But we've got five use cases there, a paragraph long each. you should not feel limited by that. I mean, it's fine for you to add, quite a bit of elaboration there. And what you could do is you could add the elaboration in the appendix and in the use cases thing, maybe write a paragraph about it or maybe you can split it up into two or three use cases. You got two different patterns,…
Manu_Sporny: so each one of those could be a separate use case. okay.
Steve Capell: All right.
Steve Capell: Leave it with me. I'll have a crack. It makes sense to put a few words around the snippets in the appendix, doesn't it? Rather than just have them dangling by themselves.
Manu_Sporny: Exactly. Yep.
Steve Capell: Okay. All right.
Manu_Sporny: And I think that's where you could, really elaborate on why are you doing it this way?
Steve Capell: Why are you doing it this way? Okay.
Manu_Sporny: What's the benefit? that sort of thing. and then there are two other use cases that we need to add after you do your work, Steve. So after you do, add your, one or two, however many, use cases you want to break it up into. We do need to add Dimmitri's we just want a list of recognized entities just their name and their logos and things like that. That's one of the use cases. and then we have a use case where it's like you want a to-peer recognized entities thing, where any individual can publish and then you want the official list, although that's probably your one, Steve, that you're going to write in there. So, we'll figure that out after you do the split and we process your PRs and get them into the spec.
Steve Capell: Okay, sounds good. Thank you.
Manu_Sporny: Okay, And thank you very much for working on this, Steve. I know, it can take a bit to get these PRs to land, but you're giving us a lot of food for thought on larger changes we want to make to the specification. with that said, any other feedback for Steve on this Anything else we want to do? Okay.
Threat Model Brainstorming
Manu_Sporny: With that, I think those are both PRs. the next item up is, working on, our threat model brainstorming. so let me go ahead and switch topics. Threat model brainstorming and then let me share this link with everyone. so we have to generate a threat model as everyone knows. in order to do that we do a number of things. So we typically provide a systems diagram and kind of the primary flow that we're interested in. We have data flows that we want to document like someone going out and getting the recognized entities list is one of the data flows.
Manu_Sporny: We describe the entities and processes and where data is stored and that kind of stuff. We're going to skip over all this stuff. We'll get to that later. we identify stakeholders. Again, we're skipping on that. today, what we're trying to do is we're trying to brainstorm all of the threats we can think of just, really quickly off the top of our heads. what kinds of attacks are we most concerned about when it comes to recognized entities? So, each one of you has the ability to go into the document and start adding things. So, all of us should feel free to jump into the document and start typing out any threats that they feel we should care about. And in vague is totally fine.
Manu_Sporny: I'm afraid of aliens using recognized entities in a bad way, put it in the list. we'll process it may not survive to the end. all right. So please start typing the types of threats you're concerned about in there and we'll go from there.
Manu_Sporny: This is great stuff so far. We're going to keep it going until I see people slowing down on their typing and we don't get any more
Threat Model Categorization
Manu_Sporny: All right, I think most of the typing has died down a bit. Please continue typing if you've got other ideas, but we have a very good starter list. how around 25 items at least. 22ish 20ish. So that's a great start. The next step here is we are going to try to move these into target threats which are threats the system was designed to address. implementation threats where these are things that impleers might get wrong.
Manu_Sporny: but we leave kind of the choice to that individual that's implementing. external threats where we're like yeah that's a threat but it's out of scope for this version of the specification and dependency threats which are like hey we depend on this other thing out there that we don't really have control over but it's a threat like if they get compromised we get compromised. So, we're going to try to classify each one of these and put them into each one of these categories. before we do that, actually, let's just go ahead and do that, denial of service fetching externally linked registries. what is that? That is an implementation threat, right?
Manu_Sporny: as an imple is the one that has to make sure that they protect the software against denial of service attacks. I guess there are two parts to this. One of them is a denial of service for the person publishing the registry. I'm wondering if there's a client denial of service as well. So let's see this is the issuer can experience a denial of service attack when a large number of clients fetch a externally linked registry.
Manu_Sporny: three. So who contributed this one? Just so we can know. Does anyone remember?
Dave Longley: I think I did I meant to cover both cases.
Manu_Sporny: Okay, there we go. And thank you for adding the other one. Did you mean server the issue or the client? Dave.
Dave Longley: So splitting at two works fine.
Manu_Sporny: All next item. An issuer of recognized entity credential is not authorized or accredited to do so. Is that an implementation thread as well? Is it out of scope?
Manu_Sporny: It's not a target.
Phillip Long: That sounds out of scope to me. I don't I mean,…
Manu_Sporny: It's like you have to like me the person that's managing the verifier has to make sure that they don't make a mistake here, And implementation threat feels like it's the person implementing the software,…
Phillip Long: right either way.
Manu_Sporny: but maybe it's the person implementing the system. So I'm torn between implementation thread and external. …
Phillip Long: Could be both, I guess, is what you're saying.
Dmitri_Zagidulin: And what's the reasoning for not putting it as a core threat?
Dmitri_Zagidulin: Because that's one of the core threats that the spec is target threats rather.
Manu_Sporny: it's like the issue.
Manu_Sporny: I don't think it's a threat the system was designed to address because we can't stop a verifier from putting a completely unknown issuer of a list into their software This is an issuer of a recognized entity credential,…
Dmitri_Zagidulin: No, no, it's more that our spec contains information not just on the entities but their accredititation and so that is exactly what our spec contains. So, it's a target threat that our spec addresses.
Manu_Sporny: not the issuers in the list. I totally agree with you for the ones in the list.
Dmitri_Zagidulin: I misunderstood.
Manu_Sporny: This is like Okay.
Dmitri_Zagidulin: I misunderst Okay, got it.
Manu_Sporny: But what you said is a good one. should add it. Yeah.
Dmitri_Zagidulin: So, that's an unknown registry host. Got it. Unauthorized. Orange.
Manu_Sporny: So let's say an unknown yes,…
Steve Capell: I might just quickly interject that that's the one that we mitigate with the UN grid right so this is regi pretending to be registered Doris when they're asserting a business identity or something where we have literally a chain. So it's not just Manu Sporny:
Manu_Sporny: I think so. I'm hesitating, Steve, because I'm not familiar with all the details of grid, right? But it's supposed to be like the global registry for every known entity that should be managing a registered entities or…
Manu_Sporny: recognized entities list.
Steve Capell: Yeah. But…
Steve Capell: but I mean the general pattern is a hierarchy of recognized entities, right? So some sort of authority recognizes a business and some sort of other authority recognizes the authority. You know what I mean?
Manu_Sporny: Yeah, I think this is the topmost one that we're talking about here,…
Steve Capell: Yeah, me.
Manu_Sporny: I don't know. I guess who added this one? okay. Then you get to decide exactly what it means. are you talking about the grid use case or are you talking about the topmost
Steve Capell: Yeah, I'm talking about…
Manu_Sporny: Okay. Yeah,…
Steve Capell: how you mitigate the risk that a verifier doesn't have a priority knowledge of the issuer of a recognized entity. Do you see?
Manu_Sporny: I'm okay. So do we agree that there are two layers here? There's who watches the watchman layer at the very very top, right? And then below the stuff below it is something our spec addresses. I think definitely it's the topmost one that I'm guessing is out of scope for the spec. But Steve,…
Steve Capell: I think technically the spec I'd imagine that the recognized entity credential format,…
Manu_Sporny: I think you're talking about the one below the top level.
Steve Capell: shape, purpose, would be identical.
Steve Capell: Whether it's the UN saying to the Australian tax office,…
Steve Capell: you're recognized as an authority register or whether it's the Australian tax office saying to an Australian business, you're recognized as an Australian business. It's just they're both entity recognitions, right? What I'm trying to draw out here is a linked chain.
Manu_Sporny: Mhm. Okay.
Manu_Sporny: So, you're trying to draw out a target threat,…
Manu_Sporny: Meaning that this is something the spec was designed to address.
Steve Capell: Yes. Hello.
Manu_Sporny: So we should word this in a way where it's like yes that is definitely in scope and the thing that I think is definitely in scope is let's see it's not an unknown issuer of recognized entity credential it's an unknown issuer of a verifiable credential is
Steve Capell: No. it's an inline issuer of a recognized entity spec credentials. I'm just trying to draw out the idea that you can actually have a hierarchy of recognized entities credentials,…
Steve Capell: right? Because up to now the whole spec is about somebody creates a list, but there isn't a list of lists and it's just turtles, right? I mean, it's the same tech and it's just following existing natural governance hierarchies that already exist,…
Manu_Sporny: Mhm.
Steve Capell: right? …
Manu_Sporny: Mhm. It's not all right.
Dave Longley: Can we cover more ground by saying an unknown issuer of a verifiable credential including a recognized entity credential?
Steve Capell: I mean, Yeah, possibly.
Dave Longley: Can we cover more ground with that as a single threat?
Steve Capell: I mean the purpose of the whole spec initially and still is to say I don't know who the issuer of this verified credential is a degree certificate so give me a list of authorized issuers right no
Manu_Sporny: Yeah. Yeah. I think that that thing makes sense to me, Steve. I think what you're going to make sense. I don't know if I'm making sense to the rest of the people on the call. Meaning the grid credential does what protects against that, right, Steve? But what happens if titute what's the opposite of a grid sphere credential or something and…
Manu_Sporny: I trick a verifier into use my the grid credential and then they're tricked into accepting a whole hierarchy of things that they shouldn't be accepting.
Steve Capell: Yeah, I think it all goes to the wording of these threats,…
Steve Capell: And I probably got the wording completely wrong, but I see that one of the biggest risks here is how does a verifier know where to look and who to trust? Yeah.
Manu_Sporny: And I think that's fair,…
Manu_Sporny: right? So, the thing that the threat model should be doing is highlighting the core stuff that we're trying to prevent. And I think your thing does that it is a core part of what we're trying to achieve with the sc. So, it is a core target threat and Demetri I think it was aligned with the way you were interpreting it and not the way I was interpreting it. go ahead Dave.
Dave Longley: I think one of the things that came out of the conversation that we want to tease out that we don't need to tease out right now is there is a subtle difference between you've got to go to your configuration to begin with some priori configuration to start with and then after that you can go down this hierarchy but those are two different Yeah. Dave Longley:
Manu_Sporny: Mhm. And one of them is not a target threat.
Dave Longley: And one exactly the configuration and…
Dave Longley: thing is not something this spec does not say how to configure your system. It just says you have to have that as an assumption coming into
Phillip Long: So does that mean that we have a target threat and…
Phillip Long: an implementation threat? The lower level being the implementation threat.
Manu_Sporny: Yeah, top level here. I'm trying to type something up. so verifier configuration is botched to look at the wrong top level recognized entity credential.
Manu_Sporny: I think that's the one I'm trying to tease out. And that is a implementation threat, right? Okay.
Phillip Long: Yeah, that's…
Dmitri_Zagidulin: Yeah, but it's also the same as…
Phillip Long: what I'm thinking.
Dmitri_Zagidulin: if you don't have a configuration in the first place
Dave Longley: It might not be an implementation threat It might not be an implementation threat…
Dave Longley: because we are not going to tell people how to implement configuration systems in this spec. We're just going to say you need to do it. So it's more of an external or dependency spec or threat.
Manu_Sporny: Plus one to that. Demetri, on your comment. it's not the same thing as not configuring at all because my guess is if you don't configure at all, it'll just ject, Any verification with an unknown issuer will reject.
Manu_Sporny: But if you botch your configuration and…
Dmitri_Zagidulin: Yes, I see…
Manu_Sporny: you put the wrong Yeah. Dmitri Zagidulin:
Dmitri_Zagidulin: what you're saying. I see
Manu_Sporny: So This is an external threat. we don't tell people how to configure their software in the spec, but if you misconfigure your software, it's going to turn out badly for next item. legitimately recognized entity claims a scope that does not match the recognition. Who contributed this?
Steve Capell: That's me again.
Manu_Sporny: Legitimately recognized Mhm.
Steve Capell: What I mean by that is in product conformity for example I might be issuing let's say a veterary health certificate and I'm accredited there. I discover a linked accreditation from a national accreditation authority and that's valid and it is about me but I'm actually accredited to grow organic cotton not to test animal health right so you can have this chain and each entity is valid but how do you know that you're not talking about something
Manu_Sporny: Yeah. Yeah.
Manu_Sporny: The use case makes sense. I'm wondering about the wording. yeah. I don't know to I mean I understand what you're saying based on what's written.
Steve Capell: Wondering about happy to change the wording.
Manu_Sporny: Go ahead, D.
Dave Longley: This is analogous to a confused deputy attack whereby the system that's applying the rules would see this thing in an ACL and…
Dave Longley: says, "Yeah, it's all good." But it's not appropriately bound to the resource that's being requested. So, it's like I looked in my list.
Steve Capell: There's something here.
Dave Longley: This thing's accredited, so we're all good to go. because the whatever was doing the looking was did not have the scope information that said you it has to be good for this specific thing.
Steve Capell: That's right.
Manu_Sporny: …
Manu_Sporny: how would we reword this to make it a little more clear about that? cuz what I'm confused about is there's one case where this entity the veterinary slash cotton growing organization registered themselves on the list they went through some process and…
Steve Capell: Come on.
Manu_Sporny: got on the list with the wrong scope and the list manager allowed that to happen versus they didn't specify anything or the list manager didn't specify anything.
Manu_Sporny: So, their scope is overly broad. I think those are two different attacks, right? One them the list manager isn't paying attention in both cases.
Dave Longley: Yeah, those are two different things.
Manu_Sporny: Didn't check it.
Steve Capell: There's also a pattern maybe…
Steve Capell: where the scope the list managers the recognized entities done their job, but the verifier is and this is an implementation thing probably, right? Yeah,…
Manu_Sporny: Yeah. Yeah.
Steve Capell: they're just not looking at it or
Manu_Sporny: Plus one of that. So, we've got kind of three places where the failure can happen. Do we want to care about all three of those? Should we generalize this as a list owners not paying attention, verifiers not paying attention?
Dave Longley: I think we've got insufficiently specified in the list and…
Phillip Long: Yes. Spaced out fire.
Dave Longley: then we verifier insufficiently follows the rules specified in the list.
Manu_Sporny: So the issuer of the recognized entity credential.
Manu_Sporny: does insufficiently specifies restrictions on the type of credential.
Dave Longley: it. Insufficiently specifies restrictions on…
Phillip Long: It's awesome. Yeah.
Dave Longley: what an entity can do or something.
Manu_Sporny: Yeah. on the type of actions the recognized entity can perform right and then the other one is the verifier of the recognized entity credential insufficiently applies the restrict
Dave Longley: They insufficiently apply the restrictions.
Manu_Sporny: restrictions on the type of actions the recognized entity can perform. Okay, so we've got those two. these are what type of threats are these?
Manu_Sporny: Are they target Feels like they're implementation threats.
Dave Longley: So there's certainly implementation threats…
Phillip Long: Yeah. Heat.
Dave Longley: if we're going to specify an algorithm. ironically if it's just a data model that we specify ironically they wouldn't be technically implementation threats because you could implement this spec just doing a data model.
Manu_Sporny: Are we going to specify an algorithm?
Dave Longley: I don't think we know the answer to that yet.
Manu_Sporny: So, let's list we don't right now. So, today they're external threats.
Manu_Sporny: Is that okay?
Phillip Long: Yeah, but put some kind of note there that indicates that…
Phillip Long: because later on we'll be confused.
Manu_Sporny: If we don't specify an algorithm, these are external threats. Then put Steve as the contributor for both All right. So, is that one compromise of a recognized allows a fraudulent actor to masquerade as a legitimately recognized entity. That's a good one. what is is it an external threat? Because we don't really talk about keeping your DID safe in the spec.
Dave Longley: Yeah, I think it's an external threat.
Manu_Sporny: Recogniz who added this one?
Dave Longley: It's got to be Telltale sign of the ass and recognized.
Phillip Long: Great catch, Dave.
Steve Capell: It seems was me again. Sorry. I started at the top and read a few.
Manu_Sporny: No, no,…
Steve Capell: You're in
Competitive Gatekeeping Threat
Manu_Sporny: this is fine. you're fine. that's right. Privacy leakage in ways compromise of a recognized that we did that An entity generates the first recognized entity list for a particular market vertical and uses that to keep out competition. This is a competitive threat. I added this one. It is dependency or external. It's out of scope certainly.
Manu_Sporny: It's not an external technology, but it feels like a dependency threat, It's a market failure in some case. do we care about this one? Let me ask that first.
Dave Longley: I certainly think we should mention this. it's duplicated as simply anti-competitive gatekeeping on number seven. So, I think we can strike that one or,…
Dave Longley: make this one more general.
Manu_Sporny: Okay. …
Dave Longley: We certainly want to talk about it.
Manu_Sporny: who? Yep.
Dave Longley: People should know that this is a threat to the ecosystem.
Phillip Long: time
Dave Longley: Yeah,…
Manu_Sporny: Plus one. who added the anti-competitive gatekeeping?
Dave Longley: that was me.
Manu_Sporny: All So, I'll list both of us and then we will delete that one. Yes. Thank you, Phil. All right.
Manu_Sporny: This was very productive. Thank you everyone. really appreciate all of the thinking about this and categorizing. We will come back next time and we will categorize the remaining 15 items and keep going until we have a good categorization of it. we did in the VCOM call earlier come up with a strategy on how we're going to move this into a document format. So Joe, Andrew, Eric Shu and I will continue to do that.
Phillip Long: Excellent.
Manu_Sporny: So once this group is done with the categorization we will then move it into spec form and that will allow us to request a horizontal review of the specification. All right. anything else that folks want to mention before we adjourn for today. All really appreciate everyone contributing today and attending even from a boat in the Mediterranean, no doubt. have a wonderful night,…
Steve Capell: Thank you so much.
Manu_Sporny: a wonderful rest of your week, and we will see everyone here next week. Take care. Bye. Meeting ended after 00:56:48 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.