[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 A: And I'm Eric Shue.
[00:00:12] Speaker C: Today on the show we talk with Martin Riedel and Daniel Kelleher, co editors and implementers of the DIDSOL specification.
This is part two of our two part episode. Part one can be found at Rubrik cc.
[00:00:30] Speaker D: It'd be interesting if we dug into this a little bit.
[00:00:35] 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 that our listeners that's you can make better decisions about which DID method is best for your use.
[00:00:52] 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 used for any purpose.
[00:01:13] Speaker A: 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:39] Speaker C: Different DID methods use different underlying mechanisms with different performance, security and privacy trade offs.
[00:01:48] 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 A: Martin Riedel was most recently the CTO of identity.com he has been working in the digital identity space for over a decade and is an active contributor to leading organizations like DIFF, W3C and OMA3.
Martin's journey in digital identity began in 2014 at the Bundes Notar Kammer, Germany, where he worked on an EIDAS compliant trust service for lawyers and notaries.
Since 2018, he has dedicated his efforts to the evolving decentralized identity landscape, holding significant roles at Civic Technologies, consensus, mesh, and identity.com Martin, welcome to the show.
[00:02:35] Speaker E: Thanks for having me.
[00:02:36] Speaker C: Daniel Kelleher is the VP of Engineering at Civic Technologies and has been working at the Cross section of Decentralized Identity and blockchain since 2018. He is passionate about building a self sovereign future for all that is both secure, egalitarian and user friendly. Daniel has a background in finance and E government and since 2020 has been a leading voice and builder in the Solana community. Co building with Martin one of the first account abstraction frameworks on Solana, the first encrypted instant messenger, as well as products in the carbon market space, among others. Daniel, welcome to the show.
[00:03:15] Speaker D: Hi, how's it going? Thanks for having me.
[00:03:17] Speaker C: Here we continue the conversation.
[00:03:20] Speaker B: All right, so let's talk about the people involved.
[00:03:23] Speaker C: Firstly, what is important about decentralized identity work to you personally?
[00:03:30] Speaker D: Well, for me personally, the egalitarian nature of decentralized identity is the main driving factor, I would say the ability to have your identity.
Decentralized identity represents what I think is the most important about real world identity in that it is a basic human right that everyone has when they're born. It's not provisioned to you by a company or a government.
Now, certain documents and certain proofs of that identity right now, like passports and so forth, for necessity, for practical reasons, are provisioned to you. But your very identity itself is something you control.
And decentralized identity represents that in the, in the technical, in the, in the digital space for the first time, really a lot of people talk about the Internet having a missing identity layer. And decentralized identity is that missing layer replacing the, the centralized or federated identity models that we are currently living in what you would call Web2.
And if you have that right, if you get that layer right, then you can build in a stable and egalitarian way everything on top, whether it's banking, communication or travel or anything like that. If you don't get that piece right, then you're building on effectively an inverted pyramid, you where everything's wobbly, everything's subject to a small number of organizations that are in control.
So it's that aspect that I think is the fact that it's so fundamental to everything else that really attracts me to the space.
[00:05:17] Speaker A: Could you each spend a little bit of time talking about what you did before you started working on Didsoul is what led you to this work?
[00:05:28] Speaker E: Yeah, I think I was always drawn naturally to that space without me even knowing it. So I think a little story about me is that I'm really a self hosting nerd or a home lab nerd, which means I have my synology and now I have a Proxmox cluster running here in my home and it's really important that I can access my home network really fluently and I have a fiber and that's kind of a representation of my values. Like I feel this data is important to me and I feel I Want to control the excess. And whenever, like it's not there, I feel like a little insecure. And that's a representation how I feel about the identity space.
In a way I understand the ease of use argument and, and whenever there's a power outage here, I painfully understand the ease of use argument. But still I would not host certain things in the cloud because I really love to be in control and I hope that I can convince other people about the fact that it's valuable to have that. I know it's not easy to build up this infrastructure and I really support any kind of project that supports building these kind of decentralized infrastructure. And in a way I hope that what we are working on and dids are kind of the really base layer of enabling this in a way that we maybe can combine the best of both worlds. Like I have nothing against secured end to end encrypted data being hosted in some data center, but follow these principles and convince me that this is a good solution to not store it at home anymore.
[00:07:31] Speaker D: Yeah, sure.
So starting from the start, I mentioned that I was working in finance, kind of back office, not the cutting edge kind of quant stuff. I don't know if that had a significant, I wouldn't say it had any significant positive influence.
Maybe it showed me the alternatives. I definitely do.
I do remember hearing stories and I was working in finance during the times of the 2008 crash and I don't really have any particular horror stories, but there were definitely, you know, things I heard around. For example, there's something called the Libor scandal in, in the uk, which is basically banks would.
There's a. There's a kind of a, A tra.
A lending rate, a standardized lending rate that all banks use to, to lend money to each other. And that was being manipulated by. By banks. Right. So they were. I can't remember exactly to what end, presumably nefarious, but they were basically lying about that rate and they could do that because there really wasn't any kind of decentralized consensus layer that they all kind of had to stick to and that was cryptographically verified. So those sort of things, although at the time I didn't have the mechanisms to find alternatives, definitely stuck out as wrong and bad.
Not to mention the fact that there was no decentralized ledger also meant that just simple ledger activities, you know, balances and so on, could also be theoretically manipulated.
Then I moved from there into E government, which is actually where I started working with Martin in Germany. And although Martin was more directly working with the trust service providers and Eidas related services that we mentioned during Martin's bio.
It also gave me a very interesting insight into how to establish trust through cryptographic methods because that was a lot of the work that we were doing was moving as part of the digitalization of Germany. Moving from trust being the paper is the document is signed in a locker owned by a notary that is trusted by the state apparatus to something more modern and cryptographically verifiable. So again just maybe the bits and pieces that lead towards a career and decentralized identity. And then I started working at Civic Technologies which is one of the earliest and the longest running kind of identity providers in the Web3 space. Even before Web3 really was a thing. And it was as part of my work in Civic and specifically building applications that that's held true to decentralized identity principles while still having high degree of usability that led me directly to work with Martin on building this new DID method.
[00:10:34] Speaker E: Yeah, I think you can already see that Dan in my life started crossing before even doing the Web three US company based work. And I think looking back it's always funny because when you ask me in 2014 like when I asked worked for the Bundes NotArkama is like decentralized identity or will identity be like your life path? I would have said no, I just like stumbled into that. But I really find this Bundes notarkama work really elemental to see where my trajectory was going because we had this trust service it was like we very European regulatory driven and I need I saw like firsthand how we needed to provide solution that adhered to the EU wide regulation that needed to be solved. And translating this into technical solution was really cool. And Germany regulates actually a lot of other things that made very interesting challenges to identity. Like one way work that we also started was like all and I don't know even if it's lifelong but all the notary documents that are certified are now centrally stored at the Buddhist Notakama but they're centrally stored end to end encrypted for notaries.
However as you know like notaries don't live forever. So you have like a lot of use cases around transitioning trust and it's not even like this notary dies and then the next notary comes and just the key rotates. But sometimes it's also like notaries get put together or other documents go to other notaries and to provide a centrally hosted but decentralized trust system to provide functionality like that were really Interesting question and I think was direct segue into like then the web3 work which started by coincidence I feel later. And Dan brought me into this and in a way it was first Ethereum and other chains and then I actually talked to Anatoli from Solana really early on. I remember having like a one on one in a conference room and he trying to explain proof of history to me and I'm like what?
But it, it was really cool. And then that's how we got into the Solana and that's how we then applied our identity program background to the Solana chain.
[00:13:09] Speaker B: Very cool. Well, we've had the two of you here on our show and you're both editors of the spec. Sounds like you both also were involved in implementing the code. Who else was involved in creating the didcel spec?
[00:13:21] Speaker D: It was one of the person involved, well, not so much in creating the spec, but the first reference implementation, the first version that was rewritten for V2 but it was. The spec didn't change very much in those two implementations. John Cinque from the Solana Labs team was very instrumental in that first version and very helpful.
Thanks to John.
[00:13:47] Speaker B: All right, this is a partner show where we like to talk about conflict.
So it could be people that cause you grief, it could be technology issues that you wrestled with and couldn't figure out.
Any kind of conflict you came up with is fair game for this section.
So I want to start with a question.
So did sol's deterministic DID document generation only provides verification relationships for authentication and for capability invocation? Why didn't you use it for the other verification relationships as well?
[00:14:20] Speaker E: I think the answer there is pretty easy. We inherited one to one from DID etherr. So if you like resolve a generative DID ether are right now you would see exactly the same relationship.
Yeah, I think the idea was to have the minimal usable kind of requirements because this is the state that is represented by every DID that has not been initialized yet. So it must be able to change its own state. So that's capability invocation and you probably want to authenticate in somewhere. So I think these are the plus minimizing then all the other implications.
But yeah, the simple answer is we took it from etherr.
[00:15:11] Speaker A: Is it correct to say that all didsoul updates must go through the didsoul program on swana?
[00:15:16] Speaker D: Yes, that's correct.
It governs which updates are acceptable and which aren't.
[00:15:23] Speaker A: Okay, is this program updatable and are there any plans to update it in the future?
[00:15:28] Speaker D: No plans to Update it? Yes, it is updateable right now. There are plans to revoke that update ability.
No strict timeline yet.
[00:15:40] Speaker A: Is there a vague timeline?
It's okay. If not, I would say, is that something you're looking to get done by the end of the year or within the next year, say?
[00:15:52] Speaker D: Yeah, I would say within 18 months is a reasonable timeline.
The question is, you know, you want to make sure to have enough, enough different organizations using it that you're fairly confident that the day after you revoke the update ability, somebody isn't going to come to it saying, hey, it'll be really great. And it would be used 100 times more frequently if it had this one little thing.
[00:16:15] Speaker A: Yeah.
[00:16:16] Speaker C: Why do you call offline creation registration when nothing goes on chain?
[00:16:22] Speaker D: My answer would be that it's in order to make it compliant with the DID spec. So it's registration in the sense of it of the DID spec, but you're right on chain, nothing's happening.
[00:16:35] Speaker C: Okay, fair enough.
[00:16:37] Speaker B: In the revocation section of the specification, it says that when a SOLDID has been deleted, the DID document will resolve to the generated version.
With that in mind, how do we tell the difference when we get back a response from the resolver between DID that's never had an update posted and one that has in fact been deleted or revoked?
[00:16:57] Speaker E: I mean, this is a good question. At the current state, you will not be able to make that differentiation. And I think it's a very valid point to raise.
So when we wrote didsol, I think we try to align a lot in general Solana program management, which means when you invest money somewhere you want to get it back, meaning you want to close your account. And that might be the technical reason why we put it in like this.
I think it is a conformant update to make to restrict that a little bit more to say you don't close out completely, but you close up to a minimal state in a way. And what does it mean? You might never reactivate it. It's just revoked for life and you need to leave a little soul in there.
[00:17:50] Speaker A: Another point on revocation, once a DID has been revoked, if someone asks to resolve that did, they would get back the generated version of the DID document.
From the resolver's point of view, this means that they would assume the initial creator of the DID was still in control of the did, even if it had had the controller change a number of times since its creation prior to the replication.
I guess, is this, does that sound accurate?
And I guess, is there a way to tell if a DID has had its controller updated after revocation is.
After revocation has occurred.
[00:18:36] Speaker D: No. So that's kind of the. It is accurate what you said. And there isn't a way to tell after revocation has occurred. It's a form of.
It's a follow on from the previous answer, really.
So you would have to employ a different strategy. For example, you could, you know, remove the key from the did.
And actually Martin, you'll have to remind me, one of the other features is the no lockout feature.
But I can't remember if it's.
If it's automatic or.
[00:19:14] Speaker E: No, it's always in there. It's one of the. It fits right in this conference.
[00:19:18] Speaker D: Let's talk about that next.
[00:19:19] Speaker E: Let's see. Like this. I think so I think just to answer Eric one more time, I think we don't have a revoke CRUD operation or we don't have a specific revoke operation. We just have a close operation. And in a way our statement would always be it's still in the self sovereign control of the user not to close out their account or to understand the implications of closing out their account.
And the thinking was maybe someone locks a lot of money in there or whatever, they want to revert an erroneous transaction that they did that never shows up on chain.
So we have to align this a little with the DID specification. Can we still allow to close in a certain timeframe or do we not allow to close at all because it reverts to that state and only allow a revocation function which burns that DID in a way and makes it like eternally revoked?
Our current answer in the current dead state would be like educate the user that closing is probably a bad idea and rather reduce your DID to a minimum, which is a representation of a provoked state.
And now I'm happy to talk about like there are two controversial functions.
I don't know if they're in the question function like one dance set about which is like a user protection kind of feature. Like in a way you can never revoke your last capability invocation, which I think was kind of a cool feature. But I think I could imagine a lot of use cases where you actually want to do that. Like want to create dids that are not modifiable anymore but still represent some kind of state.
But at that point I was more like usability feature. You don't want to lock yourself out by accident, so you cannot revoke your last capability invocation.
And that's a feature right now of Ditzol and that's something that could be discussed how we would be looking for community feedback around that, for example.
[00:21:41] Speaker C: So does that mean. Excuse me. So does that mean the last.
The last one stands until there's a change. Like you have to. You can't just have nothing. There needs to be something.
[00:21:53] Speaker D: You could of course add a key and then. Then burn the private key, so to speak, making it de facto uneditable. But it wouldn't appear uneditable to an external observer. So there's currently no way to create a DID that is provably uneditable without.
[00:22:15] Speaker A: Some off chain proof, I would imagine, like you and I could prove to each other possibly that a key has.
[00:22:23] Speaker D: Been burned if there's a burn ceremony and then you assign that, the key to that to the did, then. Yeah, exactly.
[00:22:33] Speaker C: Does the resolver pass back the history of signed transactions or is the caller of the resolver just supposed to hope the resolver does it correctly?
[00:22:43] Speaker D: The latter. Right now the spec doesn't require.
The spec doesn't include any kind of transaction history. So of course a more sophisticated resolver would, for example, do a.
Would poll a number of permissionless clients, or RPCs as they're called in the crypto space and ask all of them for the state and then respond back only if they all agree. That would be an extra level of security.
[00:23:15] Speaker E: And I think so. One more thing, but I have to think about it a little bit. Dan, please correct me if I'm wrong. I think it's also not possible on Solana to reconstruct historic state.
So I think I couldn't write a resolver that says give me the DID state at epoch xyz, at least not from the account model because the account drops. Right.
But if you.
You could do it from a transaction.
[00:23:51] Speaker D: Model, not from the account. But if you. If you had a.
Yeah, if you stored all transactions, which full nodes need to. So if you had access to a full node, then actually no, full nodes don't need to. That's a correction. They can, but they don't need to. So if you had access to a full node which did store all the transactions, then you could. It would be a very inefficient but maximally secure way of reconstructing the current state.
[00:24:19] Speaker E: But I think what we're saying is that our didsol resolver implementation doesn't expose that. It just exposes this is the current account representation, which is provably correct because.
[00:24:31] Speaker D: We trust Solana and whichever RPC we're connected to.
[00:24:38] Speaker B: Okay, how do I want to Come at this next question.
So, based on how we've talked about it so far, I'm fairly certain the SOL program itself is not a resolver in the way that the DID specification talks about having a resolver that accesses the VDR and gives you back your DID document and some metadata about it.
If that's correct, then I take it there is a piece of software that you guys have written that does speak Solana and gives you back the results, and it is not just the SOL application.
[00:25:14] Speaker D: That's right. As we mentioned before, the program is actually only involved in the CRUD operation. Sorry, without the R SO CRUD operations, the reading doesn't actually require the program at all. It just needs something, as you said, that speaks Solana, as in can call the chain via an RPC to look up the state of a particular account and then parse that account into a DID method.
And we have an open source reference implementation for that operation, which is in turn encapsulated in a few different resolver applications, a JavaScript npm library, a command line tool, and a driver for the DIF's universal resolver.
[00:25:58] Speaker A: So what happens if someone queries the SOL program for a DID identifier for a DID that has never been created.
[00:26:07] Speaker D: That falls in the category of a generative did. So it has this default state. So any key that you can think of that you can derive is already a DID or has already a DID representation, and that's a generative did. So the resolver encapsulates that logic. So it looks up Solana and it says, is there an account for this did? If Solana says yes, then it parses the data. If it says no, then it spits out the generative default state.
[00:26:39] Speaker A: So it's the sole program that will spit out the generative default state, not the resolver.
[00:26:45] Speaker D: No, it's the resolver. The program is actually not involved in that entire operation at that point.
[00:26:51] Speaker E: And that's a separated, trusted kind of piece of code that you need to trust. But it's not like on chain verifiable.
So you need to look up that code and determine that you trust that resolver code.
[00:27:09] Speaker A: So presumably when the resolver queries the chain for this did, they would receive some sort of null flag from the sole program that tells it to generate the generative form of the DID document.
[00:27:23] Speaker D: Yeah, from the chain itself. So yes, the account comes back. There's always an account. And actually.
But that account has a program owner field. If the program owner is the didsol program, then you Know that it has data in it that should be interpreted as a DID document. And if it's the system program, then that's the null flag as you described it.
[00:27:48] Speaker B: What if it's not a legitimate identifier?
[00:27:50] Speaker D: Then it will just error out.
[00:27:53] Speaker B: Okay, so there is a third issue.
[00:27:55] Speaker D: If you put foo in, then it will just return an error.
[00:27:59] Speaker E: Yeah, but that is already under the control of the resolver in a way because of the account model where we say the account is derived by the program address and by the DID identifier and by some kind of salt that is already a deterministic process that should deterministically give you a correct ED2551 and count representation. But if someone like skips all that and says just give me foo on chain like a foo account on Solana, then it errors out.
[00:28:35] Speaker C: What's foo?
[00:28:40] Speaker A: It's just a common programming term.
Foobar.
[00:28:43] Speaker E: Foo Bar. It's a bar.
[00:28:45] Speaker C: What does that mean? Oh, I see, I see.
[00:28:47] Speaker B: Yeah, we often just have methods called foo and methods called bar. It's just an arbitrary name of a method.
[00:28:54] Speaker C: I see. Okay, just checking.
[00:28:56] Speaker B: That's good. That's a good night. Person question.
[00:29:00] Speaker E: Should I give you another controversial feature of ditzel?
[00:29:06] Speaker B: Yes, please.
[00:29:07] Speaker E: We end this flag section so you can give flags to the verification methods. And we talked about one flag which is ownership proof. So if you prove to the chain that you have that private key, then you can set that ownership proof flag. Another flag is DID DOC hidden. So DID document hidden. So you can have verification method states in your DID state or in your Solana on chain state, but you can set a flag that the resolver implementation or that an accurate resolver implementation would say. If that DID DOC hidden flag is set, I don't return it in the DID document.
What are your opinions on that?
[00:29:56] Speaker B: Well, if you turn the question around, my take is it's part of the complexity of should you obscure your DID document.
Historically, I've had the same feeling that Daniel mentioned earlier, that if I can't get to the DID document, then I can't verify any interactions with the DID controller.
If you have secret or private or gated DID documents in any way, then the gating mechanism becomes a point of centralization.
I could put the DID document behind a URL that requires a login, and in order for you to log in, I need you to KYC in or I need you to Facebook login or whatever. And that all starts to create points of centralization that I am not at all a Big fan of.
So I would try and solve it differently.
[00:30:47] Speaker E: Okay. I think the motivation for that feature is again about this dualism of on chain representation and off chain representation, since we try to put both these functionality in the same state. And we call it didstate, but maybe we should call it cryptidstate when we use it on chain and we call it didstate when we resolve it to a DID document. But we kind of wanted to support a feature where you can say, I can use some key on chain in order to do something to trigger a transaction or whatever through Cryptid, but I don't want that represented in my DID document. And yeah, I think it's controversial and I see your point and that is something that we are looking for feedback for features like this.
[00:31:41] Speaker B: One option you might consider is a variation where what's in the DID document is a commitment to maybe just those triples.
The JSON representations can be treated as RDF triples. Maybe that's way too technical. But my point being is that you could replace the verification method with a commitment that is a hashtag of a document that just has that bit of information, which then means someone has to get it from somewhere else, which is already what you're trying to do. But at least you would have the verification that. If someone did provide this verification method to me in a private interaction, then I could check, oh, that is one of the verification methods, because the hash matches up.
That may give you some privacy, yet still have some cryptographic guarantees.
That may be more interesting than just having the hidden that a resolver is theoretically going to honor. But in this case, your resolver now doesn't have a choice.
The resolver doesn't have the actual underlying data, so they can't accidentally reveal it the user. But now you have to deal with the user flow where how does the controller who's using the DID get that extra metadata attached?
It's a tricky problem, but it's something you might think about.
And I love that you turn the tables and ask us a question.
[00:33:09] Speaker E: Yeah, that is the phase we're in right now. I think we packed a lot of features in and we find some features very cool, but we also want to make sure that it's compliant. It doesn't impact DID specifications.
And yeah, it's not a bloat in a way. Like if a feature doesn't make sense, I think we would remove it again.
And there's one last flag that I want to talk about in this controversial section. And then I think we have all the Detailed features of didsolout. Another verification method flag that we have is called protected.
So you can protect a verification method, which means it cannot be removed by another verification method with a capability invocation. So in a normal setting, when you don't have a protected flag, like key A can remove key B if it's authoritative enough, if you have a protected flag set, which you can only set with that key. So if I want to set the protected flag on key B, I need to do that with key B. So then that flag is set, and then I cannot remove it with key A anymore. Even though key A has a capability invocation, the process would be key B needs to do a dedicated transaction with key B, again, remove that flag, and then key B could remove it, or key A could remove it.
[00:34:46] Speaker B: Yeah, that's interesting.
To answer the question you asked before.
Seems to me one of the things we don't have a standard for is how to provide an additional scoping to a capability invocation.
But I think we might be able to get there with, I don't know if it's a query term, you know, some innovation in standardizing what certain DID URL features might be like. We could use the fragment identifier, we use a question mark.
But you could say, look, this section is only updatable by this verification method.
And we just haven't teased that out like the within document mechanism to say, hey, I've got a capability invocation. But I mean, just about updating that section or just about updating that verification method.
So that's definitely a research topic that I think, you know, we'll get to.
[00:35:42] Speaker E: Yeah, we, we would like to expose Weeks. We would love to expose these flags over the document as well. And the, the technical motivation for that is what Daniel talked about, like a recovery key in your DID document, which has some higher protection requirements.
Like a recovery key in a DID document only makes sense if an attacker cannot come in and be like, hey, I got hold of one of your DID keys and I immediately remove your recovery key. And that's the use case scenario you wanted to protect.
And I think that's for right now. It's like a convenient solution, but we have to see how that fits into the spec and the resolution from a. From a resolver point of view, how these flags get resolved.
[00:36:34] Speaker B: Okay, I think that wraps up our questions for controversy and conflict.
Let's talk about what's next. Right, so that's the question.
[00:36:44] Speaker C: What's next?
That's all right. We do need better language for our transitions here. But that is, that is the question. What's next for didsol?
[00:36:56] Speaker D: Yeah. So from my perspective, we would like to see more people play around with it.
We would like to see more people adopted into their systems and then provide feedback. We built it, as kind of Martin pointed out as well, we built it largely for our own personal usage in our
[email protected] and identity.com and although we anticipated it's used in other fields, I feel like in the initial couple of years we didn't put a huge amount of effort into outreach and into really selling it because it met our requirements.
But we do think we've got something that's very useful, not just in the Solana ecosystem, but outside as well.
And so we'd love to give it a little bit more publicity and see it used.
There is some scope, as we said, because the program is still updatable, There is some scope for changing some of the features in a minor way.
And then we also just tying in with the conversation we had right at the start about account abstraction.
Account abstraction, again for the non blockchain, non cryptocurrency listeners, is becoming a really hot topic right now.
But the intersection between dids and Identity and account abstraction, I think is under explored. And we started with that. We started with an account abstraction that was linked with the did, and we think that there's a lot more scope there. So really exploring that, working again and trying to bring more contributors to the Cryptid account abstraction program based on top of didsoul would be one of our strong motivators as well.
[00:38:51] Speaker A: And how could people that might be interested in didsoul get involved with it?
[00:38:56] Speaker D: Very good question.
So the first thing to do is to reach out to us either atcivic or identity.com probably through Twitter. That's the easiest way.
The more formal way would also be to look at the GitHub repository for didsol and submit an issue or a discussion there.
And am I missing any other important communication channels? Martin?
[00:39:21] Speaker E: Yeah, yeah, No, I don't think so. You mentioned Discord.
[00:39:26] Speaker D: Right? Yes. Civic also has a discord and identity.com as well.
And I would love if the Discord conversation were about things like DID methods rather than what?
[00:39:40] Speaker B: Well, let's get links to that in our sandbox. We're happy to point people to Discord and try and get them involved.
[00:39:45] Speaker A: Yeah, the Twitter and Discord invite.
[00:39:49] Speaker E: So yeah, we have not a rich feature set planned and the reason for this is I feel we already put a rich feature set in and we rather want to validate the existing feature set before like adding to to it or before locking it off.
So we really would be looking forward to feedback and that is one the JITSOL method. And if you're really interested, this kind of cryptid program that implements this on chain account abstraction with your ditzel.
So have a look at it and we're happy for your feedback.
[00:40:29] Speaker B: Very cool. Well we definitely have the cryptid URLs in the show notes.
[00:40:34] Speaker C: Our final segment of the podcast is our Shameless Plug segment, so we'd like to take a moment for that.
Do either of you have something you would like to shamelessly plug?
[00:40:47] Speaker D: I'll go first and if on the off chance there's any time left then Martin can go after So I actually really wanted to plug Cryptid but we've talked a lot about it the account abstraction there. So I'll also talk about civic.com a little bit. So it's the is the company where I spend most of my time and we are building a Web3 identity layer. So one of the most important parts of that offering is called Civic Pass, a tokenized identity layer based on top of dids and verifiable credentials and it's used to provide regulatory compliance and civil or bot resistance to Web3 applications.
So the idea is you can, let's say you're, I don't know, selling an NFT or you're running an exchange on the blockchain and you want to protect against people spinning up thousands and thousands and thousands of accounts and thereby completely corrupting your business, your economic model or whatever it might be.
That by the way, is that happens all the time.
Every Web3 application suffers from this and some of them frankly don't mind because thousands and thousands of bot accounts look to the layperson like engagement when it's not.
But if you do care about it, then Civic provides a very easy and privacy preserving way of protecting your users and protecting your application from it. And likewise there's the whole question of KYC and identity verification, right? So there are lots of systems that block access, that need to block for regulatory reasons, access to particular jurisdictions.
And there's a few wrong ways of doing this.
One wrong way or at least one insufficient way I guess you call it, is just having like a an IP check on the front end. I'm sure people you all are in the US and you have had to experience this.
Another wrong way is having some kind of centralized check and that's becoming actually potentially more prevalent.
There are actually centralized exchanges like Coinbase now who are testing KYC information on chain now, not saying they're exposing private information, but it is a kind of a centralized point of control. And Civic provides what I think is quite a nice layer separating the decentralized aspect from the centralized aspect by allowing a, essentially a quorum of identity providers to attest that you're in the righteous jurisdiction or you're not, for example, or a test that you're over 18 or you're not would be another example. And this, this quorum is intended to be one where the user can go to the identity provider that they trust and have them attest, rather than having the protocol force you to go to an identity provider that you don't trust. And in a world where there's this natural clash between centralized KYC providers and decentralized platforms, we feel like this is quite a good and powerful compromise.
And so that's just that alongside the civil resistance is one of the things things that we provide with Civic pass.
Go to civic.com to have a look. Did I give Martin any time left?
[00:44:10] Speaker B: Yeah, we have plenty of time.
[00:44:12] Speaker C: Oh yes, of course.
[00:44:15] Speaker E: Yeah. I think I want to plug projects that I've been working on. I think one thing that I've been very passionate about was something that we call the gateway Protocol or the Identity.com Gateway Protocol.
We have a white paper, we have an open repo with that white paper. So I think the idea behind it is to standardize how on chain permission tokens work. Because how on chain permission tokens work right now is like every application has that requirement, does their own implementation and there's no interoperability at all between one permission token to another permission token. So in a way what this gateway white paper wants to do is like define in a generic way how permission tokens should look and how they're logically defined and who can control what a permission token represents now or in the future.
And I think the last plug I want to do is like I've been working in that US based decentralized identity community for a while.
I will be moving with my family to Europe so that will be my focus over the next months.
But over the last six years I've been working for like really cool companies like Civic technologies, consensys and identity.com recently and I just find it cool that these companies gave me the opportunity to work on these topics. I think it's not a given that for profit companies allocate so much time for very community driven things and interoperability driven things. And I'm really grateful that these companies, each of them, allowed me to do that.
So thank you.
[00:46:08] Speaker B: Very cool.
I want to give a shout out to the folks at eic.
This is the European Identity and Cloud Conference run by the folks at Cuppinger Coal and in particular. So we just had this event. They've been doing it for 22 years.
But what was fascinating this year is that Martin Kuppinger, the lead analyst at Comminger Call, framed the solution to EITIS as decentralized identity.
Very specifically, I thought that was very interesting and favorable for our movement because I want us to win the narrative that these ideas and these means we've been talking about for decentralized identity are a good idea. Let's try and use them and figure them out. We're all going to do it wrong. We're all going to have bugs, we're all going to have errors. So one of the errors, if you will, from an ideological perspective, is that eitis is still centralized. The root identifiers are still expected to be issued by sovereign states.
But what they are solving, which is nice, is that all 27 member states will have wallets for their citizens that are interoperable with every other EU member state. And that's a big deal. So it is a wonderful notion of interoperability that, hey, you're going to be able to take your government supplied wallet and get your certificate from Belgium because you live in Belgium and you can go use it in Paris or Berlin or wherever. And it just works.
So I thought that was really interesting. I want to give that shout out. I think it's a sea change in the conversation and in the European context. And one of the things they had mentioned was now companies have, I think five or three years to accept these credentials.
And this is law. This is law that has come into effect and now they're profiling it.
And it's just interesting that Martin was able to say and that he did say it's okay. We've been working on this for a long time. It's called decentralized identity.
Verifiable credentials are a great solution. Dids are a great solution. Now let's all figure it out together. It was a very interesting flip from, I think, what could have been a very scary transition for an IT department in Europe. Like, how am I going to support this? I don't know how I'm going to support. And the fact that Martin said, hey, this is decentralized identity, this is verifiable credentials was a big deal.
So that's my shout Out Eric or Erica. Do you guys have anything this week?
[00:48:40] Speaker A: Not for me. I don't think.
[00:48:44] Speaker C: I do.
I have a.
It's not really a shout out as much as I guess just a shameless plug. I am shamelessly plugging.
I think the personal holiday. It happens to be my birthday today.
[00:49:00] Speaker B: Happy birthday. I knew that but I forgot during those calls.
[00:49:04] Speaker C: Unlike me, more than 20 years ago I had a good friend proposed to me that like hey it's you know, it's your birthday, it's your own personal holiday.
You should you know consider like taking the day off. Like how we have a national holiday. Have your. Have your personal holiday and take. So I haven't worked on my birthday for more than 20 years but I'm. I'm delighted that today we got to do this recording because it's really a lot of fun and I think my shameless plug is to say hey, if it's your birthday, celebrate you and maybe take the day off if you want.
[00:49:41] Speaker D: It's a very good idea. Happy birthday. Erika. I'm afraid to say that taking a day off on your birthday would require quite a strong cultural change in Germany where not only are you going into work, but you're also required to bring in some baked goods for the rest of your office.
[00:49:55] Speaker C: Oh it's like the turnaround you German is kind of let's celebrate. You bring the goodies.
[00:50:03] Speaker E: Yeah. And there's a lot of judgmental culture.
[00:50:05] Speaker C: Yeah, yeah. People would be pumped if you don't.
[00:50:07] Speaker E: Better bring something self made.
Don't, don't just walk to the bakery. Like you really have to put an effort in to your own birthday.
[00:50:15] Speaker C: But like that, that's also like a self celebration on some. I mean there's a lot of expectation I hear around that but that's fun.
Well that will bring us to the end of our show today.
[00:50:28] Speaker B: Martin, thank you for joining us on the show. Daniel also thank you. Thanks also to our staff, our producer Eric o' Connell and my co host Eric Hsu. I'm your host Joe Andrew.
[00:50:38] Speaker C: You can find all of our episodes at Rubrik cc. Consider subscribing 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 presentation 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.
