Episode Transcript
Speaker 1 00:00:07 Welcome to the rubric. I'm your host, Joe Andrew
Speaker 2 00:00:10 I'm Erica Connell.
Speaker 3 00:00:12 And I'm Eric shoe
Speaker 2 00:00:14 Today on the rubric. We talk with Daniel Hardman of CPA, editor of the did peer specification and drum and re of ever now a proud part of Avast. A leading implementer of did peer to get the inside scoop about widest method exists. And when you should consider using it, this is part one of a two part interview with Daniel Hardman and drum and read the continuation of the conversation can be found in our next episode.
Speaker 4 00:00:45 Even Alice and Bob are complicated
Speaker 1 00:00:49 On the rubric. We meet the people, making decentralized identity a reality. We discuss the technologies and motivations behind decentralized identifiers, which encompasses DIDs, did documents and did methods so that you can make better decisions about which did method is appropriate for your use.
Speaker 2 00:01:07 Decentralized identifiers enable robust identity based services without dependence on a trusted third party. Instead of being forced to use centralized identity verification services like Facebook, Google, or the department of motor vehicles, DIDs can be created by anyone anywhere and be used for any purpose.
Speaker 3 00:01:27 Did methods are the magic ingredient that gives, did their flexibility before creating any specific? Did you first choose a did method, which determines how you perform the create read, update, and deactivate operations on a did of that method once created each did includes the name of its method in the identifier itself so that when you use the, did others know how to retrieve the associated did document that contains the cryptographic material for secure interactions, different did methods use different underlying mechanisms with different performance security and privacy trade offs?
Speaker 1 00:01:58 This show the rubric reviews different did methods with their creators and implementers. So you can make better decisions about when and how to use DIDs in your applications.
Speaker 2 00:02:09 Daniel Hardman is a contributor to the verifiable credential and decentralized identifier specs. He helped launch Hyperledger indie and the sovereign foundation and has become fascinated with mesh networking and other decentralized protocols that don't use blockchain. He currently works on digital cash at CPA.
Speaker 3 00:02:28 German. Reid is chief trust officer at ever co-author of the book self-sovereign identity from Manning publications co-editor of the w three C decentralized identifiers 1.0 specification in co-chair of the trust over IP foundation governance stack working group, as well as the concepts and terminology working group.
Speaker 1 00:02:50 Welcome to the show. Thanks for having us on
Speaker 3 00:02:53 Really looking forward to this.
Speaker 1 00:02:55 Well, we're thrilled. You can join us. The did peer method was the first did method I knew of without universal global resolution designed to facilitate direct one to one DDS. Only those parties to the peer can resolve the did no one else even knows the did exist much less, how to get to the did document making did peer arguably even more decentralized than ledger based DIDs. So let me start off with our first question for all of our guests. What exactly is did pier
Speaker 4 00:03:28 Well, it's a way to create and share DIDs and the features that DIDs are supposed to have most of them, but as you pointed out, there's some that, uh, we, we turn off with this method, but anyway, you share most of the, uh, features of other did methods, but you do it without, uh, basing your trust on some form of Oracle that supports a lookup. So instead you communicate the state that is important to your peers, and because you've communicated it in a provable way, they know what your intentions are and they can therefore resolve your dead, find out what keys you're using, find out about end points or any other kinds of things that you'd expect to get out of a, a did based, uh, interaction, but they are not consulting an external source to do it.
Speaker 1 00:04:25 Great. So is it, is it fair to say that with did peer, as long as you have a communication channel between you and the other party, then this lets you bootstrap up a did resolution mechanism that only the two of you know about
Speaker 4 00:04:41 Yes, exactly. Right.
Speaker 2 00:04:43 And how did did pier come to be?
Speaker 4 00:04:46 Well in the early, uh, months of my intersection with the self sovereign identity space, I remember having many conversations. These were conversations internal to ever ni and also at conferences, uh, like rebooting web of trust. And I, I w with lots of other smart people in the space and the assumption that kept coming up over and over again was we needed, did to be written somewhere so that other parties can, you know, look it up and, uh, be confident. They're talking to the controller of a particular identifier. And I believed that story and repeated it myself many times. And I still believe it's a true story. In many cases, I'm not critical of that story, but it occurred to me part way through my learnings that most DIDs that I expected to create for myself happened to have this characteristic that I wanted to share them with one other party.
Speaker 4 00:05:52 I wanted to basically partition my identity and be Daniel, the member of the sailing club and Daniel, the employee and Daniel, the citizen and Daniel, this other thing, whatever I wanted to carefully partition out my identity. And that was step one in my realization. Um, and then step two, um, was that I realized if I partitioned out my identity, then the party that needed to look me up often changed from any arbitrary entity out there in the space to the specific entity that I wanted to talk to in this constrained relationship. Now I'm describing this as if it were all my own epiphany, but in fact, I should give credit. There were a lot of people that articulated this, um, particular insight Drummond who's on the call said as much several times, um, Jason law, who was the CTO of ever at the time, also started talking about this.
Speaker 4 00:06:59 And Jason started talking about the concept of a micro ledger. This was the idea that you get the same benefits of ledger based consensus and, and, uh, tamper evidence and so forth. But you get it in a much narrower context than a global one. And at the same time, there were a bunch of, uh, conversations that were starting up in various blockchain communities. So the lightning network in Bitcoin land, and, oh, I forget what the name of the corresponding, uh, function was in, uh, Ethereum. Anyway, they were talking about, uh, taking things off ledger to optimize. And, um,
Speaker 1 00:07:53 I think that was, did, did you port,
Speaker 4 00:07:55 Well, this was not in the did context yet. This was just general Ethereum community conversations about how to like, you know, process transactions faster by doing some of them offline and then, or how to run smart contracts offline and then bring 'em back onto online, all kinds of things like that were happening.
Speaker 5 00:08:15 It's the general, um, in the blockchain community, what they generally refer to as layer two protocols.
Speaker 4 00:08:20 Yeah. Yeah. So anyway, um, all these different kind of evolutionary tends of thought were happening. And then I got an assignment to work on how a particular party might communicate with another party. This was an architectural question. If, if you knew that party a and party B each had a did, what exactly would you do to send a message from one party to another? And, um, that forced me to answer some questions about what it meant to be a peer and it kind of triggered a determination to write a did method. Um, this was soon after rebooting web of trust seven in Boston, where we kind of wrote the, the first description of what did methods should look like in general in the abstract. And so, uh, not long after that, I started working on a did method that had this peer characteristic.
Speaker 3 00:09:24 So I think we've heard the unique aspect of did peer, which is this lack of global reliability. Maybe I'll toss this one to you first Drummond. What would you tell is the main advantages of did peer
Speaker 5 00:09:35 Great question, because it's become quite a rich specification. I believe Daniel, the last time I looked there are at least 12 contributors. Maybe it's up to 15 or more.
Speaker 4 00:09:45 Yeah. Something like that.
Speaker 5 00:09:47 And it's grown fairly rich in terms of, you know, additional features that people are seeing are needed, uh, in peer tope relationships from the standpoint of what we were doing at ever. And the talks I give about did architecture and did methods. I separate broadly the buckets of ledger based ear methods from peer to peer based did methods. The number one reason for that separation is privacy that as, as Joe said, in, in the, uh, introduction, I think very accurately that, uh, with a peer did relationship, nobody knows about, you know, the DIDs let alone the keys or the existence of the relationship or any of the communications in the relationship, except for the peers. I wanna say one thing and make sure Daniel clarifies it. That makes it sound like it's just for, you know, one to one relationships. My understanding is Daniel. You can use a peered method among a groups of peers if you also, uh, want to do that. But we primarily focus on one to one. I I'm correct on that, right. Daniel
Speaker 4 00:10:52 Sure. You can use a peer did method, for example, in a nuclear family, you've got seven people who all want to address each other by commonly understood, uh, identifiers, right? Um, you could use peer DIDs for three business partners who are in a relationship. You could use peer DIDs for six members of a seal team that are trying to communicate using did based high tech, uh, communications. And they would be talking to each other, but you don't want their signals to leave. Uh, you know, the, the little peer network that they're running, there's a lot of different use cases, but they all have that characteristic in common, which is that it's a relatively small group of people that already have some reason to be introduced to each other.
Speaker 1 00:11:41 Cool. I love that set of use cases. One of the things that the specification states is that the spec uses a protocol rather than a public Oracle as the root of trust. Can you explain how that, how a protocol could be a root of trust and what does an Oracle mean?
Speaker 4 00:11:59 Okay. An Oracle is something that you consult to get wisdom. You can't get any other place, I guess. And the role of an Oracle is satisfied by a blockchain or something like unto it, a distributed hash table or similar in most did methods. So when you want to find out what is the did document for this particular did in your resolution work, you ask the Oracle the question in a peer relationship, let's say Alice and Bob are friends, maybe they're dating. And Alice now wants to know if this message that she got really came from Bob. It's been a few days since they talked. She heard that Bob had maybe been hacked. This message looks a little bit strange. She wants to know if it really came from Bob. How does she find that out? Well, the simple and straightforward answer is she asks Bob <laugh>, does she have a way to do that?
Speaker 4 00:13:00 You know, in that kind of relationship, that's a practical answer in a relationship where Alice and Bob don't really know each other, don't have any reason to consider themselves peers. Maybe it's not a practical answer, which is why pier did, does apply in some cases and doesn't apply in others. So, um, let me just comment further on the, the idea of the protocol when Alice or Bob wants to evolve their state, how do they notify the other parties in the system that the state is changing? Now? I just did something a little bit funny with my sentence. I said Partee, but I was giving an Alice and Bob example that only had two parties in it. But one of the things that we learned from pier did, at least it was a learning for me, is that even Alice and Bob are complicated, probably Alice has an iPhone and a laptop and maybe a presence in the cloud, and maybe she has a tablet.
Speaker 4 00:14:03 Bob might have something similar. So when Alice decides she wants to update some keys, we, we make the simplification in our language that we say Alice is updating her keys as if there was only one set for Alice. But in fact, in many cases, Alice might really be updating the keys only on let's say her iPhone. So Alice needs to notify, not just Bob, the singular individual, but all of Bob's devices. And similarly, she might need to notify the other Alice devices in this relationship. So there has to be a protocol that reliably transmits data and guarantees that knowledge spreads in a way that you can trust the knowledge that you have, just like you would trust the answer of an Oracle
Speaker 3 00:14:56 To stick on this idea of the protocol. One thing that kind of stood out as you're reading through the did Pierce spec is the frequency in which did come pops up. How does DICOM relate to this protocol being used as a root of trust? There, some special elevation that you give did in this formulation of did peer
Speaker 4 00:15:13 Did peer does not depend on DICOM and DICOM does not depend on did peer. Having said that there is a tight affinity, because if you think about it, if did com is a communications technique that uses DIDs as the basis of its trust. And if we just said we needed a protocol that would guarantee in a trustworthy way that parties to a relationship find out about anything that's happening in the relationship. We've just stated two problems, domains that have an awful lot in common. So the peer did spec describes how Alice must notify Bob. And it says one way to do it is with DICOM. It's possible to do it without DICOM, by using, for example, TLS over, uh, the web and so forth. But if you do that, you can't just use familiar web security, uh, to authenticate a party. Because the question that's going to be asked when you transmit a message over this protocol is not, does Alice with her web login want this change to happen, but does the controller of this did want the change to happen? And in order to answer the question about did control, you have to be down at the level of looking at did documents and so forth, which just happens to be what did com does. So it's a, a natural affinity, but it's not a, a dependency
Speaker 3 00:16:52 It's a one way in which this trust can be established, but it's not a required method. You could do it in other ways, similar ways, different ways.
Speaker 4 00:17:01 Yes.
Speaker 1 00:17:02 So the spec calls out three different ways named methods zero through two, cuz you're all good programmers and start counting at zero
Speaker 4 00:17:11 Can't help myself. I start counting zero now,
Speaker 1 00:17:15 Not a liberal arts major. I'm guessing.
Speaker 4 00:17:17 Oh, oh Joe. I graduated with an undergraduate degree in Spanish
Speaker 1 00:17:23 <laugh> oh wow. So C those <laugh>.
Speaker 4 00:17:28 Exactly.
Speaker 1 00:17:28 So those three methods are ways that you can create the initial D document. Could you walk us through those three different methods just at a high level and how they're different?
Speaker 4 00:17:39 Sure. One of the methods is intended to exactly parallel. The functionality of did key, which I imagine you have already discussed on this podcast. So I won't go into it in great detail, suffice it to say that if you want a peer did that you are going to use for a limited amount of time and your content to have the peer did be static. That is, it will never be updated. And if you don't need, uh, to communicate in your did document, anything about endpoints, then you can do method zero, which means basically that in the value of the did, there's a particular character early on that has a zero in that space method. Zero has exactly the same description as did key and is a shameless copy of it. Explicitly says this is intended to be the same thing as did key. And the reason that we did that is first of all, did key has some nice virtues that I'm sure you've talked about. But secondly, we wanted did peer to provide an upgrade path so that you could start with something simple, like it did key and you could get it slightly more sophisticated if you needed to. So anyway, that's method zero, if you use method zero, all of the characters in a did peer, did that come after that zero character are identical to the characters that would come after the colon that separates did key from its, uh, method specific identifier. Does that clear enough? Should I go on to the next one?
Speaker 1 00:19:24 I, I think I followed that to reflect back that method. Zero has a zero in the name, so you're identifying it in the identifier. And then what follows is functionally in fact, perhaps exactly the same as what the, the value would be for a did key in that same portion of the did.
Speaker 4 00:19:43 Yes. Literally the value of the did peer is exactly the same, whatever it is, 32 characters or whatever that would be at the end of did colon key colon something. So that's method zero and the did document is identical as well. It's not just the value, but the, the rules for the did document and they're guaranteed to be aligned because the definition in the did peer spec is see the did key spec. We're not just re-articulating the rules we're literally referencing them or incorporating them by reference,
Speaker 1 00:20:18 By the way, how, how do you deal? Or have you thought about how you deal with versioning on that? Should the did key spec change?
Speaker 4 00:20:25 Well, the method, uh, numbers that I'm going through zero one and two exists so that we can, we version did peer. And I think what I would say is if did key changes in a significant enough respect, we would create another, another number, you know, besides one and two, maybe there would be three and three is, did key version two or something like that. But I have not thought about that in great detail.
Speaker 1 00:20:52 Okay. Sounds like a reasonable approach.
Speaker 4 00:20:54 Okay. Um, the second method of, by the way, I'm calling these methods, because what we're talking about here is a method of specifying the initial state of the did each of these letters corresponds to a different way of specifying that the first way is exactly the way of did key. Namely, you look at the value in the did itself and you generate a did document in a very algorithmic fashion, the second way to do this the second. And I'm, I'm using the word method here in an overloaded sense. So maybe I'll try to avoid it. But the second mechanism for generating did documents is to communicate the initial did document in a message to the other party, but bind the did value to the hash of that initial did document in a way that proves that the did document and the did were created at the same instant.
Speaker 1 00:21:55 Okay. So it allows this initial did document in a way that did key doesn't
Speaker 4 00:22:00 Right. And because it allows it, it brings in a number of other features, for example, the ability to use three or four different types of crypto or different types of keys in the same did document. The ability to add end points into a doc did document if you want them and things like that. And the other thing that's notable about this approach is that if you have started with an arbitrarily defined, did document, you now have the option of evolving your did document using the protocol that we were describing at a high level earlier. So if Bob wants to tell Alice that he has rotated his keys, he can send her a Delta, assuming that the peer did, he gave her was one that supports deltas. And that would be this kind that I'm talking about right now. So the third way that you can express the initial state of your did is that you can essentially encode a few very carefully chosen arguments as if they were in a query string. We call this the initial state approach. And what this does is it's like a compromise position between did key style logic and a full blown did document with arbitrary structure. It makes it possible to create a did that does have an end point and does have arbitrary keys. You don't have use the signing key and the encryption key, uh, based off the same seed, but it doesn't allow you to express arbitrary deltas later.
Speaker 1 00:23:59 Interesting. So you're embedding just some of the properties of the did document rather than a hash of a full unbridled did document.
Speaker 4 00:24:08 Exactly. And these are numbered in the order that we specified them. So basically the first one, which has the, the number zero as its identifier was the first one we did. And it's the simplest, it's the did key. And, and then the second one is the most ambitious, uh, that's the one that has the number one as its identifier. The third one we decided to specify was this intermediate compromise. And, uh, we learned through experience that the compromise would be welcomed. And so we made it,
Speaker 1 00:24:45 So you had said for this third method method two, that you can't update or provide a did document after the fact. So only method one has that feature
Speaker 4 00:24:56 I'm pausing here because I did not write that particular part of the spec. That is my understanding, but now you're making me a little bit nervous. <laugh> I, I better go and, and check that quickly. Oh, um, yes, that's correct.
Speaker 1 00:25:14 Interesting. Okay.
Speaker 3 00:25:15 And so while we're on the topic of these three different creation methods, Drummond gonna toss this one to you, uh, as an implementer, but if someone were looking to use, did pier, is there any guiding principles you could provide for when to choose to use each of these?
Speaker 5 00:25:30 The large dividing line I use is between what I call a FAL relationships, a FAL DIDs, and persistent did relationships peer to peer relationships, whether or not they're persistent for very long times, or just a relationship that's meant to be ongoing for some period of time, I think. And, and I want Daniel to comment on that being the, the primary distinction, the, the, a fair, uh, option being as lightweight as you can get, again, the similar sort of the peer tope context for something like dead key. And, but the other, the other bucket being entirely about how do you maintain that ongoing relationship of which a key component literally is the ability to rotate keys over time is just it's it's good security practice. It's good, uh, hygiene. And it provides flexibility to be clear. There's one more facet besides just key rotation. There's obviously, uh, portability the ability to be able to move your bid wallet slash agents that are com communicating, using the protocol to add new wallets and agents, as Daniel described, most participants in pure did will not be participating from a single device.
Speaker 5 00:26:42 I'm taking, you know, we're talking about people organizations. So you've actually got a, a group I'd like the term. I think it was Daniel first, uh, coined it, your agent army. Each of us has an agent army. And, and, and we need to be able to communicate very, very efficiently to the troops and our agent army and communicate, you know, as a whole, as an agent army with the other agent armies that we're connecting to. So I like the term, cuz it suggests, never think about or always think about the possibility that the other peer is spread across multiple devices, maybe in multiple locations. And that immediately suggests why the protocols is much more sophisticated than just the very simple diagrams that I tend to show when I'm presenting it in some conference
Speaker 1 00:27:28 That has some interesting residents for me with, I think it's, Minsky's Marvin Minsky society of the mine, but that notion that inside your brain, there isn't a single one AI process running, but you have all these different processes that are doing the different things that your brain does and in different interactions, some of them come to the fore and are dominating your behavior. And so I see this as an, as a aversion of that sort of ation into our devices. You know, my memory is definitely my phone. I only know one person's phone number other than mine. And that's the person I live with <laugh>, which is weird, cuz I barely call them. But you know, part of our, our cognition is moving into these devices. So I think this sort of notion of the period of your devices or the army of agents, I think is really important.
Speaker 5 00:28:15 The funny thing, uh, Joe, is it, it fits directly with your functional definition of identity, which is fundamentally, it starts with recognition, right? And that recognition that you're actually talking to a portion of the other peers, agent army is a little bit like, yeah, I have one thought process connecting in my brain to one thought process connecting in the other person's brain. And as you know, it it's like, oh, that might not be the right thought process, but you'll figure it
Speaker 1 00:28:46 Out. Yep. Yep.
Speaker 2 00:28:48 Will you walk us through the update process for did pier?
Speaker 4 00:28:52 Uh, yes. You know, the update process is it's inspired a little bit by the way Google docs works. If you think about, I think many of us have had the experience of having five or 12 people all in the same Google doc and having many of us write at the same time in that document. How does your view of that document get updated in a way that never generates merge conflicts? It never generates, uh, confusion about what the correct thing is to display on the screen. Even if two of you are, are fighting to, uh, edit the same line. The nice thing is that one of you will win and your view of the document doesn't get confused. It picks an answer and says, this is the answer. That particular technique is called a conflict free replicated data type C P R D um, actually
Speaker 1 00:29:55 C R D T
Speaker 4 00:29:56 C D T, excuse me, conflict, uh, conflict free replicated data type. I just gave you the wrong acronym, but I
Speaker 1 00:30:05 <laugh> that's
Speaker 4 00:30:06 Right. Anyway, it's not just Google docs that does this, but um, it's work on things like Google docs that kind of popularized the technique. So what has to happen in a case where Alice has multiple devices is each device needs to be able to contribute its own deltas. And there needs to be a mechanism for deciding whether to accept a Delta from Alice's iPhone that possibly changes a different key from a Delta on Alice's iPad. And even though you aren't sure what is the relative sequence of those two changes? Does that make sense?
Speaker 1 00:30:50 My question is so when you're working with like object transforms, which is the general algorithm that Google uses for CR DTS and, and uh, Google docs and such the ordering the temporal ordering at Google servers in fact matters quite a bit. So how do you separate the resolution through time of these different transformations from this notion that if they're out of time, it doesn't matter?
Speaker 4 00:31:16 Well, one of the insights that I had is that although Alice's iPad and Alice's iPhone may both want to change her did document at times that cannot be reliably sequenced by an outside observer. They shouldn't have the authority to change the same things in the did document. So Alice's iPad should be able to change the iPad's keys. Alice's iPhone should be able to change the iPhone's keys. And if you are able to isolate those two things, then it's actually under most conditions, but not all conditions. It's actually the case that you can afford to throw up your hands and say, I can't tell which happened first, but it doesn't matter because the outcome is clearly the following <laugh>. Now there are cases where the operations that two different devices want to do conflict with one another, but those cases can be solved by the way that you assign privileges in your D document.
Speaker 4 00:32:23 If you tell others that in order to change your route signing keys, you must have, for example, an M of N policy, three of my five devices must agree before my route signing keys can be changed, then whether Alice's iPad or Alice's iPhone was the first one to propose a change. Doesn't matter. It only matters when you get to confidence that three of her devices have agreed. So the protocol that we're talking about here is a combination of general purpose replication and C R D T logic with some specialized insights about under which conditions is it safe to partition updates for certain parts of a did document? One of the things that the peer did method does is it disallows certain arbitrary structures in a did document because they create merge conflicts.
Speaker 1 00:33:25 Ah, interesting. So you have some constraints above and beyond those in the did cor spec,
Speaker 4 00:33:29 Correct?
Speaker 5 00:33:30 I just wanna point out that is totally allowable for a did method to define a subset of what is, uh, it has to meet the requirements of the did core specification, but it doesn't have to implement everything. It has. It has to meet the Mo, but it can define a subset of the possibilities of a did document.
Speaker 4 00:33:50 A simple example of this is that pier did says that you cannot reuse the meaning of an ID. So if you give a name or identifier to a particular key, and you say the value of a key with this ID is X, you may not in a future version of the did document say that the value of a key by that name is now why all you can do is you can delete the key that had that particular identifier and add a new one with a different identifier.
Speaker 1 00:34:24 I'd argue that's actually covered by the, the definition of ID adjacent LD. So IDs do have to be unique in the document.
Speaker 4 00:34:32 Well, they have to be unique at a particular point in time, but I'm not sure that they have to be unique across all different, uh, successive versions.
Speaker 1 00:34:42 Ah, that's a great point. Yep.
Speaker 5 00:34:44 I believe that's correct that they, at any one version, the IDs all must be unique, but if you version the doc and reassigned an ID that was unique in one to a different element or property in, in the subsequent version, I don't think that's a conflict I can see where that could be a problem in certain did methods, but I don't think that would be valid use of the ideal element.
Speaker 1 00:35:07 Yep. That makes sense to me,
Speaker 2 00:35:09 Daniel, we heard from you a little bit earlier about how you got involved with this work. So drama and I wanna hear from you about how you got involved.
Speaker 5 00:35:17 Well, I, I don't do the, uh, the coding of any of this. I'm not actually a coder. I come to the design of these kinds of architectures and protocols more from treating them as products and, and acting like a product manager and a hurting a herder of the brilliant architectural minds like, uh, Daniel. Uh Hartman's and, and I do wanna acknowledge, as he did earlier, the numerous contributors to did pier, it is very much, I think it's almost a, a prototypical example of a, a community developed protocol where it's just, you know, better and better by virtue of all the contributions, the use case, the need for it, once it, once the light bulb went on it, you, you know, you can't unsee it. The, the fact that we, we all at least myself coming to this space, blockchain was the inspiration for all of us to say, Hey, we could now have these decentralized identifiers and Hey, they have this root of trust that is not centralized, depending of course, on the, on the rubric, uh, of the particular blockchain or distributed ledger or verifiable data registry.
Speaker 5 00:36:26 It was just one of those next leaps to then recognize that you didn't have to consult one of those as an external Oracle, that it could work peer tope. There was starting to emerge a very particular problem that also we were becoming very interested in the solution for really, really searching for. And that was the issues with GDPR and personal data. A D I D as an identifier, even if it's completely P anonymous is still very clearly. I have it from all the legal authorities that I've consulted in relation to GDPR still considered personal data because it can be associated with an individual. And that means everything in a dead document can also be part of that personal data associated with an individual now by itself, I do not believe, and I believe that the EU commission and EU regulators will eventually acknowledge and hopefully make explicit that it is acceptable for an individual to choose, to have a, what I generally call public did on a, a blockchain or imutable ledger and maintain it there.
Speaker 5 00:37:40 And that, that will fall under the exemptions for some of the data rights granted in GDPR like the right of erasure veteran known as the right to be forgotten. But leaving that aside, what became clear was that having an option for being able to use the power of DDS and did to did connections without having to deal with that GDPR issue was very advantageous. And did peer fit the bill beautifully because the relationship was in the hands of the two parties. If the other party was what under GDPR is considered a data controller, an organization that the sharing of that peer did, and the peer did document would clearly be under the responsibility of that data controller to manage the relationship with you. If you wanted to exercise the right of erasure, not only could you do that and they could delete all of that without any issues about, you know, imutability of a blockchain, but there was this big, wonderful bonus that you had a very clear way to send an authoritative message a directive to the organization, the request to exercise that, right, that you could document and prove on your end, you could maintain your own audit log of that.
Speaker 5 00:38:55 And so could the organization, we received this message requesting erasure on this date from, you know, the signature verified to the peer did, and we followed through, we have complied. So it became a very clear GDPR compliance mechanism that frankly, I think the, the EU and the privacy commissioners throughout Europe should be doing cartwheels over. And, and I think that they are, they really have warmed up. I mean, there's more investment going into SSI infrastructure, uh, decentralized identity infrastructure in the EU than anywhere else in the world that I'm aware of. Um, it's, uh, in the order of tens of millions of euros. And that's because it really does, I think align well with the goals of GDPR.
Speaker 1 00:39:36 Yeah. I love that use of cryptography to facilitate compliance with GDPR in some ways it's the end of the relationship that matches to the consent receipt work at the Canera initiative, where when you begin a relationship, well, how do we have a record of that on the individual side, right? And so that exchange can bootstrap, you know, the purpose, the purpose binding for the information that was exchanged and provide a record. Well, I love that this, on the other side, we can do the same thing with regard to retaining the request forsure and the signatures sort of provide a level of accountability. That's far stronger than any individual database that some company says, look, they submitted something on our webpage, it's in our web log. So
Speaker 5 00:40:18 Absolutely I, in fact, I I'm just thinking we should start calling it a termination receipt, right?
Speaker 1 00:40:24 Yeah. That's not bad. You heard it here first.
Speaker 2 00:40:28 That's the end of part one and concludes our show today. The conversation continues on our next episode.
Speaker 1 00:40:35 Daniel, thank you for joining us on the show today. Drumming. Thank you. Thanks also to our staff, our producer, Erica Connell, and my co-host Eric shoe. I'm your host, Joe Andrew,
Speaker 2 00:40:47 Wherever you find the rubric podcast, please take a moment to subscribe to our feed. So you'll be notified when our next episode is released. We look forward to you joining us next time. The information opinions and recommendations presented in this podcast are for general information only. And any reliance on the information provided in this podcast is done at your own risk. The views, thoughts, and opinions expressed by the speakers in this podcast belong solely to the speakers and not necessarily to the speakers, employer, organization, committee, or other group or individual.
