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 two of our two-part interview about did Orb Part One can be found in the previous episode.
Speaker 0 00:00:37 I
Speaker 4 00:00:38 Think it lets us, uh, address the issue of, you know, networks of networks
Speaker 1 00:00:44 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:03 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:23 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 dead, others know how to retrieve the associated Did document that contains the cryptographic material for secure interactions.
Speaker 2 00:01:49 Different did methods use different underlying mechanisms with different performance security and privacy trade-offs.
Speaker 1 00:01:57 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 DS in your applications.
Speaker 2 00:02:09 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:26 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
Speaker 5 00:02:58 Specification
Speaker 2 00:03:00 Here. We continue the conversation. Alright, now we'll turn our attention to the hard part of creating new technologies. What were the biggest challenges as you created? Did orb, this might include political conflicts, technical conflicts, or even people conflicts, <laugh>, we'll throw that out there, but what, what were the biggest challenges?
Speaker 5 00:03:25 So, so, you know, I, I don't know if these were challenges per se. Um, I, I think, you know, the timing of when we worked on orb was actually extremely fortunate that, um, we had shifted our focus to this, this block blockchain agnostic, um, structure, um, shortly before the Side Tree V1 specification had been finalized. Um, and so we were actually able to add some of the constructs that we, we needed into that specification be before it became V1 and, and a diff ratified spec. So, uh, as an example, you'll see some properties in that spec, like anchor origin, anchor from Anchor two, these kind of properties that, um, when you think about, um, something like ION who is very specifically, um, targeting Bitcoin, um, doesn't need those properties <laugh>. Um, so we're, we are very fortunate that, um, in, in the working group, um, we, we were able to, um, get to, um, this consensus that, um, these additional properties, um, should be there, um, and, and do enable these, um, uh, uh, a did method like orb.
Speaker 5 00:04:30 So, uh, I I I wouldn't exactly call it a challenge. I mean, it was a very, a very good group to work in, but I, I think we were also fortunate on the timing, um, that we, we shifted this focus and were able to get the side respect to be flexible, um, for a method like this. At that time, I, I think, um, you know, a a a challenge that we probably had was, you know, we were quite focused on Hyperledger Fabric at the time, and I think that this challenge of thinking about how do we, how do we have a, a deep method that is not just for, um, the fabric based implementations was, um, I think the biggest challenge we, we came into when we started on this work. Um, if you, if you no longer have a common, um, backing structure like fabric, um, then you need to come up with the, these alternate ideas like, um, storing, um, the, the, the, the, the relationships between, um, DIDs into a different structure that is not actually on a blockchain at all. So I, I, I think those are a couple. And then, you know, just thinking about what are these common specs that we can pull down? What is the, what is the most common way to do like, monitoring of a log right now, like certificate transparency and, and just bringing all these pieces together, um, into a new debt did method that, um, again, is trying to invent as little as possible.
Speaker 4 00:05:49 I think I'll add some, some character there, uh, because I think Troy's downplaying some of the challenges that we've had, um, for sure. Sure. You know, we, we, we were doing a lot with Hyperledger Fabric at the company, and so then when we were proposing to switch that out for an implementation of our own, there were a lot of raised eyebrows. Like, that's a major change. How, how can we go forward with that? Um, when we were able to convince our internal, uh, you know, stakeholders that, look, this is actually a better approach. It provides us with more flexibility, but we're maintaining the trust structures that were in Hyperledger fabric and we're able to sort of connect all those dots and we were able to make progress even internally, uh, for that. Um, and then the other, the other challenge that we ran into, um, was this realtime component that I kind of mentioned where, um, we, there are expectations when using, uh, DIDs within our system that, you know, maybe, maybe the person is, is in a transaction at that time and they can't wait minutes for distributed networks to up, to update.
Speaker 4 00:06:50 So how do we solve, you know, that engineering problem and how do we, how do we drive throughput, um, for a lot of updates, a lot of creations, um, through the system, uh, and make them available, you know, in a distributed way. So a lot of that engineering, uh, had to happen and a lot of that engineering actually kind of came up at the end of the project, which <laugh>, you have to go back and look at what you did and say, oh man, how do I fix it? How do I change it? Um, but the team, uh, uh, of, of, uh, orb developers here, um, really, you know, were able to be successful and, and, uh, solve deployment issues and database bottleneck issues and, and, and message queue issues and all those things. So, uh, there, there were significant engineering challenges which had to be overcome to meet, are kind of realtime, uh, expectations.
Speaker 5 00:07:33 Yeah, I I just want to like emphasize it again, we mentioned it before that, you know, the engineering on this has, has been, I think, you know, more important than the, the spec itself. Um, so yeah, definitely a big challenge has been, especially in decentralized identifiers, how do we have, um, a highly performant did method that has, you know, real time like properties that can handle the throughput, that can handle the scale. Um, and there's been a lot of, um, engineering effort just on those aspects that, you know, is really buried, um, below the spec level for sure. You, you can see like glimpses of it when you go to see the, um, orb docu, the orb implementation documentation. Um, you can see some of the, uh, diagrams that have been put together about how we're handling, um, the implementation side. And again, that's, that's, you know, below, below the spec level. So if you just see the spec, you, you might not realize the amount of effort that went into just, um, the implementation of this.
Speaker 2 00:08:27 Troy, I might count you as, uh, an optimist or a person of positivity because, um, we started with challenges, but you kindly brought up the score, like the timing with the side tree spec was like a score. And it made me think, so I should have a question like what were the, what were the awesome things that happened along the way? Yeah, that was a really cool thing.
Speaker 5 00:08:47 And, and so, you know, working with a great community is, is important, right? Especially when we're trying to come to a common goal. Um, you know, I, I, I do, um, hope that we can get orb to, you know, a more, um, standards, um, uh, more, uh, multi organization effort. I think that'd be wonderful. But on the other hand, of course, it was great that at the side tree level, which is specifying the operations that we're already there, right? We, we have this common, um, format, um, at least at that level. So, um, yeah, it, it's great working in these, these awesome communities. Um, uh, it it, it's great that, you know, when you have new ideas even near, near the end of a spec effort that you can still, um, get them in and, and get that a spec like side tree to, um, to, to be, to be at the flexibility level that it's at, that it supports both things like Bitcoin and um, uh, a method like orb that has no blockchain requirement.
Speaker 1 00:09:42 So one of the challenges that I have, um, with did ion, um, and I believe it's a side tree pattern in general, is the potential ambiguity due to late publishing. So is it with, did orb, is it possible to prove that a given did document is the definitive single did document for did Orb did, and I think this might be a queue up for, you know, how does this witnessing stuff and whatever helps solve that problem.
Speaker 5 00:10:11 Sure. So I, I think there's a few ways to, to look at that problem, right? So, um, uh, first of all, when, when you get a did document and especially an orb, when the clients are able to re-verify the chain themselves, um, you, you know, that the entity or person or thing that had the keys, um, was the entity that actually, um, uh, got the document to the state it's at, right? So, so you do have that, that comfort that to get to the current state, somebody had to have the secrets and keys to actually make that happen. Now, there's a couple, um, of side aspects that, that you have to consider, um, uh, beyond that, right? One of them is, um, do you have the latest change, right? So just like, um, systems like Git, um, they have a, you know, a chain of operations that go from the current to the initial, and you have good confidence that, um, you can re-verify that chain from current to, uh, initial, but you don't necessarily know that you had the latest.
Speaker 5 00:11:14 Um, so orb is, is using, um, uh, various mechanisms to give hints of where you can ask, do you do I have the latest change? Um, it's doing push and pull mechanisms to, um, actually propagate the changes as they go. Um, and it is using, um, witnessing so that you can, um, have logs that are actually showing you, um, which, which, uh, batches have been published thus far. Um, the other thing you have to worry about in any side tree based method or any method that's, that's basically giving the did owner, the did controller, the full controller of their own own graph, is of course, that that did owner could produce two different histories, um, because you're following a, um, basically a graph of changes backwards if they provide a change at the same level. Um, now they've basically created a fork in their own graph, and I want to kind of reemphasize again in their own graph, it's not like some network consensus made that happen.
Speaker 5 00:12:13 It's the did owner who had the keys, um, caused the fork in their own graph. And, um, that could happen. Um, um, you know, the, the, the, the owner basically publishes a, a change, you know, a year later to try to say they didn't have that key, um, or, or something like that. Um, and, and side tree, that's basically called late publishing, and you can read a little bit about late publishing in the side tree spec itself, um, in a method that uses a blockchain to resolve that kind of conflict. All, all the, all they will say is take the first change, right? So whichever change was first published to the network, um, use that one as, as the, um, definitive, um, document. And because it's based on a blockchain, everybody will make the same choice, right? If, if I'm following, uh, a blockchain like Bitcoin and I see that batch of operations happen first, well, uh, I, I will just use that one in.
Speaker 5 00:13:07 Um, or because we don't have a blockchain, what we have instead is, um, a set of witnesses who are providing signed timestamps, um, of each, um, batch of changes. And the, the rule in orb is basically the same as these other ones, but instead of saying basically on the blockchains use, use the signed certificate, sorry, use the signed timestamps, um, that you have from the witnesses to actually resolve that ambiguity. Um, I, I'd say another thing that orb put in, and this is what I mentioned earlier, this idea of anchor from an anchor too, is the did owner can actually put into the, um, into the, into the operation. Um, this operation is only valid, um, to be published between, um, uh, certain timestamps. So, um, you can actually declare that, oh, this, this, this operation is supposed to come in at, you know, timestamp, um, one, and if somebody submits it a year later for some reason and never got published before, it'll be rejected as being stale.
Speaker 5 00:14:07 So, uh, that's, that's the mechanisms we have in orb for, um, dealing with these kind of problems. Um, to summarize again, um, many sources of where you can find the latest updates, um, the push mechanisms we have using activity pubs. So we immediately publish 12 followers. What, um, the did operation changes are so that within a network you have that list of changes, um, and the witnessing structures that actually give timestamping, um, to resolve these conflicts between, um, which operation happened first in the case that the, um, did controller themselves forked their own graph, again, not the network, the did controller did it to themselves.
Speaker 3 00:14:48 To follow up, a couple, couple more questions about witnessing, uh, within, did Orb, the first one being just a quick speck clarification, is there a difference between a, did orb witness server and a did orb witness ledger because both terms were used and it wasn't quite clear what the difference was?
Speaker 5 00:15:07 Yeah, so I mean, the funny thing is if I have to go back and, and, and see <laugh>, the specific instance, but, um, in general, I, I think, uh, when we would write server versus ledger or log, basically the server has an API that, that you can access. Um, and the, the log is, you know, uh, a particular implementation like the, what we call verifiable, um, credential transparency or V C T, um, but, uh, is, is is really just certificate transparency in the background. So Le Ledger in the spec, or at least in your implementation, is, is mostly referring to the certificate transparency slash V C T structures and, and, um, the server is referring to the APIs that are baked on top to enable orb. An an example of an API in orb for that is, um, the activity pub, um, witness messaging, um, um, mechanisms. So that's not really part of the ledger or a log that's, that's part of the server.
Speaker 3 00:16:08 What are the implications in your mind of a did orb with no witness policy or no trusted witness witnesses specified
Speaker 5 00:16:16 Mm-hmm. <affirmative>? Yeah, so I mean, uh, and the funny thing is, I, I, I, I the, you know, whether the implementation like, uh, disallows it or not, like that's an interesting question. I I think it does allow it, if I remember right. Um, but the, the, the implication is, um, if if you don't have any witnessing, you don't really have a good way to break the ambiguity in this late publishing scenario that we talked about, um, and you're, you don't have as much trust, um, that, uh, the latest changes aren't just disappearing, right? Um, of course, in orb you do have multiple layers for this. So, you know, the fact that you have been publishing those changes on, on Activity pup as a push, um, you know, it, it's kind of, you can't really just take those back. Um, so we, we already have that layer there, but, um, when you have the log of changes, um, in, in a structure like certificate transparency that are being monitored, and, and the orb servers do actually monitor each other's logs like that, um, it's, it's much harder to make operation batches just disappear.
Speaker 5 00:17:22 So, um, again, why do you have these structures in the first place? It's, again, because of the late publishing, um, problem that's described in Side Tree. So the, the, um, did owner forking their own graph and then having this ambiguous, um, choice about which, which fork in the graph to take? And we reduce that ambiguity by saying, take the first one. And if you have timestamps from witnesses and multiple timestamps at that, it's very much easier to make that choice. Um, and knowing that you have the latest, um, set of operations for that did, um, and, and that's what the witness structures are basically, um, giving to you, they're increasing your confidence, right? It's not that you have zero confidence without it, but it increases your confidence, um, that you have the right result.
Speaker 1 00:18:10 Troy, you mentioned this idea that you could specify a time bound for an update, but I think I got confused trying to figure out who is setting the time bound on what activity. Um, because when I think of sort of naively applying that to how did Ion works, and I'm looking at their late publishing problem, part of it is you don't know if it's on IPF f s in the Bitcoin context, so you can publish Bitcoin and the asset isn't on IPFS yet, and IPFS itself has no temporality. So you don't know when it's, if it could have been there last year, it could have been there yesterday, but it's not there today. So could you just unpack again how that time bound process is helping?
Speaker 5 00:18:52 Yeah, if you're, if you're applying the time bounding to a blockchain, you would put something like block height into there, right? Basically it's saying, I, I wanna see my operation included in the, in, in a range of blocks, right? When you're talking about a system that doesn't have blockchains, and as, as, instead of based on timestamping, it's basically saying, I want to see my operation published by that server, um, within some time balance, right? And you might put in like 30 minutes because the, the most important reason you're putting that in there is so that if I create my operation, and again, these operations are, um, only based on control of keys that you don't want, if, if you submit your operation, it got rejected <laugh> by a server, you don't want to see that operation basically pushed in a year from now, right? <laugh>, um, uh, in instead if if it got rejected, you actually want it to expire so that it'll eventually just, you know, go away. And so that's what the from and two properties are, are giving you that in case there was a problem or like some server claim, they're not, they, that they did not submit the operation, that that server can't just, you know, submit it later. And so in Orbits, based on Timestamping, um, in other systems, it could be based on block height, although I don't think anybody else has actually used those properties inside Tree thus far.
Speaker 1 00:20:09 Okay. So if you're using I P F S as your anchor, you wouldn't be able to have this feature. Am I following that right?
Speaker 5 00:20:18 Um, if you, so I mean, if, if we talk about, um, a system like ION that uses both Bitcoin and I P F S, um, then, then you can use it because you can specify like the, the, the Bitcoin block number, right? Um, if if you don't have any blockchain and any timestamping capabilities, then yeah, you couldn't use those kind of structures. Um, but I, I don't know anybody who has just done IPFS with Cree. Um, it's usually in combination with an system.
Speaker 1 00:20:47 I, I thought Dior you could do that. So I could dib orb with a scheme that's I P F S and I don't have a LOCKCHAIN involved. So for those di orbs, I wouldn't be able to use this temporal,
Speaker 5 00:20:58 Um, for for sure. But you, but in di orb you're combining it with timestamping, right? So, um, you, you can just write two I P F s, um, but, um, each of the servers that was creating the batches and witnessing for those batches that get written into IPF FS are including the timestamps when they did that. So because orb has that timet staffing capability, yeah, you can just write, um, the anchoring information to IPF f s and that's fine.
Speaker 1 00:21:25 Okay. Because the time is asserted by the witnesses,
Speaker 5 00:21:30 It's asserted by the, so there's actually three sources of time in, in, or there's the witness, um, when they're signing off that they've, um, signed off on that particular on scene, that particular batch of operations, the server that actually published those operations is including their timestamp, um, and via the valid from, and the, sorry, the anchor from, and the anchor two properties that did controller themselves can provide their timestamps. So, um, you, you can get timing information at all those levels. And then I'll just add on top of that, um, because we have the activity pub propagations, um, there's actually an additional source of time there as well about when, when was this, um, when was this batch actually published on Activity Poke?
Speaker 2 00:22:15 The spec says that a DID controller is allowed to set a witness policy in which they specify a set of trusted witnesses that must be used when an orb transaction has updates to the particular, did, is it possible to not have a witness policy? And if so, can you still update the did?
Speaker 5 00:22:37 Um, yeah, I mean, so, so you can basically not have, uh, witnesses in orb, and that leads to the, um, the, um, less confidence that we talked about. Um, it's, it's not that you need to have witnesses, um, but it does give you that confidence. I'll, I'll just add on to that though, that sometimes the lingo in the spec wasn't quite up to date between things like the anchor origin and witnesses, and, and sometimes the language got, uh, the same language ended up being used for both. Um, so what is important, uh, even without witnesses is for the, um, did owner to specify the anchor origin. Um, and the anchor origin is what lets the resolver, uh, have, uh, get access to a source that tells 'em what is a hint of what is the latest updates available. So of course, you can also say, well, you don't need that, right?
Speaker 5 00:23:30 And it's true that, um, if if you're in a network where every orb server is following each other, um, and receiving updates, um, you don't even need technically an acre origin. But I'm gonna guess that our implementation requires it if <laugh>, if I remember right. Um, because, uh, if everybody's receiving updates, um, you don't need to query anybody about what's the latest because, um, everybody would've already received it, right? Um, uh, because because we don't want to restrict ourselves to one particular network where everybody's tightly coupled to following each other, it is very useful to put the, for the, the did owner or the DID controller to put their anchor origin property in so that we can query even across networks. Um, and this is part of this idea that we should be able to create networks of networks and not just, you know, single, um, islands where that island of course has followed each other and knows everything. So, uh, in the end, we wanna both, right? So you can have this tightly coupled island that all of those, all of those entities in that island know all of the updates. They're published immediately. But because we've put extra properties in, if you share that did outside, um, you can discover the the DID operation updates. Um, you can find out who can supply information about the latest updates, um, even outside of your own island
Speaker 1 00:24:48 In section, uh, 4.81 on discovery. I was a little bit confused, and I think maybe it's because it's only applying to one particular scheme of a, uh, scheme based, uh, did orb, but it says a client discovers a domains endpoint for did resolution and did operations using a well-known scheme. But if I've got an arbitrary, did orb, what domain are we talking about? Like your, the example mentions alice.example.com, but I don't know how that got into the conversation because there isn't a did example, so maybe you can unpack.
Speaker 5 00:25:24 Sure. So, um, the reason for dot well known there is so that we can have a shorthand in, um, the DID string and in the anchor origin property. So instead of having to supply an entire u i, um, to, um, the, the, the side tree, or sorry, the orb api, I guess in this case, um, we can instead just supply, oh, this is, um, example.com, and if you query example.com, you can get the dot well known, and the dot well known will give you all the API ac, uh, endpoints. That's of course, like the very generic use of dot well known for any other purpose as well. Um, in Dior, how did you find the domain? Um, well, there's a few places where that domain is coming from. One of them is if you include the HTTPS scheme, that domain will show up right there, right?
Speaker 5 00:26:11 So if I get a did that says, did orb https example.com, well, I can go to example.com, download the dot, well known, um, get information about the orb servers that are associated to that domain and then query them about that did, right? So I can query them to resolve the did, I can query them to download the anchor files or the other side tree files. Um, another place where you're gonna see the domain come in is the anchor origin property that we've been mentioning. And again, the anchor origin is set by the DID controller and is signed as part of the create and recover operations. So this is actually the did owner declaring what their margin is. Um, and when you look at the, um, the, the witness messaging, you can also see domains coming in there. Um, so if you start browsing a set of anchor files, um, and, and following the, uh, transactions backwards, you may discover new ORP servers, um, and then you can query the dot well known to actually find their endpoints.
Speaker 1 00:27:07 So in, in terms of, if, if all I have is the, is the Dior did, then the only place I'm gonna get that domain name is if it's in the scheme.
Speaker 5 00:27:18 Um, if you, um, if you get a canonical did without, uh, the domain name in it, you can actually still get at that domain name. Um, and that can happen if you've been following, um, a set of orb servers and they're propagating their DID operation updates to you, and you've been applying those updates. Again, because the anchor origin is part of the Create and recover updates, um, you may have already received that information, um, via the activity pub messaging, even without having that discovery information. So if, if, if you have a network that's all following each other, you don't really need discovery, um, because that information is, is, is actually coming from the message propagation. If you're not following those servers, this is where you need discovery and with that discovery information, then somebody outside of your island of, uh, uh, orb servers, uh, you can actually query from, from outside and find that information.
Speaker 5 00:28:15 And I should add that I, I keep mentioning https s but if, if you, um, dig into a little bit, um, it, it wasn't actually limited to https s you can actually do the same thing with IP n s, right? So you can create a, uh, you can create that discovery information within IP n s IP n s is, um, part of IPF fs if, if, if you're not aware, um, and you can include that discovery information within an IP n s address and then put the IP n s address into the D orb, um, string, right? So we, we've had this, uh, ideal where we can say, Hey, if somebody who's using orb and can only use H gtps, that's fine. Um, here's how you can set this up. And then those who want to not use h g TPS can of course, um, put use IP n s instead. Um, that does lead to this interesting thing about if somebody says, I only do IPNs and somebody says, I I only do HT ps, well, of course they, they won't be able to discovery off each other, but, um, that, that was the choice that those particular servers made.
Speaker 3 00:29:15 So I think a couple of times so far, you've mentioned this term verifiable credential transparency or V C T, which I believe builds off of this idea of certificate transparency. Could you guys please just give us an overview of what this is? Um, both certificate transparency and verifiable credential, then transparency?
Speaker 5 00:29:39 Yeah. So, um, yeah, verifiable credential transparency is certificate transparency with this small change where we said, Hey, wouldn't it be great if we could put verifiable credentials into the, uh, into the Merkel tree? Um, that's defined by certificate transparency instead of X 5 0 9 s, right? Um, the, the, the, the spec for transparency was generic enough to allow for this, you can make different types of, um, uh, entries that you can put into the tree. Um, so what we did is basically defined a new, um, leaf type called it verifiable credential, basically. And our V C T server, um, is storing the verifiable credential format instead of X 5 0 9 s. So when we say that the, the orb servers are, um, storing these witness entries, yeah, the, this is being stored in verifiable credential format. Um, certificate transparency is, um, kind of a, a very well known mechanism for, um, monitoring the behavior of certificate authorities in, in the PKI world.
Speaker 5 00:30:44 Um, basically the reason that it's there is, um, if cas are all publishing the newly issued certificates, um, and, and you happen to be monitoring that stream of newly issued certificates and, and somebody issues a certificate for your domain that you didn't authorize what you can find out about it a lot faster. Um, so there, if, if you, there, there's very good information about how certificate transparency works. There's, um, this, the certificate, if you, if you, uh, search for it, you can find a very nicely, um, laid out site that's describing a lot of the details behind it. Um, the Wikipedia article is, is very good. There's, um, the, uh, R F C about certificate transparency as well. Um, and, and one of the reasons that it works so well is some of the browsers basically require, um, certificate transparency to be used, right? So, um, if you're in a browser that requires it, you'll know that that that, um, certificate has actually been logged to an independent certificate transparency log independent of the ca. Um, and if you're, again, if you're monitoring it, you'll know that the, the, the domain owner can actually, um, discover UNA unauthorized issuance of, uh, certificates.
Speaker 1 00:31:55 So what is next for data orb?
Speaker 5 00:31:59 Sure. So, um, implementation wise, we have done two release candidates. Um, and, uh, we're working through, you know, some more minor issues going forward now, uh, where we don't plan to break things anymore. Um, so that implementation is, is going forward until we get to a v1. Um, again, it's already at the, uh, RC two with, with some planning with RRC three, um, that you can actually see on, on GitHub. Um, once we're, you know, finally, um, very happy with the implementation, then we would go back and, um, basically update, uh, any gaps that have ended up in the spec, um, after <laugh> the implementation changes. Um, so, uh, then we can get the spec up to V1 and, and, and basically put the, the stamp on on orb.
Speaker 4 00:32:51 So Troy, I'm gonna put you on the spot a bit and, um, it's because I've heard that there may be some spec changes coming or some ideas around making did Orb, um, more compatible with did Web, um, I think that, uh, the did web method is a great way, very accessible way, again, for organizations to host, uh, did files, but then, um, did documents, but they, they kind of lack the, the history and, and traceability and trust that that did orb offers. So, um, I don't know, I think you've been noodling on some of those ideas on how to bring some of the capabilities of did Orb into did Web without disrupting too much. I don't know, do you wanna talk a bit about that?
Speaker 5 00:33:33 Yeah, sure. So I mean, one of the, you know, one of the concerns I always have about, you know, something like, did Orb, um, and even any other DID method other than like, did Key and did Web is how many other, um, organizations, uh, end up supporting a particular DID method, right? And this is, this goes back to the, the interoperability problems. Um, so, you know, one of the things that we thought about in did orb is the ability to, um, expose the current state of the DID documents, um, as a, as did web, um, and basically have a, uh, and also known as, or, or something similar like that in the DID web document that actually can point back at, at the underlying DID method, like did Orb, right? So basically it's saying, Hey, what if we're, um, doing did updates in, in did orb, um, and then basically nearing them to, uh, a more well-known method like did web, um, where if somebody who knows to look for and also known as, or similar in the DID web document and they see did orb sitting there in that property, you know, can they then go back to the did orb server and then re-verify that history that led to that?
Speaker 5 00:34:40 Um, particular, uh, did document state, um, and again, this is in kind of the hopes of, uh, greater interoperability, but um, also, um, somebody who sees, uh, did orb in the property there, um, can, can also then get the confidence that the DID document, uh, in the DID document history and changes, right? So, you know, we haven't really done anything with that yet, but that is definitely something we've been thinking about. Um, um, how do we kind of have these, these hybrid methods of something very simple, like did web that gives you the current state, but then also backed by the more complicated, but um, more confident, um, uh, history that led to that current state.
Speaker 4 00:35:21 I think there's an underlying theme to did orb that maybe I can highlight where we tried to make did orb as accessible as possible. Um, so you don't need witnesses, but it's good if you have them. Um, you don't need need to check the witnessing history, but it's, it's good if you do, uh, the, the theme is a little bit like you can apply as much distrust as you like when you resolve a did document as you're inclined to. So if you're a very, you know, trusting, uh, consumer of, of, of the resolution process, confident that you're talking to a trustworthy server, um, and, and maybe it's a low risk transaction, then you don't have to do all these complicated, uh, uh, verifications of, of that history and the personal graph. However, Dior has been designed in a way that, um, if you are in a de truly decentralized scenario, you really don't have trust frameworks that you can rely on and you really want to do your own homework and your own math on the reliability of a particular DID document and, and its history.
Speaker 4 00:36:24 All of these mechanisms are available. And so how do we then extend that to things like, well, maybe like a did web where did Web is very accessible, um, well understood, uh, by, by organizations that have, you know, existing P K I infrastructure, but what, what if they want to distrust it? What if you want to challenge that? Well, then did Orb provides a history that you can then, uh, you know, back up these changes with and, and have your own confidence that you're dealing with they'll Right. Did document not, uh, just a document published on a, on a web server.
Speaker 5 00:36:57 Yeah, I think, I think that's, uh, you know, very, very, very good, uh, uh, points there, Mike. Yeah, the, the design of orb has been very much on the trust by verify approach, um, throughout the whole process, right? And that, you know, more examples, even, you know, when we use Certificate Transparency, this idea that we don't have to wait for an entry to be kit be treated on a blockchain, um, when we're trying to monitor it, because that's obviously a very big scalability and, uh, performance issue. Instead, we say like in certificate transparency, um, the the log is promising to insert within a maximum amount of time. Um, and then you're, you're trusting that it's gonna do it, but then, you know, you go back and monitor that the log actually, um, accomplished it. So you, you, you trusted that they'll do it. You didn't block any operations or slow it down, um, and then you come back later and actually monitor for it, right?
Speaker 5 00:37:48 So just another example of, um, the same, the same principles, uh, in orb kind of very consistently applied. Um, and I think what we've talked about here is what's, what's the next level? And the next level is yeah, like what if we did something like, uh, did web <laugh>? So you, you get the, the did web result you trust it became, because it's from a reputable domain, but then you can go back and actually verify that history using a, a mechanism like orb, right? So that's, that's kinda the, the next logical step in, in this trust by verify approach of, uh, of orb, um, coupled with this, um, uh, goal of creating networks of, of, of networks and, and, and not forcing each network to make the same choices about dhts and, and blockchains and such.
Speaker 3 00:38:33 So I'm gonna put both of you on the, the spot here a little bit. When can we expect to see version 1.0 of Dior? Is there a timeline that you're working with?
Speaker 5 00:38:43 So, I mean, I think the, the simple answer right now is, you know, we're, we're, we very much concentrate on the implementation lately. Um, and so you, you already can get and play with and touch V1 RC two. Um, and again, RC three, we're not expecting to break things <laugh> at this point. Um, uh, in terms of, um, going back to, uh, update the, the, the spec documentation, um, I don't think we've really put a timeline on on doing those, those updates, but, um, um, it's definitely something we should, uh, be getting back to.
Speaker 2 00:39:21 How can listeners get involved with what's happening with Did Orb, where is a good place to point them?
Speaker 5 00:39:27 Sure. So, um, of, of course the, if it's about Side Tree, um, the right place is, uh, decentralized Identity Foundation, um, the Side Tree Working Group, um, if it's about Orb, um, then the current location is to, um, to go to GitHub and, and create issues and, and, and start from there. And, uh, the, the, the GitHub is, is github.com/trust block slash orb.
Speaker 1 00:39:55 Besides did Orb, what are your favorite DID methods, both of you
Speaker 5 00:40:01 <laugh> <laugh>? So that, that's a tough one, right? Because, um, favorite for me, like is, is very much based on, um, how, how, how big is the, is the DID methods audience, right? So how interoperable is the DID method makes it, you know, the most relevant for me, right? So, um, did Key and did Web are <laugh> are obviously like very simple, but um, uh, move the field forward, right? That's the important thing I think right now in decentralized identifiers is to keep the ball rolling, right? And, and, and obviously, you know, with Orb being a Side Tree method, um, and being very much aligned with, with what's in Side Tree, um, um, ION has been, you know, an, an, I think an important method, um, and an influencer method for the orb work. So it's easy to point to those. And also, um, um, the, the, the, the, the other side tree mechanisms that were, you know, based on Ethereum, right? But these are all, these are all Side Tree answers. Uh, Mike, did you have a few?
Speaker 4 00:41:10 Uh, so yeah, my, my answer is maybe kind of interesting. I mean, for sure did Key, I think I was on the did key podcast with, with, uh, RI from Transmute, uh, where we talked about did Key. I find it as a great way to pick up the technology and, and get started with it right away. Um, and then also, uh, did peer for a lot of the same reasons that I, that I, you know, like did Key, uh, and that it doesn't actually require, you know, a, a, a blockchain to, to make use of, um, but actually sort of in line provides, uh, its own its own updates and its own its own history and, and Trustability, um, I think did Peers pretty interesting as well. We haven't done a lot with it at, you know, on the secure side, um, in, in recent time.
Speaker 4 00:41:55 But, um, you know, I, I was talking to Dan Hartman when he first kind of proposed the idea and, and, uh, you know, we were involved at that time, uh, helping to kind of formulate the idea of what did Peer was about. Um, so yeah, I think, I think those type of did methods that reduce the complexity of, of the blockchain component, uh, were probably my favorite. I, I do see a lot of value in, in having that, that registry and that, and that ledger, um, uh, you know, to provide that, that level of trust. Um, so that's not to say that I'm against, you know, the, the blockchain backed methods. Um, it just, uh, it, I also sometimes see them as, as, uh, barriers to entry and, and to get this technology rolling. I, I like to reduce those barriers.
Speaker 5 00:42:44 Yeah, and I, I, I doubt add a little bit, like, um, I haven't really been involved, um, uh, with the carry folks, but, um, of course the carry method does share some of the, some similar, um, design points, um, with the orp, I, I think we took the, you know, the direction of building on top of things like Side Tree and, and certificate transparency and activity pub. Um, but of course, um, you know, the carry folks have also been working on, um, uh, on, on, on this similar ideas of, you know, blockchain independence and, and self-certify identifiers, which, um, you know, are important points, right? So, um, I, I, I think there's, you know, several did methods that are, um, in, in the same similar families, I suppose. Um, that, so that's why I com you know, compare to side tree based methods, um, because of the side three protocols. But then also, um, you know, there are methods out there that are, um, you know, building on selfer, self-certify identifiers and, and, you know, um, uh, very much aligned with the, you know, ledger agnostic principles that are also important.
Speaker 3 00:43:51 There are well over a hundred did methods registered, uh, with the W three C. Are there any that the two of you would be interested hearing about on this podcast?
Speaker 4 00:44:02 Um, I, I guess maybe the question for you, have you, I, I believe the European blockchain service infrastructure, bbse has their own method. Um, and I don't know, so, uh, well, I would like to learn more about that. Let's just put it that way. I think, I think part of it may be a reinterpretation of, of did key, because I think they're, they might be making use of that, um, technology, uh, to avoid, you know, putting identifiers on, on immutable ledgers. Um, but I know that they're doing more with that. So I think if you haven't spoken to them, I believe they have their did. Um, and if it's not in the registry, I can, I can provide where I saw it, they have a, they have an Interrupt spec where they mention it, so maybe, maybe that would be a fun one. Depend what they're up to.
Speaker 1 00:44:55 Great. I would love to see, uh, a link or a method or something. Uh, they're not currently in the registry for what? It's yours.
Speaker 2 00:45:02 Now it's time for our shameless plug segment. Does anyone have a shameless plug today?
Speaker 4 00:45:09 I, I tell you what, my, my mother is, uh, is a painter. She's an artist. Uh, you can go to her website, ma varley.ca and go buy all her art. Uh, and there are no NFTs available for that, so you have to get the painting
Speaker 1 00:45:23 <laugh>. Awesome. Yeah. Wonderful. I love that because in some of my communities, people ask, how can I support art? And one of my friends who runs a gallery says, by art.
Speaker 4 00:45:32 Yeah, by art.
Speaker 1 00:45:33 I fully endorse that <laugh>. Yeah.
Speaker 2 00:45:36 And that will bring us to the end of our show today.
Speaker 1 00:45:39 Troy, thanks for joining us on the show, Mike. Thank you. Thanks also to our staff, our producer Eric O'Connell, and my co-host Eric Chu. I'm your host, Joe Andrew.
Speaker 2 00:45:49 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.
Speaker 6 00:46:01 The information, opinions, and recommendations presented in this podcast offer general information only and any reliance on the information provided. 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.
