Episode Transcript
[00:00:00] Speaker A: Foreign.
[00:00:06] Speaker B: Welcome to the Rubrik. I'm your host Joe Andrew.
[00:00:09] Speaker C: I'm Erica Connell.
[00:00:10] Speaker D: And I'm Eric Hsu.
[00:00:12] Speaker C: Today on the show we talk with two of the co authors of did jwk, Jeremy Miller, known for creating Jabber and xmpp, and Orey Steele, CTO and co founder of Transmute.
This is part one of a two part interview. Part two of the conversation can be found at Rubrik.
[00:00:34] Speaker E: The word or the phrase self sovereign doesn't exactly ring true to me.
[00:00:41] Speaker B: On the rubric. We talk to the 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 that's you can make better decisions about which DID method is best for your use.
[00:00:58] Speaker C: Decentralized identifiers enable verifiable interactions without dependence on a trusted third party.
So instead of being forced to use centralized verification services like Facebook, Google, or the Department of Motor Vehicles, dids can be created by anyone, anywhere, and be used for any purpose.
[00:01:15] Speaker D: DID methods are the magic ingredient that give DID 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. This is so when you use the did, others know how to retrieve the associated DID document that contains the cryptographic material for verifiable interactions.
[00:01:40] Speaker C: Different DID methods use different underlying mechanisms with different performance, security, and privacy trade offs.
[00:01:47] Speaker B: 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.
[00:01:57] Speaker C: Jeremy Miller is a computer programmer and entrepreneur known for his work in developing the Jabber XMPP messaging protocol. He's also been involved in several other technology projects, founded several companies, and contributed to numerous software libraries and standards. Miller is widely recognized for his contributions to the field of instant messaging and online communication. Jeremy, welcome to the show.
[00:02:20] Speaker E: Hello.
Great to be here.
[00:02:23] Speaker D: Orey Steele is the CTO and Co Founder at Transmute, where he leads all architecture design and execution for the Transmute platform. Orey has an Ms. In Computer Science and BS in Cybersecurity from Stevens Institute of Technology. He is an author of W3C Decentralized Identifier version 1.0 and an editor of W3C 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. Orey, I think for the third time. Nice to have you back.
[00:02:56] Speaker A: It's awesome to be back.
[00:02:58] Speaker B: Great. Let's get started.
DID JWK embeds a JSON WebKey or JWK in a DID so that you can use JWKS in DID enabled systems. Simple and straightforward, frankly, it promises to give didkey and DID PKH a run for their money.
So in your words, what is DID jwk?
[00:03:22] Speaker E: In my words, it is created as a bridge for groups that are using the jose, the JSON object signing and encryption standards.
If you're already within an ecosystem where JWs, JWT, JWKs are in common use and you have those libraries implemented, this provides a bridge, a way to sort of access and port into the DID ecosystem. So it's a means to connect those, you know, one ecosystem into a larger one, I guess.
[00:04:02] Speaker A: One thing I might add to that is the JSON web key format shows up in a lot of places, even when JSON web signatures or JSON web encryption might not be natively supported.
So for example, in the web crypto APIs in a browser, you can export JSON web key formats, even though you may not have in the browser a native API for producing a JSON web signature or a JSON web encryption.
[00:04:28] Speaker B: Okay, so a JSON web key, how is that different from say, the standard RSA key pairs you might know and love from using ssh?
[00:04:38] Speaker E: So the Hosing Working Group many years ago in the IETF set out to make some sort of web familiar or web native wrappers around the more native or lower level cryptographic systems.
And you know, out of that came a set of standards, you know, JSON web signatures, JSON web encryption, and the algorithms that are used as part of those JSON encoded formats is JSON web algorithms or jwa.
And then kind of a byproduct of all of this was the need to have a JSON representation for key material.
And so that's where they did the work to define JSON WebKey as a way to take the parts of a cryptographic key public and private and embed them in a JSON document in a standard way.
[00:05:32] Speaker B: Cool. And where are developers typically using that? What's a common use case?
[00:05:37] Speaker E: Very commonly in the OAuth openid ecosystems, it's widespread usage, it's anywhere that you're doing single sign on, you're under the hood. There's probably JSON web tokens which are based on JSON web signatures and the backend systems when they're using these protocols, they tend to go fetch the key information, right, and validate the key information or load it off of this using JSON web key. So you may not ever see anything like this in your browser.
You're never really exposed to it, but the backend systems are using the standard format to exchange that public key information.
[00:06:16] Speaker A: I guess just one other comment about like the key formats that existed before JSON WebKey became a popular representation, you know, within OAuth, I guess it's the PEM format, you know, PEM and PKCS and other other representations for key material that predated jwk. And for some of those key representations you needed libraries to help with the encoding of the material. And some of those libraries were difficult to implement. And so you think about the total cost to support a key representation.
It's not just, you know, do I understand the difference between elliptic curves or rsa?
It's also what software do I need to encode those representations and decode those representations consistently so I can work with lower level cryptography modules that might be expecting bytes instead of particular encoded serialization. I think ASN1 is a big component of key representations before and JSON webkey doesn't have that same dependency.
Am I getting that right, Jeremy? I don't want to overspeak.
[00:07:29] Speaker E: No, yeah, that's some great background, appreciate that.
[00:07:33] Speaker C: And so I think they've hinted around this or maybe mentioned it already in some of the nuance here, but what problems specifically did JWK design for? And like when would you use a DID JWK instead of just a JWK, for example?
[00:07:51] Speaker E: So JWKs are useful just as themselves when you are as a file representation that you're maybe storing locally or fetching remotely, or if you're using it in a JWK set where you have an array of them in a native JSON representation where you want to represent key information in a larger JSON object. Jwks are pretty effective at that. Where they're not useful on their own is in any kind of uri. So if you want to encode key information into a single string or identifier. Right. These are rich JSON structures that tend to thrive in that environment, but there isn't really a direct mapping to a URI. So that was the work that we did with DigWK to take that JSON representation and provide a way to use that in an identifier. And that bridge is really kind of the link here, the reason that it exists.
[00:08:51] Speaker A: Yeah, I think there is a new RFC called the JWK Thumbprint URI RFC and that built on a previous RFC that was for the JWK thumbprint, which is a way of getting a hash of a particular JSON web key. So there's. These are some related standards, but I think one of the main things that folks are looking for when they use digiwk is they care both about DIDS and about the JSON webkey ecosystem. So they want the easiest possible way to sort of do both.
[00:09:23] Speaker C: The question part, I think, is what are the distinctions of DID JWK that makes JWK the right DID method for users?
Part of the answer, I think, is what you just said. What else? Is there another distinction about it that.
[00:09:39] Speaker B: Makes it the right choice?
[00:09:41] Speaker E: So the number one reason by and far is you're in an ecosystem where you already are using GWKs.
So that is really the primary reason. The secondary reason that sometimes occurs is that you're in an environment where you are required to use standards.
And so you want something that is a referenceable standard for as many components as possible.
And even if you're not using other JOSE standards already, you might still need to be able to reference a standard. And so did JWK lets you reference the W3C did standard and the IETF RFC for JSON web keys as a standards based solution.
[00:10:23] Speaker D: Cool. So now that we've kind of established a little bit of the background of jwk, would the two of you mind walking us through the CRUD operations? Create, read, update, and deactivate for this DID method? Kind of. How would you go about performing those? As a user that wants to make use of this DID method?
[00:10:39] Speaker E: Sure. So it's really. We tried to keep it as simple as possible. Right. So there was a lot of choices that we might get into here around the decisions that we made of how to keep this simple. But the create is, you know, essentially you, assuming you already are, have a library that handles JSON web keys. It'll give you a JSON output of that JSON web key. You take that JSON output and you just stringify it. So you don't really have to do anything special other than turn it into a string and then you perform a base64 URL encoding on that string. And again, base64 URL encoding is used widely in the JOSE standards and commonly in IETF standards. When you ever have to use put base64 in a URI.
So you take that JSON string, you base64 URI, encode it, and you append DID colon to the beginning of it, and that is your create just As.
[00:11:41] Speaker D: A clarification point, it would be DID colon JWK colon, the string.
[00:11:47] Speaker E: Yes, absolutely.
[00:11:49] Speaker A: Prepend, not append. Yeah, prepend.
[00:11:51] Speaker E: Yes, I prepend.
[00:11:53] Speaker D: And the read.
[00:11:54] Speaker E: The read is as simple as the inverse.
So again, you're kind of assuming that you're in an ecosystem where you have a JWK parser or decoder. So you take the did JWK colon and then the base64 ur encoded string, separate out the did JWK colon base 64 URI decode the remaining string. Assuming that's successful, that will provide an octet string, right? Or, you know, a UTF 8 string that you can then pass into a JSON parser. So your JWK library may take a string, or it may. You may have to use your language platform to parse the JSON.
Either way, you know, decode the JSON and you pass it into generally your JWK library to decode for you.
[00:12:47] Speaker A: So, I mean, that answer seems more accurate for the DID URL dereferencing sort of component, not necessarily a DID read operation. The read operation should produce a DID document. And so once you've got that JSON web key representation, you need to take that key and construct a DID document that has the JSON members that other DID DO document parsers are going to.
Verification methods, assertion methods, authentication, key agreement capability, invocation capability, delegation, and of course, everyone's favorite at context.
So the READ operation is one of those interesting pieces like when we were first working on the spec.
It's sort of sad because the method is so simple, but most of the complexity in the method implementation is about what are the choices you're making around constructing that DID document because you've got the key, but there's many different JSON representations you could produce for that given key.
One of the things that I've explored in some of the implementations that are experimental I've worked on has been if you know this is a curve that can do key agreement and digital signatures, do you put that key in both of those relationships?
Or if the key representation says this is a key that's only for signatures, do you omit it from the key agreement section? Or if it says it's a key, that's only for a key agreement, or an algorithm for encryption, do you only put it in the key agreement?
The cool thing about JSON WebKey is that it's an ecosystem that's been around for quite some time, and they have their own representations for key use and what the DID spec calls verification relationships.
JWK also has support for Connecting to the certificate ecosystem.
So as you convert from that JSON web key format into the DID document representation, you have all of those capabilities to build on as extension points. That's one of my favorite parts about JSON web keys.
[00:15:00] Speaker B: The way you just talked about it, you have different.
This is really how dids are structured. It's not just how you talked about it. But in a DID document you can have these multiple different kinds of verification relationships. As you mentioned, authentication, attestation, match the key agreement, et cetera, is the fundamental choice with a jwk just about which of those you're associating with that key. And how would that choice be specified?
Because you only get one key. If I'm right, in a jwk there is one key only, correct.
And so if you have this need to have to specify that this is to be used for an attestation method, but not for key agreement, how would that be encoded in the jwk?
[00:15:42] Speaker A: So I imagine different implementers might answer this slightly differently, but I tend to think of the JSON web key representations as the primary authority.
So for, you know, P256, for example, you can use that algorithm, you can use that key representation for ES256 signatures, but also for ECDH, ES, a 256kW for key agreement, you know, and encryption.
If that JWK didn't say this was a key that's only used for this algorithm or this other one, then I think it's natural to use it for both purposes. But if the JWK has a statement inside of it that says this is only for encryption, then it makes sense to have the DID document representation reflect that original intention in the key.
That's again, implementation specific choice within the libraries that I've built. But I think again, the cool thing about JSON web keys is that inside of the key representation itself, you can embed the intention at the time of key generation, you can embed that intention.
Jeremy, I'm not sure if it's.
Is my answer sort of in line with how you think about these things, or is it too far in the weeds?
[00:17:00] Speaker E: Yeah, and I was just, you know, when we discussed this and when we created the spec, we did actually get some of this language into the spec itself. So it does say the use property, you know, which is that from JWK is specifying how that key is intended to be used. And we do. When you create that DID document during the read process, you are supposed to set, you know, either include the key agreement property or not include it based on the value of the use property on the jwk. And there is that extra wrinkle there for those that do deal with ED25519 and X25519.
Those inherently have with part of their definition is that they're only supposed to be used for signing or for encryption. So you know, although the use property may not be assigned on the jwk, the curve itself kind of provides that definition restriction.
[00:17:55] Speaker A: Yeah, and that, that, that same issue comes up in some of the post quantum key representations that I've been sort of exploring and experimenting with. You know, from a JWK representation standpoint, you know, KYBER is used for chems, it's not used for digital signatures. So if you have a, you know, KYBER based jwk, you're never going to see signature related verification relationships inside.
And the same thing is true for some of the post quantum signature schemes like, you know, Dilithium or Sphinx. You're never going to see key agreement pieces or at least right now, as far as I'm aware, you're not going to see any key agreement uses for those.
[00:18:35] Speaker B: Okay, so there are some subtleties that can be encoded in the JWK itself and an implementer would need to figure out how to map that to the DID document to have these links correctly in there.
[00:18:48] Speaker E: Yes, that's correct. And there is guidance in the spec to kind of give them a framework for how to do that.
[00:18:54] Speaker D: Because this was a long and good conversation, just want to anchor a couple of things for the listeners.
One, we'll be coming back to this use property a little bit later. We have some questions around that and some interesting implications around what it means for a unique DID that we'll be talking about, but also kind of somewhat hidden in all of that ori, as you were describing how to do the read operation. For those listening, just want to make it explicit. DID JWK is a generative DID method. I believe it's the third one we've looked at in that you can generate the DID document entirely from the DID string itself.
So this puts it in the same classes, at least in my mind. Stuff like didkey and DID PKH, I believe, which we've both done before, but to re anchor back to the last two operations in our crud. You guys mind walking us through the update and deactivate briefly?
[00:19:47] Speaker E: Absolutely. It's very easy. There is none.
[00:19:52] Speaker D: Hopefully if you've listened to the didkey and didpkh, you might have caught on to that pattern.
[00:19:58] Speaker A: So Jeremy's correct, but one of the things that I think is really interesting is that certificate tie in opportunity with JSON web keys because it is possible to embed chaining information.
And then if you had decided that you wanted to verify that chain as part of that particular identifier, which I don't think there's anything in the spec that tells you how you're supposed to consider certificate chains today. But if, if you as a verifier decided that you wanted to do those kinds of checks, there would be a mechanism for applying that certificate layer validation to that particular question. And you see these certificates show up in OAUTH servers, you know, in the, in the, the keys that are used to sign tokens. So I think there is potential for a future there for DigiTABK where maybe certain verifiers decide they want to make use of those certificate extensions to help answer some of those questions. I don't think any of that's been formalized in any way just yet.
[00:21:03] Speaker B: And that would include figuring out how to represent it in the DID document.
[00:21:07] Speaker A: So the DID document representation of it. I mean in the current spec, the certificate chain would show up in the JSON web key in the verification method. So the chain that's in the JWK would show up again inside the DID document.
What does the processing of that actually mean? I think that it's at a different layer than the representation of the identifier or the document or the key.
[00:21:34] Speaker B: Got it. So the current spec retains the information you would need to use to apply that chain evaluation.
But there isn't a standard about how you do that processing.
[00:21:46] Speaker A: Right. And one other comment just about JSON web keys generally is, you can add additional properties to them.
So they're all, all those properties are retained as part of the production rules.
[00:21:57] Speaker B: Okay, so next question.
Are JWKs limited to specific cryptography?
[00:22:04] Speaker E: They are not inherently limited.
So that said, there is a registry that the IETF runs that for specifications for known sort of popular algorithms. There is a, you know, links to those specifications that have been registered with the ietf.
And as Ori knows, you know, he's actively working on registering new algorithms for the post quantum space.
So there you, you can technically sort of do your own, but for the most part when there is something, you know, widely known, there is that is being registered with the itf.
[00:22:48] Speaker A: Yeah, you can create a new JWK representation, but until it's registered, there's very little reason to believe there'll be a lot of interoperability or adoption around that particular representation.
So like for the post quantum schemes that I'VE been working on the JWK representations for them. They're proposals, they're experimental.
After if I. If we're successful in describing those JWK and JWS shapes for post quantum schemes, at some point the IANA registries will be updated and the properties that you need to represent a Kyber or Dilithium or Sphinx plus jwk, once those are in those registries, then there's higher confidence that there's going to be interoperability because you can go to the registry and you can see for that given representation. But there's been lots of cases in the past where folks have made a new JWK representation, they've started working together on it, then they go to write the RFC for ietf and a small part of the representation changes. Maybe the key type is renamed or something else that happened with the SEC P26K1 curve. People started working with it before it even got to the registry. Then when it got to the registry it had some differences and folks went back and updated their libraries for JSON web keys.
It is possible to work outside of the Registry process. It's just you might have to make updates if the future and RFC comes and defines that key shape.
[00:24:16] Speaker B: Okay, cool. So we would enable new cryptography by defining new properties.
Eventually those properties are desired to be registered with iana, but you can work with it if you aren't registered. It's just maybe most people won't know what you're talking about or what that property is for, but it's not. It's not that it's invalid or illegal, it's just most people won't recognize it.
[00:24:39] Speaker C: Are JWKs used with private keys?
[00:24:43] Speaker E: They are not.
So there's no intention. While JWKs can be used with private keys, did JWKs are not intended to be used with private keys.
[00:24:53] Speaker A: And just to spell it out because of the deterministic production rules, you should be careful there. Right? Because if I give you a private key, there is a JWK representation for it, that's just its base 64 URL encoded value. But you should not be using DID JWK to share identifiers for private keys around with people, because that's sharing a private key which is destroying the entire purpose of a private key.
If you build an implementation, you might want to throw an error or explode or do something else that's helpful to your developer other than producing a DID document that contains the D property for a jwk.
[00:25:36] Speaker C: Right, Gotcha. Yep, makes sense.
[00:25:38] Speaker D: And because it might come up later and would also come up for readers that are going through documentation. Could one of you please explain what a collision resistant name is in the context of a jwk?
[00:25:49] Speaker E: Sure. So it's actually that phrasing is kind of unique to the the whole Joseph Ecosystem set of standards and it is intended to be within a set environment or ecosystem that you choose a name that is not going to naturally conflict with any other user within that ecosystem. So you might be in a closed environment, right, where your ecosystem has a defined boundary, so you kind of know who all the parties are and you have some mechanism of identifying something uniquely in that group. Maybe there's a common specification for that group. So you can come up with collision resistant names by simply putting them in a list in that common specification for all of the parties within that one ecosystem versus on the open web, you don't have that. So if you're creating something that's using any of these standards and you want to use a property name that is not going to conflict with somebody else, you better make that property name a URI or some fragment of a URI so that it is collision resistant against any other potential user out there. So there's not one definition of like what is collision resistant. It really depends on what is the scope within which you're using JWS or JWK and then choosing a property name that is unique within that larger space.
[00:27:18] Speaker D: So this would be analogous to these large online systems. Often video games have this where you make your account with a name and then they assign you a random number to make sure that someone else that picks the same account name doesn't actually collide with your username.
[00:27:34] Speaker E: You could do that. You can use hashes or random numbers, but most of the time what we see out there is people using like a reverse DNS approach.
So user domain name like org specification and then a unique property there because within that specification.org, they can actually claim that that property name following it is unique.
So much more human readable. Whereas the random numbers or hashes are not really useful to anyone. So why make them a property name? Sure.
[00:28:08] Speaker B: Okay, let's turn our attention to the people involved in DID jwk.
Jeremy, how did you get involved?
[00:28:15] Speaker E: So I'm involved in some of the OpenID work for all of the new verifiable credential support. So around issuance and presentation and the sort of the bridging between the OpenID and OAuth specifications into support for verifiable credentials. And in doing that, you know, I, I've got a lot of experience through Ping Identity around the existing JOSE platforms and libraries and all of the implementations in that large ecosystem. And trying to, you know, really my involvement came from like, okay, there's all of these new things. They're verifia and verifiable credentials that we want to start to take the existing uses and existing deployments and provide ways for them to start adopting some of these newer patterns and newer protocols and newer standards.
So in that work we really a very simple observation was well, we need to be able to create a decentralized identifier that uses the types of identifier representations that are common in OAuth and OpenID Connect and that is JWKS.
[00:29:37] Speaker B: Great. How about you Orey? You've been on our show. This is the third time.
So why did digwk catch your attention when you're working on all these other ones at the same time?
[00:29:47] Speaker A: So I first encountered DID JWK the concept of it when trying to work on didkey. And in fact there was this proposal like a really long time ago on the didkey method repo to just support JWK instead of multi base and multi codec.
And you know, for folks who don't know, you know, this, this episode isn't about didkey, but didkey is very similar to did. JWK has some additional software dependencies that you need to use in order to make its representation and one of them is the the Multi Codec registry, which is a basically a list of identifiers for different key representations. It's its own way of representing key material. And I found that actually really difficult to work with with didkey because you need a uvarant library so you can process the identifier, integer identifiers for the key representations.
And then you need to, you know, sometimes you need to do elliptic curve point compression which maybe isn't available in the programming language or libraries that you're using.
And then once you've got uvar in and elliptic curve point compression, you're ready to construct a didkey and those are the libraries you need to do that are like it's. It can be hard to get a library that's going to do that well that you like. There are open source implementations out there for multi codec and for elliptic curve point compression, but I don't need to use any of those libraries. When I open up web crypto and say export JWK software isolated key from my browser, I can get a software isolated public key in my browser without any libraries. It's part of the browser's native ecosystem. And the same thing is sort of true for node crypto exports or other libraries that have been targeting JWK for some time.
So it's easier to build a library that's built if you're trying to work with dids. Every dependency that you add is a thing you have to maintain for that piece of software.
When I was working with didkey, I asked the question, I was like, can we just use JWKS instead?
And the other folks involved in the didkey method specification didn't want to do that. They wanted it to be focused just on multicodec identifiers. And there were other folks that were excited about JWK representation at the time. And then it sort of some time went by and then I saw Jeremy's proposal and I was like, oh my God, it's, it's back, you know, and there's other folks who are interested in it and it's super exciting and jumped on immediately. And we have implementations that were really easy to modify to support it.
[00:32:33] Speaker C: Jeremy, you mentioned in our earlier conversation your feelings about dids. We want to know why don't you like dids?
[00:32:42] Speaker E: Yes.
So this is the comment I made that I'm not exactly a fan of dids. And it's not, you know, when I to qualify that a little bit. I mean the specification, my in the background here is my whole career has been in really in wire protocols, lower level systems. We often now are depending on cryptography in some way.
And my entire kind of perspective is based on creating specifications that have very clear outcomes and very clear boundaries on trust decisions and how you verify those.
So, you know, in sort of first encountering dids, you know, some years ago, my frustration came from not being able to clearly define the authorship, right, the ownership, the authority through a cryptographic decision and instead the specification relying on resolver software as your trust mechanism.
And I, you know, I was immediately like, okay, they're going to do this in 2.0, right? But you know, having learned that 1.0 was was very hard to reach consensus on and it makes it less likely that there's going to be a follow on spec anytime soon. But I would appreciate it in a follow on spec if the did auth side of things was actually specified, was actually inherent in part of it, such that I, as an application who's using dids can get back something from the resolver that I can cryptographically verify so that I'm not just trusting a resolver piece of software to say no, this, this entity you're talking to is the authority, you know, separately that they are. I have some way I can verify with that entity that they are the authority on this did not just what the resolver told me. And so that's really like again, wire protocols, cryptographic relationships, trust boundaries. It came from like oh, this is, this is like half of a solution. It's like maybe a little more than half, but it's a partial solution where I really wanted a complete solution. So it's kind of long been my complaint. But that doesn't mean I'm not adopting them. Right. I'm definitely still embracing them. But clearly with the JWK it is something you can cryptographically verify. So I'm sort of stepping slowly into that space.
[00:35:10] Speaker B: Tell me more about that. With a jwk, how do you cryptographically verify the authorship of the jwk?
[00:35:17] Speaker E: Well, it comes down to the, you know, is it by. Are the. Is the key material by reference or by value? Right. And just you call them generative DID methods. And so the generative DID methods, it's by value. So they come with the key information.
So you're, you don't have to go resolve against some other service in order to get the key information or the current or correct key information.
It also means they're unanchored. Right. So you can't anchor them against some other. The identifier isn't anchored against something else so that that key information could change. So there's very, very serious trade offs there. Right. You really have to. Your use case is going to demand if you can have anchored or unanchored solutions. And so that's really, I guess what you were asking, how do you verify with did JWK?
Well, you get the JWK back and in an OpenID or OAuth context you can use the JWK to verify a token.
Now you've got token verification, JWS signature verification that you can use the JWK for. So you've got other protocols that you can use to do that.
Now I think a did 2.0 that actually did the did authentic as you know, an additional step that a resolver can provide would be brilliant. I think it would be great for an application to be able to say, hey, how do I here's something from this entity. How do I verify that they actually own this did?
Not just resolving the current key, but verifying a request was actually a challenge was from them.
[00:36:57] Speaker B: Right. So part of the decentralized gestalt is to use platforms instead of institutions.
So who would sign this bitcoin based or an ethereum based did when there is no institution that is standing up and saying this is a legitimate DID from this institution, this entity.
[00:37:18] Speaker E: Well, like in Bitcoin or Ethereum, it would be the wallet, right? Their wallet would have the current private key for that's bound to their did.
And they would be able to accept a challenge and then respond to that challenge.
[00:37:35] Speaker A: That is how did auth, you know in quotes like works today, but it's not necessarily the answer to how do you have confidence in the integrity of an identifier in a given registry?
So like the issue is, you know, the DID spec and verifiable credentials spec, they use the term verifiable data registry to avoid talking about databases or blockchains basically.
And there are certain databases that can give you a receipt that proves that your record's included with Merkle proofs. There are blockchains that you also use, Merkle proofs that can prove inclusion. And for a given identifier that's anchored in such a system, you might want that additional information as part of the resolution metadata. I think that's sort of what you were saying before for Jeremy. But even once you've gotten that piece, the whole authenticating the controller or the subject is a separate sort of step where you have to challenge them and they have to sign with a key that's registered for that identifier. And then how do you trust that key is registered for that identifier at this point in time? That becomes a method specific question because each method solves for that differently. Bitcoin based ledgers are going to handle it one way, Ethereum based ones are going to handle it another.
And a major reason why the W3C is very unlikely to ever solve that problem in a more elegant way is they would have to sort of speak to the nature of using Bitcoin or Ethereum to provide that confidence in some way. And they've been historically kind of opposed to discussing those technologies by name. That's why we have the word verifiable data registry instead of blockchain or secure database.
[00:39:21] Speaker E: Yeah, and I was actually speaking to the latter, latter part of it that I would have loved to, or would still love to see the interaction with when you get a DID document to get a challenge in there or to be able to request a challenge, you know, some opaque body that I can then over my own protocol, over whatever mechanism I have to speak to that other party, I can present a challenge and you know, get a response that I can then hand to the resolver to Validate that response. Right. So that challenge response perspective is kind of that, that trust extension of the trust in the resolver to the my interaction with that party separate. And that's the part that I, I would love to see, I guess from a wire protocol perspective. Unfortunately, there's a lot, as you said, there's a lot of subtleties there, there's a lot of complications. And the actual protocol you're using to speak to them often imposes restrictions on how you would phrase that challenge and how you would get a response back. So it's not as easy, you know, oh, is this happening through a QR code now all of a sudden? These challenges and responses have to be really, really compact and have other security issues around them. So it's not easy. But that's where I kind of went into this, expecting that. And then, you know, yeah, I think.
[00:40:45] Speaker B: I think a big part of why we don't have that today, and I agree, I think it is the right next step for the community is this protocol layer element around how do you resolve a did?
And so in the current expectations about DID resolution, there is a quote unquote contract in the core spec and we're going to, we've sort of booted to they DID resolution spec that hey, we, we'll figure out how this works later. And it's way under specified. Like what is the metadata that you would get back from a DID document that would give you some of this confidence, like you might have an SPV sort of value that you could go look up on Bitcoin or whatever the mechanism might be. That's certainly method specific, but it's also a big gap that is TBD in the overall ecosystem. So I'm hoping our next iteration at the W3C will focus on DID resolution and hopefully address some of these questions.
[00:41:38] Speaker A: That you've raised, even if it doesn't. One of my favorite parts about DIDS is you can project from an existing cryptographic ecosystem into the space of dids. So for example, with webauthn and passkeys, when you're looking at the registration flow and the authentication flow, there's a public key verification component there.
That public key can be represented as a jwk and in a lot of cases it is represented as a JWK or another CBOR based key representation for those flows. There is a natural challenge flow built into that. But what you're authenticating there is not the subject. You're authenticating that particular authenticator for the subject.
And there's a whole bunch of other challenging.
The WebAuthn ecosystem is sort of client to server.
It's two party system, not a three party system like verifiable credentials. And it's also just about authentication.
But the cool thing about it is anytime you see a public key somewhere, that public key has a representation in one of these generative DID spaces. So it has a representation in DidKey and it has a representation in DigitABK. It could actually have several representations in Did. JWK.
[00:43:06] Speaker E: Yes. So it is a.
If you're already using, you know, OpenID OAuth that ecosystem, you know, as, as I've said and you have a requirement, right? You're. You're an engineer and you have a requirement like okay, we have to support gids.
It gives you. It's that escape hatch. It's like, okay, I don't actually have to install the universal resolver. I don't have to do blockchain. I don't have to go figure out how these anchored things work. I know in my ecosystem we already have a different anchoring mechanism or we already have a different solution, but I still have to represent this in dids, you know, to bridge to something else based on a requirement I'm given.
So it's kind of that escape hatch of I have requirements to use this, but I have my existing system.
What's the simplest way to connect the two without me having to install an ion node?
[00:44:06] Speaker D: The answer to this may have been layered into that last discussion, but Jeremy wanted to ask. You've referred to digib. JWK is an escape hatch at least once in our pre production call and I think once on the call here today. Mind explaining a little bit more by what you mean by this term as escape hatch?
[00:44:25] Speaker E: Well, that's an interesting question.
Obviously my background with XMPP and Jabber is I've been about decentralized architectures, decentralized protocols my entire career.
And it's, it's a very, very common theme.
What, what's little?
Kind of.
I have, I'm a little. I don't know how to, how to just say it really. But the word or the phrase self sovereign doesn't exactly ring true to me. Where if all of the decentralized work and even federated work, you know, all of all of that history, it isn't to me self sovereign feels like self asserted that I am saying things about myself.
And to me that that kind of definition, it is important, it is a component.
But you're, you're an ecosystem in and of yourself and maybe people who Some have some trust mechanism to trust what you say.
But when you look at what I call decentralized identity, it's that trust boundary isn't self sovereign anymore. Now I have the state of Colorado who's assigning me a driver's license, right? I have a little bit of sovereign sovereignty over how I can use that driver's license. But what's in it is an agreement between myself and the State of Colorado that we negotiated, you know, when they gave me the license and I provided evidence and I have some rights to update my address and so forth. So there's a negotiated. It's not self sovereign anymore, Right. It's an agreement. So it's decentralized in my identity because now I have some rights and they have some rights. But now you include a verifier as well, right? And they also have some rights. They say I have to have a driver's license number. I'm required to by law.
And so now they.
I have to give them that in order to have a relationship with them. So I lose a little bit of sovereignty that way too, right? So now my. It's not self sovereign anymore. It's really a decentralized relationship between multiple parties who all have some rights in that relationship.
[00:46:47] Speaker C: This is the end of part one and conclude concludes our show today. The conversation continues on our next episode and that will bring us to the end of our show today.
[00:46:59] Speaker B: Jeremy, thank you for joining us on the show today. Ori, thank you. Thanks also to our staff, our producer Eric o' Connell, and my co host, Eric Shue. I'm your host, Joe Andrew.
[00:47:10] Speaker C: Wherever you find the Rubrik 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 seeing 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 speaker's employer, organization, committee, or other group or individual.
