Speaker 1 00:00:08 Welcome to the Rubric. I'm your host, Joe Andrew.
Speaker 2 00:00:12 I'm Erica Connell.
Speaker 3 00:00:13 And I'm Eric Shum.
Speaker 2 00:00:15 Today on the show we talk with Troy Rhonda, editor of the DID Orb Spec, and Mike Farley, who's been building the DID orb implementation at Secure Key Now and Avast Company. This is part one of a two-part interview with Troy, Rhonda, and Mike Valey regarding DID Orb, the continuation of the conversation can be found on our next episode,
Speaker 4 00:00:39 I think it lets us, uh, address the issue of, you know, networks of networks
Speaker 1 00:00:46 On the rubric, we talk to folks making decentralized identity happen. We chat about the technologies and motivations behind decentralized identifiers, including DIDs did documents and did methods so our listeners can make better decisions about which did method or methods are appropriate for your use.
Speaker 2 00:01:05 Decentralized identifiers enable identity-based services without dependence on a trusted third party. So instead of using 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:25 Did. Methods are the magic ingredient that give DIDs their flexibility before creating any specific, did you first choose a did method, which specifies how to perform the create, read, update, and deactivate operations on a did of that method once created each did includes the name of its method and 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
Speaker 2 00:01:51 Different, did methods use different underlying mechanisms with different performance security and privacy trade-offs.
Speaker 1 00:01:59 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:11 Troy Rhonda is the editor for the DID Orb Specification and leads the Trust Block Development Teams at Secure Key in Toronto, Canada did orb implementation is part of trust block. Troy was chief scientist at Secure Key and is now Director engineering.
Speaker 3 00:02:28 Mike Farley is the Director of Architecture at Secure Key Technologies and has been involved in digital identity authentication, payments innovation and solution architecture for 10 years. Before his work at Secure Key, Mike
[email protected] and the wireless telecom startup, Soma Networks. He has a passion for distributed system design, security, and end user privacy, as well as making these complex systems accessible to non-technical individuals. Mike is a co-editor on the Open ID Connect igov Specification.
Speaker 1 00:03:02 Welcome to the show.
Speaker 4 00:03:03 All right, thanks for having us.
Speaker 5 00:03:05 Yes, thank you. Glad to be here.
Speaker 1 00:03:08 Did Orb is a ledger agnostic, did method that enables averse of federated, verifiable data registries, combining Side Tree and certificate transparency. So let's start with our perennial opening question. What is, did orb,
Speaker 5 00:03:28 Right? So, so did Orb is a did method that's like you said, based on Side Tree leveraging the excellent work that was in the Decentralized Identity Foundation and from, you know, very, very good folks in the Side Tree Working Group. Our motivation behind Dior was to enable, uh, a side Tree based did method that did not have a coupling to a particular D L T or d H d. Our, our motivation for that is, um, to, to reduce the dependency on, on ledgers so that we can increase interoperability and enable, uh, basically a network of networks that, that doesn't require every participant to choose the exact same D h T in the exact same D L T or blockchain or, or related technology.
Speaker 4 00:04:19 So I think I'd just like to add in there, uh, the part of the motivation for DID orb was to make DIDs, uh, a little more accessible to large partners who, you know, depending on your, your backing, uh, <inaudible> technology, uh, may have challenges picking up a solution based on either a public blockchain like Bitcoin or, or even a, a, a private blockchain. Like something like, uh, Hyperledger Fabric, where suddenly they have to find engineering expertise and security expertise around those. So Dior's motivation was to abstract away some of those challenges so that the properties of a, uh, of a diar are, are maintained and that there's, there's a recorded history of its changes, but also, uh, you know, provide the, uh, cryptographic benefits for, for having decentralized identifiers. So, uh, that was kinda the motivation, uh, behind Dior and, and why when Troy, you know, was, was noodling around the idea. I was, I was excited to hear about it because it, it kind of solved some of our customer problems they were having, picking up the technology around DIDs.
Speaker 2 00:05:23 Can you walk us through how you create Reid update and deactivate a did? Orb did?
Speaker 5 00:05:31 Sure. So, um, those operations are actually in common with the side tree specification. So similar to DID methods like did ion, um, you actually create a SCI tree operation for create, for recovery for deactivate as specified, um, in the diff specification for that to do resolution, we expose the universal Resolver endpoint from the orb servers. So that's, uh, a very standardized way to actually make a request as a light client to resolve a did. Of course, the server itself is reconstructing the sign, did operations create, update, recover, et cetera, um, to actually construct the current state of the DID document. And, um, like I said, di Orbe is following the, uh, side tree specification for the format of those operations for the signing of those operations for the, uh, chaining of those operations together using what's called commit reveal schemes.
Speaker 1 00:06:33 Commit reveal schemes. Okay. So some of our audience will not have heard of Side Tree or not be familiar with how it chooses to implement, create, read, update and deactivate. So could you dive a little bit deeper? Like what's the first thing you do? Sure. Create that. Any particular dit orb?
Speaker 5 00:06:50 So I think that the important thing, especially in a side tree, um, related method, and one of the reasons we picked Side Tree is because of the property of self certifying. Self certifying means that the, the did identify itself has a cryptographic link to the initial state of that did. So what was, what was the initial DID document that was created, um, has a hash, the hash of that. The initial state is actually in the identifier itself, because you have that, that, that initial state, that means we can chain upwards. So, um, we can update that did document, it will point to the, uh, the, the next transaction, which might have been the initial state and, and and so forth. So the important thing here is the self certifying property and the ability for each operation to chain back or chain forward through a verifiable chain to that initial state.
Speaker 5 00:07:45 Um, inside tree. The DID owner or did controller, depending on your terminology, is fully responsible for their, for their document history. They have the keys that actually sign the updates. Um, and when we say commit reveal, what that means is each time you do an update in, in Cree and of course in orb, you are committing to the next key that will sign the next update. So when you provide the next update, you're actually revealing the key that was, um, in the, in the commitment to commitment to the hash of the key. Um, you sign your next update with that revealed key and that actually forms the verifiable chain between the updates.
Speaker 1 00:08:25 And is that commitment to the next key is, is that unique to Dior or is it sort of how any VDR manages the control over a given, say, on chain asset or asset in the registry?
Speaker 5 00:08:40 Mm-hmm. <affirmative>. So, um, not every DID method would be using that kind of scheme. Um, some did methods may use, uh, a consensus approach or other approaches to deciding, um, what is the next valid state how to, how to authorize the next valid state. But the commit reveal scheme is in common with other side tree, um, uh, based methods. This is not defined by orb and it is in fact, uh, defined by the side tree specification.
Speaker 3 00:09:06 Section three of the DI orb spec calls out four different types of di orb DIDs, these being orb canonical did or long form did orb scheme did, and orb metadata did. What is the difference between these and could you give a brief overview of their intended purposes?
Speaker 5 00:09:24 Sure. So in, in, did orb, um, we can start with the canonical DID identifier. Basically the canonical form is containing the DID suffix. And again, I, I'm, I'm using side tree terminology a little bit. So if you're unfamiliar with, um, side tree, I'll have to give a bit of an explanation. So the, the did suffix is the hash of the initial state that we talked about before. That's actually the, the, the part of the string that gives you the self certifying aspect. What's a little bit different about did orb in comparison to, um, other side tree methods is that there's an additional component to the DI string, which is the hash of what we call the anchor file. The, the anchor file is actually what's providing the knowledge of, uh, the relationships between batches of DID operations. And, and again, I apologize because batches of DID operations is another kind of backing side tree concept.
Speaker 5 00:10:23 Um, so lemme just take a little digression there a sec. So in in Side Tree, the way side tree works is did owners are submitting, um, a, a change to their did to, um, some side tree server. Uh, again, those could be create updates recovers, um, the server is actually batching a bunch of did operations together into, um, one batch that it ends up propagating in some of the, the side tree methods that that batch of, uh, did operations is then, um, hashed and then propagated on a blockchain. So, as an example, you can use a blockchain like Bitcoin to actually propagate knowledge of a new, um, batch of data operations. And when a server that recognizes that particular blockchain sees that new, um, hash available, it can then pull down that, that set of operations and then apply them. So in side tree methods that are coupled to a single, um, blockchain, you don't have need for any other, um, components to the disc string because, you know to look at, um, a particular blockchain and you know that the, there's a single ordering to that blockchain.
Speaker 5 00:11:34 You just follow the blockchain. Exactly, and you'll see the new batch of DIDs coming in when you don't have a common, um, blockchain to rely on. Um, you actually need to record that, um, that link between batches in a different location. And in orb we're recording that to a structure called an anchor file. So the anchor file is, is saying here's a new batch of DIDs, um, similar to how you would see it in another side tree method, but then additionally it's also providing the links to previous batches that are related to the current batch in the form of a hash link. Um, and it also uses, um, witnesses to provide timestamping of when the batch actually occurred. So we can get into witnessing kind of later, cause I want to get back to the, the question at hand, which was what's the difference between these different DID strings or, or types of did strings in Dior?
Speaker 5 00:12:33 So coming back to that question, hopefully with this background I can get to that now. Um, the canonical is actually the, um, the did suffix like inside tree with the hash or effectively the hash of, um, the current anchor file. So that when I see this, um, did come in and I don't recognize that suffix, I can actually go and find, um, the anchor file that's associated to that hash, pull it down, and then actually understand what is this did suffix. So then I can download, um, the previous batches that are, um, uh, prior to this operation and we'll get into a little bit further in the orb details. I can find out what is, um, what we call the anchor origin associated to the DI from those side tree files. And I can query the anchor origin to actually find out what is the latest operation associated to that particular di.
Speaker 5 00:13:30 So once I have the latest, then I can actually, uh, pull down all the operations that come before, verify the entire chain and get to the current state of the DID document. So that's, that's what the canonical is giving you. So if you had a common D H T, um, of course you could just go to the D H T, uh, uh, uh, D H D being a distributed hash table like, um, I P F S, I can just query, um, the IPF f s network, pull down that file, uh, and then go forward. Um, so when you're on a common D H T or a common storage network, you don't need anything other than the canonical identifier orp. Now, if you're not on a common D H T and you don't recognize that particular good suffix, you actually need some hints to tell you where to go.
Speaker 5 00:14:15 So in orb we had the goal of not actually requiring this single D H T or the single blockchain. So we've actually enabled a few different schemes of how you can, um, actually discover these anchor files. One of these schemes is https, of course, being, um, a very <laugh>, obviously common way to download files. So one of the schemes is actually saying, um, hey, you can put, uh, a domain name into the did, uh, with h gtps s and then from that domain I can actually go and discover some orb servers, um, who would have knowledge of both the anchor hashes and the di suffixes. You can actually include, um, IP n s as well. So if you don't wanna use h g TPSs, it's okay. Some orb servers can, um, support IPF FS and I P N S instead. And some orb servers might just say, I only support H GTPS S and that that is their decision.
Speaker 5 00:15:08 So that covers, um, the canonical that covers each TPS and related, um, schemes like that. Then, then there's one other one that's called longform. This is actually coming off of the side spec where you can not only include the hash of the initial state in the did, but you can actually include the initial state itself. Um, so, so some side tree methods are implementing this, this version of longform, and now the question is like, why would you need, um, a longform did, and this is basically because some side tree methods have a long delay between creation of the DID and when, when, when it will actually show up on a blockchain. So as an example, if you're thinking about Bitcoin, there's actually, you know, multi minute delays between, um, actually writing something <laugh>, uh, to, to a Bitcoin block and then it's showing up. And so you can get around that kind of problem by actually including the initial state in the DID stringing itself.
Speaker 5 00:16:07 And, and when you do that, um, you can actually have the did document available immediately. So we, we did put that into the, into the orb spec, just to say that that's a possibility. Um, but in orb, we, we generally take a little bit of a different approach, at least in the implementation in that instead of saying, um, you need to put the initial state into the string, the orb servers are maintaining a cash of unpublished operations. And because we put a hint in there, but where you can find or related updates and, and side tree operations, the resolving client is actually just able to go back to that, um, originating server and then download this date instead of having to actually put into the string. So although we put it into the spec, you know, our implementation doesn't really use that long form so much. We, we actually concentrate on using, um, caches of unpublished operations. You can just download.
Speaker 4 00:17:00 So Troy, can I jump in there? Um, I wanna help explain the motivation for that particular feature in the way that we're using DIDs in our Verified me network and in trust block, we, we have a user kind of in a transaction involved in a transaction, and if they create a did to represent, you know, their, their digital identity and a credential, there's a user expectation that that's gonna happen quickly and they're gonna be able to use that identifier, uh, right away, which means that it needs to be resolvable right away. And so when that's communicated from, you know, a holder and then communicated to say an issuer or a verifier, if they have the long form, did, they can associate that with the individual, but then, you know, do they have to keep that long form forever or, you know, uh, how does that resolve, you know, once it's actually anchored and there's a shorter form for that, did that, the user may come back to that issuer verifier with. So there's this kind of synchronization problem of I want to create a, did I want to use it right away? It needs to be resolvable now and it also needs to be resolvable on the same identifier down the road. So orb had this challenge of how do we, how do we make this a little more real time and consistent for the edge servers so that our, our use cases, uh, so that our use cases can, you know, be be more interactive with the user.
Speaker 5 00:18:24 Yeah. And, and just, just a little, a little bit more on top of that is, um, another, and I know we're like really far from the question at this point, but, um, caching is actually an important piece of orb that is quite different from, from I think the other side tree implementations. Um, so because we did caching, um, we, we don't only support the create operation for this more real-time, um, discovery of changes, it actually applies to any update, right? So when you think about longform, it's, it's really only for the create operation. When I'm initially creating the di I can have quick access to it, but that does not help you with updates. Um, for updates you will have to wait the propagation delay in the network. Um, whereas with, OR because we have caches of these unpublished operations, it behaves exactly the same way with updates as create.
Speaker 5 00:19:14 Um, if you know the or originating server, you can actually query it immediately and get access to those unpublished operations. Now, because, because, uh, side tree operations are not based on consensus of the network, they're based on this signing scheme where each update changed to the previous and all the way back to create, um, we're also capable of having resolving clients revalidate that chain themselves. So not only do we give the DID document in these situations, we also give the chain of operations that led to that did document, and that means the client themselves is actually re able able to revalidate all the signatures back to the initial state in this way, reducing the trust that you have actually in, in the backing network, the need for the trust in the backing network.
Speaker 3 00:20:03 Thanks for the long detailed answer. I'm going to attempt to summarize real quick, which would be that effectively the orb canonical did is the expected string that is used for, for normal operations. Then you have the orb long form, which solves this kind of upfront time delay problem that some of the VDR may have so that you can make use of your new DID immediately. And then you have orb scheme did and or metadata did, which are really more about the discoverability.
Speaker 5 00:20:34 Yeah, it, it, it, the scheme points you to the storage of the anchor files, right? So again, because orb is not coupled to a particular blockchain like Bitcoin or a particular content addressable storage or D H t, like I P F S having the metadata and the scheme, um, enables you to actually find those, those anchor files. Perfect.
Speaker 1 00:20:58 So help, help me understand the metadata relative to the scheme. So the scheme, I understood there's a little helper that will tell you what type of, uh, anchor like that it's I P N S or I P F S or what have you, but how does the metadata do something similar?
Speaker 5 00:21:14 Right? So metadata is isn't actually a separate form of the did, um, it's actually just a sub, uh, component of the scheme, right? So, okay, you wouldn't actually separate scheme and metadata. What metadata is doing is the exact same thing as, uh, if you know about hash links, um, hash links being, uh, the hash of the document you want, and then some metadata that is basically saying where can you find it, right? Um, this language here is, is actually the same as the hash link language, um, which is saying you can in the dis string include the hash and then have a colon separator like in hash links and then supply metadata about where to actually find that that document. So that, that's useful in, in, in like the hash link scheme of course. So that, that's why you actually see the, um, the did string structure set up that way. Uh, again, it's, it's not a different kind of did stringing, it's a, it's just a sub-component of, uh, of a scheme.
Speaker 1 00:22:11 Okay. Uh, that helps a lot. If I am using a scheme, did, is it possible for me to have two DIDs where the hint is different? Are those different DIDs?
Speaker 5 00:22:26 No. So, so this is actually why the canonical string was set up this way. So, um, you can have, you know, many different equivalent DIDs and you know, if, if you actually go to the, um, um, the orb getting started tutorial, you'll actually see examples of that in the documentation, um, where you can have an equivalent did that's, um, you know, using the HTTP scheme that another one that's using like a hash link scheme, another one that's using IP n s scheme. And when you resolve all three of those, they'll return the same canonical identifier in the resolution result and they'll return one or more, um, equivalent identifiers, um, depending on the preferences of that particular resolution server to expose that.
Speaker 1 00:23:11 In my opener, I mentioned both the fed averse and federated verifiable data registries, but so far I'm not sure I understand what federation or the fed averse means for did orb from what you've shared with us so far. So how does that connect in?
Speaker 5 00:23:29 Sure, I mean that, that's definitely a good point. We've really been covering these scenarios where you actually don't need <laugh> any federated, um, connections because you can simply download the anchor files based on discovery from the the did itself, right? So we haven't delved into what are these scenarios where you actually even need, um, further propagation between the servers. So when we talk about fed averse, right, that that's actually basically ta that term is taken from these implementations that are on top of activity pub, um, another W three C uh, recommendation. Those, those, um, systems are typically like social network alternatives, um, that are, you know, also trying to get out of centralized, um, the usage of centralized platforms. But again, for social media reasons, um, tho those, those systems are basically allowing users to sign up to a particular metaverse node and then those nodes can actually interconnect with each other and, um, start sharing things like, um, your social, your social media updates among those different servers that now have become interconnected.
Speaker 5 00:24:38 So in, in, or we actually had the same intention, right? This idea that I can actually set up a, a did server, a decentralized identifier server, um, I can start publishing identifiers from that server, and then somebody else can create their own decentralized identifier server. Um, and then these servers can start publishing your identifier changes to each other. Um, so of course this, this has this nice advantage of, um, when you start publishing changes to each other that you immediately have the updates available and you don't need, um, discovery, right? It's actually an alternative to things like A A D H T because all of the servers that are following each other actually have all the updates and can actually just resolve based on the canonical identifiers without hints. So that, that's the reason why we have, um, activity pub for, for that portion. It's basically saying, here's a push mechanism for the updates, whereas the discovery pieces in the ditch strings is more of a, a pull mechanism, but there's actually a, a kind of a separate reason for, um, this kind of structure.
Speaker 5 00:25:42 And that's because we are also using that protocol for what we call witnessing. So what, what we have in, in the anchor files is actually saying a, a witness server that says, oh, I've seen this, this, this anchor file before, and they record it to their, to their MONITORABLE logs. Um, and we're actually using an activity pub message for that called offer. So basically we're saying we're, we're enabling different servers to sign up as either a follower to get propagated updates about identifiers or to sign up as a witness, uh, to that system. And when you sign up as a witness, we're also sending these messages that say, Hey, we have this new batch of DIDs that we're about to publish. Um, can you sign off that you've seen it and promise to put it into your log within a certain amount of time? They'll sign off and say, yeah, we promise that we're gonna insert this into our log in this amount of time.
Speaker 5 00:26:33 Uh, with, um, a proof that they send, I'm back. And when we propagate these updates and, and actually store these anchor files, we're including that, um, signed proof from those witness servers actually into the, um, anchor file itself. So when somebody comes later and sees this anchor file, they'll actually know, um, these set of witnesses have, um, seen this, this hash, sorry, seen this anchor file before they've, um, included into their log within the certain amount of time that they promised that you can then check later, by the way, and then go forward. So we're using this fetti structure for these two reasons. One of them again, um, as a way to message witnessing, um, information between, uh, did server and, um, the witness and back, um, and also to propagate and push updates, uh, among a, at a followers, which enables you to not need things like discovery. If you know that, um, you're, you're sharing the did between servers that are actually doing that follow operation,
Speaker 4 00:27:31 I think it lets us, uh, address the issue of, you know, networks of networks. And if you have certain, you know, organizations, small organizations who get together and they, they build a network for their use, um, and maybe they're on different sides of the country and they don't even know about each other. Uh, but then as their networks grow in, in popularity, you know, they find out that they actually wanna start, uh, exchanging, you know, DIDs with each other or trusting each other's DIDs, uh, in an efficient way, then, then, you know, this, this structure allows for these networks of networks to kind of grow and, and, and trust each other in a dynamic kind of way. So I think that was the, that was the motivation and approach.
Speaker 5 00:28:12 Yeah, and totally, and, and if we go back to kind of the intro remarks that was, you know, again, what we're trying to get to that's saying, Hey, how do we actually enable a network of networks, um, without this dependency on everybody in those network of networks choosing the same blockchain, choosing the same DLT technologies, choosing the same dhts? So how, how are we gonna do that without that requirement? And without that re without having that requirement gives us the, um, ability to actually have much better interoperability because you don't force everybody to make everybody to make that choice. And again, this is how we came up with orb because, um, at the time we couldn't just say, yes, let's, let's pick a, uh, everybody who's gonna participate in, in our network, um, go use a, you know, a, a public blockchain to do it right. Um, so instead we have this orb structure which, uh, uh, gets rid of that requirement altogether and, and gives us the network of network properties that we need.
Speaker 2 00:29:08 Did orb is the second did method that we have looked at that uses Side Tree, the previous one was ion, what are the key differences between ion and orb?
Speaker 5 00:29:19 Yeah, so I think we've covered some of that, um, as we've been going, of course, right? So I think the most important <laugh> difference between, uh, orb and ION is, uh, orb is not based on Bitcoin and I P Fs. So I ion is, you know, very specifically targeting, um, those two technologies, which is, um, a, a, a good choice, uh, if, if that use case, uh, demands it. Um, but when you're unable to choose, uh, Bitcoin and I P F S, uh, then you need a, a method that makes it agnostic, and that's what we're doing in Warp. And again, you know, I think this again comes back to this point about, hey, when you wanna do networks and networks, and not everybody can make the same choices like Bitcoin and I P F S, um, then you need a did method that supports it and, and that that's what we have here.
Speaker 2 00:30:09 Awesome. Thank you. Let's switch gears now to talk about the people of did Orb first from the, the two of you. How did you get involved in this work?
Speaker 5 00:30:20 Yeah, so I mean, we have a quite a long history, I think with, um, <laugh> with, with working with these kind of identity systems, especially coming from security and, and now at, um, Avast. Um, so, uh, initially, you know, we were evolved in, in the Side Tree working group and, and trying to figure out how we could, um, bring decentralized identifiers into the technology we, we were using, um, at the time, which was actually Hyperledger Fabric. So, um, we had actually started off with building the Side Tree Core protocol and, and Go Lang, and that's available on, on, on the Trus block GitHub. And then we were, uh, working on actually bringing that into Hyperledger Fabric. Um, but sometime along that road we kind of made this realization that we don't really need to couple the implementation to a particular blockchain like fabric, um, and instead switched gears a little bit to say, how do we make this, um, ledger agnostic, um, version that, that a, anybody can use without that, that coupling. And that's, that's where the, uh, Genesis of ORP came from.
Speaker 4 00:31:28 Yeah, I think, uh, from security, we have our, our verified me, you know, identity network that's running in Canada, uh, and the principles that that that's built on include, you know, um, unique identifiers for individuals that, that represent, you know, their cryptographic keys, which allows 'em to prove ownership over the data that they're, they're sharing. So from that, you know, source, we, as Troy mentioned, we, we started, uh, developing, uh, did methods, uh, using Hyperledger Fabric. But again, when we went to deploy it in, you know, in more broader sense when we went to new markets, um, and we were talking about just the system requirements for bringing up, you know, our, our trust block network, and if we mentioned that you had to run a particular blockchain, um, that immediately caused another hurdle for adoption where they go, well, we don't have expertise in that area, or, you know, we reviewed that particular blockchain and, you know, it doesn't suit our particular security needs at this time.
Speaker 4 00:32:23 And it became kind of a barrier, an extra hurdle that we had, that we encountered when we were just trying to get systems rolling. So, so again, when did Orb, uh, you know, when, when Troy started thinking about what we could do with, with Side Tree technology to abstract away some of that, um, and allow for organizations and groups to pick their own, uh, their own backing technology, uh, but still interop operate, I think that was the real motivation to really go ahead with it. Um, and, uh, and I think we've, we've got something pretty neat.
Speaker 2 00:32:52 My follow-up question is a little more personal. So what's important to you personally about working in the decentralized identity space? Kind of like, why, why do you do this work? We understand a little bit more about why you do orb, which is awesome. Love that. But why, why do you, like, what gets you up in the morning?
Speaker 4 00:33:12 For me, uh, it's definitely trying to make, uh, digital, you know, identity and digital interaction for people just more accessible. I, um, you know, I have obviously a technical background. I'm architect at a technology company, and so whenever I have people in my life who are not technologically oriented, uh, encounter problems with authentication, or I don't know how to use this form, or what's this identity thing, you know, like I, how do I change this? I've entered this wrong and it's, it's broken. Um, why is the system doing that? I get the phone call, um, and, and I see this, and sometimes even I struggle with this, and my current pet peeve is, uh, is if I look at the gaming industry, the video gaming industry, and all the accounts I have to make for my children in order for them to access all the various platforms they're on, I mean, it just melts my brain, right?
Speaker 4 00:34:06 Uh, and I'm in the industry. I, I know why they're asking this information and why they need it, and it just kills me. So, so I wanna make that simpler for everyone. Um, I'm motivated to do that. I see, um, you know, what we've been doing at Secure Key was primarily around federation and involving, you know, systems that you, you know, like bank accounts that you have can be used for, uh, doing things online that are not related to banking. That was our starting point, but we've since evolved, I think, uh, and I think we continue to evolve to at Avast to try and actually solve that problem for people, um, so that their interactions online and their digital <laugh> and their digital identity makes sense to them instead of just being a lost spaghetti mess of, of things. Anyway, that's definitely what gets me up in the morning.
Speaker 5 00:34:50 Awesome, Nick. Yeah, that's a, that's a great explanation. Yeah. I mean, I, I being, being a security for quite a long time, and now I've asked, I mean, I think, I think these principles of empowering the user is, is, you know, uh, very important. And, you know, that's actually what, what gets me going with this as well. Um, um, en enabling, um, digital identity, um, on the Internet's always been a very difficult problem to do well. Um, and, uh, I, I think we've, we've spent a lot of time on, um, how how do we enable, um, different forms of identity even in kind of challenging situations where there might be, um, rules that still need to be followed, but like we can enable, um, the user privacy, um, and, and, and still provide, um, valuable credentials, um, both from, you know, a, a digital wallet like we do with verifiable credentials, but even, you know, real-time forms of, um, credentials as well. Um, and do that in a, a way that preserves their privacy and, um, kind of promotes this idea that, uh, you really can validate somebody on the internet. <laugh>.
Speaker 3 00:35:58 Wouldn't that be nice?
Speaker 5 00:35:59 Yes.
Speaker 4 00:36:01 <laugh>
Speaker 2 00:36:02 Also, it sounds like the, the better a job you do here at this than the less phone calls you might get, right? The folks in your life who are like, help.
Speaker 4 00:36:11 Definitely <laugh> appreciate
Speaker 5 00:36:13 That.
Speaker 4 00:36:13 Stop calling.
Speaker 3 00:36:18 So who else was involved in the development or implementation of Dior?
Speaker 5 00:36:23 Yeah, so I think at the beginning, you know, we kind of mentioned, um, you know, this is built on, you know, the shoulders of giants. So, uh, we used as many different specifications as we could from the start. We, we didn't really want to invent any more than we really had to. So, um, of course, you know, the, the decentralized Identity Foundation was, um, an important, uh, aspect of this where we were able to work together in the Side Tree Working Group and, um, have a common specification that could actually be, um, at that level agnostic of a, of a particular blockchain. Um, the, the Certificate Transparency, activity Pub, all of these different standardization efforts have been extremely valuable. Um, in terms of, you know, uh, what we did on top, um, uh, we have a, a great team, uh, of people, um, at Secure Key and now have asked, um, uh, that have been working on the implementation. Um, the implementation's actually a very critical part of this, obviously, um, you know, in many ways more important than the spec, um, that we can have a, a stable, um, interoperable, um, fast implementation that, that we can depend on, um, which is, you know, actually on GitHub as well. Um, so, um, we've, we've had many members of the, of the, the implementation team actually working, um, tirelessly to get this thing out the door.
Speaker 4 00:37:45 Yeah, I think from, uh, the standards point of view, it was very important as we developed Orb to leverage as much, uh, that was already built and available, you know, for our, for our implementation. One of the, one of the challenges, again, when we're talking to organizations who want to get into this space, uh, you know, if we present too much technology that's new, their security InfoSec teams have a lot to dig into. When we can take something like, did Orb, and we can say it's built on standards like Activity Pub, there's an RFC for certificate transparency. Certificate transparency is already being used by browsers. When you can point to these things that already exist, um, and still maintain the properties of, you know, a trusted, uh, did document, then uh, it just makes that whole adoption a lot faster. So I think that, you know, that without, without those standards, you know, we, we wouldn't be able to build, uh, what we have done,
Speaker 1 00:38:37 As we've already discussed, a bit Secure Key was recently acquired by AVAs, which was a delightful surprise, I think, to many of us in this space. What other companies are involved in making Dior reality?
Speaker 4 00:38:51 Well, I think Twi, who else has contributed to, uh, to some of the, some of the design and code around it? Um, cuz I think it's primarily Side Tree where the interaction has been, but
Speaker 5 00:39:02 That's, that's right. Yeah. So, so I mean, that's exactly right that thus far, um, you know, the, the, the combined efforts between companies has really been at the, the side tree level, right? So, um, we contributed, of course there's a many important contributors in the Sci Tree working group that came together and made this comment spec about how do we, how do we, uh, create, did operations that are agnostic of a particular ledger and, and, and did Orb has really been kind of our effort on top of that, um, thus far. But, you know, we have been doing that, um, in the Open, it's on GitHub. Um, we'd love to, we'd love to see more, um, uh, more, more usage and more contribution to it.
Speaker 3 00:39:43 Just real quick, we have mentioned Side Tree a lot, so I did want to call out to our did Ion episode where if anyone that is listening is interested, we go into quite a bit of details, uh, with the Ion folks about Side Tree as well. Uh, so if you wanna learn more, maybe that's a place to look
Speaker 2 00:40:03 Here ends. Part one of our episode on did Orb and concludes our show today. The conversation continues in part two, and that will bring us to the end of our show today.
Speaker 1 00:40:17 Troy, thanks for joining us on the show, Mike. Thank you. Thanks also to our staff, our producer Erica Connell, and my co-host Eric Chu. I'm your host, Cho Andrew.
Speaker 2 00:40:27 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 joining us next time.
Speaker 6 00:40:39 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 speaker's employer, organization, committee, or other group or individual.
