Speaker 1 00:00:07 Welcome to the rubric. I'm your host, Joe Andrew I'm Eric Shu.
Speaker 2 00:00:12 And I'm Erica Conal
Speaker 1 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 that key for his company.
Speaker 2 00:00:24 This is part one of a two-part interview with Ori steel and Mike Varley about did the continuation of the conversation can be found on our next episode. <inaudible>
Speaker 3 00:00:38 When you, when you think about the future did care, I want you to think about not doing key conversion
Speaker 2 00:00:45 On the rubric. We meet the people, making decentralized identity a reality. We discussed 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 does, 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 to 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:12 Or he's steel is the CTO. And co-founder at transmute where he leads all architecture, design and execution for the transmute platform. Or he currently serves as editor of the W3C, did core registries and editor of the encrypted data vault specification at diff secure data storage working group, or he has managed security concerns for startup in publicly traded companies ranging from host based intrusion detection, automated scanning and vulnerability assessment, logging aggregation, and alerting policies, procedures, and documentation for HIPAA compliance, for an insecurity, architecture, API security architecture, and applied cryptography. He has built secure web applications in finance energy and healthcare.
Speaker 2 00:02:54 Mike Farley is the director of architecture at secure key technologies in Toronto Canada, and has been involved in digital identity authentication and 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 systems, design security and end user privacy while making complex systems accessible to non-technical individuals. Mike is a co editor on the open ID connect. I gov specification welcome to the show.
Speaker 3 00:03:30 Thanks. It's great to be here. I do
Speaker 4 00:03:32 Glad to have you to 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 dead itself, making it easy to understand and implement. So let's start out with the most basic question. What exactly is did QI
Speaker 3 00:03:54 Did? QI is a encoding of public key material into a decentralized identifier that allows for interoperability testing for different public key formats types and representations as did documents. So it's a compact encoding of public key material that is very helpful in terms of testing some of the base cryptography that all did methods rely on in terms of verification, relationships and supported cryptography that might be necessary for certain proof formats.
Speaker 4 00:04:27 So they don't need DLTs. There's no ledger, there's no Bitcoin or other backend something Southern.
Speaker 3 00:04:36 Yeah, I guess that's sort of the headline for dead key is that you can do the did resolution step completely in memory. It's a deterministic transformation of the identifier. So there's no network request, no consensus, no resolution over DNS. And all of those are potential attack surface for adversaries. And so did key is a very calm, very simple solution to getting a document from an identifier. It has a number of drawbacks that are a function of that simplicity. And so on. I'm sure we'll get into this, but for example, those core did operations of read update, uh, ND activate, you can't do a key rotation or an update or a deactivate with a dead key. It's a fundamentally impossible because there is no, uh, ledger or recording system to anchor those kinds of operations.
Speaker 1 00:05:30 Yeah. It's somewhat unique. I think from at least any of the did specs that I've seen that the specification essentially says there is no update. There is no delete. Mike, do you want to talk a little bit about the implications of that?
Speaker 5 00:05:43 Sure. So, uh, I think my view of did key is it, it is almost a response to, uh, the question of, you know, if DIDs are meant to be ledger back to, or, or registry backed, what if you don't have one of those, how do you test, how do you work with this technology without, you know, all the complicated underpinnings. So did ki uh, then, you know, represents a public key and a private key pairing, uh, that you can use in your tests or in your, or in your specific use cases as you build out your solutions, but they really are meant to be kind of transient or testing vectors. So you, you almost should not be updating these things or doing key rotation. That's not, that's not their intent. There are other mechanisms and more secure mechanisms for doing that. Did he is really just, I need to provide you with a key to use for this message transaction or interaction and, and then we're done.
Speaker 3 00:06:42 Yeah. That's um, that's totally, totally correct. I mean, I think one, another way of thinking about the value of did key is that, you know, before decentralized identifiers, you'd see a lot of public key based crypto systems that would just use the public key as, uh, an account or an identifier for a user or a system, a process, and did key just preserved that kind of trend, right? It's a, the identifier is bound specifically to one public key. And if you lose the private key or it's compromised for that, you're, you're just as in trouble as you would, if you lose, lose your Bitcoin or Ethereum private key.
Speaker 4 00:07:21 Well, so one of the things that I understand about did key is there's a certain amount of flexibility that you get because under the hoods it's using multi base, and this gives you a way to represent different kinds of keys or different encodings for keys. How does that work?
Speaker 3 00:07:36 Yeah, so Mo multi is really awesome. Um, but I should warn, uh, you know, listeners that is relatively new technology. Um, and the, the, the general idea behind multi-phase is how do you get compact binary encodings of, of different types of content? So the way that multi based works is there's a, uh, encoding a sort of type tag that comes at the beginning, tells you what's coming next. And did key uses that tag to tell you whether you're about to get an ed 2, 5, 5, 1 9 key, or a sack of P 2 56 K one key, or a BLS 12, 3 81 key or some other NIST curve key, and the P 2 56 P 5 21 family. Um, so multi base is a way of expressing that there's, there's going to be these bites. They're going to come right after this identifier. And this identifier tells you what those bites are. And when you encode that raw binary and base 58, or base 64, then you get a string and coding of that raw binary, that's like highly portable. And, um, and you know, you can move it around in a system without moving around binary, um, which is historically are sort of hard to handle of the serialization layer. One clarification
Speaker 1 00:08:55 I did want to get, um, because it kind of tripped me up as I was reading through the spec. Um, you do give an example of a number of these encodings of the multi-phase and coatings just wanted to make sure those are, uh, examples, correct? They're not, that's not an exhaustive list in the,
Speaker 3 00:09:12 Yeah. So the spec is a work in progress. It's a CCG draft. The spec today covers a number of registered key types that are exposed in the specification today. And those registered key types have actually a multi codec reference in the multi codec, uh, registry. Uh, so for any key type that you'll see in the spec, we had to register that with multi codec first in order to, to have an implementation, but that would exist in the spec. And so the list that I gave isn't exhaustive, but it's nearly exhaustive in terms of the public key formats that we're seeing, uh, be used with did key today.
Speaker 4 00:09:54 And we could add to that multi codec or to multi base to extended key, correct.
Speaker 3 00:10:00 That's right. So we would, in order to add, for example, a fundamental new did key for our new elliptic curve that maybe was invented this year. What we would need to do is we would register a multi codec tag for that key representation and binary. We'd probably leave a comment saying it's a compressed key and not an uncompressed key. And then we would perform a series of serializations for that multi codec representation of that public key. And you get a base 58 in coding or base 64 URL encoding of that particular public key. We'd add those examples to the key method spec, as examples of support, key formats. And we would provide set of, uh, did documents that sort of show you how that particular string is supposed to be expanded into a dead document. And that's the process for adding a did kids it's, uh, one of the easiest possible did methods that you could work on because you can do all of that work in memory, just looking at the, the string identifier itself,
Speaker 4 00:11:03 Right? One of the things I noted and the work that you were involved with, I think both, both of our guests were involved with the DHS SVIP work did key was I think the most popular did method because of its usability. Could you speak to that in that particular use case?
Speaker 3 00:11:19 Mike made me go ahead and take.
Speaker 5 00:11:21 Um, so again, when testing across different companies who, you know, have various maturity levels of their implementations, you need to find a common ground, uh, on, on which to perform the testing without having to rely on, you know, early did methods, maybe immature infrastructure that may be going up and down during testing times to, and also you want to make sure that, uh, your test vectors and, and, and, uh, automated tests can survive past just the limited testing window that you have, you know, with that, with that group of companies. So, uh, did key kind of fill, again, fills that gap of how are we going to test, you know, the fundamentals of these protocols, uh, without tying into infrastructure, which is still very, very much in development, especially in that DHS SVIP program. Uh, and, and it definitely fit the bill, I think for that, uh, for that function.
Speaker 1 00:12:20 So used quite a bit in testing and build out of infrastructure if I'm hearing that right. Are there any use cases that the two of you have in mind for, did he, that are more on the, I guess, consumer side or actual implementation, what would it be used for out in practice beyond this setting up of test infrastructure?
Speaker 5 00:12:42 Yeah, so secure key very much sees a use for, for did key and, uh, in the way that we provide what we call triple blind privacy, extra data exchanges, uh, in our networks where we don't want the originator of a, of a data package for, for an individual to necessarily have to reveal themselves to the consumer of that data package. Again, you know, if you're, if you're signing up for, for a new cell phone plan, T-Mobile does not need to know that you are a chase bank customer. They just need to know that, you know, you hold a bank account that's been verified and so on to, to set up that identity binding as kind of a, uh, an example. So, so did key fits that role of transactional single use identifiers that can be trusted in the context of a, you know, an authenticated session through more binding identifiers.
Speaker 5 00:13:38 There was also work that we, uh, were looking at using that's related to it's the did peer method, uh, which is used in the indie space and in the area's space for exactly that same kind of relationship did peer is more robust though. It's not just a public key, it has a whole bunch of other information associated with it. And so the portability of did key in that in a very concise string in an ID field, in another data package, like a verifiable credential, you can, you can have, uh, that identifier and key experience and the trust is then sort of established outside of that transaction. So security sees a lot of use for, for these transactional based or relationship based keys where you don't need rotation. You don't need update. It really is just, do you trust this key for this period of time?
Speaker 3 00:14:27 Yep. Yeah, that's totally agree with everything Mike just said about, you know, the uses for, for dead K a femoral use is, is one area that, you know, at transmit we're really interested in using did <inaudible> another is as a building block for building other, other dead methods. So we'll often use, did key as part of constructing key material and getting the kind of data structures that we want to see. And then we'll convert from did key to did web to side Treebase did methods. So we use it as a building block for building other more complicated did methods in much the same way that Mike mentioned, uh, did peer sort of built on top of some aspects of did key and another use? Um, that's sort of exciting for Dickie to kind of think about is hardware bound, uh, cryptographic material. So either hardware tokens that are authenticators or hardware, uh, backed key management servers on popular cloud providers like Amazon or Google or Microsoft. And in those cases, you're often getting an API that will expose a public key, but won't give you any access to an extractable private key. And so there's already a natural sort of bridge there to expanding support for those, you know, widely adopted key management servers into the did ecosystem by just converting that public key to a D a D key identifier, and then getting the same kind of interoperability that you get from the did core specification.
Speaker 5 00:15:53 That's a nice a property, Ari. I hadn't thought of it, but, but, uh, I do really like that, that use when dealing with protocols, um, in this space, if we're already exchanging public key material with, uh, with a format, like did key, it's understood that the coders have a library for it. Why then if you need to provide another key, would you do that in a different format and make it more complicated for the developers? So, so absolutely that's, that's a, that's a great use case where if, if the developers have access to a key resolver, uh, locally already, then, then they can take advantage of that for, for any key that you need to pass across.
Speaker 1 00:16:33 That was great. Thanks for all of that. Uh, one thing I did just want to highlight Ori you, you mentioned you often start with did key. So if someone was out there looking to create their own, did method get into the space, um, that would be where you would recommend starting B with did key and kind of build off from there.
Speaker 3 00:16:51 Yeah, absolutely. So I think I've said this a number of times, but, you know, we, we tend to think about dead methods on a sort of continuum where it did keep being at the very beginning. And the reason it's the beginning is it, it doesn't have those advanced features advanced in quotes, right. For update and deactivate, it's as simple as you can get. And it, and that simplicity, it comes with some drawbacks, but it's a good place to start. If really all you're trying to do is like create an identifier and, you know, create some cryptographic material that's bounded out of that identifier to pass some tests, did keys great for that. And again, like you can use it as a building block to build more complicated methods. The next step up from dinky, I would say is a sort of centralized or semi central as trusted did methods like did web and then above that are the, you know, permission and public permission-less ledger systems.
Speaker 3 00:17:47 And did key is actually a thread that you can see weaving through all of those kinds of dead methods. So, like I mentioned before, when we do anything with did web we're often starting with dinky and just translating some of the identifier bits to make it fit into the did web to document. And then when we're working with psychiatry based did methods, which are anchor to public permissionless, ledgers, or permissioned ledgers, we're often starting with a key material, which has a good key representation. And then we're changing the identifier record to be pointing to the anchor instance of that public key, for example. So it's, uh, it is definitely, uh, I think of Dicky as a fundamental building block, um, in the ecosystem. And I, another thing that I think about it, um, as, as a it's in some ways, and this sort of gets into the, you know, more of the link data theory around, you know, cryptic cryptography, but I think of dead key as being one particular representation of an information resource that is like the public private key pair. So anytime you think about there being, if you think about what is the space of all public private keys of a given type, every point in that space has a key representation. Um, and so it can be helpful to think about that space and the relationships between that space and other representations of that space that you see in ledger backed, did methods.
Speaker 4 00:19:14 I love that expansion of the did key from, oh, it's how you can represent a public key to how you can represent any public key. And that is hugely powerful. I mean, I think all the other did methods are a little bit more specific, right? It's typically on this ledger, right? And that ledger will have a particular set of crypto. And you sort of are buying into this whole suite of choices that you don't get to make, but what did key, you have a little bit more control over, at least the software implementers get to choose which versions of dead key or supported that the end user may not be able to have those choices, but as an application developer, you get to have those choices. So I like that a lot about did key. I'd like to transition into the next phase of the conversation and learn a little bit more about the people involved. So U2 and the teams that you've been working with. So let's start with Ori. How did you get roped into helping with the G
Speaker 3 00:20:08 I think out of necessity on trying to work on decentralized identifiers? So working on the, in the W3C working group for decor, a lot of my work in that, in that working group has been focused on support for our existing cryptography. So, you know, we don't transmit we're, I mean, we're excited about novel cryptographic solutions, but we're also really focused on implementing support for legacy cryptography, uh, and existing public key crypto systems that are out there today. And for us, that meant how do we represent key material that's widely today, um, or that's, you know, considered to be a recommended best practice. So when we look at, um, you know, for example, safe curves, uh, cryptography website, or recommendations from DJB, we would see ed 2, 5, 5 0.9 X, 2 5, 5, 1 9, come up over and over and over again. And we, you know, we think that that set of cryptography there's a lot of consensus around it it's been adopted widely.
Speaker 3 00:21:15 And so we had ended up needing to use that cryptography a lot and did key became the easiest way that we could always use that, that cryptography in the same place, uh, that we were trying to use more complicated methods like did web or side tree based did methods every time we would choose something other than did key, we would pretty much regret it. Um, and, and the reason for that was like, you know, we're writing a lot of tests. Things are changing, those networks are going up and down. And like, all of that stuff was actually just sort of like outside of the, sort of the problem that we're trying to solve was like showing that the signatures were stable, test factors were compliant, you know, that kind of cryptographic infrastructure tooling work. Um, so that's, that's sort of how we got introduced to did key.
Speaker 3 00:22:03 And then we kept encountering, um, needs to sort of extend or expand it a little bit. So as soon as we wanted to work with it there in Bitcoin, we needed to represent the sec PGV six K one curves, indeed key. And so we added support for that, you know, to the did method. And we started using did key in a lot of places where we were using just raw hex keys before, um, or mnemonic based approaches to public private key pairing. And then, you know, later as we started to work on BLS 1231 and zero knowledge proof, you know, select a disclosure proofs, like we needed a way to represent that key material. And Dicky was again the easiest way for us to represent that material. So it's, it's really just been the place that we start really all of our fundamental support for, uh, cryptographic material. Like if we need to represent some cryptographic material, we start by thinking about how would you represent that material and dinky?
Speaker 4 00:23:02 So you got involved, um, because you were sniffing around with DIDs and this particular type of did method, uh, seemed applicable to what you needed for your work at transmute. Is that right?
Speaker 3 00:23:15 Yeah. So, you know, why does anybody need a, did you know, the reason you need DIDs is, is you have some other cryptographic material that you're trying to bind to an identifier or some format. So it could be a credential, it could be a capability, it could be, you know, a cryptocurrency, um, and all of these are software identity information, you know, infrastructure objects that are bound to digital signatures essentially. So the reason we needed key was we were working with digital signatures and verifying digital signatures, and we needed an identifier for looking up the key material for verifying those digital signatures. So how do you prove that that cryptocurrency is really owned by that party at this moment in time? How do you, uh, prove that these claims made by an issuer are really about a subject, those kinds of use cases for verifiable credentials and currency and capabilities, all necessitate the need for a did, and then the simplest did that you can use as did key. Um, and so we start with it before we try and add support, you know, in our platform for other, um, did methods like did web or psychiatry based did methods
Speaker 1 00:24:28 And, uh, same question to you, Mike, how did you get involved with,
Speaker 5 00:24:33 So it was more kind of by discovery through that DHS SVIP program where, where that group of companies had aligned on, on the usefulness of did key for living that, to that test suite. And then, you know, sort of once we started working with it, uh, we realized that it could extend into some of the use cases that we had. So, you know, in our, in our verified me product and another solutions, you know, security loves pseudonymous identifiers. And, and, and we also, you know, rely on, uh, on public keys and public key cryptography for establishing trust between entities when these identifiers are used, this is before deeds were really a thing. So we were already passing around key material, but as Oreo had said, we were doing it in our own in our own way. Like we have a problem, here's the solution. And so once we started using did key, uh, and, and working with it, we, then we then found that it could be useful internally.
Speaker 5 00:25:33 Also security is lucky enough that, that we're working with DHS in the United States, but we're also working with the Canadian government and some programs up here, uh, with treasury board. And I said, and so on, and we have companies trying to join the band. They're trying to figure this out. They also have internal solutions that they're, that they're trying to bring into the standard space. And, and it's, it's, it's one of those chicken and eggs, you know, they want to come in, they want to play, um, the first thing they need, well, what's your dead method going to be?
Speaker 5 00:26:03 Well, Hey, try did key it. Like, you don't need anything. You don't have to buy security software or make an arrangement with us. You don't have to, you know, pick up anything, uh, or run any kind of ledger. You can just start working with this. So, um, in that way, it's been, it's been very handy to help bring people into the community and get them started on their solutions. There are obviously challenges with some of the aspects of the spec, but, but it's still a, it's still a very low hanging fruit, easy adoptable method to get people up and running
Speaker 1 00:26:32 Before we move on. I just wanted to anacronym acronym ties a little bit. Um, we've mentioned in the past Pascha is, but for those that don't know, DHS SVIP is the department
Speaker 4 00:26:43 Of Homeland security, Silicon valley innovation program. So I want to go a little bit deeper on both of you and we'll start with Mike, how did you get involved in whatever you call this field, if it's cryptography or identity? Like how, how did you as a person, how did your career end up in this place that you are helping make these solutions? Sure.
Speaker 5 00:27:03 So I guess in my bio, it mentioned that, um, I had been involved with, uh, distributed system development and telecom and, and then also in, in, you know, web security and then an opportunity came up to, to join secure key, uh, and secure keys mission was to make strong authentication, generally available to people who are not technology savvy. And, and that really motivated me. And maybe one of the motivations was just so I didn't have to deal necessarily with my parents calling me and saying, how do I reset my password? And I forgotten the password all the time, you know? And so that, that alone is enough motivation to get me, to get me excited. And so with secure key, we started with a very traditional federated authentication broker system. But what we found was that there's actually a wide open, you know, opportunity space for strong authentication, whether it's with financial institutions, with government, with retail, it's sort of pervasive everywhere. And what started out as kind of a, a straightforward, how do I stop resetting my password became a, how do I prove who I am online and how do I do it on mobile and web? And how do I do it, you know, in person when I have a device or when I don't have a device anyway, the field just exploded. So, so that, you know, has been so interesting that, that I stuck around.
Speaker 4 00:28:28 And how about you, or how did you get involved in cryptography or identity, or however you'd like to think about this space?
Speaker 3 00:28:34 Yeah. Um, so my, uh, undergraduate is in cybersecurity, um, from Stevens Institute of technology in Hoboken, New Jersey. And during my time there, uh, you know, between like 2007 and 2000, you know, 12, 13, uh, I focused a lot on, um, social network, malware, botnets, and information warfare. And, you know, in the time in that timeframe, you know, just to give you guys some context for, you know, what was happening back then in the cybersecurity space, this was, you know, basically right before, and then immediately after the, the Bitcoin paper came out. Um, there was a lot of pickup, uh, of Bitcoin and cryptocurrencies by organized crime and various nefarious actors. And so what I was looking at, you know, from a research perspective in college was how are, uh, various threat actors, you know, organized crime to nation state, leveraging emerging cryptography, um, to, to do the same things they've always been doing.
Speaker 3 00:29:40 Right? So we were looking at various different, you know, uh, but net, uh, utilization of cryptocurrency, you know, both as a command and communication channel, but also as a way of purchasing hours on a, on a bot net, I don't know, you know, we don't need to get into what all that looks like, but suffice it to say, people need to be able to pay for their illegal goods and people were using cryptocurrency to do it. And they were hiding the way that they were doing that, um, inside of encrypted messages, on various different platforms. And I was looking at how can we hunt them and find them, how can we defend companies from this kind of, you know, issue both, you know, exfiltration of corporate data, but also various attacks that were happening on companies and trying to figure out who's attacking who and why, and those kinds of things.
Speaker 3 00:30:29 And then at the same time, another thing that was was happening was the first sort of usages of social networks to try and influence elections. And I know it sounds crazy, but back into the country, there was a lot of this going on. Um, and it wasn't in the United States, it was in other countries. And so I was looking at some of the earliest instances of this. There was attempts to use Twitter, to influence elections. And a lot of it got caught because they were using the same hosts that were doing other kinds of bad things were known to be bad, but we could all see the writing on the wall that this was going to go into fundamental new identities that you had, that you had no sort of linkability to you. Couldn't tell that this was actually a bot. You can tell that it's not a real person on Facebook.
Speaker 3 00:31:15 And, and so I was looking at, you know, what are these bad guys about to do with this cryptography in the future and how are we going to defend folks from it? And it was terribly depressing, but, you know, fast forward, you know, a couple of years later after leaving college and working in healthcare, I realized that some of those same technologies, the bad guys were using are actually what's necessary to defend individuals and corporations and governments as well. So cryptography is, you know, fundamentally a neutral technology, but its use can be, you know, to defend the innocent or, you know, the worst of the worst, right? So you have to be careful with a technology like cryptography and, and I've always been committed to providing the same level of security that governments and corporations, uh, need to, to perform their activities and defend themselves from folks who have, uh, ill wishes towards them to individuals.
Speaker 3 00:32:10 So similar to, you know, what Mike said, you know, I believe, you know, every human being has a fundamental right to privacy. I believe that, you know, cryptography is a necessity in the digital world to protect your, your individual human rights. And, and that means that you maybe, maybe you don't need to understand exactly how cryptography works, but we all, as technologists, I have a responsibility to make it easy for as many people as possible to use photography, to defend their rights and to allow for safe commerce and trade and all of the things that come with, uh, transparency and accountability, right? So in order to be accountable, you have to be able to prove facts. You have to be committed to being observed. And in a way that, um, you know, corporations are committed to being observed and individuals are committed to being observed in certain circumstances. And so cryptography that we've been developing and our work on open standards is all part of that mission to make these tools more widely available. Now, not just to individuals in the self-sovereign identity space, but you know, organizations and governments as well.
Speaker 4 00:33:19 I love the moral position that both you and Mike brought to this conversation and that, uh, you see human rights being enabled by this technology. I'm fascinated by a turn of phrase you just mentioned, or a is you use cryptography and transparency and the same sentence. And I think to most people, they think of cryptography is how you encrypt stuff, how you hide things. So could you unpack, you know, maybe more for the lay person than someone who's, you know, plugged into these technologies, how does cryptography help with transparency?
Speaker 3 00:33:51 Sure. Yeah. So, you know, cryptography is a really exciting field and, you know, really what it is, is it's about using math as a kind of building block to build certain kinds of structures. And there's two sort of really popular kinds of structures that people use. The kind of math that we're working on to build. One is digital signatures. And we, we we've talked a lot about digital signatures already, you know, capabilities, credentials, authentication. Those are things that typically come from the concept of a digital signature. I'm speaking generally, there's another kind, which is, uh, privacy or security and that's encryption. I mean, you get both of these properties from public key cryptography and there's forms of encryption that don't use public key cryptography and ease, secret key cryptography. But for the most part, a lot of the, uh, modern identity and security has been built around public key cryptography.
Speaker 3 00:34:47 And the fundamental sort of building block that people are using to build digital signatures is, is this public key verification scheme where I can sign with a private key and I can verify with a public key. And that public key is going to represent an identifier that I can then believe is always the same entity, as long as I believe that they're able to keep their private key private. There's a whole bunch of reasons why you might not believe that, um, or, you know, there's can be all kinds of various attacks stealing people's private keys and stealing their money and their cryptocurrency and their credentials. And that's, that's totally thing. Make sure you're keeping your private keys private, but if you do keep your private key, private, and you're a person or an organization or a government, you have a certain set of capabilities that come from that, that, that ability to have a private key and you can be held accountable, or you can, um, build a reputation around your public key.
Speaker 3 00:35:43 Right. And then on the other side of that, on the encryption side, uh, there's, uh, a process called key agreement. It's, uh, a mechanism where by, you know, a key pair public and private key can be used to agree to a shared secret. And that's the building block that a public key encryption is, is mostly built on top of. And that's the kind of thing that you, you see when you hear, oh, people have end-to-end encryption, you know, across their devices, right? Signal has end to end encryption, you know, being able to have a message that only a given public key can read and being able to send that message. And I'm definitely speaking generally here from a private key is that's another capability that sort of aimed more at private communication. So when I said transparency, I mostly mean leveraging the public verification capabilities associated with digital signatures.
Speaker 3 00:36:42 And when we say privacy, often times, what we mean is leveraging these encryption capabilities or secret key agreement capabilities that are available in public key crypto systems. And I should add just one more sort of historical fact public key cryptography is actually not a super new concept or hope, hope. No one feels like cryptocurrencies are the first time that this has ever happened before blockchain was even a thing. People were using public key cryptography to secure, uh, communication between embassies and the first sort of widely used demand. Democratization of public key cryptography is PGP, which we still use today to sign software distributions in the Linux and Unix environment. And that public, that PGP, which stands for pretty good privacy, um, was used to secure the communication between developers, but also to prove that software packages were really coming from the right developer. So this kind of public key verification and public key privacy and encryption, uh, technology has a long history before blockchain, you know, in cryptocurrencies, people would just call these enterprise security products probably, um, or, you know, privacy enhancing technology or other other terms. Um, so it's, it's not a new concept, but w what blockchain has done is it's gotten a lot, a lot of people really excited about it, and it's helped further the Democrat, the democratization of the use of public key crypto systems. So before it was just about having secure messaging and privacy, and now it's about ownership of assets, but they're both powered by the same fundamental cryptography, which is public key cryptography, digital signatures, and key agreement. We got a great, concise
Speaker 4 00:38:36 Blurb from Mike about secure key as making strong authentication accessible. What's the equivalent for transmute, what's your company doing all right.
Speaker 3 00:38:45 Yeah. So I know at transmit, we're focused on securing critical trade data in the global supply chain. And we use the same global, you know, international standards that security uses to do that. So decentralized identifiers, verifiable credentials, very active in the W3C. And those are standards for working with digital identity and credentialing technologies. And then the applications of those digital identity and credentialing technologies are widespread. So there are everything from, you know, electronic medical record use cases to software supply chain, physical supply chain, you know, today transmute focuses a lot on upgrading, uh, paper documentation associated with physical supply chain, which is, uh, you know, frequently attacked by various forms of fraud that come from the ability to tamper with critical trade data and documentation. And if you think about, you know, what, how do you know that a product is authentic? How do you know where it came from?
Speaker 3 00:39:45 How do you know what's in it? Those are, uh, pieces of information that various actors in the supply chain sometimes have a incentive to lie about or to change and digital, um, identity and credentialing technologies like decentralized identifiers and verifiable credentials are an open standard that provides a solution to that problem. So it's not just like a proprietary, you know, supply chain, traceability product. You have to get into my consortium to use it. These are built on real open internet standards, and anybody can implement the same fundamental cryptography to power those solutions and transmit. We're just the best at it.
Speaker 4 00:40:27 All right. Well, I love the confidence.
Speaker 2 00:40:30 This is the end of part one, and concludes our show today. The conversation continues on our next episode, 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 groups or individuals.
