Episode Transcript
[00:00:00] Speaker A: Foreign.
[00:00:06] Speaker B: Welcome to the Rubric. 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 DidJWK, Jeremy Miller, known for creating Jabber and XMPP, and Orey Steele, CTO and co founder of Transmute.
This is part two of our two part episode.
Part one can be found at rubrik Ca.
[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:22] 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. Ori I think for the third time. Nice to have you back.
[00:02:56] Speaker A: It's awesome to be back at the.
[00:02:58] Speaker C: End of part one. Our guest Jeremy Miller was describing self sovereign identity as more of a decentralized relationship between multiple parties who all have some rights in that relationship.
Here we continue the conversation.
I very much appreciate that distinction and I love the shift to talk about it from the decentralized place because I've been, we've been looking at how to ask this question and that helps.
So, so what if it's centralized or decentralized?
[00:03:32] Speaker E: Loosely coupled systems foster innovation.
That's really. And for me that innovation comes through increased communication.
So when you loosely couple systems, when you create protocols that don't impose as many rules or restrictions, now you've let the adoption of those protocols, the things built on top of them innovate more. They have more wiggle room to kind of solve their own problems differently than whoever divined the protocol could have thought of. And that often increases the richness of the experience for the person or the richness of the communication they can accomplish using those tools built on top of those protocols. So I've always kind of seen it as a, as like kind of a fractal system, right? You, you define a few shapes, as few as possible at the lowest level so that you let the layers on top be able to reshape even more and have more adaptability to kind of the natural world as it's evolving.
So it really comes comes down to that freedom to innovate and change. You want to maximize the choices other people can make on top of your system. You still want to give them utility for interoperability because that also helps kind of maximize the number of people that can access it. But you still want, you want to leave as many of those choices as possible for the upper layers.
[00:05:04] Speaker C: And so you're saying a decentralized world allows more loose, more looseness and therefore more choices?
[00:05:12] Speaker E: Absolutely.
In OpenID Connect or OAuth ecosystem, it's this very kind of rigid defined relationships. And by decentralized identity, we've kind of unlocked a whole new layer on top of that where I can now get to have some choice as a user in how things.
I take that back. You know, you do have choice. Like you get those dialogues of do you want to share, do you want to add this application? You know, do you.
The type of oauth dialogues that everybody has seen.
But that relation, you're now, you're letting go of it right now you're saying Those two parties can have that relationship directly. Whereas now this lets me kind of sit in between the decentralized identity lets me sit in between that relationship.
So now they don't have to know anything necessarily about each other or have a direct relationship. I can kind of, you know, be that gateway. I can provide information that they might need to verify, but that the issuer no longer needs to know what's going on over here.
That said, privacy is also key here. You know, I think privacy is a fundamental kind of parallel to increasing that innovation and capability is that systems that don't have privacy will inherently inhibit adoption.
[00:06:37] Speaker D: Right.
[00:06:37] Speaker E: They inherently reduce the information that people want to put into the system or trust getting out of the system because it's not protecting that information with privacy. So now you have to really address privacy at all of these low layers so that people can have adopters, you know, just people, companies, entities can have more confidence that their interactions are not going to have some side effect that is going to affect them negatively. And so that also increasing the privacy here by not forcing a verifier and an issuer to communicate directly. So now you can reduce that kind of tracking ability that the issuer knows about where you're using your identity everywhere. And that's tremendous. So I think the.
I really love that I'm here and around and being able to be part of this transformation that I think is going to happen across the entire identity ecosystem where we're maximized. We're dramatically increasing the privacy capabilities and the innovation capabilities beyond what we have today.
[00:07:47] Speaker C: What I hear in some of your subtext there is that the more choices there are and the more integrations we have and the more people have privacy, then like also the more different kinds of people from different places can participate, that they're not.
They're not able to in a centralized system.
[00:08:04] Speaker E: Absolutely. I hope so. I've always thought the reason, one of the reasons I created Jabber was I believe that communication can heal the world, that the more people can communicate, the more they'll come to an understanding. Now, social media hasn't necessarily shown that to be true. So I think there's some caveats to, you know, my oversimplified definition there. But I still believe that connecting to people and letting them communicate is a net positive in the end.
[00:08:32] Speaker B: Yeah, I love how you've framed this, the question about SSI as decentralized identity, because frankly, if I had a different definition of decentralized than you did, I think I would be motivated to change mine because I respect what you've done right, you've helped define a whole generation in this space about how we think about it.
I want to reframe or push back a little bit about how you characterize self sovereign. However, sovereignty is not omniscience or omnipotence.
It just means that within a particular boundary you don't have to ask permission. If you're the king, then within your kingdom you don't have to ask permission. It doesn't mean that you can make rivers flow backwards or plants grow backwards or make gravity go away. You don't have all the power, you just don't have to ask anyone permission.
And outside of your kingdom you are treated as a peer.
So if the King of England is engaged with the King of France, they treat each other as peers. That's the respect between two sovereigns. And so I very much see the self sovereign identity as fundamentally that. What are these boundaries and how is it that I can be treated as a peer within that context?
Part of that you touched on, which is we're putting the user in the loop of the data sharing so that I'm a gateway of the actual flow of information, which is not quite what happens with OAuth and OpenID models.
I think we're aligned there. I just wanted to shape that sovereignty. Those boundaries are negotiated at the point of a sword.
I mean the territory that is the US's was earned with blood. Like these boundaries are what we are now collectively defining as we move into this new dimension of interactive or network based communication of what are the appropriate boundaries for an individual to control the information about them and what are not. And it's a really interesting open ended sort of sociological conversation that will probably take us 30 years or more to actually I think make serious headway in.
[00:10:34] Speaker A: So I'm glad you, you brought up the SSI topic. Like again what you were saying before about like the wording, like I think the framing of self sovereign identity is, I think it is problematic not, not, not to say that your Joe, what you just said in terms of one way of looking at it is, is valid. I think it is valid. It's just that people read into the word sovereign many, many different things.
For me the important property is it is a process that starts with access to mathematics as a fundamental capability.
And from that I can generate a private key. From that I can generate a public key.
From that public key I can start to build authentic relationships with components. Sometimes there's a registry that I need to work with. As soon as there's A registry, that concept of sovereignty starts to become a negotiated property. Because if is the registry forever, well then it's first come, first serve. I'm there, my name is, you know, this public key forever. But if that's a registry that is maintained by a group of individuals, that's not actually something where I can assert sovereignty anymore because it has to be negotiated. With those other components, you know, they could remove me from that registry or they could add me or they could add, you know, there's, there's these other sort of dynamics that come into play. So for me there's like there's the mathematics and the cryptography layer and then there's the legal framework and jurisdiction that you're existing in as a human being. You have to be in some 3D space on the planet Earth and you're going to have a legal jurisdiction that you're going to be existing within when you're in that 3D space.
And there's differences between the rights that you get from being in that 3D space than the rights that are inherent in understanding the mathematics of public key cryptography. The self sovereign identity in a lot of people's interpretation of it blends these together in a way that you can't easily see that they are separate entities. They're always separate. Whether or not I can maintain a private key as being private and use that to assert my authentic relationships is very different than whether or not those relationships will be respected by the group as a whole. The wider ecosystem, I think that wider ecosystem, that's the communication layer, Jeremy, you were talking about before, that is a negotiated property of societies.
I can't just bring my, I control my private key. So I have these rights attitude to that environment because there's a group of people that have to agree on what communication traffic will be carried within a network. It isn't just, you know, what one individual wishes for it to be.
[00:13:26] Speaker E: I love the, the addition of access to mathematics that it, it brings a, it really makes you step back and think about what, you know, the definition of sovereignty or just kind of what are your, you as a human making a choice, you know, you, you do have to choose a cryptographic library, right? And people can't make that choice without input from others that they trust or some experience that they trust, you know, from a platform vendor. So there's a lot of subtlety there in just access to mathematics because, you know, nobody's going to sit, well, maybe somebody, but pretty much nobody's going to sit down with their abacus and do elliptic curve math, but so you. There's, there's a lot that you have to build up in order to reach this digital space where you can both act with your identity, communicate with your identity, and cross lots of different geopolitical and technology boundaries.
[00:14:29] Speaker D: I would just add an addendum. You need access to mathematics and a source of randomness Also share I guess a fun little story before moving on to the next question about the term SSI and self sovereign identity, which is that last fall I actually got to sit down with Christopher Allen at the rebooting Web of Trust for dinner and he gave me a little bit of a history on that term and in the end he picked it not because he liked it, but because it was good for marketing.
He agrees with a lot of these same concerns that the term itself has some problematic components to it, but he thought it would be the best one to get traction in the open ecosystem space. So fun little history for that because he was getting a lot of pushback from his friends in the same space when he was throwing it around, but he ended up going with it anyway.
But onto the next question, which is is there anyone else we should know about that was involved with the DID JWK work?
[00:15:34] Speaker E: It's primarily the two of us. There's a number of other people that were reviewing it and helping with it. You know, my, my colleague David Waite was a big part of, you know, giving me feedback on it as well.
But yeah, it's pretty small group.
[00:15:51] Speaker A: I mean, I think David Chadwick was definitely interested in the early ideas around DID JWK back when we were negotiating or you know, on issues in the didkey method specification. So I know David Chadwick had had some thoughts at the time about whether DID JWK could be a thing, and I remembered that thing that I forgot like way back when when I said there was this one other thing that I couldn't remember. And it is, it's again, it's sort of related to the didkey method.
So like I said before, the didkey method relies on the multicodec table, which is basically an integer identifier for each of the different representations that could be encoded in that particular identifier space.
And Most of the Didkey representations for elliptic curve public keys or RSA or X25519 or ED25509 or whatever those particular entries in multicodec, there's an integer for sec P266R1, there's an integer for ED25519, but now there's a multi codec entry in that registry for JCS jwk, which is basically saying that didkey could be encoding a canonicalized representation of a JWK as well. This is a relatively new entry and it was created by a lot of folks who were excited about JSON webkey and for whatever reason they thought that it would be better to modify the multicodec registry then use DID JWK by itself.
I think that's a good example of some of the challenges with the didkey versus DID JWK sort of community.
There are different design philosophies at play there and some of the people who've contributed to didkey, I think are actually in a way contributors to DID jwk because they've commented on this is a thing that I really want to see.
But there's no way to get it into the didkey representation. And so it becomes a thing that digit WK can handle. Or it could be that they really just wanted to use jwk in which case it then sort of contributes back to didkey in the, in this registry, you know, multicodec registry component. So some of the folks who've worked on that might be folks who could in the future become contributors to digiwk. I would encourage them to look at digiwk instead of continuing to expand the multi codec registry because I think that there's going to be implementation burden and challenges associated with that approach.
[00:18:37] Speaker B: And in addition to people which companies are particularly behind dig JWK are involved in its work.
[00:18:46] Speaker E: Well, Ping Identity, obviously it's something we've implemented and adopted.
We work with a group of companies on an Interop profile as part of the Decentralized Identity Foundation.
And that Interop profile is for presentations and soon transition to also include issuance.
DID JWK is part of that Interop profile. So that larger group, you know, I can't speak to each company's position, but it does include Microsoft, IBM, Workday, Gen Digital.
So there's the awareness and the, you know, acceptance of it into that Interop profile at least covers those companies.
[00:19:39] Speaker A: Yep. Transmute obviously supports DID J. Owk.
You know, there's a lot of, like I said, like a lot of properties that we really like about DID jwk. We feel like it's just, it's basically the simplest DID method that you can use off the shelf tooling to quickly build an implementation of. I think it is currently number one in that positioning within the DID method registries. You know, there's a lot of DID methods out there.
This is one of the simplest and cheapest methods if you're going to do an implementation, if you want to do an implementation of really easy one. I've done a lot of method implementations in my time. This is definitely the easiest one I've ever done, and it's nice because it has a lot of interoperability with the existing ecosystem.
I don't want to sort of speak out of turn for other companies, but I know folks have because of how simple it is.
A lot of folks have added it as a first method that they use in testing software that's meant to support interoperability with other DID methods. So, for example, like decentralized web nodes as a technology that folks are working on, I think there's been some experimentation on using DID JWK within that ecosystem.
Yeah, I don't know how much more I should say about that, but obviously decentralized web nodes are a really popular topic within the Decentralized Entity foundation and Block, and I imagine other folks are excited about them as well.
[00:21:06] Speaker B: Cool. We've already shifted a little bit into talking about the conflict, the technical or personal challenges or political challenges.
So let's go to that directly. What were the challenges as the JWK came together?
[00:21:22] Speaker E: Honestly, it wasn't thanks to Ori being involved.
I think he brought a lot of the perspective of how to do things correctly to generate the DID documents and to do dids. So I think between the two of us, it wasn't really politically or even technically that challenging.
[00:21:45] Speaker A: Jeremy, One thing I'm really proud of for DID JWK is that the key identifier is just zero because didkey repeats the entire key encoding in the fragment and it's like it just makes their identifier super, super long. And this is one of those cases where it's like, it's awesome that did JWK just the key identifiers fragment 0. Like it's awesome.
[00:22:14] Speaker E: Thanks to you.
[00:22:15] Speaker A: Yes, I guess since you asked about the drama of DID methods and I have unprecedented insight into DID method drama as being an editor of the DID spec registries, a lot of folks look at DID JWK and they're like, well, I've already implemented support for didkey because it came first.
Why should I switch to DID jwk?
My answer to them is often, well, you probably have implemented DID JWK already then, and you just got a bunch of other code that is inflating that implementation bundle size potentially to add support for multi codec or elliptic curve compression or the DIR encoding for RRSA keys or JCS because you're implementing the DidKey JCS JWK variant. So if you've got an implementation out there that was built on top of didkey, you probably inside of that implementation have a smaller implementation of DID JWK that you could pull out and make good use of.
Another thing that's interesting is didkey as a method was a building block. A lot of people use it to build more complicated methods that have some registry component to them. And I think Digit of UK is naturally a better, smaller building block. At the beginning, you start with less dependencies, you still have the core data model representation, you still have the generative properties associated with it. So it's nice to start with a generative method and then add a registry method on top of it or build a registry method from a generative method.
Those are like common design patterns I've seen sort of repeated over time in different DID method design.
I think you know the main sort of drama fact within DID jwk there's two components.
Well, probably the biggest point of drama is the same public key could be represented many different identifiers because of the ordering of JSON members.
There's no canonicalization built into the method.
For some folks that is really concerning property. They really want a identifier scheme that's canonical.
The public key is always the same identifier. But within digit wk I could reorder properties and get a new identifier, but that comes from the fact that I don't need to ship a canonicalization library.
And that canonicalization library is a place where there could be lots of bugs, could be performance implications. There's all this other stuff that can come with adding that dependency. There's a design trade off there. Like folks who don't want the canonicalization boundary, they don't want those libraries in the implementation are excited about Digit wk, but folks that want a consistent identifier for the same public key, regardless of how it's represented, that might be wishing for that property and it's not there in digitabk.
[00:25:20] Speaker D: So you kind of read our minds orey a little bit. Looking ahead.
So kind of riffing off of what you just said, I do want to ask because you can have these different properties and they can be reordered so your DID string that gets generated from the JWK can be different for the same public key, Is that correct?
[00:25:43] Speaker E: So this comes back to our discussion around sovereignty and this.
[00:25:50] Speaker B: When I look.
[00:25:51] Speaker E: At a decentralized identifier, the sovereignty definition that you gave Joe was great in that I am the person or the entity who's operating the software, who's creating this decentralized identifier for me.
And I get to choose the encoding of that identifier, right? So maybe I'm sourcing it from a JWK because, you know, it's tied into some other ecosystem, but I am still, I have the right to choose how that's encoded. Not the issuer, not the verifier, not anybody else who's going to deal with this DID that they get. I chose that representation and I gave it to them.
So they shouldn't be, you know, although the DID resolver for DID JWK will decode that and generate a DID document, they as an application should not be storing, you know, that DID identifier in any of the representation in the one I gave them. They shouldn't be transforming it if they weren't told to, right? If the DID resolver gave them back this identifier, they should be using that.
So while I can now choose to encode it differently to say, move my keys around and generate a different identifier that happens to have the same key material, it's a different identifier, right? I chose to have a different identifier that is not the same one as the one before, even though they might have the same cryptographic key material underneath. And so we chose the DID document that comes out of that to represent that. You know, it represents that. It is a different identifier. We're not canonicalizing it, we're not changing that in any way.
So that's really where this decision came from to not do canonicalization is that when you choose to encode it, that is your sort of right to choose that form of encoding that everybody else should adhere to.
[00:27:57] Speaker A: And as an entity that might create many DID keys, you should be careful, don't reuse the same key and generate different encodings and use it with four or five different entities, unless that's your intention. And then also be aware. The important part is the private key remain private. That's where the power comes from.
When you have a private key that is compromised. If you have several identifiers for the public key representation of that, those are all also compromised.
It's important when you're using this technology to remember that the private key is the important part.
If you make many representations of the public key and distribute them all around, each of those points are places where if private key has been compromised, you have to go consider the implications of that fact, right?
And that problem, you see versions of that sort of challenge Kind of come up a lot in the web3 blockchain ecosystem because there's a lot of cases where there'll be sort of one secret that's used to maintain many separate public keys or many identifiers like the mnemonic and BIP 39 and BIP 44 standards for cryptocurrency wallets are an example of this. And it's a problem in those cases. It's like DID JWK in that like there's a single private key and then there's many possible public key representations. But it's. It's actually worse because with a mnemonic it's an infinite set of private keys, each of which has a public key representation and all of that set is destroyed when the mnemonic is lost.
So it's not specific. The reason I'm bringing up mnemonics and the challenges associated with working with them that's in a cryptocurrency ecosystem scenario that also has this non economical property. It's got massive adoption. Lots of people use mnemonics for cryptocurrency wallets, but they still require users to consider the cost of. When you lose your mnemonic, you lose all of these public identifiers bound to it.
[00:30:10] Speaker B: Yeah, I love this. I particularly like this distinction that really DID resolution is unidirectional. It's not expected that you're going to round trip from a valid DID document back to that original identifier. The important thing is that you can go from that DID to a DID document that can be considered authoritative.
So there. It's. It's only an elegance, it's only a computer scientist. I want things to be symmetric and go round trip. That I think is leading to this desire to have the DID JWK be canonical based on what the, you know, what is in the DID document. And that doesn't quite. It's really not important but. But I do want to push back on something you had said, Jeremy, in that there is a pattern we've been bumping into with the fact is you do need a negotiation between two parties about what DID method is going to be acceptable.
There will be service providers who can't handle btcr. There will be service providers who can't handle some NIST supplied stuff because they're a Chinese company and they're like screw nists. Like whatever the political or ideological boundaries are, it may just be you don't have the library for that particular quantum specific solution. And I can't support that DID method because I don't have a quantum computer to run it on, right? So there's just always going to be that first level negotiation which is a lot like nihongo hanasu kotoga dekvaska, right? Or parley vu francais. Like if I'm not using a language you understand, we're going to have a very hard time communicating. And so even as decentralized as we might make it, we still have that first step of between the two parties, we have to find a lingua franca that we can agree on.
[00:31:57] Speaker D: I did have a couple of questions. First one's clarification Jeremy, because I think you answered this, but I just want to be explicit which is that if I get two different dids from as far as I know, two different locations or DID JWK specifically, obviously, and then I resolve these two and I end up with a DID document that is identical except for the second one has one extra property that didn't exist in the first jwk. Would you consider these the dids different and also the DID documents different? Or should these be thought of as completely independent dids that should not be treated as the same thing.
[00:32:38] Speaker E: They are completely independent dids that should not be treated as the same. All of that DID uri, while some part of it might be the same, it will be different, right? So there will be a difference. So they do need to be treated as entirely separate things.
[00:32:51] Speaker A: And, and based on the private key, right? Like I could challenge both of them and they both might produce a signature that verifies with the same public key, ignoring your extra property that's been added. But from information theory perspective, if the identifier is different, the thing that it's identifying is meant to be sort of thought of as these are different names, right?
And so if any any bytes are different, it's a different identifier.
[00:33:18] Speaker D: And then I guess this is more of a spec clarification question, but in the spec it doesn't make it super clear how the JWK properties that are not the use property are meant to be represented in the DID document and where they are meant to be represented. So I just wanted to get your guys statement about how these extra properties that can be added that aren't explicitly in the specification are supposed to be represented in the DID document.
[00:33:49] Speaker E: Yes. So those any additional custom properties or values, they're only accessible inside the verification method. So in the verification method it will have public JW public key JWK and that will have the JSON of that JWK and all those properties will be there so they are accessible, but they are only accessible in that one place.
[00:34:13] Speaker D: That's what we assumed. Just wanted to get it explicitly stated. Thanks.
[00:34:18] Speaker A: Just in case this is giving people the idea that, oh, I'll just put lots of stuff inside of my JWK and then I'll have this open extensibility model. All of those properties are getting base 64 URL encoded and that's making your identifier super long.
Don't go adding like a bunch of properties to your jwk.
It's not a great idea to do that. It's also like potentially going to cause privacy issues. You start putting interesting stuff in there that's not related to the key material. Like be careful adding properties to a JSON web key.
[00:34:52] Speaker C: On the topic of anchoring, which you mentioned a little bit about before, what's the problem of anchoring and what would need to be done to solve it in a satisfactory way?
[00:35:03] Speaker E: The problem with anchoring with related to did JWK.
[00:35:07] Speaker C: Yes.
[00:35:08] Speaker E: You mean.
So that's where, as Ori had mentioned, JWKs do have x509 so you can reference a certificate chain.
So you could accomplish a form of anchoring using that one mechanism.
We haven't defined that.
We haven't really explored that there is a did x5.09 method.
So, you know, that might be.
[00:35:39] Speaker B: I.
[00:35:39] Speaker E: Guess it's not a use case that I've had to encounter yet, so I haven't had to think a lot about it.
So, you know, I don't know if that method would be. If you're going to be doing that, that might be a better method, but it's something we could explore. We could explore what would an anchored version look like using an XL509 certificate.
[00:36:01] Speaker A: There's also a similar to anchoring topic within the DID ecosystem, which is the concept of DID nesting.
I could take DID Web and I could make a particular DID Web implementation and I could take the Digit of UK piece and make it part of the DID Web.
That's nesting.
The authority is still DID Web. All of the security properties come from DID Web. But I might build on top of DID Web support for DID jwk inside of the identifier piece. I'm creating a custom profile.
Similarly, if I have a ledger based DID method out there, I might convert from that ledger based DID method into Digit of UK if they only had one particular key in that identifier.
So there are relationships between these generative identifier methods and the registry based ones and nesting, and they can be combined in different ways depending on what it is that you're trying to do.
And just coming back to that point Jeremy made at the beginning is such an important point.
If your DID method is really simple and it doesn't go into a whole bunch of details around it, it makes it a better building block for those kinds of scenarios. Because now you can combine it with these other methods in different ways. And because the method that you're using as that base building block is so simple, it's not going to have requirements or constraints that prohibit it from being combined, nested, or anchored with these other methods that you might want to build in the future. If you want to build a method on top of digit wk, is Z.
[00:37:47] Speaker E: Nesting actually defined anywhere?
[00:37:52] Speaker A: No, it's a thing I've seen people do. I've done it several times.
I think Wayne from Spruce has also talked about it before.
Yeah, because of the ordering for dids, you can treat the entire method specific identifier as its own space where you can add implementation detail.
The entire DID Web method specific identifier space can include an Ethereum did. It can include any other dids you want inside of there.
It's possible to do that kind of thing. The interpretation of it is if they can't read that in your method spec, nobody's going to understand it. But there's nothing that prevents you from adding those details in your method spec. To say, if I want to use DID JWK with DID Web, here's how the DID Web spec says for you to do that, you could modify the DID Web spec to do that.
[00:38:54] Speaker E: Okay, so nobody's explored actually kind of creating a universal anchoring.
So you could say, I'm going to or universal relationship.
[00:39:06] Speaker A: A lot. A lot of the methods that are registered nowadays, you can see that they have some intentionality around, like basically being a root namespace for other namespaces that are well established.
So I've seen some of the newer registry entries. They take this approach. The new registry method is like, you know, DID everything. And then the examples inside of it are like, here's a DID key inside of a DID everything, or here's a Tezos DID inside of a did everything.
So I've seen registry method authors start to take that kind of approach of like, what if my method was just a pointer to all of your other methods, or the five methods that I really like? Because there's a lot of methods out there and it sort of makes sense because some of the methods have unique properties that you sacrifice, you know, when you switch to a different method, like DID JWK is a simple method with no registry associated with it. When you add that to DID Web, the properties change. They become DID Web properties primarily.
So the concept of like nesting DID methods or taking one DID method and anchoring it inside of another is like.
There's a lot of work that's happening in the ecosystem to sort of explore that space, but I don't think there's any specific standards associated with that practice.
[00:40:30] Speaker B: So, Jeremy, could you tell me more about this Did X509? Do you know the name of it?
[00:40:36] Speaker E: It's Did X509.
[00:40:38] Speaker B: So it's not registered.
[00:40:41] Speaker A: Yeah, it is registered.
I can give some background on it. I know the folks who worked on it.
It's a newer DID method and it similar to Digit of uk. It comes from this idea of what if we create a DID method that just maps to the behavior we see in the industry in the wild, people using x509 all over the place.
Can we make a DID method that just describes what they're doing in terms of the DID spec?
So instead of having to build an entirely new thing, you go look at things in the wild and you find a way of describing them in a way that aligns with the spec.
And the cool thing about did x509 is, you know, there are.
Everyone thinks of x509 in terms of like securing web pages, you know, so I can do online banking. But X509 shows up in a lot of other places as well, including like code signing. And so there are certificates out there that are not meant to secure webpage interaction, but that are meant to represent confidence in a digital signature for a software supply chain artifact.
And that's a case where mapping to did x509 might provide some value because it kind of provides a generalized identifier namespace for those software signing use cases.
[00:42:00] Speaker B: So, Ari, I'm not seeing x509 in the registry then.
[00:42:05] Speaker A: It's never been registered, but the people talk to me about registering it and so I'm just misremembering.
[00:42:12] Speaker B: Okay, that's all good. As you know, we run the DID directory and I checked there and it wasn't there. So I was like, oh, did our subscribe process fail?
But I think it's also not a DID spec yet.
[00:42:27] Speaker D: Well, as we move to wrap up the show, thank you guys for the great discussion. And what's next for DID jwk?
[00:42:35] Speaker E: Well, this anchoring discussion is interesting. Again, I haven't encountered the use case for it and that for me, I'd like to form protocols and specs based on kind of real use cases because it really helps inform, you know, exactly what you need to do.
So that's a.
That's definitely something that could come in the future, but that's really the only big thing I think, on the radar.
[00:42:59] Speaker A: That I've seen right now.
[00:43:02] Speaker C: How can our listeners get involved?
[00:43:05] Speaker E: I think there's a link that's going to be shared to the GitHub repo. We would love any discussion on the GitHub issues as well as reaching out to us directly if you're involved in any of the standard stuff. I'm on the Decentralized Identity Foundation Slack and the W3C Slack and IETF Slack, so if you want to have a chat, you can grab me in any of those mechanisms.
But yeah, GitHub and reach out anywhere.
[00:43:34] Speaker B: As we wrap up, we like to ask all of our guests, We've asked Orey now twice this question. This will be your third time. Orey, other than the DID method we're talking about today, which of course is didjwk, what is your favorite DID method?
[00:43:48] Speaker A: I broke DID meme. Did meme used to be a DID method. Now DID meme is just a transport for DID jwk. That was a change that I made to it not too long ago. Did mean used to have IPFs and images and steganography in it. And then I just made DID mean into when you use steganography and images to transport a DID jwk.
So I made use of the fact that DID JWK is really easy to implement. I was able to drop a whole bunch of dependencies from didmeme. It made didmeme so much better just using DID JWK instead.
Jwk. It's my favorite DID method.
I guess I'd give a shout out to some of the newer DID methods that we talked about on the call as well. The did x509 proposal, which isn't registered, and did CCF, which is relatively new, which is related to this concept of maybe your verifiable data registry doesn't need to be a blockchain, which is something I really believe in. Like, I think the verifiable data registry does not need to be a blockchain in order to provide a lot of value as a registry. And there's lots of verifiable database systems out there like CCF from Microsoft, Amazon, qldb, Google Trillion. They're great verifiable data registry building blocks if you want to build a DID method.
[00:45:12] Speaker C: All right, well, speaking of shout outs we'd like to take a moment for our shameless plug segment. Do either of you have something you would like to shamelessly plug today?
[00:45:22] Speaker E: I'd love to give a shout out for the Jose Working Group at the itf. We're going to be doing a lot of zero knowledge proof work there to kind of bring the traditional elliptic curve and RSA algorithm ecosystems, move them forward to a lot of the newer, more advanced zero knowledge proof based algorithms. So there's quite a bit of work ahead there.
But I'd love anybody who's interested in those kind of privacy preserving algorithm techniques to go join the mailing list and get involved.
[00:45:56] Speaker A: Awesome. I would also like to give a shout out to a different IETF Working group, the Supply Chain Integrity, Transparency and Trust Working Group at ietf, which is really interested in securing software supply chains using cozy, which is the CBOR cousin to hozy, which we've spent so much time talking about today. And what's cool about the SCIT Working Group at IETF is it's also interested in applying decentralized identifiers to this use case as well.
[00:46:26] Speaker B: Cool. I want to shout out to the W3C and not just because you mentioned some other standards organizations. Sorry. I've been participating as an invited expert in both the DID working group and the Verifiable Credentials Working group. And for those of you out there who are trying to get into this work or trying to get into this industry, it is an incredible open door for you to show up and participate in community groups like the Credentials Community Group or once you get involved or join the organization properly, it's very welcoming and you are invited to join the working groups to bring your use cases, to bring your experience as an implementer, to join the debate and help shape these standards. Because the reality is the standards only get better when people bring in more use cases that help us address things we maybe weren't considering before and we need more people in these groups, we need more diversity, etc. So that's my shout out. Learn about the W3C, the IETF, the ISO, but I'm most familiar with the W3C. So that's my shout out w3.org and.
[00:47:33] Speaker C: That will bring us to the end of our show today.
[00:47:36] 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:47] 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.
