Meeting minutes
<ottomorac> transcriber-bot, connect
<ottomorac> transcriber-bot, connect
<ottomorac> transcriber-bot, pause
<ottomorac> transcriber-bot, resume
DID Threat Modelling
Otto Mora: Right, put it back on...
Joe Andrieu: So… All right, the first thing I'm just going to share with folks is the… uh...
… The current draft of the threat model
… which is your best reference for the diagram and for the introduction language. If you have any questions about you know what the elements are, those sorts of things, the components. But where we're actually working today is going to be in the Google Doc we've been using to corral
… The enumerated threats that we have so far. That's in a different spot
… That is that Google Doc. Um
… And there were basically two things I want to do today. One is I want to go over the fleshed out threats
… that Steve and I have documented in here, and get feedback on it. Just like, hey, here's how we're approaching this, here's the… these are, in my view, complete. Um, although maybe we don't have the component, so they're 99% complete
… Um, and I want to make sure they're landing right, and that people are understanding what we're doing. Then I also… we have one question about, um
… Where some of these go in the structure. Which I'll get into about, are they external threats or are they
… Uh, dependency threats, or something else altogether. And then the other big item is that I think, in our conversation, Steve and I have come to the conclusion that
… There is probably only one threat model right now for our group. Um
… Uh, and that was basic, because we had talked about, hey, let's… let's use the
… potentially smaller scoped DID resolution threat model to go through the exercise of threat modeling and understand what it would be. And then there might be a separate DID threat model, right, for DID core
… Um, and I think there isn't. I think there's no daylight between these two. Um, so I guess let me just introduce that first, and then as we go through this, we can have that in our… in our minds. um… Although we did not have resolution defined concretely in DIDCOR. Dids don't work without resolution
… So every threat to resolution is a threat to TIDCOR
… Um, it may be nuanced because did resolution, you know, now has parameters being passed, or has particular bindings that we didn't have before, and those could have their own unique threads. Um
… But we came up in our conversation the items that Steve was motivated to dive into
… And they're… they're great threats. Um… Really are did threats and not about resolution
… Like, to my sense, as a threat modeler, I want to look at the system, and I want to contain my analysis to that system
… Um
… With an awareness of where it's embodied, but things… I'll get into this shortly, I guess. Maybe I should have prepared a presentation. It would have been clear
… But I think we should just have one threat document that has all the threats, whether it's did or did resolution. I think that boundary isn't helping us. I don't think we want to create a separate document. All that feels like more work than is necessary, and I'm not seeing a good reason for it. So… open to feedback right now on that, or we
can… we can dive into, uh, the Google Doc
… Thumbs up from Stephen
Otto Mora: And I saw that Phil had his hand up for a second, but...
Phillip Long (GU, ASU): Yeah, I was… I wasn't sure immediately until Joe, um, explained a little bit further that the… the difference… the distance he was talking about was between...
… uh, threats to DIDs in general, and threats to specifically DID resolution, and he's made that clear now, so I understand that, and I happen to agree that that's the proper way to view it
Joe Andrieu: Cool...
Phillip Long (GU, ASU): Thanks...
Joe Andrieu: Thanks, Will...
Otto Mora: Perfect. And as we go through this, I mean, I'm sharing my screen here, Joe, but if you prefer to share your screen and walk through it, I'm happy to help you do that as well. I just...
… Wanted to, like, for folks that may not be on their computer. Well, um
… It might just be 4 cents, yeah
Joe Andrieu: Sure. I appreciate that. And I'd be happy to share my screen. But since you already have it — oh, there you go. I was about to say, so do you have it up? You can go ahead. But I can grab it, too. It's easy...
Otto Mora: Oh, okay...
Joe Andrieu: Okay, so this document is a work in progress. Did you have Sanado? Do you want to add?...
Otto Mora: No, no, I'll keep an eye on the queue. That's what I can...
Joe Andrieu: Okay, I appreciate that. This is a work in progress...
<ottomorac> DID Resolution Threat Model doc: https://
Joe Andrieu: And we're going to go over the yellow highlighted things today. This is not all of the threats that have been enumerated by the group. We have quite a bit more. They are in here in the sections in which we think they belong, but they aren't quite well fleshed out
… Like, we have interference by central authority. I'm not sure that that's a well-formed threat, but it needs a description. It needs a bit more details, as do all of these that aren't highlighted in yellow
… This is the short list which really helps you get some sense of scope like, what kinds of things have we covered? What kinds of things have we not? Those should all be realizable by here. The main thing that happened is after. The, um
… Uh, our last call, where we talked about the at-risk for the resolution architecture section, um, I don't know who put it in my ear, it may have been on the call, someone said, hey, that, you know, if that's a threat you're concerned about, it should be in the threat model. And so that triggered me generating several of these threats that we're
going to go over
… And a couple that I haven't. They're all so they're all proxy related. And what I don't write have right now is is tampering with the URL. uh
… Which isn't really about proxy, but it is about
… Um
… the, uh, confused deputy risk. So that's not in here, and I know it needs to be. Um, but let's dive into this first one, and I'm gonna make this bigger
… So this thread is eavesdropping by did resolution service provider. And it could be surveillance or eavesdropping, I think I only want one of those
… Unless people holler, I'm just going to get rid of and surveillance. I think eavesdropping feels more unique. So, did resolution service providers receive a significant amount of data that may reveal personal or proprietary information? I want to include both personal risk and corporate risk with that statement
… Um, this is a, uh… In STRIDE, this would be called the Information Disclosure Risk
… And we came up with four responses. One is we can let the user know. So this is convey threat likelihood. When onboarding users to any particular data resolution service provider, explicitly communicate the data use policy in terms that users can understand. So in many jurisdictions, this is lawfully required
… But this is one response to the fact that the surveillance provider is getting your stuff, is that they can tell you what they're gonna do with it, and they could commit to it in terms of service or not, but there is this point in the relationship where they tell you exactly what they're gonna be doing
… Um, the next step of this is the purpose binding, so they've told you what they're gonna do with it, and they actually do only what they say they're gonna do, right? So this is restrict the use of data provided to the DID resolution service providers to explicit purpose
… As agreed to by the user. So this is a level up from R1
… Um, R3 is to recommend local resolution. So, when explaining DID resolution, and we think this is mostly, like, our job, like the community job, um, educate users about the trade-offs of running a local resolver versus using a service provider
… And that is, in fact, part of what this threat model is doing. So this is one of the responses we have to this risk
… Um, and the third one, or the fourth one, R4, is use a locally controlled resolver, rather than using a service provider
… And so I think that's actually going to be repeated. So I'm going to note that
… R4 is probably what I should be using later, but, um, so there's no eavesdropping by a service provider if you're the service provider, so that's another way you can, you can deal with this. Um, this addresses these components, um
… I don't have the diagram up. Maybe if I get the diagram handy
… One second
… I'm surprised our diagram is so… oh, I'm not… that's right, I'm in the wrong URL. Um… Let me get there. Hold on one second
Phillip Long (GU, ASU): It's the diagram at the top of the document, isn't it?...
… No
Joe Andrieu: Correct. I just wanted to put it on screen easily without losing the place...
Phillip Long (GU, ASU): I understood. I just wanted… because I was mapping to the letter combos...
Joe Andrieu: Okay. And do they look good? E seven f one c one...
Phillip Long (GU, ASU): Yep...
Joe Andrieu: Okay...
Phillip Long (GU, ASU): Yeah, they're understandable...
Joe Andrieu: Sometimes those shift...
… Uh, and I keep going to the wrong
Phillip Long (GU, ASU): What I don't see are the F… oh, I don't see the Fs...
Joe Andrieu: thing. Okay, I'm… I'll just skip that...
Phillip Long (GU, ASU): in the upper document. Maybe that's… looking in the wrong place. And I don't see… well, maybe… It's the lower one...
… No, I don't see the F, the F series
… in either of the three graphics
Joe Andrieu: Should be...
… Oh, that was the other link
Otto Mora: Yeah, it's mentioned in the architecture dictionary, but yeah, I don't see them. Yeah...
Phillip Long (GU, ASU): It's not in the graphics...
Otto Mora: Well, actually, in page...
Phillip Long (GU, ASU): Page 7. Hang on...
… So
Otto Mora: 7, there is F0. and F1, F2...
… H7, yeah. and the top graphic page 7. Yeah
Phillip Long (GU, ASU): I don't see it there...
Joe Andrieu: Oh, I am… I gave you the wrong URL, and I've been going to the wrong URL. Um...
… No wonder
Phillip Long (GU, ASU): In the doc that I'm looking at, Date Resolution Threat Model. That was shared in the Zoom chat...
… There is no F in
Otto Mora: But it… If...
Phillip Long (GU, ASU): that diagram, and it… and it would be helpful if you put diagram, uh, numbers. By the way, in the dark...
… F1, diagram 1, diagram 2, diagram 3
Otto Mora: Okay...
Joe Andrieu: So...
… At the very top of this file that I'm in
Otto Mora: By the way, just one… one thing, just, Joe, like, you're… you're mainly just sharing the Google Doc. I think you… you did that thing where you just share one tab or something like that? Okay. Okay, okay, okay, I just make sure. Right. Right...
Joe Andrieu: Yeah, no, no, no. I'm sharing the screen, but it only has a Google Doc open. This is the diagram I was talking about and looking for. So...
Phillip Long (GU, ASU): Where is F?...
Joe Andrieu: I've just pulled it up in a duplicate. F is...
Phillip Long (GU, ASU): Oh, the flows! Okay...
Joe Andrieu: the flows. F0 used at URL, F1 resolved. F3...
Phillip Long (GU, ASU): I see. I was looking for the boxes. Okay...
Joe Andrieu: Um, so...
Phillip Long (GU, ASU): My mistake...
Otto Mora: And in there, too, you can see it in the light blue box inside. It says F1 Resolve F2...
Joe Andrieu: Yeah, for the other profiles, it moves around...
… Come on. Bye
Otto Mora: Yeah, you could do like a side by side. Yes, that's fine...
Joe Andrieu: Okay. Um...
Otto Mora: Yeah, okay...
Joe Andrieu: So that was E7… The entity is probably the service provider...
… Alright, there we
… the resolver service provider, F1, which is the resolve flow, C1, which is the DID user client device
… I'm not sure the client device is implicated here
… It's really C2. Resolver device. So, I'll adjust that
… By the way, we're not going to do this on all these, but I just want to demonstrate this is what should be. Um
… And the components tend to be the last thing you think about
… And p two is right and d seven is right. Okay So those are now up to date. And this is an implementation thread. Potentially. So let me talk about that. So we have these four different kinds of threats
… Target threats, implementation threats, external threats, dependency threats. I added this temporary category which if we're all in agreement on tomorrow's call
… Um, then, you know we'll get rid of this and just integrate things. Um target threats are a threat to specific behavior feature API protocol or capability that the specification is designed to address. So, um
… uh
… Things like the resolution algorithm, if there are threats from the resolution algorithm. Then hopefully we've done something to deal with those threats. Like one of the threats we did deal with was HTTPS binding. It deals with tamper evidence
… Uh, communication and trusted communication between, uh, the client and the resolver. So that would be a target threat
… Um an implementation threat is an implementation I'm sorry is a threat that arises from how it may be implemented
… But, even if the specification text is a hundred percent correct. For example, we don't talk about how you sign anything
… Um… Uh… but if you are going to do some signing, then you need to have a key store somewhere. And so that's on you
… Um, we don't… our specification doesn't read on it, we did not solve that problem, we did not really engage with that problem, but we want to identify it so that implementers understand what's happening. Um… And then there are two others, external threats
… I didn't get the phrase copied in. External threat is a threat that is external and exogenous to the system. And this is just a heads up
… Uh, because some people do… are concerned about this threat. Um, and we don't necessarily deal with it, and we don't know that implementers are gonna deal with it, or it's not expected that implementers are gonna deal with it. One of my, uh
… favorite examples of this is the eavesdropping problem at the pharmacy when you're talking to a pharmacist
… Um, it's a personal pet peeve of mine that, uh, a bunch of my personal medical data gets spoken out loud in front of strangers. Um, it's really not that big of a harm, but it's annoying, like, come on, guys
… Uh, but that's an external threat. Someone's looking over your shoulder, our system doesn't have a way to deal with it. Like, throughout the architecture, we don't have good ways of dealing with that. But if you're concerned about it, we identified it. It is a threat, you might. And then the fourth one are what we call dependency threats
… Which also I didn't copy the description of that. A dependency threat is that we're dependent on some other technology
… And… and there are risks associated with that technology, and we might hint at them, or we might state some scary things, some names. And in our case, um
… TLS is a dependency threat, or tampering on the channel that is addressed by TLS is a dependency threat, so that's very weird
… Sorry, made me existentially question what I was just saying
… There's a threat of eavesdropping on the channel of F1 when we do Resolve
… We address that threat by transferring it to TLS. And so if you're concerned about TLS, you should go look at that
… Um, and so threats that TLS creates are dependency threats. As an example
… Um, so I… I actually… all these proxy things that I created
… I'm not sure if their implementation… Um
… Threats, or external threats
… Um… So that's that's a weird question. We're we're gonna have to noodle through
… But let me stop there. And this was initially submitted by Steve
… Um, so this is a threat. It will be formatted and put in a prettier, uh, disposition in the repo, in fact, using, um, this JSON architecture and this rendering tool that we're using
… But I'm open for feedback. I see Phil, you've got a raised hand?
Phillip Long (GU, ASU): Yeah, I just wanted to know, are you suggesting that where there are threats that are not addressed by the… by the… the Reddit resolution spec, and you've mentioned several of them so far that aren't specifically because...
… They're either completely external to it, or, as you just described, the TLS threat. Is there going to be a section that is dedicated to those things, just to bring it out, rather than… Inserting them wherever they happen to appear
Joe Andrieu: Yes, that is in fact what the external threats section is...
Phillip Long (GU, ASU): Okay, that's what that is. Okay, that's what I need to clarify. Thanks...
Joe Andrieu: And so, one of the reasons I currently have, um, these proxy… Things...
… Um, and actually, I think… I think, Steve, we duplicated this one. I think this is the same one. Um
… So that'll be interesting to dedupe. Um
… Is that our spec does not define proxies. Normatively. We don't have a mechanism to secure that. Um… So, I don't think the spec deals with proxies
… We could call it an implementation threat if our belief is that implementers might use proxies
… That would be a good reason to move it up to implementation threats. Um
… But you don't have to use proxies. So… Uh
… I'm not sure which one it would go in
… I think right now
Phillip Long (GU, ASU): Where else would they… they appear? Where else would you use a proxy?...
Joe Andrieu: Either… right now, I think implementation or external...
… Like either we're saying it's external to our spec or it's an implementer's choice and therefore it's on the implementer whether or not they're proxying. Which feels a little bit more correct to me right now. Just curious how folks… Thank you. Go ahead, Steve
Steve McCown: Yeah, so there...
… Part part of the part of the concern, especially with these internal external threats. Is we don't always know
… as… as users or builders, um, developers of the system, where… where the threats actually originate. So if we go to a cloud service. for resolution
… It's not always going to be clear to us that they virtualized that and farmed that out to another resolver. Um
… and then we're just getting. We're just getting back the result, and we tend to trust that the result is is correct because we trust the 1st resolver. But if they virtualize that process and sent that out
… we don't know anything about the other resolvers, so it's not just a matter of our choosing a good resolver that we trust, it's being concerned about their internal operation. And all along that path. Regardless of how many times that might be relayed. Um
… There's opportunities for surveillance along the way. I've heard some resolver projects talk about collecting analytics for resolution requests and so forth
… And and that being a good thing from
… The way they talk about it, they talk about it being a good thing. I'm saying it's a bad thing
… Um
… that um
… you know, like Google Analytics, that's the way the web's monetized, and so they're looking at it as from that light. But then from the user perspective, or the developer perspective, that's where these surveillance tampons. I can't speak. Tempering and repudiation threats start to emerge
Joe Andrieu: Awesome...
Steve McCown: And the reason they're in here, even though some of the threats might say they're external threats, is because they still need to be handled here. They still need to be addressed. I mean, we didn't go all the way down...
… to say, you know, if your operating system's insecure, please patch it. I mean, that kind of goes without saying, but some of these borderline cases, even though the threat originates externally, there's something that we can do about it
… Locally. Anyway, this is my thoughts
Joe Andrieu: Yeah Thank you Steve That helped me really see these proxy threats as implementation threats. Um, precisely because the end user may not know. Um, and so, when they choose a proxy. Um, I mean, when they choose a resolver...
… These are matters of how did that resolver implement their resolution process like, are they doing proxying or not? So that to me, I think, moves it away from external into implementation. But an example potentially of a good external threat
… Uh, which I'm not numbering or highlighting because it's not fleshed out, would be using this on a shared computer
… Right, so if you're trying to use DIDS on a public library, um, or on someone else's phone
… uh, you know, a different… whole different, uh, set of problems arise. Um, and in much of the world, we do have shared compute devices as normal, so it is an interesting and challenging threat, and I don't think we do much about it. Like, I don't think our spec
… I don't think we as a community have spent a lot of time trying to solve that problem or contextualize how we might solve that problem together. So I think that's an example of an external threat. Okay Any other thoughts or I'll continue on?
Otto Mora: Marcus, Marcus was on the queue. Sorry...
Joe Andrieu: Okay, so the… I realized, uh, although these… Oh, sorry. Go ahead, Marcus...
Markus Sabadello: Yeah, I just want to say something about the proxying. I think I share all the concerns and all the comments about...
… Proxying, or relaying, or surveilling, or tracking the resolution
… behavior. I just want to explain that in the current specification there's a subsection about proxy resolution
… and
… it's important to understand that at least the way the specification is written right now, we sometimes have local resolvers and remote resolvers, or local bindings and remote bindings. And if I
… invoke a local resolver, for example, an SDK or a command line interface that would, in the current specification, that would be considered a resolver over a local binding, and then that resolver calls a remote resolver over a remote binding
… then essentially I have a local component, which calls a remote component, which then performs resolution. And in the current specification, that is also considered proxied resolution, even though
… there's just one remote service, right? I call one remote service, and that remote service does not call another remote service, but it's still, at least the way the specification is written right now, that is also considered proxied resolution, because I call a local resolver, and that calls a remote resolver, so there. There are two, two
resolvers. Just wanted to mention that
Joe Andrieu: Yeah I appreciate that That is in fact why those sections are marked at risk. I don't think we as a community have come up with any consensus standards about how you deal with that...
… There is text in there. Personally, I think it violates our security model, but that's not what we're going to dive in today. That's a longer conversation we're going to be having about those sections. What I want to do is capture the wisdom of those sections without making it look normatively like this is how you should do it
… In fact, I want people to be encouraged to not violate our primary security dynamic by proxying
… So let's let's talk about these proxy threats
… Um, uh, I… we have a deeper argument there, Marcus, to have in a civil manner. Uh, I just don't want to do it right now. So, I appreciate that input
… Okay, let's… I'm sorry, did you respond, Marcus? I didn't want to cut you off
Markus Sabadello: Yes, yes, I'm just trying to explain...
… That, uh
… I don't know, are we against remote resolvers altogether, right? Because
… The the current specification does not
… talk about remote resolver calling another remote resolver. I think some of the concerns and some of the arguments and some of the threats have to do with a client calling a remote resolver which then calls another
… remote resolver but that's different from a local resolver calling one remote service. And. I'm not sure if
… If we correctly distinguish between that in the
… in the conversations
… And so if you're saying you want to mark proxy resolution at risk or we maybe want to drop proxy resolution or we don't want to support proxy resolution, then I'm just saying the way how the specification is written right now
… that would eliminate all of… all remote resolvers. It would only then allow pure local
… resolution, and I don't think that's any… what anybody wants. I'm just explaining this. I'm actually agreeing with, I think, with you on what we want and what we don't want
Joe Andrieu: Well, I disagree with what you just said because we can get rid of proxied resolvers without the problem you introduced, but I really don't want to have this conversation right now, but I see Steve raised his hand...
Steve McCown: Yeah, so what we're doing, firstly, remote resolvers have been super useful...
… And the work you've done for the universal resolver is super useful. What we're identifying here is not that remote resolution is bad
… just that there are some risks associated with it that need to be mitigated. Um, so if we… if we figure out, um, good ways to mitigate those… those risks, then what this document does is say
… is, um, tell future developers, hey, if you're building a system and you're using remote resolution, there are some risks that you'll want to encompass. So, um, that doesn't mean that remote resolution's bad, just that if we… we need to mitigate those risks. the notion of of
… Relayed proxy, like, like, um
… uh, resolution site that forms out to another resolution site by virtualization. That creates a different set of risks
… And our job is to not say that any of those is inherently bad, just that we need to mitigate those risks, and we don't want to lose sight of them. as future developers create new solutions
Markus Sabadello: Yeah, yeah, I totally agree with that. And and we we should have a definition of what we mean by proxy resolution. So we mean the same thing. Oh, thanks...
Joe Andrieu: Cool...
… Um… So, uh… Moving on to the next one. One of the things I said just a few minutes ago was, oh, it looks like these are duplicates
… Because I was forgetting that number one is about the fundamental that the resolution service provider, regardless of whether they're proxying or not
… They could watch your your data flow, and they could get information from that. These next 4 are all about proxies, and we do, in fact, define what that means in a lightweight manner. But that's what's different. This is directly talking to a resolution provider
… And surveillance by proxy means that you've got a proxying resolver who passes an incoming resolution request to another resolver before passing the result back
… enables the initial resolver to observe all traffic to all proxy resolvers So they'll they'll get to see all the did methods that you are resolving even if they don't have the ability to resolve it directly. And the responses we have for this are there's direct resolution. Uh, local resolution… Um, which we've already talked about
… Well maybe we haven't talked about direct resolution So in this in the context of proxying, if my if the server I'm talking to for example doesn't know BTCR two it doesn't want to talk to Bitcoin, but it knows that hey there's another BTCR two resolver that will proxy to
… And then we'll go get the result and bring it back. In that case, my opinion based on our security model is that the original caller should directly call that BTCR2 resolver It should be their trust choice
… So, and that's what direct resolution means. So there is some… there is some resolver out there that's capable of doing it, so let's just call them directly. Um, that's this response R4. Local resolution we've already talked about, um, and I made a note that this is likely a repeat. Um
… Um, you can put in your terms of service that there is no proxying
… That's one potential answer
… Uh, terms of service, no tampering. That is not part of this one
… So let me mark this. A different color
… The threat here is just surveillance, right? So it's not tampering. We have another threat to address that. Another response is duty of care. Duty of care and duty of loyalty were inspired in part by what's going on in Utah because there is an opportunity to change the law
… And you might change that through a lawsuit that establishes case precedent, or it might be by statute, which is the path Utah is navigating through, which is pretty amazing. So duty of care is about how they treat sensitive data
… So, hey, you know all these dids I'm resolving. That creates a burden on you to take care of that information appropriately. We do this in other domains, but it's one of those things that follows society. It doesn't drive society. So eventually we will have some sense of what's the appropriate duty of care
… Right now, none of that really is is out there. Like
… Service providers use our data willy-nilly in all sorts of ways. And so duty of care is currently under-defined, under-socialized, and under-enforced. Duty of loyalty is similar but different in that this is when you have an agent acting on your behalf
… You could argue that the service provider is in a certain way. And then it pertains to how they use that sensitive data
… So this is what they do to take care of the data, i.e. not letting it be redistributed to other folks. This is what they do with it themselves. And an example of duty of care is a fiduciary, like a doctor. They have a duty of care with your medical data
… They're not allowed to use that in their own interest and put that ahead of your interest. That is in some context called duty of loyalty. Um
… And I point out that this response likely entails both contractual elements and other legislative or court based engagement
… Because that… if… if you want these responses to exist, you're not gonna solve it in a technical problem. You gotta get out into society and pass some laws, or convince some judges, or something like that. And then, uh… the last response is trust
… Our security model depends on trusting the resolver to honestly return the result from each did resolution process. And so if we trust them
… Why don't we trust them?
… If they choose to proxy, why don't we trust that? That is an option. Obviously, based on my comments here, it's not my preferred option, but there's a little bit in this decentralized world of what I call Martha stewarding all the way down
… Right? Making your own resolver, making your own DID method, making your own wallet, um, so that you can trust it. Um, and I respect all that. Um, I love my clients who'd like to do that. Um
… But most people can't do it, frankly. Uh, they're gonna use Coinbase, right? And they're gonna say, hey, I know not my keys, not my coins, whatever, I'm gonna trust them
… Um, so that is a valid response
… So this is the first pass through of the set of proxies. And when we move on to the next one, which is tampering by proxy. Um, and that is where
… Uh, the terms of service, no tampering goes
… So I'll just inject that down there
… Obviously, we did some refactoring incompletely
… I'll clean that up later. But tampering by proxy is now that you're going through a proxy. Your results could be tampered with on the way back. So in this theoretical example where we're connecting to a resolver that doesn't want to deal with Bitcoin
… It could get the result back from a legitimate BTCR2 resolver and modify, either the metadata or the DID document itself
… And so there are a bunch of responses that are the same. All these proxying things have the option to go directly, do it locally, or use terms of service to address it. I was wrong with the tempering in the one before because that threat was about surveillance
… This threat is about tampering. And so you could have in the terms of service, they could legally agree and bind themselves and hold themselves accountable in the court of law that they are not going to tamper that evidence. That is a response. It's a transfer of responsibility to the legal system
… We're not coming up with a cryptographic or technical solution, but we're letting the rule of law deal with it
… Um, and then another response that's innovative here, right? So we sell duty of care and loyalty. These are repeat. Um, and you could, again, just trust them. So these are common to all of these proxy months. You'll see that we just have a few new things, and the other ones we're going to look at in this section
… Um, another one is signed resolution results. And I think in the… in this section, uh
… Uh, that I'm not a big fan of, Marcus. We talked about this, I think you talked about this as verified resolution?
… Um, so I tried to copy that notion, that that is one way you could address this risk
… Is that if the calling party knows the public identifiers of the proxies, proxied resolvers, they could independently check and say, oh, okay
… My resolver, which is doing proxying, is giving me results that I know are actually from those other providers. Now, maybe for operational reasons, I didn't want to go to direct resolution. I wanted to have this service bureau that has, you know, better uptime, better reliability, better whatever. I do want to go with the proxying guys
… But they're in an architecture where the resolvers they are calling are signing the resolution on the way back. Um… So that's signed resolution results
… We just haven't standardized what that would mean is really my main complaint with that other section. But this is tampering by proxy. And with that, let me pause and see if there's anyone who wants to chime in
Otto Mora: Marcus?...
Markus Sabadello: Yes, signed resolution results. We have talked about this, and there is a bit of content in the specification...
… There's also, I think, one other response, I'm not sure if you have that, which would be to include
… the document metadata and the resolution metadata from the upstream resolver. Right? So that proxying resolver could or should include all the metadata from the the other resolver that it's calling and return that to the client, and that could make it possible for the client to independently verify that the
… results are correct. This doesn't work for all bid methods, and it doesn't work for all the
… situations or all the threats, but it could be a partial response to
… to this thread. In the current specification, we, at some point, we added
… properties to the… to both the deed resolution metadata and the deed document metadata. We… we added this property called proof, uh, right? So we said that in the deed document metadata
… There could be proofs about the from the deep methods or proof that the result is correct and the resolution metadata that would be proofs about
… the resolver, the resolution process, for example, designed. signed results that you
… that you mentioned. So there is a bit of that in the specification, but maybe not detailed enough based on your analysis
Joe Andrieu: Cool. Thanks, Marcus. Um...
… Okay. Go ahead, Will
Otto Mora: Will also...
Will Abramson: Yeah, I just wanted to comment on this a little bit, um, because...
… I think, in my view, maybe it's almost like there's too much detail on this proof in the specification. I mean, I think it is a good threat response to have, but really
… I think we're just… we're just pointing at it and saying, look, this is one way you could do it. We have no examples, and we are not going to tell you how to do it, right? Like, we're just saying… I mean, in some ways, the proof property that we're defining in the metadata
… I kind of have questions whether it should be defined in this spec or not. I mean, it kind of feels like we're having a placeholder, right? We're trying to hold that name, that property name, in those objects, and saying to people, if you're going to use something that's like this, you should put it in here
… I think. But we don't have — we haven't described in our spec because we don't have any examples of how to actually use those properties in practice
Joe Andrieu: Cool. Thanks, Will. Okay, I just want to draw folks attention to the link Steve dropped in the chat about duty of loyalty...
… Um, and what Utah's doing is a nice paper about their approach and how they're framing it
… Okay, and with that, we'll move on to DOS. So proxying resolvers who pass incoming results can arbitrarily choose to deny proxy service to some or all secondary resolvers
… Um, and it could be for good business reasons, i.e. the secondary resolver charges too much
… Um or it could be malicious reasons They're just trying to disrupt, um those clients that have become dependent on that proxied results
… So we see a lot of the other proxy responses repeated. But you could also have assurance in the terms of service
… And the nature of this assurance could take many forms, but one form of it would be a guarantee to resolve all requests for specific data methods, regardless of back-end service providers. Um, uh
… That seems like maybe a really risky way to present it and maybe a service provider wouldn't quite put it that way. So I'm open to improvements. But the idea is, look, I'm not going to let you down. I'm imagining I'm the service provider who's providing this universal resolver. Um, not
… I wish I'd use a different term. I don't mean it has to be, uh, the universal resolver Marcus has worked on, but a resolver that's proxying to these other parties, and they'll say, hey, look, come hire high water. We've got, we've got so many, um, uh, did key compatible resolvers. We can, we can resolve did key for you no matter what
… Um, you know, that's kind of silly with Dead Key, but I think you see what I mean. You can… you can put it in the Terms of Service that they will not deny you service. And that's a way to transfer this risk to the legal system
… And that's the only new threat that DOS denial of service by proxy gives us. Any thoughts before we go on?
Otto Mora: No one in the queue...
Joe Andrieu: Okay, the next one is repudiation by proxying resolver. Um...
… Which is, uh, the proxying resolver may deny that they were responsible for any particular result, asserting that the errant result was the output of a secondary resolver
… So you get back a did document that was fraudulent, and somehow you were able to determine that through other factual means. The proxying guys can say, oh, I wasn't the one who resolved that. I wasn't responsible for that result
… That was, uh, that BTCR2 resolver. They messed it up. I just passed on the normal thing
… So having the proxy in the loop creates this sort of question of repudiation of who's on the hook
… For doing the different things, and uh
… The responses there are mostly the same. Um
… In fact, I don't think there's a new one in here because we have signed resolution results, which we talked about before. If they have a signed document, then that's a correct repudiation. No, that wasn't me. Look, I have signed evidence that says that this other person provided. And of course, you could have terms of service that address it
with no proxying. Ah
… That it is there. We had an agreement that you were not proxying, so you don't get to say that you went to a proxier. Like, a court of law would hold that accountable if they agreed to not proxy
… So these are the possible responses to this
… Uh, fourth proxy. Threat. Any thoughts about that?
… And I'm noticing in here, and I must have… I must have stopped copying it
… Uh, because I was sad we weren't filling it in. We don't have the components in here
… But it's going to be the same components, fortunately, for all these proxy ones
… Okay, let's get into Steve's contributions
… Uh, which I think were really great. So the first one here is correlation by overuse
… Um, also called a super cookie. Some of you may have heard this. This has been a term of art, um
… Uh, from the beginning, uh, I think, I think it was Daniel Hardman who used it most with me. Um, so I'll give him a tip of the hat to this, which is the idea that if you use a single DID for interacting with multiple parties
… Like your own you got one did I mean it doesn't have to be just one but if you're using a single did for multiple parties, then those parties are able to use that did to correlate your activity They could talk to each other and say hey, the guy with did x y z came over here It's like oh I know the guy with did x y z. He did this other thing And
now they can start correlating user activity
… And it's especially true when user activity is correlated like what's done with web analytics right now, where you pass on your log to a third party in the cloud, and they are doing this sort of correlation metrics to give back some interesting summation
… IE analytics over that data. And so now that third party is potentially seeing all the DIDs from all these people that they are providing. And that person is in a catbird seat with regard to seeing how the DID shows up on dozens or hundreds or even thousands of websites. Um
… And the only response we have right now for this is convey the threat likelihood. Um, which
… Uh, maybe as a repeat, I'm gonna put a question
… Because the description may change but
… So when people created did explicitly communicate the data use policies that's similar and repeating
… Enable users to create multiple DIDs and recommend using peer DIDs for each connection the user establishes. So that is unique to this particular, this idea of peer DIDs, or what I prefer the term, contextually unique DIDs for each connection. Um
… But that's really all we can do. Like, users can use the same data everywhere. I don't know that we have any other ways except trying to get users to not do that. Um, so if there are other responses, we'd love to hear them
… And we need to identify the components here
… Hey, Mike
Otto Mora: Yeah, I wanted… I put myself in the queue for this one, because, um, I… I personally… at least we did identity. We did, um...
… kind of experienced this as… it was something that the DID method itself kind of optimized for, like, your wallet kind of
… on purpose established, uh, different DID identifiers for each connection that you make to, you know, relying parties and so on
… Um, so I think this is, this is a great response to the enable, you know, different dids as you interact with different, uh, parties. But what I was wondering is, is, is that a different, I mean, like one, one response seems to be, yeah, like convey that this is a threat
… But isn't is another response like an R. 2 for that. What Steve is suggesting there to create multiple dids like, you know, kind of your your peer dids that he's mentioning there. Right?
Joe Andrieu: Oh, yep. Yeah, of course. Yeah, this should be its own response. That's a good call out...
Otto Mora: Yes...
… Yeah, contextual. Correct
Joe Andrieu: So, we'll deal with that...
Steve McCown: Kind of the implicate. Oh, sorry. Go ahead...
Joe Andrieu: Oh, no. I was just gonna say I'll save that for later. Like, we'll come up with a good description...
Steve McCown: Yeah, part of the...
Joe Andrieu: Just in the interest of time...
Steve McCown: Yeah, the implication of what's going on with this, the reason this is a concern is, just like everybody wants your cell phone number or your email address today. Um, when DIDs are more prolific, that's what they would be correlating on...
Joe Andrieu: Yep, agreed. Okay. Looking at the next one...
… Correlation by data exchange. So even if you use contextualized unique DIDs with different parties. It can lead to correlation if in the context of those DIDs, the user exchanges additional correlatable information
… So, uh, for example, sharing an address in order to receive a product, like, have Amazon ship you something, um, allows anyone who got that address to correlate the… the user. And so, if I go to a bunch of different sites, and I'm… I have to
… Give them other information because maybe they require me to like, oh, they've got to do KYC. So I have to upload my driver's license, but I'm using a unique DID to log into that site. They now, of course, have data that they can correlate. So it doesn't get rid of all the risks in this world of a sea of information where lots of things are
going around
… Um, so this is just a heads up. Like, hey, you…you can…uh, use contextually unique DIDs, it will help, but it is not the silver bullet that solves everything. That's basically
… what this is saying to me. Um, and we only have one response right now, uh… Which
… Uh, we could also have… so, and that response is duty of loyalty, which is a repeat. Um, I think we also have the response of, um… Uh, some terms of service. Um… And it don't correlate
… That we could write up. That's… that would be another response, is that the
… The parties agree, you know, we're not going to correlate or we're not going to distribute it. Et cetera
Otto Mora: On this one, I'm wondering if, um...
… I mean, part of… it seems like the threat is kind of two things, right? One is like, yeah, the reusage of the DIDs enables the correlation, but I think you're also saying
Joe Andrieu: That's right...
Otto Mora: If you're also exchanging correlatable information, like I'm sharing my driver's license ID or address or something, then you can correlate over time, right?...
… um… I wonder… uh-huh, go ahead
Joe Andrieu: And… and with… and with other parties...
Otto Mora: And with other parties...
… I'm wondering… Like, one response could be, depending on the type of data that is being requested, you know, you could use zero-knowledge proofs or selective disclosure of data. To mitigate
… That and and, like, zero knowledge proofs with unlinkability, I might say, maybe because just
… It's useless if you're always, showing the same ID and it becomes, linkable
… But depending on the type of data that's being requested, you could… We could perhaps do something like that. For this one
Joe Andrieu: Yeah That's good Um and as we write it up I'll tea I'll try and tease out whether or not there's something meaningfully different between zero knowledge proof and selective disclosure...
… But data minimization, right? That is also one of the things. Like, everyone should just ask for less data. That is a potential response. So we can describe that and flesh that
… Um, okay, noting the time, um, we… well, that's actually pretty good. We've… we've got just one more to go over. Any more thoughts on that? I guess I didn't want to rush on. I did want to rush on, but realizing we've got a little. Okay
… Um, and then 26 is spoofing after trust on first use. So, you prove your control over a DID, and then that's, uh, treated as proof of identity and subsequent interactions. Um
… And you demonstrate control of the DID by control over the private key. But if the device that holds the DID and the keys is compromised, then the malware or the attacker could be asserting control of the DID by virtue of its control over the key. So, um… Even though it was robust when we we did the tofu, the trust on first use
… After that, the user could still spoof you. So there's a heads up. Like, hey, even though you're using DIDs on both ends, there are still ways that the person presenting the DID and even performing the proof of use ceremony, the challenge and response
… Uh, they could still… there are still ways to hack that, and so this is just a heads up about that
… I don't know that we have any other response than conveying this fact is possible
… And that's what we wanted to go over today
… Okay. So feel free to raise your hand if you have thoughts as I wrap up
… Uh, I will incorporate the feedback we got here. You know, we got some things that made partial notes, and we will update that. And then, um, Steve, I'm hoping, uh, you and I can get another half a dozen or so. uh, threats to consider next week. Um, and I'm hoping that between those two sets
… uh, we'll feel like we have something complete. Um, and if we don't, then we can identify the holes. Um
… Uh, and flesh it out. I… I invite people to come to this Google Doc and flesh out the items that are already there. So, we… we have used this document to enumerate. Um, uh, we had a session, uh, where, you know, we just wrote up a bunch of stuff. Um, but they all need to be fleshed out. Um, so we welcome contributions. Um, doesn't need to
be a PR, you can just dive into this Google Doc, uh
… Um, and we'll do this again, hopefully next week, if that works for the chairs
… Ah, okay
Otto Mora: Excellent, uh, thanks, Joe. And Phil did have his SKU, I wanted to… I don't know...
Phillip Long (GU, ASU): Yeah, real quick, because we're at the end, but I just wanted to point it out, and I put it in the...
… Ah ah
Joe Andrieu: Uh-huh...
Phillip Long (GU, ASU): Chat in, um… that there is an intensive focus at the moment on putting DIDs associated with AI agents, many of which are intended to be very ephemeral lifespans...
… And, um… and so the question of… that you raised about multiple DIDs is… is… has a subset of multiple… of DIDs that are ephemeral for particular specific interaction uses and the like
… Um, in the context of… of a delegated set of responsibilities that a set of agents are working on
… And I think that's probably going to need to have some attention given the context of where we are at the moment
Joe Andrieu: Yeah, that's really interesting. I don't think any of our conversations to date have...
… Even contemplated, where does AI create new threats? So that is a good flag
Phillip Long (GU, ASU): Yeah, it's… it's… at AIAW, they have the meeting after the meeting that's all about AI agents and… And that's been a major topic there...
Joe Andrieu: Yeah, I think a lot of that's problematic, but that doesn't change the fact that it's a big part of the conversation...
… Um, I think that's my sense of a lot of the stuff that goes on in our world, like, people are doing crazy stuff
… But the fact that they're doing crazy stuff is in response to, you know, things that are happening in the system, and people trying to figure it out, so… Hopefully we can figure it out together
… Yeah. Yeah, that's a good call out
Phillip Long (GU, ASU): Yeah, if nothing else, raise it, just be aware of it, because people will… will immediately look at this and say, but you forgot, and not realize that, of course, we… we thought about it, but since there's no real answer yet, we haven't… what are we going to do other than say that we're aware of it?...
Joe Andrieu: Okay. I think that's a wrap, then...
Otto Mora: Thanks so much, Joe. Thank you, Steve McCown, as well, for contributing. Thanks...
Joe Andrieu: You're welcome. Talk to you otherwise...
Steve McCown: Thank you everyone...