Unlocking did:key (Part 2)

Speaker 1 00:00:07 Welcome to the rubric. I'm your host, Joe Andrew I'm Speaker 2 00:00:11 Eric Shu. And I'm Erica Connell Speaker 3 00:00:14 Today on the rubric. We talked with Ori steel of transmute and editor of the key spec and Mike Farley of secure key, who has worked through that spec and implemented the key for his company. Speaker 2 00:00:24 This is part two of a two-part interview with Ori steel and Mike barley about did part. One of the conversation can be found on our previous episode. Speaker 4 00:00:34 When you, when you think about the future care, I want you to think about not doing Speaker 2 00:00:41 On the rubric. We meet the people, making decentralized identity a reality. We discuss the technologies and motivations behind the movement, including decentralized identifiers, which encompass DIDs did documents and did methods. So you can make better decisions about which did method is appropriate for your use. Decentralized identifiers enable robust identity-based services without dependence on a trusted third party. Instead of being forced to use centralized identity verification services like Facebook, Google, or the department of motor vehicles, DIDs can be created by anyone anywhere and be used for any purpose. Did methods are the magic ingredient that gives 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 date 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 document that contains the cryptographic material for secure interactions, different did methods use different underlying mechanisms with different performance security and privacy? Trade-offs this show, the rubric reviews different did methods using a common set of criteria comparing apples to apples, so you can make better decisions about which dead method is appropriate for your needs. Speaker 1 00:02:08 Did key might be the simplest and most useful did method out there. It certainly was the most surprising when we first learned of it did key and codes. Everything needed to generate a valid did document in the did itself, making it easy to understand and implement. I want to move into the next section, which is to talk about the complexities and the complications that arose as did key was written up, tested, fixed all of that. What were the hard things about, uh, figuring out did key? Speaker 4 00:02:41 Yeah, so, I mean, there's a, a couple, a couple pieces of it that have been hard. Um, one is the registration of those multi codecs for the public key types, just remembering to register things. Is it painful? It's sometimes harder than you might think. Um, and so, you know, we've had to register these, uh, you know, essentially tags for the new key types. And then we've had to decide is that key is the thing that comes next, a compressed public key, or an uncompressed public key. And that has to do with elliptic curve compression. And so along the way, we've, we've had to address concerns and make choices, you know, like that, like we're going to say that did key is mostly just for representing compressed elliptic curve, cryptography, not run. I'm not gonna use it to represent the expanded, but that, that kind of decision actually happened recently when folks pointed out rightly so that we were using uncompressed in some places and compressed in others. Speaker 4 00:03:41 And another area of challenges, this thing called <inaudible>, which I hope Mike will explain because I've gotten that problem so many times, it's a, it's a, a concept that is very, very popular in some languages particularly go Lang and that is less popular and other languages. And it has implications for how to basically get the most compact representation of a, a, you know, an identifier for a specific point in a table, essentially. So it's a way of tagging values in a compressed way, but the way that it gets, you know, most of the problems in photography design often are in coding problems. And this you've RN is one particular and coding thing that you can very easily get wrong. I certainly got it wrong and know, I'll be the first to thank secure key for pointing it out, although the history is public. So you'll see, um, they, they caught someone coding errors that I made when we first registered the NIST curve. So <inaudible> MP3 84 and P 5 21. And I was generating the encodings for those did, did identify as incorrectly because I wasn't processing you've RN properly. And so you have to that's, that's the thing you sort of have to watch out for. Um, my, you know, what what's your experience with, uh, with Dicky than like, Speaker 5 00:05:02 Yeah, so yeah, I'll, I'll talk about that. You've, aren't a issue. You, you touched on sort of the, a few of the issues that they wanted to bring up. So thank you for the lead in. So again, we kind of stumbled on to did key after the initial work had been done and using ed 2, 5, 5, 1 9 for signatures was sort of already established and set up. So our early experience was, was quite smooth when we wanted to take advantage of the, of the NIST P curves, which again is important for, for securities customers, uh, to take advantage of, of those curves. We did notice a couple of issues and one of them was this you've aren't issue where a bite is not necessarily a bite. There's a way of, of, of running it through this algorithm that's available in go Lang I'm sure this spec is out there. Speaker 5 00:05:50 You've RN does not just the Golang thing, but the point is, is that it's able, it's a, it's able to compress, you know, into and ins into, uh, into, as tight of space as possible. It's, it's popular in, in protal buffs, which, which is, you know, again, sort of which is go lying and then sort of, you know, propagates that way. So, so we kind of discovered the problem because it go Lang which we build our trust blog platform in this is a native library function it's already in Golang. So, so we would just say, oh, it's a you've RN, you know, and our coders just wrote, you've already this value. And our number came out different than what was in the spec, which had people kind of scratching their head and then having to figure out, well, wait a minute, you know, are we doing it wrong? Speaker 5 00:06:32 Or, or was there some other issue with, with how this table was put together and so on? Anyway, I think we found out that it was, it was, you know, just a lack of experience with <inaudible>. Um, and, and again, it's not that we had a lot of experience with it. We just had a local library handy, which, which kind of made that conversion. So we were able to resolve that issue, uh, and, and, uh, and, and sort of move forward. What we also found with, with, um, the NIST Kurds is again, when we were trying to bring people in, this is one of those issues where we were trying to bring people into the club to start working with the technology. They stumbled across this error and they said, oh, this is the wrong bite. And it doesn't work. And is this a compressed key or an uncompressible key? Speaker 5 00:07:15 There's a, there's a bite missing, and I don't know what to do. And to which I responded, you know, look, these are great findings, please file a GitHub issue, get out there, get involved. We need, you know, this, we need help. And then there was an immediate little reluctance. Uh, I said, well, I'm not willing to go that far. I don't want to join that club. I just want to, you know, I want to work with the technology. I don't want to, you know, uh, have to start attending a large community meetings and so on. So it was just an intimidating kind of, kind of expectation. And then they backed off and then it brought it for a while security came back and, and, you know, we were able to actually patch it up and then, and then bring them on to, to help. So those types of issues, um, where the spec is not necessarily clear, or I think in this case with the, with the varnish tissue is just a matter of testing, right? No one had actually tested it. So, you know, the, these fixes need to go in. Um, and, and then the spec becomes more useful. Speaker 4 00:08:12 Yeah, I would say, you know, the thing that is so important when writing specs is test factors, this is one of those cases where we caught this because when I did the first registration for the NIS curves, and I did an implementation of them, I generated from our implementation a set of test factors, and I committed them to the spec. And at the time I was like, eh, I'm, I'm pretty good coder. I probably got this. Right. Just, yeah. And that's, that's exactly why you commit test vectors to source, because it turns out that I made a mistake and it was able to be caught because we had test vectors in the spec and people were trying to generate the same strings from the same inputs that I had, and it didn't work. And that's what test factors are so important because if you don't provide those test factors, how are you going to know whether two implementations are compatible? Speaker 4 00:09:04 What I had built, worked in our libraries, but it was wrong. And that's why committing test factors and working together and having multiple implementations, ideally in separate languages, which is another really great thing that secure keys has been doing. You know, the other implementation that we have is in TypeScript, there is, is in go, when you get to independent implementations compatible with the same test factors, you're really on your way to like something that's actually worth standing on. So I'm, you know, so incredibly grateful for having them have a completely independent implementation and having them go over these tests factors and catch these issues. And for anybody out there who's ever encountered this kind of issue and cryptography library never be afraid to raise the issue. If, if, if you find a problem read and see if there's a disclosure policy on the repo, if there is send them an email, don't raise the issue. Speaker 4 00:10:00 But if there isn't raise an issue and say, I, you know, I'm trying to figure this out, I'm getting this error. I think there's something wrong. Worst thing that's going to happen is they're going to tell you what you're doing, it's wrong. And you're going to, you know, you're going to have your problem solved for you agree a hundred percent. Yeah. So always raise an issue like we're, you know, a transmit we're powered by the issues that are, are, uh, open source, uh, consumers, rays on our platform, as well as customer issues that they raise on our platform. We really value issues. Um, we don't bite. Um, you know, please, please open Speaker 3 00:10:36 W well, I guess that leads in nicely to the next question, which was going to be, who controls the specification and how would someone that maybe finds an issue actually go about reporting it to the people that control it is that you guys, is that a different group? Do they, where do they go? Yeah. Speaker 4 00:10:52 Yeah. That's a great question. So the specification today lives in the W3C CCG. And if your, if your issue is related to the spec, um, either a question about the spec or the spec isn't super clear, or if you think that some of the test vectors are broken, that's where you should raise the issue, but then probably underneath that, there's also going to be an implementation that you might want to track down and raise the issue there as well. And cross-link them. And then to answer your original question, which was, you know, who owns the spec, um, you know, who do I have to bribe to get my did method, you know, to get my key representation in there, or like, you know, where, what are the governance attack surface for this spec, right? Like how do we, how do we attack the governance process associated with maintaining the spec? Speaker 4 00:11:41 One of the great parts about working in a W3C CCG is there is a formal process, um, for managing the specs and they're on, you know, some people use the term sand standards, track there's different language for different layers of community draft report. This specification today is a community draft. And that means that there's community members that are working on it together. And if there's a problem with the spec, it is the responsibility of the editors to implement a solution to that problem and work through the consensus process from community members that are having an issue with it. So if it's a feature or it's a paragraph that needs to be added, or it's, you know, objecting over the biasing, and one particular part, the way to, to, to work on that is to raise an issue, ask, you know, get some kind of, you know, degree of consensus work to raise a pull request. Speaker 4 00:12:37 And then the editors will be responsible for reviewing emerging, the pull request. If that sounds too hard, you can just raise an issue and the editors are responsible for handling that issue. So they're responsible for reviewing all those issues. And then for the ones where there is a clear decision, they are ultimately responsible for implementing that. If they fail to do that, there's the chairs of the W3C CCG, and you can appeal to them and say, there's editors working on the spec. I think they're biased. I think they're doing bad stuff. Please don't abuse that ability to appeal, but there is a formal standards process around the management of this specification, which is really good. And I would say generally the W3C has some excellent, uh, processes for managing specification development. And I've been really privileged to learn from other folks in the community on other specifications, and I'm doing my best to apply those learnings into this specification and, and develop it. Speaker 4 00:13:34 Um, so I can't just like make Dicky what I want it to be as the editor, right? Like it has to be the will of the community. And if even one person in the community thinks that I got it wrong, there's a process for them to appeal. It's all going to be publicly tracked. And if, if there is lack of consensus around something that goes into the spec, the PO the full policy is generally just to revert it and continue to work for a stronger form of consensus. It's probably one of the most painful parts of working in the W3C, the level of consensus that they require, but it does have some really positive effects in terms of the spec only reflecting things that everyone who's contributing to. It really agree on. Speaker 1 00:14:16 I really appreciate that, that overview of the process. And in particular, I want to echo for anyone who's listening to this, you found this podcast, please show up at these standards groups show up in these meetings. There were multiple calls every week, uh, focused on different parts of the infrastructure. You are welcome, even as a stranger, that fact that you're interested, you may be able to help us. You may have a use case. You may have some feedback you may know about a vulnerable population that has particular needs that maybe, you know, the guys in the room haven't thought through yet. So, um, I just want to echo that you are welcome. Please show up. If you're, if you're here in this podcast, please come over to the W3C and to diff, and to related efforts at IATF and ISO, if you hear about them, you will be welcome. Speaker 5 00:15:02 Yes. Please come, please come join the group. There are no bad questions. It's a very welcoming group, uh, and, and very respectful of, of all points of view and all, and all levels of implementation. It can go from ideas or it can go down to bits and bytes. You're welcome. Join, please. We need your voice. Speaker 3 00:15:20 Before we move on to the next topic, there was one other complexity. What did key that was brought up in our pre-production. I wanted to give you a chance to talk about Ori, which was the unique case of did key when it comes to curve conversions. Specifically, you brought up ed 2 5, 5 1 9 2 X 2 5 5 1 9. Speaker 4 00:15:41 Yeah. So like, uh, like we've been discussing did key is primarily a representation of public key bytes. So what does that that mean? Well, it means mostly just single public key bites, right? Like one public key, but there's some fancy cases where you can get one type of public key from another, and then there's even fancier cases where you have things like pairing friendly cryptography, and that's what BLS 12, 3 81 is. And in those cases, sometimes you have two public keys that are either drivable, one drivable from the other, or they're paired to, uh, the same private key. So, you know, in our, in our code and in our comments and discussion, we, we call these the did key snowflakes, cause there was something special about them. So <inaudible> is, is a total snowflake. And the thing that's sort of hilarious and somewhat sad about it is it's the first did key implementation that was out there and it has the snowflake attribute that's different than everything else. Speaker 4 00:16:49 And what I mean by that is that when you resolve an EDD 2, 5, 5, 1 9 key today, you get back an X, 2, 5, 5, 1 9 key, and an 82, 4 5 0.9 key. And it's something you might not expect because like I thought this was supposed to give me just one public key material. Why am I putting in one and getting back out too? And the reason for it has to do with that fundamental capabilities associated with public key cryptography in that, uh, lib sodium and safe curves and DJB ecosystem, uh, 82, 5 5, 1 9 is really popular for signatures and verification and X 2, 5, 5, 1 9. It's really popular for key agreement. And those are the two building blocks for building credentials and capabilities and building secure messaging and privacy. So in order to make the EDD 2, 5, 5, 1 9 key representation, the most useful, there was a decision to do this key conversion as part of the resolution process in the first, very first version of did key that was ever released. Speaker 4 00:17:58 And that decision has some implications. Like now we're, we're forced to ask for every new key, is there a key conversion that we should be doing here? Do I, do I need to convert this key so that I can do encryption in addition to digital signatures? And for the most part, the answer is like, no, like you'll, you'll, you'll look at all of the different curves. You're not going to do any key conversion as part of dinky resolution. And I should also note that, like the security consensus over ed 2, 5, 5, 1 9 to acts 2, 5, 5 0.9, is that like, it's probably safe, but you shouldn't use the same key for multiple purposes and yeah, that's basically it. So it's like a thing that we kinda know isn't really, uh, yeah, it's not really a great thing to do. Like if you don't have to use that, <inaudible> key, you might not want to use the <inaudible> that you're getting from that key conversion process. Speaker 4 00:19:01 You might want to generate your own version of it. And when you resolve that X 2, 5, 5, 1 9 key as it did key, you're going to get back into a document that only has X 2, 5, 5 1 9. And so it's one of these, these cases where the cryptography exposed an interface that was legal, the implementers implemented that legal interface, uh, because there's usability benefits for it, but it creates a slight sort of snowflake nature around this 82, 5 5 1 9 Dicky, which by the way, is like the most popular key out there. And so it is, yeah, it's a, it's an interesting aspect of the specification and its current form. And it, it, it, it brings up security considerations concerns for key reuse and using the same key for multiple purposes. We're using the same key for multiple messages. You know, those kinds of security best practices. This definitely raises an eyebrow around them, but it has some really great usability benefits. And so, you know, a lot of people really like to take advantage of that, Speaker 3 00:20:05 But a good thing for implementers to keep in mind, Speaker 1 00:20:09 You mentioned this issue of different keys for different verification relationship or different purposes, which, which I believe is NIST guidance, not just for federal agencies, but in general, is there a future for did key where we're not using the same key for multiple verification relationships? Is there, uh, an evolution of Dade key that, uh, has some features that could be NIST compatible? Speaker 4 00:20:33 Yeah. So I think the first thing I'd like to say is just because you can do something doesn't mean you should. And I think the problem with crypto conflating cryptographic fundamental reality with recommendations is sometimes you get the wrong kind of feedback in the wrong layer, right? So it is an undeniable fact that you can do elliptic curve, Diffie Hellman with a P 2 56 key. You can do it. You can also do ECDS a digital signatures. That's a fact now, should you use the same key to do both of them? No, it's not a best practice, but when you're representing that as a did key, should you expose the recommendation? And if so, which one would you pick for a given public key point in the infinite spit while some, yeah, not infinite, but like very large space of <inaudible> keys. You're going to have to figure out how to divide that space between two things. Speaker 4 00:21:39 If you want to follow that guidance. And it's, it's probably not the right layer to make that decision, right? Like did key is about a representation, fundamental nature of reality, not a security best practice. So I would say that the place to handle the key usage problem is in your software and in did methods that aren't did key where you can generate two key peers and use one for a key agreement, use the other for digital signatures, and now you can follow a security best practice, but for did key, it's more about like fundamental nature of the reality, the cryptographic capabilities associated with this key. So things like the public key conversion that we just mentioned from 82 5 5 1 9 to X 2 5, 5 1 9, because you can do it. And because it creates these usability benefits, I think it's, there's an argument to me that it's a good idea. Speaker 4 00:22:33 And there's definitely an argument to be made. That it's a good idea that did key to documents today. Say, you can use it for authentication. You can use it to make verifiable credentials. You can use it to do key agreement for, uh, you know, privacy preserving, you know, communication, I think did key in particular. It can't, um, it's not appropriate for these kinds of NIST's, uh, security, privacy, best practices to be applied to the did key, did document representation, but they totally apply to any vendor that's using did key for a software application. And just one sort of final note, like if you look up the vulnerability disclosure key for Microsoft today, it's a PGP key. It says it supports digital signatures and encryption. So even beyond like the NIST best practices, which are what you've just said, you know, don't use a key for multiple purposes. There are a lot of folks out there today that use one key for multiple purposes, and you shouldn't deny the reality observe reality of cryptographic use in the wild today, right? PGP keys are used for digital signatures and they're used for encryption the same key. It's very common. Speaker 5 00:23:53 Yeah. I'd like to kind of touch on that already. And that, and that did key has a very simple mission, right? I want to communicate a public key in a known way and in a resolvable way, and in a way that can be used as an identifier for, for other, uh, you know, credential types and, and assertions to, to build and business logic, uh, for such a simple construct is, is a very slippery slope. And, and, and, and then where do you draw the line? And then, and then your very simple identifier, which, you know, on, on an 80 and 80 line, you know, text screen suddenly becomes 4,000, uh, whatever 26 bytes that you can't, you can't read on a screen that doesn't fit inside an HTTP header anymore. You know, like you suddenly run into all of these problems. So, so it's, it's meant to be simple. Keep it simple if you're in a, in an application space where you need different keys, one for signing, one for encryption provide two, did keys find a way to do it, you know, like a solid at that layer. And then once you understand your problem space, maybe there's another did method, which actually solves the problem better, but, but don't complicate did key. It's not, you know, don't make its life hard, Speaker 3 00:25:04 So we're not going to be updating, did key. And that way, how will did key be updated in the future? Uh, is there a one point, oh, I don't believe the spec is quite to a 1.0, as of yet. Um, or possibly looking more future forward to 2.0, after that. Speaker 4 00:25:19 Yeah. I love to get to one point, oh, it's used way more than something. That's not one point I was, should be used. Uh, so I think, you know, first of all, I'm an editor and contributor to the key and the will of the community is what will make it evolve over time. Um, and I'm responsible for channeling that will and documenting it, implementing it, you know, as a, as the consensus evolves for how folks want to use did key. I think there's security sort of considerations and guidance around what we just were talking about regarding how to use did key, uh, and the relationships and sort of it's, it's not enough to just say, well, you can't deactivate it or you can't update it. You don't have to sort of explain a little bit more about why those are problematic and, you know, those sort of relationship aspects of Dickie that's, uh, you know, typically we would call that informative language in the spec. Speaker 4 00:26:16 We could use a lot more of it in the did key specification in terms of like major structural changes to the specification itself, um, support for, uh, the cryptography that is widely used today will remain an area where we would expect to see it evolve as newer curve types come online, or we add support for X 4, 4, 8, or, you know, other Ayana registered curve types. And while we're on the subject of Ayana and one area where I totally expect did key to level up is, uh, alternate representations. So what do I mean by that? If you're not familiar with the decor specification, it has this concept of the document representations and the most popular by far is Jason LD. And it is, uh, basically a, uh, Jason representation that has some link data features. Um, and those features are basically describing a set of semantics for the properties, the key value pairs in the Jason object itself. Speaker 4 00:27:24 And Jason LD is like I said, the most popular did document representation, but it also tends to have a lot of other semantic, uh, strong opinions involved in it. And sometimes the key representations that you see in Jason LD are a little, a little bit, future-facing like multi-phased everywhere, for example. And that there's problems that, that creates like, I love multi base, but you can't use an office shelf cryptography library with it. So if I want to verify a digital signature today, and I want to just reach into the, you know, NPM package registry or the Golang package registry, I'm going to find a cryptographic building block by big well-known company like Microsoft or Cisco. I'm not going to see support for multi based in there. And so if your did document representation only exposes public keys and multi-phase guess what you're going to be doing key conversion, you know, what is my least favorite thing to implement the whole world key conversion? Speaker 4 00:28:27 When you, when you think about the future of did key, I want you to think about not doing key conversion because the representation that I asked for did key should do that for me. If I asked for did application did plus Jason, I should get back a JW K because the J WK is going to be usable and off the shelf, cryptography tooling from ver from all these different companies, including ones that have had many security audits, and that are in production, protecting national security secrets in these libraries have really survived the test of time and they don't take public key multi basis and input. So you're either gonna ask your developers to do that key conversion before they can use a reputable security library, which is sort of like fixing your very expensive car yourself, you know, right at the right, at the most critical part where you really want that to be handled by an expert. Speaker 4 00:29:22 So I think key conversion is an area where did key still has some room to grow. Like I love, I love polo public key, multi based. Like I said, I'm very supportive of it. It's very, future-facing did key needs to be something that works with legacy systems off, you know, off the shelf. It needs to work very well with existing systems out there. And today, if you're asking what are the most popular digital signature suites that I might use to build a software product, you're talking about Jose, uh, Jason, uh, object signing and encryption standard cozy, which is the seaboard binary, variant and PGP. And so I think did keys, future is easier use with those really popular tooling, um, systems. And there is a lot of spec work to be done on that front, Speaker 3 00:30:09 Mike, any ideas of where you'd like to see Speaker 5 00:30:12 In the future. So, uh, I think that, uh, initially, um, there's a gap in the spec, uh, that, that are, you know, uh, developers have, have found where, how the did document normatively gets built from, uh, did key representation, uh, is also a bit of a challenge. And, and I'll, I'll, I'll give you an example, you know, the key ID usually has the did, and then there's a hash mark, and then there's an ID. And then there's an identifier for where to look up the key. And I think there's a gap in the spec that says, well, what should that after the hash mark, what should that be? Can it be anything, can it be the number one going to be Mike, or should it be the key again? And I think what we've, what we used in, in DHS SVIP was we just used the same, you know, uh, representation, uh, after the hashtag and then, and then, and then that's how the document was built. And then, and then keys were able to be resolved with, uh, if it did resolve our library. So that convention isn't really, you know, noted in that document. And I think we've tightened up that, that some of the normative pieces of that spec, uh, and, and we also talked about, you know, our public keys compressed or uncompressed, and are there bits and bytes missing those, those are gaps, which, you know, the community needs to come around and, and help support. Uh, it can all be on origin. Speaker 5 00:31:34 We need, we need people who are using this stuff to, to contribute. So, uh, so those are the areas where it can really, really tighten up to a one Dato and then really came broader adoption. And then I, I'm very interested to see other representations. So, um, you know, I was almost afraid to ask if there would be a JW K representation that can be a hot button topic, but, uh, what what's in market today, what's, what's, what's gone through, uh, battle-hardened testing, uh, again, Jose cozy specs libraries in production, again, nothing wrong with, multi-phase nothing wrong with new. It's just, how do you get into the hands of developers? And, and, you know, there's kind of a common saying which, which I learned early on in my career when building API APIs and building specs, don't make your problem, your customer's problem. And, and, and when you're trying to build interfaces and specs, and, and there's suddenly a spot where the developer has to learn, uh, learn a new skill, take, take a, take a step off a sharp allege you're, you're introducing challenges to them. And, and it may not turn out so well all the time. So, uh, how do you help them get into, get into this face? And that that comes with accessibility and library accessible. And maybe already, maybe we actually just have to go and write, uh, all those, all those nice libraries for Golang and, and, and a JavaScript and get them pen tested. And then, and then there will be an issue Speaker 1 00:32:57 That's a beautiful feature. Speaker 4 00:33:00 I would say, just, just on the topic of, you know, library support, it's easy to get really excited about writing cryptography libraries. And I can hear my cyber security professors yelling in my ear to tell your users absolutely do not, do not do that, do not implement your own Homeworld cryptography. Find the software libraries out there that have been reviewed, but are in widespread use today where a bug would be really valuable and the incentive would be really high and, and use those libraries. And in the few cases where you can't find a library that does whatever it is that you're trying to do from a reputable developer, that's lived a long time, or you trust the software supply chain and yada yada yada, then maybe be willing to write a whole bunch of interoperability tests as the first starting point. Before you even start to think about implementing any of this cryptography yourself, and I've gotten it wrong myself many times. Speaker 4 00:34:00 And the only thing that's caught it is if I've had something that I could compare it against. And if you're the first guy through that door, you were by yourself. And the only thing, and the only thing you can do is really wait for the second guy through the door, like secure key to come and say, I caught your caught all these problems with what you've done and thank God they caught them in cryptography that we weren't actually using yet, because it was just part of developing a spec. So I think it's a really, really important just to be sort of somewhat cautious in terms of the exuberance that folks might have about cryptography and software development. It's not that you can't work on building your own digital signature library. Please go ahead, have fun doing that. Be very careful shipping that to production without extensive testing. And generally speaking, you should trust a hundred percent or as close to a hundred percent as you can get of your software supply chain. And that's going to mean looking at legacy software libraries that have stood the test of time and figuring out how can I adapt them instead of how can I make a new version of them that's not backwards compatible. Speaker 1 00:35:04 So is there a clear roadmap for getting, did key understand is track? Speaker 4 00:35:10 No. The thing about CCG drafts is they don't have like an expiring forcing function. Like you might see in ITF or some other draft community standards communities, right? So it can be really helpful to say, well, we're going to work on this draft together, and we've only got two years to work on it. And if it doesn't get promoted to the next level, it's going to get retired as stale. That's really helpful forcing function. The CCG doesn't have that for these kinds of, they can sit there forever and they can stop getting contributions. And you should go look at the commit history and see is this active? How many people contributed to it? You have to kind of look at the, get history to figure out whether it's alive or not to answer your question directly, you know, what needs to happen to make deep key go standards, track. Speaker 4 00:35:58 First thing that needs to happen is did coordinates to finish getting through it standards, our process almost there. You're not going to yeah, exactly. Like we're, we're almost there, but you couldn't really do did key before you finished decor. So there are dependencies, you know, one is a specific implementation of another standard that has to sort of complete its life cycle before you can standards, track the dependency. Um, but we're almost there. And I think it would be really great to see did key go standards, track. Um, there are a lot of companies using it. It's probably the most widely used did method out there, I would guess. Um, based on it being a building block of many other did methods, you know, and including, um, good methods that hopefully we'll get a fuller list of. But for example, like I know did key is used as a building block in our side tree implementations for did ELAM and for, uh, did photon. Speaker 4 00:36:52 We use it inside of our implementations for did web. I think, um, the folks at Microsoft use in the ion STK and ion toolkit used parts of did key in the JW K variant for building side tree and side tree tooling. So it's very popular building block and it'd be really great to see it get a standards track. Um, but the community has to sort of apply the pressure to make that timeline happen. And nobody's going to be applying that pressure while did core is still finishing its final lab. Any, any thoughts from you, Michael? So, Speaker 5 00:37:24 Yeah, I absolutely agree that, you know, decor has to, has to get there, to get, to get across the finish line in order to have, did ki get onto that standards track. And one of the issues there is, is the one I just brought up about how does the document actually get built, or how does that, did representation get built from a did key? Well, without a spec to say what that representation is and what you can do, you know, that becomes difficult. So, uh, you know, that is, that is the starting ground. I, I sincerely hope that it does actually get onto the standards track. So once did core is ready, did key should be the next followup and the reason why is there so much flux in this space with any, with any did method, um, they are sort of self-published, you know, by the D method, uh, owners, um, and are subject to change and not necessarily subject to, to scrutiny or, or to any kind of governance, right? Speaker 5 00:38:17 It could be, it could be just someone who is, uh, you know, like Joe in their garage and decides to change that decides to change their, uh, their did keep method, uh, or, or representation out of the covers. So the, uh, did key being a stable base to, to bring your implementations, to test your implementations and to build your models. At which point you can then do, do the next step of evaluating something that maybe led your back that maybe, you know, locked in a registry or, or relying on another security technology. They really need that starting point. And having, having something stable and standardized to work with w it would also really help the community because it provides confidence, you know, that, that when they look at the standards in the space that they're stable and they can be worked with, and they're not going to change, you know, underneath them at a, at a moment's notice. Speaker 4 00:39:06 Yeah, that's, that's totally correct. I mean, one, one extra note I would give about the decor did key relationship is there is a test suite for decor that's been necessary to help it decor through the final phases of its standardization process. And in that test suite, there are implementations of specific did methods that help show that the decor spec has is that it statements are testable. That it's a good specification. And did key implementations have been really some of the most significant aspects of being able to prove that decor is testable. Um, you know, so not just for did consumption and production, which are core concepts, but also for did resolution. And for showing that two different implementations can implement, you know, the same did method and it can still conform to the standard. Um, did keys, one of those rare test cases in the did core test suite, where you, you see different software vendors implementing Dicky and, and still passing the same set of tests. So I think D did core has a lot of, uh, uh, thanks to O two D to did key in terms of encouraging a lot of the inputs that we've used to pass the decor tests suite they've come from implementations that are either did, did key themselves or other did method implementations that were built on top of dead key that were used to then further test to decor. Speaker 2 00:40:28 Thank you, gentlemen, for this wonderful conversation about did key. I am going to shift our gears a little bit as we move into our shameless plug section of the podcast. So I'd like to hear from each of you about whatever your shameless plug is, Mike, would you like to offer a shameless? Speaker 5 00:40:49 Yeah, but my shameless plug was, was just for security, uh, mentioning our work in Canada with, uh, uh, what was known as our security concierge, a Federation broker it's now government login by, by verified me verified me is our distributed identity solution. It has a lot, you know, it's built on top of the distributed ledger. It, you know, involves a mobile app, but it has a lot of the concepts that SSI, you know, embodies and it's in market today. So, uh, with the six major banks in Canada and real people are using it, uh, for healthcare, for financial services and, uh, government access, uh, and also retail. So, um, you know, the viability of this technology is definitely real. And then trust, block trust block is our open source program to actually take the verified me protocols and, and, uh, data objects and get them into that standard space and increase its reach. So it's an open source project. Uh, it's very strict about working on open standards and open specifications and being, uh, its own implementation. So, um, we firmly believe that in order to prove, you know, that a standard is viable is, is you have to have more than one implementation. And then that is a major principle behind trust block. Uh, it's written in Golang and anyone interested in joining should, uh, should check it out at the links. I'm sure it will be in that, in the show notes. Yes. Speaker 2 00:42:13 Thank you. I was just going to mention that we will for sure have the links in the show notes for listeners, uh, or how Speaker 4 00:42:20 Awesome. Yeah, so I'm in the shameless plug section, I'm happy to shamelessly plug our company. Transmute transmute helps secure critical trade data related to suppliers products, shipments, and to give customers a competitive edge and increasingly dynamic global marketplace. We're actively piloting in the supply chain sector and eager to expand these efforts with customers and steel automotive and manufacturing, logistics, and customs brokerages. There'll be a couple of links, um, you know, to the corporate website, but also a link to our, uh, did key workbench, which, um, is a graphical representation of some dead key concepts and an entry point into our open source libraries for did key. Um, and if you're a TypeScript developer, you might like these libraries, if you're a Golang developer, I'm sure there'll be links, um, uh, into the GoLine ecosystem. Um, that secure key has, Speaker 1 00:43:14 So that the followup shameless plug question is, um, what's your favorite did method? Is it did key or is there another, that would be worth mentioning? Speaker 4 00:43:26 That's a good question. I know my, my CEO is going to kill me for this. My favorite did method is, did web the reason my favorite did method is shocked. Speaker 4 00:43:40 Yeah. So, so I've, you know, at transmit, we've worked a lot on blockchain that did methods and, you know, particular, the side tree family did methods. And I'm sure you're all expecting to hear me say that did ELAM or did photon, or did I on that's? My favorite did method and I do love those did methods. And they do have a security properties that are superior to did web in a number of scenarios. And for certain kinds of customers, those, those properties are really valuable and, and, and worth it, right? The issue is that those properties come at a cost in complexity and understanding and infrastructure costs and did web is built on the web. This is not, this is not a new thing. This is the thing that's been around for quite some time. Did web's really, to use, you can host, did web identifiers on GitHub on your favorite website, hosting provider. Speaker 4 00:44:38 You can run one on a raspberry PI, you know, you can control as much of the web infrastructure as you can control. And if you don't trust DNS and you don't trust the ability to do online banking today, then you shouldn't trusted web at all. But if you do trusted, um, those online banking, uh, technologies, and you're willing to run your own, did web infrastructure did web is incredibly easy to use, and it is a much softer landing place to start out your journey. You could start with did QI, but if you're ready to level up from key, I'd recommend going to did web first because we'll need a blockchain to do key rotation. Thank you. Speaker 1 00:45:21 Awesome. How about you, Mike? Speaker 5 00:45:23 So, uh, uh, I have to say did, or, which is a new, which is a new security, uh, method that we're developing and the reason why it's not just because it's new. Uh, what we found was that we had, uh, did trust block, which was a Hyperledger fabric based solution. And we looked at, uh, the other, uh, complexities around other, other, uh, ledger based methods, um, and did, or sort of solves the problem of how can you take a, did that is associated with an identity and maybe associated with workflows and, and, and so on. And if that ledger needs to change or move, or it, maybe it goes away, how can you preserve those identifiers, uh, and the associated, uh, key links and history across ledgers and, and did orb is looking at solving that problem. So to decouple from the, what do they call it, the ledger substrate and make it more portable, uh, easy to discover. Speaker 5 00:46:23 So, so if you have, you know, a community that's maybe a little closed on, uh, uh, or, or more closed shop on, on their identifiers, but then they want to partner with another community, you know, did ordinates that discovery and that extension very easy, uh, to do it's all sort of built in. So, uh, we see it as a nice evolution, uh, of, of what DIDs are intended to be. And, and I'm, I'm, I'm excited about it. And, uh, and, uh, it is still in active development. So hopefully it ends up where I hope it does and all these great things that I've said, but, you know, the rubber has to throw Speaker 1 00:47:00 Indeed, well, I appreciate the work and I love those two methods. Um, we have already put into our plans to have dead web on, and we would love to have did, or bond sometime in the future. So we'll, we'll be reaching out to both of you to be back to talk about those methods. Excellent. Speaker 5 00:47:15 Thanks. Speaker 1 00:47:16 And that will bring us to the end of our show today. Ori. Thank you, Mike. Thank you. Thank you both for joining us on the show today. Thanks also to our staff, our producer, Eric McConnell, and our co-host Eric Schuh. I'm your host, Joe Speaker 2 00:47:29 Andrew, wherever you find the rubrics 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 belongs solely to the speakers and not necessarily to the speakers, employer, organization, committee, or other group or individual.