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:11 And I'm Eric Shu.
Speaker 2 00:00:13 Today on the show we talk with the editors of DID Web about this Innovative DID method or a steel c t O at Transmute and Oliver Turbo Tech Lead at Spruce Systems Incorporated. This is part two of our two-part interview with RI Steel and Oliver Turbo. About did Web Part one can be
[email protected].
Speaker 4 00:00:40 Part of building Simple and usable software and standards is keeping them short.
Speaker 1 00:00:48 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 is appropriate for their use.
Speaker 2 00:01:06 Decentralized identifiers enable robust identity-based services without dependence on a trusted third party. So 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:26 Did. Methods are the magic ingredient that give DIDs 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
Speaker 2 00:01:52 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:10 Orry Steel is the c t O and co-founder at Transmute, where he leads all architecture, design, and execution for the Transmute platform. Orry has an MS and computer science and a BS in cybersecurity. From Steven's Institute of Technology, he is an author of the W three C decentralized identifiers DDS version 1.0 specification, and an editor of the W three C verifiable credentials data model. ORI has managed security concerns for startups and publicly traded companies. He has built secure web applications in finance, energy, and healthcare. Ri welcome to the show.
Speaker 4 00:02:48 Thanks for having me.
Speaker 3 00:02:50 Oliver Taboo is Tech Lead at Spruce Systems Incorporated. He has been working in the digital identity space for about a decade and was involved as chair, lead editor, author, and contributor in various organizations such as ISO, c e n slash c e n e l e c W three c Diff, and O I D F. Before joining Spruce Mr. Turbo joined Walt Dot IDs advisory board was head of architecture at Consensus Mesh Identity and standards lead and Solutions architect at U Port, part of Consensus sis at the Austrian State Printing Office. He worked as a solutions architect on mobile identity solutions for the public and private sectors, and became delegated expert into various identity related ISO working groups. He also received the Austrian Standards Award in 2018. Oliver, thanks for joining us today.
Speaker 5 00:03:43 Hey, thanks for having me.
Speaker 2 00:03:45 Here we continue the conversation.
Speaker 1 00:03:49 Okay, now we're gonna shift gears. What were some of the political, technical or human challenges that you faced, um, in developing? Did web,
Speaker 5 00:04:01 I mean, there's definitely some, um, challenges related to privacy. I think we already talked about that or touched, um, that, um, part of the web. Um, I mean this is because, um, in order to resolve a did web requires sending an HTP get request to the server. So this means that every time a did web gets resolved, the server would actually know about the resolution process and could potentially track the IP address of the request of the resolution request. Um, I mean, this could be mitigated by having a trusted universal resolver service, um, to achieve, uh, her privacy. Um, you can also use a V P N service or perform a resolution over the tour network. There are some mitigation strategies, but there are obviously also some downsides in using data web.
Speaker 4 00:04:48 Yeah, I think the, the privacy issues associated with the resolution requests, the, the biggest one that folks, you know, immediately recognize and the method, the, the metadata issue, which we, we covered sort of briefly is also, you know, a fairly large concern with DID web and it's, it's an unsolved and it's question of whether it it will be solved in the future or whether it intentionally won't be. But just to sort of give some background on that particular problem. If you were to use a did web to execute, you know, a mortgage document today, um, in the future someone might be doing a title check on the property and they might want to, you know, see your signature and then they might want to ask the question of, okay, is this really from the, this, this person? And if the current did document for that person didn't contain the key that they used to sign when they executed the mortgage document, it might look like, well, that's, that's not a bill.
Speaker 4 00:05:55 It's signature for them anymore. So this question of was the key authoritative for that did method at the moment in time where the signature occurred is a, it's a problem in the, in the DID method, you know, did space generally, and it's often solved by being able to look up what were the keys in this document at this moment in time in the past, which is really easy to do if you've got all of the state transitions for that did on a, on a blockchain or any other immutable storage system where you've got all of the versions of history forever in one place. But for did web, you don't have that. Anybody can change the contents of the file at that path and those keys will be added. Those keys will be removed. And if you don't use a third party service to sort of witness those changes or attest to, you know, the authority, you know, the keys that were authoritative at this moment in time, it can create challenges.
Speaker 4 00:06:53 Um, so I've hinted at like a couple different ways of thinking about the problem. Like you could kind of take the approach the blockchain based, did methods have taken where they, they keep their own registry of changes for the identifier. You could rely on a third party service to, you know, give you, uh, a receipt that these keys were authoritative for my identifier at this moment in time. Uh, you could do other things with the, the data document metadata that might expose that history of key material in some other way. But all of those things are sort of, they get very complicated very quickly. If you want folks to implement them consistently and you want interoperability, that can create a lot of challenge. So I think this is, this is also, uh, an important aspect of DID web that folks should be wary of because depending on your use case, did web by itself might not be fully enough, especially if you're thinking about 30, 30 year periods, like really, really long time periods, did web, you know, if you're, if you're rotating keys really, really frequently at did web might not be a, a great solution if you want really excellent auditability of every key that's ever been authoritative for that identifier.
Speaker 5 00:08:15 I also wanna add something to the privacy concern I mentioned earlier. I think the concern is less of an issue if, if you only use, um, data web for issuers, um, in their referral interest, because then all the server actually can keep track of is, uh, who resolved the issuers or the servers, um, dd, um, which is not really a problem. Um, I think the problem if privacy only services, if, um, you use did web for end users, um, because then the server can keep track of, um, where the end users actually consume services. Um, so my conclusion on that is actually I think it's, um, reasonable to use use Datalab for issuers again. Um, but for end users it has certain, um, privacy considerations.
Speaker 3 00:09:03 It is common in corporate networks to strip off the TLS with an intentional man in the middle architecture devices on the network are required to recognize the firewall as a legitimate root authority. Uh, you may have experienced this in the corporate network where your laptop or computer wasn't part of it and you can't reach any websites. Um, but this allows the IT department to intercept and or modify network traffic, uh, even over tls. Does this mean that, did web resolution on these types of networks can be arbitrarily rewritten by the IT department controlling the firewall?
Speaker 4 00:09:39 I think the short answer to that is yes. Um, so if you think about wh what is that, what are we really talking about there? It's the question of whether a corporation or a government has authority over the network that they maintain. And, um, yeah, they do, uh, <laugh> in, in some cases they may have authority over huge regions of the network beyond just a local, you know, corporate network. They might control network. They're, you know, if you think about the security architecture that the web relies on, there are regional institutions that maintain trust, um, for large areas of geography. And what you're saying that, you know, that particular kind of attack you're most likely or feature, it's, you know, it's, it's weird whether you, you consider that to be an attack on the network or is that really just the corporate IT department doing the, the right thing, right?
Speaker 4 00:10:42 Keeping an eye on all of the traffic, making sure folks aren't, you know, exfiltrating sensitive IP off of the corporate network. Um, there are use cases, uh, within certain networks where you rely on, you know, surveillance technology like that is a defense defense strategy. And there are cases where some of these infrastructure components that go into, into dead web start to fail when you have certain categories of adversary. So it depends on your, your threat environment, whether this is gonna be a really big problem or not. Um, if you are accessing, did web documents on a corporate network for legitimate business purposes, and you trust your IT administrators to protect that network and not be compromised, then that activity might not be, um, that all that concerning. But you can imagine how an attacker might exploit that natural defensive t you know, strategy that corporate IT folks had implemented, and the attacker gets in there and they're injecting key material and they're playing other games.
Speaker 4 00:11:50 What looked like a defensive strategy has now been exploited as an offensive attack strategy. And you, you see that a lot in systems that attempt to attack end-to-end encryption, just broad, broadly, generally, right? So it, it, there are folks out there who really want the ability to see or, uh, interact with encrypted traffic because they have, you know, uh, either a corporate oversight responsibility, law enforcement responsibility, or that's just the security, you know, posture that that particular organization has. And it's, it's a dangerous thing because it can be exploited by the attacker, but it's also potentially a required capability depending on the regulatory framework that you're in and, you know, particular governance strategy of the corporation that you're, you know, a member of. Um, it's a great, a really an excellent question, and I think it speaks to the limitations of the web as a security infrastructure that you're building on just generally.
Speaker 4 00:13:05 And so there are mitigation strategies for some of those things. Um, like you could attempt to sign the content, you know, on the original web server, and then if there was tampering, you know, in line you would be able to detect it. But then there's other issues with that, like how do you know to trust this key that this content was signed with? It sort of creates a turtles problem <laugh>, which you, you might think, well that's, that's really well solved by other DID methods, maybe did Web just slowly goes away and it becomes a bridging technology to more decentralized methods where you can discover the key material and it's some, it's providing some confidence in defense against attacks on tls. I think that gets, it starts to get very complex again. Mm-hmm. <affirmative>. So I would be concerned that as you try and patch over the inherent limitations in TLS and DN dns and the, as you mentioned, like current corporate, it, you know, firewall security patterns, if you start trying to make did web resilient to some of those things, the trade off could be that you lose adoption of the technology to add a, a small epsilon of security, um, to it.
Speaker 4 00:14:26 Or maybe, you know, you disagree and it's a larger, larger than an epsilon of security that you're adding, but still there's complexity that comes with that trade off. So yeah, it's a, it's really a great question and I think, um, as folks implement, did Web, they will hit this, this point and then they'll ask, is this, am I concerned about that use case? And often I'll interact with someone on issues and they'll say, you know, my threat model is I'm trying to defend against nation states. And I'll say, Ooh, I'm not sure you want to be using did web for that. Um, there are cases where maybe did WEB isn't the right solution and um, to some extent trying to circumvent your corporate IT policy, uh, it might be that what you're doing there with with DID Web might not fit perfectly well with what did Web was, was created to do.
Speaker 5 00:15:25 I fully agree, um, with what or just said. And I also wanna add that, um, so what software is typically, um, installed on, um, employees, devices, um, employees, um, computers or laptops? Um, so typically in a company that, um, does SSL breakup or TS breakup, um, I mean employees, they use corporate software, but they might also use consumer software. The corporate is not really interested in providing wrong data to their own software, so it makes no sense for the corporate. So the, there's, there's, there's no reason to be concerned about that use, uh, about that thread. The other thing is when uh, employees run their own software on their laptops within the corporate IT or network, then um, they could be affected by SSL breakup, TLAs breakup. And, but then in my opinion, it would still be possible that this, this software, this type of software would still be able to detect, um, that the T LS certificate is not the, the, the right one. It's basically like the t l certificate that the IT security officer installed, which is typically not installed in consumer software. You need to, you know, trust that certificate. And if the end user is not doing that intentionally, then um, that software might fail retrieving the, the, the <inaudible>. So it, it won't work perfectly because, um, the tls, uh, connection cannot be verified. But, um, at at least the, the software would not get the wrong research from the Resolver.
Speaker 1 00:17:04 Uh, that is a great workaround and, and feeds into my next question. I mean, you, you basically said the software itself that might be running on this desktop that might be in a corporate environment doesn't have to rely on the default DNS configuration of the IT department, so it doesn't have to accept the man in the middle, uh, route authority as valid. And so that is an interesting architectural shift. The assumption is, uh, that the software will defer to the operating systems, uh, uh, authority architecture. And so you check out, you know, I don't, I don't think it's Etsy hosts, but it's like Etsy host, right? You, you, you defer to the policy that your device has and the software doesn't have to do that. So the general question is, um, so DIDs basically were designed to provide end-to-end verification or trust relationships, right? So if you have this key and it is actually protected, you have privacy around the secret material, then you can have end-to-end encryption or end-to-end verification that yes, that person really did sign this, and some of these attacks that we've been talking about mean the man in the middle could, could in, you know, interject in that, are there other mechanisms where we can address that risk in the way that Oliver, you just pointed out, like, I thought that was great that your software doesn't have to rely on the current network's, um, architecture.
Speaker 1 00:18:33 Are there, are there some other ways to improve end-to-end verification with DID web?
Speaker 4 00:18:39 Well, I think I mentioned before, you know, you can sign the DID web document, um, and then of course you have to have everyone agree to, to verify that did web document according to whatever mechanism you've used to sign it. And depending on which, you know, key material you've, you've used that, you know, for that it, it can, like maybe there's some value that can be provided from signing the DID document or, or aspects of the, the DID document metadata. That's, that's definitely one. Um,
Speaker 5 00:19:14 Another option might be, which might not be super feasible, is to anchor the DID web, um, the documents in an aggregated way on some, uh, decentralized ledger. Um, so you can then verify based on a did document result, um, that a particular did web is, uh, was registered on ledge, if this makes sense. Um, but again, so in practice this might not be feasible, especially because DID WEB was invented for people who are maybe more reserved, uh, and hesitant, um, in implementing, um, decentralized letter technology. Um, yeah, but there are ways like that where we have,
Speaker 4 00:20:01 Yeah, I think I would, when you're thinking about why do I trust this key as authoritative for this issuer, I would like for that problem to be solved for did web using a generic building block that would be relevant to other DID methods and not to be sort of solved by injecting deeper complexity into the DID web method itself. So I think that it's important to negotiate where do the, where does the, the DID method layer end and the supporting software, uh, that goes along with it begins. So what about the trusted resolver layer? What about endorsements for verifiable credentials and endorsements for issuers and systems that manage endorsements, um, and those kinds of o other other systems that you have. And, and like you also mentioned, you know, what about the device and the installed certificates and other material that might be preloaded into the device, either at the operating system level or, or even deeper, you know, firmware layer. So there's, it's not, um, the DID method and interaction with a specific identifier isn't happening in a vacuum. There's layers before it and layers that come after it. And sometimes you get a better property by handling these things at a different layer than in, in the, the DID method implementation itself.
Speaker 2 00:21:25 In our earlier chat, you mentioned simplicity as a design pattern and I think also earlier in this podcast. Can you speak to what you meant by that? Tell us a little bit more about it.
Speaker 4 00:21:38 Sure. So, um, the, the software or the standard, um, the sta let's start with a standard first. The standard should be short, should be easy to read so that you're not getting lost in the details between page, you know, 57 and page 214. Now there's, uh, if it's that long, there's a lot of chance for, you know, weird discrepancies to pop up. So it's part of building simple and usable software and standards is keeping them short. And that means that you don't have a lot of wi you know, wiggle room and you talk about what does it take to create an identifier? You, you've got only so much space to do that in. And so today did web has some fairly loose requirements in terms of what a, a did controller needs to do to create a new identifier for a subject. And the controller could be the subject or they could be separate entities, right?
Speaker 4 00:22:41 If we start to expand all of the things that you need to do to safely support an operation, the, the method itself could become more complicated when you read the specification, but also the implementations of the specification can get really complicated because two different implementers could read the same paragraph and come to different implementation choices and they might be consistent, but if that paragraph becomes a couple pages long, the chances of them disagreeing on something sort of fundamental go up. And then further from that, you know, the risk in, uh, an implementation difference that is like actually exploitable. So like we're concerned about those kinds of cases when we build the, the method specification because the of specification is gonna guide the implementations and differences in the implementation are ultimately gonna be what, uh, will lead to interoperability or vulnerabilities that are exploitable in a particular implementation and those kinds of, uh, of consideration.
Speaker 4 00:23:44 So today, I think did web is really biased towards being very, very simple and, and not having a lot of complexity where you might get tangled up in, in the, an implementation difference. But I, I suspect as it's, uh, as it, you know, matures and becomes and moves towards standardization, there will be additional complexity that that is, that has to be addressed to remove ambiguity and uncertainty and to give it, um, some sort of future safety and, and upgrade ability in some of these other extensibility, you know, features that you, you want in a longer lived specification. So I think it's good that it's simple now because it's only going to get more complicated from here. And, and as, as a, you know, an editor and a contributor to it, my, my bias is to try and keep it simple and look at what are the features that are being asked for.
Speaker 4 00:24:43 Is there a simple way to afford them? Is there a better solution for, you know, this person, they have a feature, they have a use case, but maybe a trusted resolver is actually the thing that they're looking for, not a change to our method specification. Or maybe they want another system for getting a trusted list of issuers instead of having the method specification itself embed that kind of information. So it's a, managing complexity is, is a difficult thing and, and oftentimes you need to have some other sort of categories of, or places where you might be able to put a couple piece puzzle pieces together to give that same kind of feature without making the method specification more complicated. And, and I, I consider it to be as a method author, it's sort of part, part of my job is keeping the specification as simple as possible so it's as easy to implement as possible. And so the chance of critical security issues in implementations is low as possible.
Speaker 1 00:25:46 Yeah, that's a great answer. When, when I first heard you say that in our pre-call, my thought was the web is already so complicated. I thought you were suggesting something else, but that was a great example of, of how valuable it is to have simplicity, um, cuz it goes through not just a spec, right, but to people's ability to implement the spec, um, which is a much wider audience.
Speaker 3 00:26:12 If a, did web resolution query returns a 4 0 4 not found, how is the resolving party to interpret that?
Speaker 4 00:26:19 So that's, that's a a great question. Um, and for future listeners, um, go read the method specification cuz it could change. So what I'm about to say might not be, um, the right answer, uh, several years from now. Um, but essentially the important feature of DID resolution is that the identifier that you get in the DID document match the identifier that you put in to resolve. And so if you get a document that doesn't have that identifier, you've resolution has failed. There are many different ways of interpreting different kinds of resolution failure for did web, I would say the 4 0 4 status code is already, um, you know, indicating that this is an unresolvable identifier that you've requested. But I, um, the point I'm making about the id, the ID property and the DID documents important because you might ask what's the simplest resolvable did web and it's really a J S O object that just has an ID that matches the the DID web. So it doesn't need anything else that's a valid J S O did document just an id it's not very useful did document, but it's very, very simple, um, at its at its most basic layer.
Speaker 1 00:27:47 So doesn't this mean that a deactivated did document is indistinguishable from a did that was never created with did web?
Speaker 4 00:27:56 Yeah. And it, it's, it's sort of also sort of tied into the, that question about, it's related to the, your time, the, the timing and metadata issue for different states of updates to, uh, at did web. So you might ask how many, how many updates has this did web ever had? You, you won't know the answer to that by just looking at the DID web specification and you also won't know if it's unavailable today, was it ever available? And just on the point of deactivation, there are some DID methods where deactivation is permanent terminal thing for the identifier and others where A did can become deactivated and then become reactivated again <laugh>. And so what about did web like which, which of how should did web behave with respect to that property? Um, and the DID web spec specification should describe how you should interpret, you know, these kinds of considerations. I think to answer your your question sort of as directly as I, as I can today, I think a deactivated did web and an unresolvable did web are indistinguishable from, from each other.
Speaker 1 00:29:05 And are you aware that that would, that makes it not conform with a did spec?
Speaker 4 00:29:11 I'm not sure it makes it not conformant with a did spec, but uh, I'm happy to hear the argument in greater detail.
Speaker 1 00:29:19 Sure. Uh, the quote is, if a did has been deactivated, did document metadata must include this property with a and value. True.
Speaker 4 00:29:28 Yeah.
Speaker 1 00:29:29 So you have to be able to distinguish between a did that was never created and it's just not resolving. And a did that did once exist but has now been explicitly deactivated.
Speaker 4 00:29:37 Yeah, I
Speaker 1 00:29:38 Think we could evolve, but I think right now we're not quite compliant.
Speaker 4 00:29:42 Yeah, and I I should also mention that the whole concept of did document metadata is generally not handled well with respect to interoperability. So the entire category of that document is optional as I understand it. So a mandatory field and an optional object is, what does that mean? You know, <laugh>, it's hard. Um, sure. I think the, the, the one did method the, the family of did methods I have the most experience with that comes with deactivation sort of built into it, is that the Side Tree family of DID methods and they do return that deactivated flag. And I don't know how you would ever create that kind of flag in did web without starting to store a consistent version history for a given endpoint. Actually for every possible given endpoint a unique version history of all State changes associated with that URL forever. That's an expensive proposition I would gather that did Web is probably not super likely to implement that particular pattern.
Speaker 4 00:30:51 And it should be noted that deactivation is not a required to implement operation. So you could say that it's impossible to deactivate a did web and it's kind of a way of getting around it cuz it did key, for example, you can't deactivate a did key. So there's, there's a couple different ways of tackling that kind of problem. But that's a great example of the kind of, uh, uh, thing that folks stub their toe on when they come to implement did web, and they come back to the specification and they're like looking for the answer and they can't find it. That's a great time to open an issue and complain, get people into the issue and start to discuss the problem further work forward towards the point where you can open a poll request. Um, and, and then once the poll request is merged, the draft moves forward. But remember it's a draft and when that draft goes to a formal standards body, they can take all of your decisions and just erase all of them. So there isn't really stability around what did web is until it's a a permanent standard, you know, with a a version number that's never gonna change. And so even if there's a solution to this tomorrow, it may not be the solution that a working group would agree too several years from now.
Speaker 5 00:32:06 Yeah. Fully agree with what or just said. And um, also keep in mind that, um, did Web, um, is been around for a while and was, um, invented or developed before, did co-op became final and did co became final, uh, only recently, so there's room for improvement and as or mentioned just go to the GitHub or join CC Chief First go to the GitHub and create issues, create prs, that would be really great.
Speaker 1 00:32:33 The DID Web Spec does require tls but not dns sec. Could you unpack why that particular distinction? Why not also require D N S sec?
Speaker 4 00:32:44 Yeah, um, it's, it's what the SPEC says today. It's a community group draft. Um, I think there's complexity in D N S SEC that is, is painful and, and one of the things that I like about DID Web is you can kind of, if you trust a service provider, you can use did Web and let the service provider manage your Let's Encrypt certificate and your DNS level security. So for example, a GitHub, if you wanna use GitHub pages to host a did web document, you can trust GitHub to handle a hundred percent of that for you. And you're, you're fine. Uh, you don't, you don't, you you just change the file in the GI repo and you get actually a really awesome version history for every change you've ever made. Um, and everything works. If you start to require every implementer of DID WEB to conform to dns sec, you would lose off-the-shelf c m s support in certain categories of, uh, server, uh, service provider.
Speaker 4 00:33:51 So I, that's, that's one of those sort of cases where I think you're, you're, there's trade-offs there and you're looking for what's gonna make this method, you know, highly usable and are is are the security trade-offs that I'm making for usability, you know, worth it in terms of adoption or have I, have I missed something sort of critical? Is DNS SEC a feature that should be turned on and mandatory and it's okay to lose support, um, for certain kinds of service providers that can't support it. So I, I think, uh, again, it's, it's a question of how, where the community wants to draw that line in the method specification.
Speaker 3 00:34:33 Okay, so to move into our resolution, what is next for DID WebP?
Speaker 4 00:34:38 So, um, we'll certainly continue to review issues and poll requests. I think, um, there's certain sets of guidance that probably doesn't belong in the method specification, but that would be very helpful to implementers and there might need to be an implementation guide that's paired with it or another place to sort of get into some of these, um, more technical details, uh, you know, or security trade-offs. So like, you know, there's a couple examples of that, like the DNS SEC question's. A good example of that, like what if I really want DNS sec, how do I do that? Well with DID Web, another one is what if I really want X five I nine and certificate chains? How do I do certificate chains? Well with DID Web and maybe I've got, you know, a software signing use case where I really want a certificate chain to be exposed in my DID web document.
Speaker 4 00:35:35 So those kinds of, you know, things maybe they don't belong in the DID Web spec itself, but they belong sort of paired with it. Um, there's, there's a lot of interest in in those kinds of issues. And then there are issues in the specification itself, like addressing the deactivated issue, like, uh, discussing the sort of history or provenance for a given identifier, those kinds of considerations. And then I think, you know, the biggest sort of major checkpoint that everyone should be keeping their eye on for did web is when does it become an internet standard and, and where does it become an internet standard? Does it go to the W three C? Um, does it go to i e tf? Does it go, you know, to another standards organization to be standardized? You know, what's the right home for Did web, um, and you know, what's the, what's the journey that it it takes to get to that place and how long and how many years, et cetera. So I, I think it's important to remember that it's still being developed. Um, it's, you know, gaining traction. It's very easy to use. But, um, it's the, you know, the, the, the last pages of, of DID Web aren't written yet. And so we, we don't really know exactly what's next for it, but those are, that's a sort of smorgasborg of different possible, uh, paths that it might take from where it's today.
Speaker 3 00:37:02 Is there any hopeful timeline for that first version or is that still too early in the process? Hopefully in the future?
Speaker 4 00:37:12 Um, if it goes to W three C many, many years, so I'm not sure, uh, it, it feels like W three C would be a natural place to to, to do it. And in fact there was, there's con you know, already been discussion about the next version of decentralized identifiers and will the working group standardize the set of methods as part of the next working group formation? And this is clearly a did method that's on the top of everyone's mind when it comes to that kind of thing. But I'm not sure what the timeline would be for that. And I think it's, it's years out.
Speaker 2 00:37:48 How can our listeners get involved?
Speaker 5 00:37:51 Um, I believe they should join WS three C credentials Community Group. Um, it's free, it's open source, and then they should, um, participate in the deep web GitHub discussions by talking about issues in the issues treating new issues or raising prs to address certain issues after they, after they reach consensus.
Speaker 2 00:38:15 Perfect. Thank you.
Speaker 4 00:38:16 I agree with Oliver.
Speaker 1 00:38:18 As we move to wrapping up, we like to ask all of our guests, other than the DID method we're talking about today, did Web, what's your favorite DID Method?
Speaker 5 00:38:29 Did P K H
Speaker 1 00:38:31 P K H?
Speaker 5 00:38:32 Yeah, because it can represent any blockchain account. Um, the blockchain agnostic, uh, representation of blockchain accounts. So you can essentially represent the serum accounts, uh, even Bitcoin accounts, salon accounts or whatever accounts, um, as it did. That's why I like it. It's very similar to did Key, but IT, but for blockchain accounts.
Speaker 4 00:38:59 Yep, that's a good one. I, I mean I, I like, uh, did Key. I like, uh, did JW K, which is like did Key, but it's sort of more focused on JSON web key representations and the Iion registry. It has a slightly different set of dependencies that you need to implement it. Um, that's a, a cool one. Um, I think, like I said this before, um, and I really strongly believe this, but diversity is a security characteristic. I think if you look at this so many different DID methods, yeah, some of them are gonna be fairly similar and it's gonna be hard to tell which one has better security characteristics. But within this, you know, sort of large field of different DID methods, there are ones that have these interesting properties and those, those properties could be inspirational and you might take a series of those properties from several different DID methods and you might create your own a new one.
Speaker 4 00:40:00 And I think it, it's important to consider that your favorite DID method might not be invented yet. You might be the one that's gonna invent it. You can go to the registry, you can look at all of these different, DID methods, pick the traits that you're looking for, combine them and make a new method, write a method specification, open a poll request to, to register it. Um, and there'll be one more DID method and everyone can insert their obligatory reference to the XKCD comic about how we get, you know, one more standard. Um, but I think that that's an okay thing for DIDs for where they are today. And I think we should embrace diversity and we should sort of explore the space before we start to get, you know, really particular about, you know, which did method is the, the best did method, you know, which one should I use for everything? I don't think we should be using one did method for everything. I don't think that's ever gonna be good advice.
Speaker 2 00:41:01 Now we'd like to take a moment for our shameless plug segment. Oliver, I think you have one for us, is that right?
Speaker 5 00:41:09 Um, yeah, I think I have at least one. Um, I think it was interesting that or mentioned, um, the trades. Um, so it's Bruce, we recently, um, published a blog art article, um, which is about, um, deep method trades and we are also going to attend a rebooting love trust in the Hague, um, where we are going to host a session on deep method traits, which is complimentary to the DID rubrics
Speaker 1 00:41:35 Work. Wow. Cool. I'm going to shamelessly plug our DID directory service, which is the easiest way to find the details on any W3C registered did method. You simply go to did directory.com/method name for details and including links to the official method specification. For example, for did web visit did directory.com/web, that's d i d D i r e c t o r y dot c om slash w e b.
Speaker 3 00:42:05 And I'm going to give a shoutout to our DID evaluations
[email protected] where we post did method rubric evaluations of various methods, one of which happens to be DID web. And I'd also like to give a big shout out to ri our guest for helping out with that evaluation. So if you wanna learn more about did web go take a
[email protected]
Speaker 4 00:42:29 Awesome.
Speaker 2 00:42:30 And that will bring us to the end of our, oh, alright. One
Speaker 4 00:42:33 More. Yes. One more. Yes, please. You know, shameless plugs, they've gotta be off the cuff, right? So, um, I just want to, I want to give a shameless plug for the, the traceability work happening at the W three C C C G. So this is work on applying decentralized identifiers and verifiable credentials to issues involving global supply chains. So if you're interested in securing supply chains for oil and gas, for agriculture, for steel, or for e-commerce or if you've got a use case that isn't one of those, um, the traceability work happening at the W three C C C G is a great place to look at how to build credentials, verifiable credentials for a given use case and how to use decentralized identifiers to secure them.
Speaker 2 00:43:18 Awesome, thank you. And that will bring us to the end of our show today.
Speaker 1 00:43:24 Ri thank you for joining us on the show today, Oliver. 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:43:36 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.
