Speaker 1 00:00:08 Welcome to the rubric. I'm your host, Joe Andrew
Speaker 2 00:00:11 I'm Erica Connell.
Speaker 3 00:00:12 I'm Eric shoe
Speaker 2 00:00:13 Today on the show we talk with Steven Keran lead editor of the did indie specification and Daniel bloom team lead at NDCO creators of one of the first did indie implementations.
Speaker 4 00:00:26 You know, I believe that privacy is a human right, hopefully that doesn't come across as too political,
Speaker 1 00:00:30 But 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 can make better decisions about which did method is appropriate for their use
Speaker 2 00:00:47 Decentralized identifiers enable robust identity based services without dependence on a trusted third party. So instead of being forced to use centralized identity verification services like Facebook or Google, or the department of motor vehicles, DIDs can be created by anyone anywhere and be used for any purpose
Speaker 3 00:01:09 Did methods or the magic ingredient that give DIDs their flexibility before creating any specific. Did you choose a did method, which determines how you perform the create read, update, and deactivate operations on a date of that method once created each did includes the name of its method in the identifier itself, so that when you use the, did others know how to retrieve the associated did document that contains the cryptographic material for secure interactions,
Speaker 2 00:01:34 Different did methods use different underlying mechanisms with different performance security and privacy trade offs?
Speaker 1 00:01:43 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 DS in your applications.
Speaker 2 00:01:54 Steven Keran of cloud compass computing incorporated is a software development DevOps veteran. Who's been working with DIDs, VCs, ledgers, and the trust over IP stack since 2017 consulting for the government of British Columbia and others. Steven has helped define, build and launch a variety of proof of concept and production applications based on verifiable credentials. He has a regular contributor in the hyper ledger, indie and Aries communities. And at I, I w and rebooting the web of trust conferences, facilitating collaborations and driving interoperability. Steven is a co-author of edX courses on Hyperledger indie, Aries, and Ursa, and is the current chair of the sovereign foundation. Please note that Steven does not speak for the government of British Columbia. His comments and opinions on the rubric podcast are purely his own.
Speaker 3 00:02:50 Daniel bloom is a software engineer and team lead at inicio PBC, where he helps design deploy and customized solutions built on DIDs and verifiable credentials. He was first introduced to decentralized identity in 2018 while working for the sovereign foundation and has been a contributor to Hyperledger, indie and Aries ever since Daniel is focused on identity agents and did communication and is a frequent contributor to A's cloud agent Python and other agent projects. He is a maintainer of several projects in the Hyperledger Aries community and serves as co-chair of the DICOM user group at the decentralized identity foundation.
Speaker 1 00:03:31 Welcome to the show.
Speaker 5 00:03:32 Thanks Joe. Happy
Speaker 1 00:03:33 To be here. Did Indy is specifically designed to support issuing a non-res credentials. It's one of the first methods to offer a flexible name space, allowing did indie DIDs to be registered on any Hyperledger indie network. An evolution of did solve did indie is designed specifically and only for privacy preserving self-sovereign identity. So let's start with question number one. What is did Indy
Speaker 5 00:04:02 Well did Indy, as, as you mentioned, is a did method that allows for the creation reading update and delete of DIDs on Hyperledger Indy networks, Hyperledger Indy networks are public permission networks operated by a relatively small number of nodes. They are a distributed ledger technology. A DLT did indie is a did method that can be used with Hyperledger indie networks. When Hyperledger indie networks first started, there was somewhat of a vision. There would be one network, one indie network, and what's evolved over time. Is there are many, uh, potentially many ind networks. There's a number of them in production today, uh, five or six in production today. And the expectation is there will be a number more as a result did indie was created because of the need to resolve DIDs on multiple networks, a multiple ind networks specifically, this will allow, for example, a holder to receive a verifiable credential rooted in one of many indie networks, be able to present approved to a verifier using multiple credentials that they hold and that verifier can verify the presentation regardless of what Indy networks those are on.
Speaker 5 00:05:24 So they may have one on sovereign network, one on, in the DCO network, and, and yet still be able to verify it, Joe, as you mentioned, Hyperledger indie networks are specifically for privacy preserving self-sovereign identity solutions, unlike other ledgers. The only thing that go on Hyperledger indie networks are objects that enable the use of a non-res anonymous credentials, a form of verifiable credentials in particular, primarily the ledger is for an issuer to host objects that are used to allow them to issue and revoke verifiable credentials. In some cases, a verifier might use might create a did so that they can be publicly identified in all cases, issuers and verifiers would be enterprises would be organizations, public entity or not public entities rather, but not private citizens. And it's absolutely the intention of Indy that private data, personal data, including a did of a private person would not go on an indie network.
Speaker 3 00:06:33 I think so far, just through the introduction and answer the first question we've probably used the term Hyperledger 20 or 30 times. Can you give us a rundown of what a Hyperledger is?
Speaker 4 00:06:45 Yeah, absolutely. So Hyperledger is a, uh, what shall we call it a incubator for distributed ledger technology? Uh, it's not necessarily a thing. There is not a Hyperledger. Uh, there are multiple projects that operate underneath the Hyperledger umbrella, which is a, uh, subset of the Linux foundation. So to name a few Hyperledger projects, there is Hyperledger fabric, uh, which is also a, a distributed ledger there's Hyperledger India, of course, Hyperledger Bezo, which I believe itself is also a distributed ledger, but Hyperledger also acts as a host of, uh, distributed ledger tools. So ways to interact with, uh, these various distributed ledger technologies, I guess. So Hyperledger Aries falls under that category. It does not itself provide any form of ledger. It builds on top of other lectures, uh, to do, uh, exchange of credentials, presentations, and other, you know, secure private interactions between, uh, multiple parties. So Hyperledger indie is one project underneath the Hyperledger umbrella, uh, and Hyperledger just provides us with, uh, a lot of resources to develop indie and open and friendly environment.
Speaker 3 00:08:00 Great. So hyper ledgers, somewhat like an ecosystem you might say yeah. With indie being a particular project within it focused on self sovereign identity.
Speaker 4 00:08:09 Yeah, exactly. Yeah. Uh, and to, to add on even a little bit more to that. So we, uh, I mentioned Hyperledger fabric, there's a lot of overlap, I think, in, in the capabilities of Hyperledger fabric and Hyperledger indie. And there's been a long standing conversation between the indie and the fabric communities, how we can do identity on fabric and whether there's use cases for doing fabric related stuff on indie. So there's, there's friendly relations between all the Hyperledger projects and, and a lot of opportunity for interesting crossover between the different use cases that, uh, the different Hyperledger projects are focused on.
Speaker 1 00:08:44 Great. So extending our historical review beyond Hyperledger, could you give us a little bit of background about like sovereign and did solve and maybe even ever, and I think a non-res is part of this Milu so if you could just put all those in context, that would be helpful.
Speaker 5 00:09:01 Sure. And non-res is the foundation foundational piece for, for the work that's that's gone on at Hyperledger indie? Um, a non-res was academic papers give, or take 2004 something in that timeframe based on the work of, uh, uh, uh, on cl signatures, what's called cl signatures. And, and these are the things that enabled zero knowledge proofs to be used. And zero knowledge proofs are core to what an on creds is about and why Indy exists. So that's where we started ever ni and I think give or take, uh, 2015 started a project predating, both the verifiable credentials work and the did work to take the concept of an on creds, uh, and use distributed ledger technology. So called blockchain back in those days to, uh, host and to publish the information necessary to use a non-res that work was open sourced by ever ni into, uh, Hyperledger and called indie.
Speaker 5 00:10:03 So that's where that started at the same time ever ni started or spun out the sovereign foundation. And the sovereign foundation is independent of both in the, and ever, and has been, was at the time and was designed to be an instance of indie running, uh, a, a, an instance of an indie network. And so that network was started five years ago, next month. In fact, um, the fifth anniversary of, of the sovereign main net comes up, um, next month. So all of those are, are independent. The, the open source software that is HL ND that was donated by ever Nim, um, but worked on by a number of organizations, um, sovereign deploys, an instances of that. And now, as I mentioned, there's five, six others that run instances of Hyperledger in a production mode. Once those were in place, the client software, the agents that would use indie and would exchange a non-res ex verifiable credentials would exchange credentials, the issuers, the holders of the credentials and the verifiers were all agents that needed to connect with one another exchange information, such that they could exchange credentials that started as being called indie agents and evolved to what is now Hyperledger errors.
Speaker 5 00:11:30 So S consist of the protocols for connecting and communicating. It relies on did come. Notably did come V1 right now, which is communication based on DIDs and allows this ecosystem of, of verifiable credential, issuers holders, and verifiers to operate. And then coming back to it, one of the things that we're we're working on right now is extracting an on cred, sort of out of being tied to indie only, and on creds is not actually tied to indie or sovereign or any of those concepts. It's actually agnostic to those. So what we're trying to do right now is change it from being not only open source, but being an open specification so that others can build their own versions of it. There's at least two versions right now of an on creds that exist. And, and we'd like to make it both independent of indie and, you know, able to be used in, in other, based on other ledgers or, or other storage of the objects necessary to carry out an on creds operations.
Speaker 2 00:12:37 Will you walk us through the credit operations for a did indie?
Speaker 4 00:12:41 Yeah, absolutely. Some of the historical background that Steven just gave is actually pretty important for understanding the primitives that we use when interacting with an indie ledger. So rather than having a, a native representation of a D I D for instance, on Anie network, there's an object called a Nim, which is kind of the, the precursor. So to speak of the concept of a D I D uh, Nim that's YM deriving from the Greek word, whatever, uh, that we use as an acronym, Sy Nim, meaning name, uh, is kind of the core transaction that we use in indie for anchoring an identity to the indie network. So the Nim transaction is our, our ultimately our create operation and, uh, did Indy there's again, as it predates the, the did core specification by a number of years. Uh, there's not an, an exact one-to-one mapping of Nim to D I D, but we do have a, uh, a way of mapping from the Nim space into a, a did space or resolving a D I D and D I D document using the primitives provided by the ind network.
Speaker 4 00:13:49 So a Nim includes at its core, a desk or destination attribute, and this represents the identifier to be written to the ledger, uh, or the method specific identifier in this case, or the namespace identifier, I believe is the other term that we use and the did method specification. Uh, and then the other required attribute is the que that's a V E R K E Y, or verification key, or the public key portion of a signing key pair of a type of ed 2 55 19. So these are the minimal, uh, attributes required on a NM transaction to the network. What we did as part of the work to implement the ind did method was add a new attribute to this NM transaction, which was a did doc content. And by joining the, the base desk very key and did doc content, uh, we're now able to express the full range of did document capabilities.
Speaker 4 00:14:45 So not only do we have just a single verification method and a single identifier within the, the values resolved from the Indian network, uh, we can have services, any number of keys, any number of, uh, verification relationships. So from a minimal Nim transaction, we have the desk and the ver key. And from those two values, we're able to derive a based D ID document. Uh, so without any modification, without any of the work that we did to support the dead indie method, we could derive a, a minimal D ID document, uh, that included, you know, the did colon indie colon, and then name space, and then the method specific identifier and a verification method list containing a single object, which had the public key base, 58 of that very key that we, we use to create the Nim transaction, and then joining that with the di doc content, uh, results in a full rich DIT doc.
Speaker 2 00:15:45 So the first step is to create a Nim transaction on an indie ledger, right?
Speaker 4 00:15:49 Yeah. Uh, okay. Maybe I should back up a little bit and say where the verification key is created first. So the first step is to create an 82 55 19 key pair, uh, and then using that public key, we can derive a did value, which is then used to construct the Nim transaction, uh, that we submit to an ind ledger.
Speaker 2 00:16:10 Right. Gotcha. Okay, cool. And that's the create sequence?
Speaker 4 00:16:15 Yes, that is the create sequence. So to read an indie network provides the GI request, uh, which is a way of retrieving the value of an Nim. And part of our work with the indie did method implementation was to add support for resolving NIMS or DDS using a version ID or a version time. So using the version ID in version time, we can recall the state of a did in the past look up previous versions if there's been key rotations or additions of services and, and whatnot. But yeah, uh, using that get transaction, we're able to read the value of, of a D D document. The ledger itself speaks natively in these transactions of the Nim. And, uh, it is actually responsibility of, of the resolver to format the return to data as a D I D document. So the resolver calls on to the ledger receives the raw Nim result.
Speaker 4 00:17:09 It then does a very well defined assembly step, uh, to construct the DD document from that. And then returns that to the, the requester when updating a did Indy, did we perform another Nim transaction that updates the previous values stored on the ledger? This is an update operation that overwrites wholly the attributes that were previously stored with the Nim. So if we wanted to modify the did doc content, for instance, we would need the entire value of the did doc content make the modification that we wanted to make and insert it into the Nim transaction, and then submit to the ledger. You rotate the core verification, key associated with a Nim. The transaction needs to be signed with the key that was previously associated with the Nim. And this happens for every key rotation. So no matter what state of the Nim that we're resolving, we can walk back through the history of the, of the ledger and prove that the original verification key is associated with the, the D I D and then walk the signatures all the way up to the current value of the key
Speaker 3 00:18:17 Last but not least deactivate
Speaker 4 00:18:18 Deactivate. So deactivation OND networks that consists of rotating the very key to a no value. So it's making it impossible for any future transactions on that Nim to take place, because you can't verify a signature from Anol key and that effectively deactivates the Nim or the did
Speaker 1 00:18:36 Great. So you said rotate a key to ano value. What was the adjective on that key? Did you say Nim
Speaker 4 00:18:41 Key? I think I just said ver key, ver key verification
Speaker 1 00:18:44 Key, right. Which you mentioned earlier. Yep. Okay. And is the Ky represented in the D document itself?
Speaker 4 00:18:51 It is, yeah. In the base di document, uh, the, the core value that is returned by a Nim, that core que is the first key in the verification method list of the D I D document.
Speaker 1 00:19:03 Okay. So it doesn't have an explicit verification relationship. It is sort of hard coded as the zeroth entry in the verification methods list.
Speaker 4 00:19:13 Yes, we also, we do have in the base did document as defined by the did method specification. We also include the authentication verification relationship with that verification method referenced as well.
Speaker 1 00:19:24 So just to put a point on it, the way that the actual identifiers constructed requires an on chain transaction. So, so there, isn't a way to create a, did Indy off chain. I mean, the way that you might with a did E or a did key or a did be one, is that right?
Speaker 4 00:19:41 Right. So there are, there are local aspects that need to be created before you can submit the transaction to the network, but the did itself as a did Indy D I D does not exist until the Nim transaction has been written to the ledger.
Speaker 3 00:19:54 Yeah. And there was one thing that caught me up as you were explaining this around the way you're talking about a Nim transaction in the spec. When I was reading through it, the Nim was listed as one of eight different types of objects. I think this is what you meant by primitives on the network. Could you just clarify as the Nim and object on the network, or is it a transaction or is there just an object and a transaction, both named Nim?
Speaker 4 00:20:19 Let's see, I think there is both an object and a transaction, depending on how you wanna look at it. I suppose the, the state of the ledger contains an object or, or a set of data associated with a Nim. Uh, and you could call that the object, but then the transaction that updates, that value updates, that state is also referenced as a Nim transaction.
Speaker 3 00:20:41 Got it. Thanks. How do the other indie ledger objects, other than the Nim fit into this equation, where, where do those come into play?
Speaker 5 00:20:50 As we mentioned, indie networks basically were created to allow issuers to issue and on cred, credentials, anonymous credentials. So all of the other objects that reside on an indie network are intended to be created by the issuer to allow them to issue credentials. So the sequence of them are a schema which defines the list of attributes within an anonymous, an a non cred credential, a thing called a cred death, or a credential definition. And basically what that does is it links to an issuer. So the did of an issuer, it links to schema. So it, it may have been created by the same issuer or maybe a common schema used by many issuers. And then it contains a set of public keys that are used in signing the credential that gets issued. So with those three objects, an issuer can issue a million credentials for, with just those three transactions on the ledger.
Speaker 5 00:21:53 Their issuer did the Nim, the schema that is used for the credentials and then a credential definition, and then as well, indie support or a non cred supports revocation. And so a, an issuer may choose to make a credential definition that allows for revocation. When that happens, there are additional objects that get created a revocation registry, which allows a set of credentials to be issued from it. So you might have 10,000 credentials in a registry, and then allowing what are called rev, reg entries or revocation registry entries that update the status of individual credentials, perhaps revoking them and then publishing a cryptographic data element that allows for a holder to prove that their credential has not been revoked in zero knowledge. Why is that important? Let me go through that briefly. And non creds is one of its attributes is not providing a correlatable identifier for the credential or the holder. So what we're trying to do is allow the issuer to issue the holder. A credential allow that holder to present it to a verifier and the verifier not have a unique identifier for either the holder or the credential itself that can be correlated with other verifiers. So the act of proving a credential should not give a unique identifier. So those set of objects are defined specifically to support issuers issuing and non cred, credentials, and allowing holders and verifiers to access the cryptographic material necessary to verify those credentials and use them.
Speaker 1 00:23:46 Okay. So tell us a little bit more about revocation and how that works.
Speaker 5 00:23:50 Okay. Revocation is handled a little differently from other verifiable credential approaches in and on creds. A key part of an on creds is not exposing a unique identifier for either the holder or the credential in the presentation process that has to extend over to revocation. So the revocation approach in Indy enables that basically what happens is a issuer decides they wanna have a revocable credential defined. So when they create, uh, the credential definition, they say it's revocable. And then they add a revocation registry to it. They then issue credentials based on that revocation registry, the holder receives those. And when asked to present a proof about them, they prove in zero knowledge that their credential has not been revoked. So how do they do that? The issuer over time revokes some of the credentials in that revocation registry in doing that, they publish to the ledger and update to the revocation registry, which contains a list of which credentials have been revoked and a cryptographic element, a, an accumulator that allows the holder to prove without exposing which credential they are using, that their credential has not been revoked.
Speaker 5 00:25:11 The verifier can then check the value of the accumulator by retrieving it from the ledger, checking it with the proof that the holder gave them. And they know that the credential has not been revoked. This has one other important attribute that the, since the verifier does not have a unique identifier for the revocation of that credential, they can't continue to monitor whether that credential gets revoked sometime in the future. If in the future, they need to know that the credentials revoked, they have to ask the holder. And again, this is one of the important privacy preserving attributes. You prove a credential at a point in time, or you prove information about it by presenting it to a verifier. They verify that information at that point in time. If they need to know more about it, they have to go back to the holder and ask again for a presentation, including whether the credential has now been revoked in the intervening time.
Speaker 1 00:26:15 Okay. So when a holder presents a, a non cred, you were, if I understand correctly, they are in effect generating a proof of non revocation, correct. That really should only be treated as valid within some timeframe.
Speaker 5 00:26:32 Exactly.
Speaker 1 00:26:33 And then, so the verifier doesn't have a separate VC, which they can then later at some future time check again,
Speaker 5 00:26:40 Correct. A, a verifier never receives a VC. They always receive a derivation of a VC. That is a presentation, first of all. So it, even the presentation is only valid at that point in time and included in that presentation is this proof of non revocation. And if they wanna check it again in the future, as they said, they have to ask the holder. One of the interesting as attributes of, of how revocation was done is basically that in theory, the verifier can request, oh, I wanna know whether this credential was invoked at some arbitrary point in time in the past. And because of how the proof of non revocation is created, it can be done for now, or it could be done, you know, June 6th, 2020, when you had a car accident and you're proving that you had insurance at that time. So there is flexibility in that, but in most cases, it, it is give me the most recent, you know, revocation date. It's going to be tied to a transaction, an object on the ledger, which is the latest time that the issuer updated the revocation registry. And that's usually what it is not necessarily right now, but the last time that a update to that revocation registry was published by the issuer.
Speaker 3 00:28:00 Oh, that's very cool. So you can check the revocation of any, an on cred at a given point in the past at any given point in the past. Right.
Speaker 5 00:28:10 So yes. And again, you can't check it as a verifier. You can ask the,
Speaker 3 00:28:15 You can ask yeah. The, the, sorry, the holder can generate a proof of revocation at any point in the past yes. Of the revocation status.
Speaker 5 00:28:24 Yes.
Speaker 3 00:28:25 Yeah. Gotcha.
Speaker 4 00:28:26 Yeah. I, I'll also briefly note that credential definitions must explicitly support revocation in order for you to check revocation status. So there are anonymous credentials that do not have any revocation registries associated with them, which are effectively not revocable, so that there is a, a minor distinction to make there.
Speaker 2 00:28:44 Steven, will you speak to what is a non cred? Because my listening ear, I think hears something that it's not, I hear an like a not credential, but I think you are saying a shorthand for an anonymous credential.
Speaker 5 00:28:59 Yes. Anonymous credential, a non creds is the name used for this technique of credentials. It's different from the w three C verifiable credentials model for, for one reason, it kind of predates it. And, and the sort of, some of the components of it were added as the w three C VC spec was defined, but an on creds is designed for privacy preserving in that it aims to minimize the amount of data shared and it aims to, to prevent correlate ability based on the fact that you have presented a, a, a proof to a verifier so that they, the verifiers can't, uh, collude and, and correlate the presentations of a holder. So what is minimizing the sharing? Well, there's, you've heard me use the term zero knowledge proof. So that's, that's one piece of it. Zero knowledge proof being, you know, I think, uh, listeners of the rubric podcast would know what zero knowledge proof probably is, but basically being able to prove something without, um, providing that information.
Speaker 5 00:30:06 So prove that I'm the classic prove that I'm older than 19, which I definitely am without providing my date of birth. So based on my date of birth, I prove that I'm older than 19, but I don't give you my date of birth. And the cryptography is such that you can trust that, um, that you can, uh, that that is what the issuer gave as the date of birth. So zero knowledge proof that one in particular is called a predicate. So instead of, as they say, exposing your date of birth, you can just say I'm older than 19, and that can be proven. Um, selective disclosure is another important part of it. You only need to present the necessary attributes from a credential that are required for the verification that you are conducting. So you don't provide the entire Verifi credential on all the attributes in it.
Speaker 5 00:30:56 You only provide the requested attributes necessary for the transaction. The third part of it is that non correlation you're basically proving that you were issued the credential. You are the holder of the credential, but you do it without presenting some sort of correlatable identifier for yourself. So that's a, a little bit of magic, but basically means that you don't provide the same identifier to each verifier. You actually provide different information. And it, it, it is based on a zero knowledge proof that proves it was issued to you, the hit issue, or definitely issued to you, but you don't have to prove who you are as part, uh, they identifier that the issuer used. And then the last part is, um, what we talked about earlier with revocation, that in doing the revocation, we wanna do that again without exposing a, uh, unique identifier. So those are the attributes of a non-res that indie enables as the ledger component of it by having these other objects on it. And that the, and non-res protocols and data models enable for the issuer, for the holder and for the verifier.
Speaker 2 00:32:09 Awesome. Thank you.
Speaker 1 00:32:11 So let's move into the people behind. Did Indy starting with the two of you, how did you get involved in the work?
Speaker 4 00:32:18 Where do we start? So I I've been involved within Hyperledger Indy for a long time, or I guess long is a relative term. I started working for the sovereign foundation while I was still a student in school actually, and started working in the indie agent space, um, and just kind of continued working with Aries and indie up until now, pretty much. So we at Inco, I've been building on top of Indy using sovereign, and then later using the NDCO network, uh, which we stood up to build solutions based on top of anonymous credentials for our clients as well. It's, it's one of our big goals to just make privacy, a bigger aspect of our lives in the modern digital age, I guess. So Inco got involved thanks to a code with us opportunity that, uh, government British Columbia put out, which maybe I'll let Steven speak to a little bit more.
Speaker 5 00:33:07 Okay. I began with getting involved with Indy early on as mentioned in the 2017 timeframe. When I was working with the government of British Columbia, we started looking for ways to do verifiable credentials. We knew enough about the different pieces going on, and, you know, some of the approaches were a bit problematic for governments at that time may still be, I don't know, I won't comment. I wouldn't comment on that, but asking, for example, the premier of British Columbia to, um, let's get some Bitcoin so we can cure everyone's identity. That was a bit awkward. So the idea of Indian being a public permission network that has the governance necessary for the particular use of it that got us involved. Obviously the other folks involved early on the people from ever M the team from ever M the team from sovereign. And then it grew over time to a, a number of organizations in Europe, a number of organizations in Canada, fair amount, particularly in Germany and Finland, and, and now it's, it's pretty global.
Speaker 5 00:34:15 The number of people building on either directly on indie or building on Aries Aries is the component that enables rising above the ledger and allowing the use of many ledgers or agnostic to the ledger agnostic in fact, to the verifiable credential model. And so that allows a wide variety of solutions, but what's continued to be cornerstone to Aries. Um, you know, there's 10 implementations of Aries right now, at least, but most of them are based on using the indie ledger and using the, in on creds verifiable credential model. So really expanded from, from that small cadre around the ever name sovereign to basically global use.
Speaker 2 00:35:04 And so as a follow up, why, why do you do this work? What's important about it to you personally?
Speaker 5 00:35:12 The important thing for me continues to be two parts. I think I'll, I'll go with one is just the privacy preserving nature, um, and goals of, of what a non-res is trying to accomplish. And, and therefore, you know, the indie underlying that, um, I do look forward to the day where, um, and, and did Indy as a step to that, that we could actually use a non-res with a variety of ledgers and, and evolve it. So I'm, I'm less concerned about the underlying as that capability of, of what a non-res allows. Um, I think it's gonna be an interesting evolution over the next few years, as we standardize this spec and allow it to be used with evolving the, the, the involving the standard without compromising the capabilities, it offers the zero knowledge, proof capabilities. It offers that's one reason. The second piece is just the concept of verifiable credentials in general, and being able to give a holder control over the, what amounts to their information and allow them to share it when necessary and, and, and, and minimize the amount that they share. What I'm looking for is to try to eliminate the surveillance economy that we live on right now. It really <laugh> bothers me the extent to which surveillance occurs. I'm always amazed, even in the role I'm in, when I read the inside scoop on the, on the operations of companies that are collecting literally hundreds and hundreds of attributes about each person correlating them and then providing personalized experience for them. That's what I'm trying to accomplish.
Speaker 2 00:37:00 Yeah. Awesome. Thank you, Daniel. How about for you?
Speaker 4 00:37:04 Yeah, I think I I'm in a very similar place as, as Steven, I would say, I think everybody's becoming more aware of just how much information is held by, you know, the Googles and the Facebooks and the Amazons of the world. And that doesn't sit right. You know, I believe that privacy is a human right, hopefully that doesn't come across as too political, but like, that's, that's something that I, I think is pretty fundamental to our existence as humans is the ability to have control over how much information is known about us to the rest of the world actually had a conversation with Joe at I w where I kind of made a, a new connection that I hadn't formed before. So a little bit of background. My wife is a PhD student, she researches sexual consent. And so I, I have a lot of conversations at home with her about like consent, not even just in, in the concept of sexual behaviors necessarily, but like just having the ability to say yes, I want to participate in this.
Speaker 4 00:38:03 So consent in that sense is defined as like enthusiastic agreement to participate. And, and I feel like that's something I think we could learn a lot from, and like the privacy world where like, sure people are aware of and are maybe allowing all this information to be collected about them. You know, they agreed to the terms of service or whatever, but they don't necessarily enthusiastically agree to these terms. So the, the power imbalance is very real, very concerning, and I'd like, like to help shift it back the other way towards individuals being able to exercise their own right to privacy and, and to choose how much information is revealed about them.
Speaker 1 00:38:46 Yeah. I love that language around enthusiasm, because so much of what happens with regard to data sharing on the web is really ransomware. Like, Hey, uh, to use this app, you have to log in with Facebook, or you don't get a bunch of features. Like they're withholding value for me in order to get these identifiers and these attributes. And I tolerate it because I don't have another way to play the game or what have you, but it really is not enthusiastic. And when I think in the context of dating or sexual harassment in the office place, like it's the UN enthusiastic, but grudging, okay, I'll go out on a date with you because you won't leave me alone. Like that is not okay, but we do that all the time digitally. So I love that turn of phrase, cuz I, I think it really captures a nuance that we just don't have good computational mechanisms to, to deal with.
Speaker 4 00:39:37 Yeah, absolutely.
Speaker 3 00:39:39 You mean, you're not excited about scrolling to the bottom of the turn tos before you click accept to
Speaker 6 00:39:43 Use that. <laugh>
Speaker 1 00:39:46 Favorite part of my day. <laugh>
Speaker 3 00:39:49 Do wanna give you guys both a chance, obviously you're not the only ones involved in did Indy. So is there anyone else you'd like to give a shout out to that has been important to the project?
Speaker 4 00:39:59 Yes, absolutely. So I have the privilege of representing the, the implementation team in this context, but, uh, it was definitely a lot more than just me that participated in the implementation side, Shar Holland on the NDCO team and Adam verte were both instrumental to the success of the implementation and also want to call out Amin burner, who was also crucial in, in, uh, the, the ND VDR side, the, the resolver side of the implementation.
Speaker 5 00:40:28 I'd like to always call out, uh, John Jordan of BC gov, who is instrumental in all this work that we do and is, has, has done just a stellar job, um, at moving these things forward and finding ways, compliments absolutely to the government of British Columbia in developing a thing called code with us. It is a procurement program which when people hear government procurement program, they run away in terror. But BC is really managed to pull off a brilliant program, which is they basically can publish in a matter of weeks, including approvals to request that somebody sign up to accept a challenge, to create what amounts to a poll request in an open source repo once they get, or are selected as the winner of the challenge, the code with us challenge, they are able to, um, do the work. And once their poll request is accepted is merged and accepted.
Speaker 5 00:41:22 They get paid and the overhead is as simple as that. We can write what amounts to a, you know, one and a half, two page description of what we want with very clear goals as to what will go into the poll request. A company like NDCO can respond to it. We can evaluate their response. Their response is again about a page and a half to two pages, and then we can select them. One of the interesting things that come out of it is that often the things we want from a BC gov team, <laugh>, I shouldn't say from BC gov, but a BC gov team that I participate in is things that the community wants. And so by putting out a carrot, if you will, to the community, you, you get more people involved. I, I should also mention we had a number of contributors to the dead Indy spec as we went through it, the method specification. So team from Bosch in Germany, um, team from Maine incubator as well. So they, they were all contributors to that AIAN, uh, Christian Borman, a number of, of folks participated in that and we certainly appreciate their efforts.
Speaker 1 00:42:29 Excellent. I, I really wanna second year endorsement of John Jordan and the British Columbia government, they've been active at I a w at rebooting, the web of trust. I mean, they have really put their work in the public eye really early, which is very unusual for government initiatives. So, you know, John, Jordan's done a great work in terms of evangelizing this possibility as a infrastructure solution for big government. And that's super powerful, the way he's been engaging in British Columbia. And it's an echo also to Tim Bama, who does, you know, the Canadian, uh, federal layer, uh, he's, he's moved jobs, but, and then a Neil John in the us, right. But at DHS, who's also been trying to figure out how can we use these technologies for the government and let's face it. The government is perhaps the anchor, um, verifier and issuer for most credentials that matter in civil society, right? Our driver's license, our social security payments, all of that stuff. So really powerful and important that the British Columbian government is so active and forward thinking about this stuff. So glad you brought them up. I endorsed that. They've been great. Okay. With that, let's move on to conflict. What conflicts did you run into or challenges did you run into in creating did indie? And that could be technical. It could be political, it could be people. What was hard about putting this together?
Speaker 5 00:43:56 I'd say one of the most difficult things was Indies out in the world. And it's been out in the world for five years on sovereign for three years on other production networks, you know, so it exists and we, many, many people are using it. There's um, as I mentioned, you know, something like 10 Aries, um, implementations nine of which all, but one include an indie resolver within it. And thousands of, of people deploying Aries components. So we had a, a history to, to deal with. And so that was a good problem to have, we're happy to have it, but it did make things challenging and it made some, we had to make a lot of interesting decisions. So for example, one of them was schema, for example, are, are, could be from anywhere and could be on any network. And we'd love to be able to have them on all ne you know, just have one schema posted on one network somewhere, and all of them use it.
Speaker 5 00:44:51 We, we decided we couldn't do that because just the whole idea of a ledger checking, another ledger just blew up our mind. So we just couldn't handle it. And, and we had to stop there, but, uh, you know, a whole bunch of things that we had to think of and then say, well, no, that's too aggressive that evolves it too much, that, that we won't be able to deploy it. We won't be able to make it happen in, in real, um, systems. It, it will break too many things. So that balance between backwards compatibility and future capabilities.
Speaker 4 00:45:25 Yeah. Second what Steven said briefly, I remarked multiple times throughout the whole project. Just how little code there actually was to write as the implementation team. And it was mostly, uh, a matter of coordination, just making sure that the right change was made and being very communicative with those who are invested in, in making did India thing, and those who are running India networks to make sure that we don't, you know, break the whole world with something that seems relatively benign from our perspective on the ledger side. So it was the definite challenge to, uh, like Steven said, balance, you know, new features like, you know, the self certification attribute of NIMS and making sure that we're not breaking 99% of the deployments of India out in the world. So for sure.
Speaker 1 00:46:12 What did you mean by the self certification app?
Speaker 4 00:46:15 Yeah, I kind of dropped that one out there. Didn't
Speaker 7 00:46:16 I <laugh>, I was gonna say the same
Speaker 5 00:46:18 Thing. You just dropped that one.
Speaker 7 00:46:20 <laugh>
Speaker 4 00:46:23 Uh, so originally there was no constraint on what the, the desk field, the destination field in the name transaction was. So it, it could be something that was derived from the very key. It could be a vanity D I D something that you just decided to put in there, but there was no checks on the ledger side, uh, that that value was anything in particular. There was a convention within indie, uh, SDK, especially where the D I D was derived from the first 16 bites of the verification key. And we wanted to upgrade that to making the identifier be the first 16 bys base, 58 encoded of the chat 2 56 of the verification key. So we had, we had a way of proving that the identifier that was generated originated from a verification key. So it, it provides a binding between the D I D and the verification key that created it.
Speaker 4 00:47:19 So the conflict that we had was there was no checks previously, all the code that was written was, you know, making the assumption that it was relatively, you know, permissive in what was submitted to the ledger, and then getting us to a point where we had the self certification attribute, where we could prove that it DD originated from a ver key and making sure that check didn't bring everything crashing down. So it, we ultimately ended up adding a, an additional optional attribute that could be added by a newer versions that said here, you can prove that my D ID is derived from the sphere key. And, and it is an opt-in additional security feature that we added with the di method.
Speaker 3 00:47:58 So, one thing that caught my eye while I was reading through the spec was the call out to did solve and how DIDD builds upon did solve, but it kind of made me wonder why did you feel the need to create, did Indy as something beyond did solve, and more specifically what features of did Indy were identified as lacking in, did solve?
Speaker 5 00:48:20 Yeah, the, the big thing there was, um, did solve was created, as we mentioned before, sort of the did spec and, and, and things like that did solve sort of assume there would be one indie network in the world that would be called sovereign, and that would be it. And over time it was realized that wasn't gonna happen. There was gonna be a network of networks and we wanted to be able to address. So primarily it's that addition of a name space, so we could have did indie sovereign. Yes, we can have that, but we could also have did indie ID union and did indie in DCO and hundreds of others, not thousands or millions, but hundreds of others. That's one. Um, and then the second part with this did docs support, as Daniel mentioned, there's very limited ability. Uh, you know, you basically get a very hardwired did doc back from a, did saw reference with did Indy, the controller of the did can put as much detail as much additional information into the did doc as they choose. And that's a new capability that isn't isn't part of did solve. So those are the big things we were trying to do. There's a couple of more subtle things, but those are the big ones.
Speaker 1 00:49:34 So can the controller of a, did indie add arbitrary attributes to any part of the did document or is it a constrained set or, or location that they can customize?
Speaker 5 00:49:48 W we chose to make it that they can pretty much add anything? So, for example, we mentioned, Daniel mentioned that there's a verification key, the one that's in the, the did object itself, the Nim, the ver key that goes in as the, you know, as you said, the zeroth entry in the verification list, but they can add more if they want, obviously, uh, a client should restrain themselves to only put in what the did speck allows, but we didn't go too strong into verifying the did doc at the ledger level. We left that to be a, a res uh, a resolver level, um, issue.
Speaker 3 00:50:26 So with one of the main reasons to move to dead Indy, being the inclusion of this network specific and identifier, which allows you to have many indie networks. Could you just talk about why this was desired?
Speaker 4 00:50:40 Sure. So as Stephen was mentioning, you know, originally we had did sovereign and the sovereign network, and that was it. That that was the network. But as we saw more and more networks emerge, we ended up having to, uh, address, uh, a very specific problem on mobile wallets. For example, that support indie networks and anonymous credentials. We wanted to be able to use multiple networks. There are a couple of mobile wallet implementations out there that, that solve this problem in a, in a couple of different ways. Sorin, for example, allows you to pick which network you will use as the network for your current wallet session. So you could select the NDCO test net. You could select sovereign builder, net, may, net staging net, but all credentials issued to the wallet are expected to be from exactly one of those networks that you've selected at runtime. I guess another alternative approach that was taken I think was in <inaudible> wallet, uh, or, or Lissy
Speaker 5 00:51:38 It's Lissy
Speaker 4 00:51:39 Lissy okay. So the Lisi wallet, uh, takes an alternative approach where it says, okay, we know about this number of, of Indian networks and this value, this credential definition, this scheme ID, or, or this did that we're attempting to resolve might be on any one of them. So we'll, we'll issue five concurrent requests to each of these ledgers, see which one comes back. And then that's the, the ledger that, uh, that will use to resolve this subject to, or to, you know, go through with this verification process that works on the scale of less than 10. But as Steven was mentioning, once we start seeing hundreds, once we start, you know, seeing more and more ind networks, you know, sending out concurrent requests to all of these different networks is just not a scalable operation. So having unambiguous identifiers for where exactly the ledger object that we're intending to resolve is while enabling us to use these various networks for what they're good for, uh, or for the relevant jurisdiction was a really big part of why, uh, having a network specific identifier was so important.
Speaker 2 00:52:44 So the intention of indie is only issuers will have DIDs on the ledger, perhaps verifiers might, but definitely people will not. Is this controversial that did, did indeed can't be used like for people,
Speaker 5 00:53:01 It shouldn't be, let's talk about that. <laugh> so there's a couple of reason people need DIDs and, uh, and those reasons are supported. So independent of indie when two agents connect like a person's agent that resides on a, on a mobile, uh, you know, on a wallet, on a mobile phone and an enterprise. Um, what happens in, in DICOM in particular is that the two exchanged what are called peer DIDs, which are DIDs, that they create an exchange with each other, and they don't publish them anywhere. Those are the identifiers for people. And as a result, they don't need to publish those anywhere else, publishing those leads to Correl, relatability and, and other things. So people will get identifiers issued to them from other places via verifiable credentials, and might share them via verifiable credentials, but when communicating, or when connecting, contacting other, other, um, agents, if you will, whether those be other people or, you know, enterprise servers or, or things like that, they will always use peer bids.
Speaker 5 00:54:15 So the peer bids are used to, um, enable communication allowing for things like the exchange of credentials. So that's the big place in the S community where bids four people reside. The one other place that it resides is, um, something I alluded to earlier, which is that ability to prove. So there is an identifier for the holder in each credential that's issued to them, but that identifier is shared with verifiers in a way that it's non correlatable so that they can, the holder can prove the credential was issued to them. And, and that they have a, what amounts to a private key to prove that the credential was issued to them, but they don't have to expose that identifier to the verifier. They do it in zero knowledge. And so again, that prevents Correl relatability. So again, the whole goal of a non-res is preventing Correl relatability.
Speaker 5 00:55:14 So, you know, it doesn't make sense for individuals to be publishing DIDs on the ledger, it in what we are trying to use Hyperledger Indy for the other big reason is indie is a public permission network. Meaning it's operated by entities. Usually companies and companies have to deal with things like GDPR. And so if a did for a person goes on an indie network, and that person requests that, that be removed, they have to figure out how to get that off the network. And so a big reason for not allowing them on an indie network is the governance of most indie networks doesn't allow it because there's no solution to removing the did from the network.
Speaker 3 00:55:58 So what implementations are out there of did Indy and if so, what, what are they doing?
Speaker 4 00:56:05 So, as it stands today, the indie did method is implemented in, uh, depending on whether you're, you're talking about the ledger or the resolver side, exactly one or two locations, we have submitted the code for support for the did indie method to the Hyperledger indie node project that is currently residing on a branch that has not yet been merged or released, uh, into the mainstream just yet. And then on the other side, on the resolver side, the ND VDR library, which is a, a component that can be built and then used from a number of applications, implements the, you know, reciprocating retrieval and submitting to the ledger. So we're, we're in definitely early stages of rolling out support for did Indy across all the many thousands of deployments of areas in India, out there in the world today. Uh, and it'll be many months more before I think we're to a point where we achieve our ultimate goal of being able to issue credentials from any number of networks and be able to hold and verify from any number of networks,
Speaker 3 00:57:05 Not quite there yet, but it's all in the pipeline.
Speaker 4 00:57:07 Yeah, exactly.
Speaker 5 00:57:09 The value of what Lissie did with being able to do this parallel request and getting back the response is it bought us a, you know, a year, year and a half of time and runway to be able to get this all out there. So we're very appreciative of that. Cuz we could continue to go with multiple networks, which is crucial. We can't, there is not gonna be one network. There already is not one network there's already at least a handful. And that bought us a ton of time. We are so appreciative of that design.
Speaker 1 00:57:39 Another item that jumped out at me from the specification was the dynamic discovery of indie networks. You currently have two mechanisms stated. One is the software that is engaged with the DIDs, simply knows about the networks, right? There's some tribal knowledge or industry knowledge. They've learned about it. They heard about it at a conference, whatever, and they put it into their code base. The other one is a GitHub repo, which is a public repository on a, you know, private service that's available to the public, but GitHub is owned by Microsoft, et cetera. But that is one place where you could go and check to get a list of current name spaces. Could you talk through the design decision about that? And in particular, why not put that on a ledger somewhere? <laugh> it's ledgers all the way down, right?
Speaker 5 00:58:32 That was definitely one of the key issues. We talked about a lot in, in figuring it out. So we actually got a, a pretty detailed and complex design of putting it on a ledger. Basically a, a client would know about one ledger for example, but on that ledger, they could find the transactions that represented other ledgers and so on and so on and so on. So from one ledger, they could find other ledgers from which they could find other ledgers and six degrees of separation. They know the world, we have talked about that. That is a possibility, but we just felt that was more work than we needed. And given the ease of doing it on the order of hundred networks or hundreds of networks that are out there that doing it via GitHub repo would be a sufficiently decentralized way to do it. So we're actually building that repository right now.
Speaker 5 00:59:25 We have a set of maintainers on it. They have a set of guidelines as to what they're allowed to merge. They've gotta know who submitted it. They've gotta know that it's, um, the, the submission is from a human perspective, trustable <laugh>, they've gotta, um, and, and, and that the polar request is properly formatted if you will. And beyond that, they decide to merge or not merge based on that. So that's the governance, if you will, and should disputes come up happily, we have the Hyperledger foundation, which has a bunch of mechanisms to deal with it. Should, should that be a concern? So that was the, the, the rationale behind it. It was more just pragmatic.
Speaker 1 01:00:09 Sure. Right? Yeah. When, when your universe is expected to be in the hundreds, having a custom registry on chain, like your own, like that does seem like a lot of overkill. So seems like a reasonable compromise for where you're at in the, in deploying this.
Speaker 4 01:00:24 Yeah. I'll, I'll add on that. At least from my relatively limited perspective, I think it's gonna be more common for us to see like the static definition of which networks we're willing to interact with from a, a given jurisdiction. I, I think that'll be, uh, as opposed to dynamically retrieving from a GetHub repository. I think having it be defined within a governance framework, these are the networks that we are willing to interact with. Feels like the way to go, typically speaking. So there's a lot of conversation at, I w about the concept of machine readable governance, frameworks, and kind of having a way of declaring, like these are the trusted entities from this perspective but organizations interested in in saying like, these are the parties that we're aware of. These are the parties that we are willing to trust in relaying the sorts of information. I think in a very similar manner, we'll have assertions made by different groups, such as the government or company that we work for, or whatever about what networks we should be aware of and might be in use for these particular use cases. That's not an absolute outlining of these are the only networks you are permitted to work with. Uh, it's more a just in terms of discovery, these are the values that you might work with, uh, in this context.
Speaker 3 01:01:37 So what's next for did Indy.
Speaker 5 01:01:40 It's all about deployment. We have a number of organizations in the community. They wanna see it sooner than later. They realize the solution we have now is limited. The number of indie networks is expanding and we need to get it out there. So we're working as hard as we can to accelerate all of the pieces to push it out there again. That interesting problem of having lots of deployments out in the world and need to therefore amp up all of those deployments so that they can use, uh, a new capability. Um, that's the hard part. Um, the big thing in the areas community, I think think that's a little different than others is we're heavily into mobile wallets. There's a number of mobile wallet implementations. The core of using and non-res is based on for people, at least not for organizations, but for people is to use mobile wallets to hold their own credentials on their own hardware, if you will. And so that makes it interesting to get that through the areas components into the components of the various organizations building on top of areas and therefore in, and then into app stores and things like that. So lots of steps to get that to happen. Community upgrades are fun,
Speaker 3 01:02:57 Daniel, anything to add,
Speaker 4 01:02:59 It'll be a very significant lift on a lot of different code bases. There's just like Steven said, there's a lot of implementations out there and, and coordinating across the community as large as the Indian S community is just a very non-trivial endeavor takes time.
Speaker 2 01:03:16 And so how can our listeners get involved?
Speaker 5 01:03:18 Um, the place to go is Hyperledger. I think we've included links to the spec itself. The ind did method spec. Uh, there's a number of Aries communities. As I mentioned, there's currently about nine implementations of Aries each with its own community. Number of them are in Hyperledger and another of them have, you know, weekly meetings. So if you're interested in building on top of Aries, check out the discord at Hyperledger, check out the Hyperledger website and then figure out when the meetings are and, and jump in. We've got, as I say, discord channels on all of the frameworks, a pretty active community, uh, very responsive to requests and questions. And so that's the place to go.
Speaker 1 01:04:01 One question we always like to ask our guests is other than the did method we've been talking about, which is Diddy, what is your favorite did method?
Speaker 5 01:04:10 My favorite is did peer did. Peer is the one that allows us to connect to entities, whether it be a person in an organization or a person in person, and they don't publish it anywhere, or they can rotate the keys, they can modify it. They can provide information necessary to use communication protocols like DICOM. And I think it is super clever the way it was created. So that's my favorite
Speaker 1 01:04:37 Daniel.
Speaker 4 01:04:38 Uh, that's a hard question for me. I can't say that I've interacted with a ton of did methods to this point. It's been a lot of did solve a lot of did peer. A lot of pseudo did peer, I guess, even as a precursor to, to that method being defined, but throughout did E C the concept of having AA European union sponsored thing that enables organizations to use decentralized identity is, is of particular interest to me, I guess
Speaker 3 01:05:05 I think this is the first time we've, haven't had a guest say, did key,
Speaker 5 01:05:09 But I knew that
Speaker 1 01:05:11 <laugh>,
Speaker 2 01:05:14 It's now time for our shameless plug segment of the show. And we'd like to take a moment to allow you to shamelessly plug, what, whatever you like.
Speaker 5 01:05:24 I'd like to talk about the, a non cred specification work that's going on a non-res has become a standard, but it's a open source and a defacto standard, but it's not a recognized standard within a standards making organization. And, and that's what we'd like to change. So we're currently working on creating the specification, what we call the 0.1 specification, which is what exists today and what has has been already created from there. We'll move on to a 1.0, which is a Hyperledger indie agnostic version of an on cred so that it can be run with any underlying infrastructure or ledger. And then a 2.0, which is what's the future. After we get past what's called cl signatures, which is the basis we wanna keep all of the attributes, the privacy preserving attributes of an non-res, but move it into future beyond where it is today. And so that's, um, my pitch is I'd love to have, uh, people come join us and help out with that work.
Speaker 2 01:06:24 Awesome. Thank you. We'll put the link in the show notes
Speaker 4 01:06:27 For me. I think the biggest thing I'll out here is, uh, inicio is hosting a meetup on may the 24th, by the time this podcast is going out, I think that date will have been passed. Uh, but we're gonna be talking some more about the indie did method. So if you liked what we talked about here today, and wanna learn even more, kind of get more into the technical details behind it, that's what we've got planned for that, um, there should be a recording posted for that, I believe.
Speaker 2 01:06:52 Yep. And we will link to it in the show notes as well. So listeners can go check that out and see how awesome it was slash is going to be <laugh>. Yeah,
Speaker 4 01:07:04 I'll throw one more out. Since I, since I brought up the, my wife's research on, on sexual consent, she has an Instagram page where she talks about a lot of these concepts. So I'll throw that in as well.
Speaker 2 01:07:14 Great. Awesome. Thank you. Have that. A link in the show notes too, for interested listeners
Speaker 1 01:07:19 And I have a shameless plug, Erica, I don't know if you or Eric do. I know sometimes we do. Sometimes we don't, but I would like to plug rebooting the web of trust in particular, we are gonna be having a, our live face to face event the last week of September in the hag. So, you know, we've had a great community. We tend to get about a hundred people, 70 to a hundred people at these things and just wanna get the word out. It's a fun event. We do some interesting work. I think that's how I met you, Steven. So if you're listen to this podcast, you are invited. We'd love to have you join us.
Speaker 5 01:07:51 And I will second rebooting web of trust being a great conference. It is a one that makes you think do not go prepared to sit back, go there prepared to be creative and, and contribute. It's great.
Speaker 2 01:08:06 We have one more special announcement. Legendary requirements is hiring. We are a small consulting firm focused on requirements engineering for decentralized identity. We are looking for people who can bridge the gap between technology and humanity. If you have a technical background, thrive on attention to detail and are passionate about helping build systems that make the world a better place. We'd like to talk. We are actively looking for remote team members, capable of working flexible hours on a project by project basis. You can drop us a
[email protected], J O E L E G R eq.com. And that will bring us to the end of our show today.
Speaker 1 01:08:50 Stephen, thank you for joining us on the show today, Daniel. Thank you. Thanks also to our staff, our producer, Erica Connell, my co-host Eric shoe. I'm your host, Joe Andrew,
Speaker 2 01:09:01 Wherever you find the rubric podcast, please take a moment to subscribe to our feed. So you'll be notified when our next episode is released. We look forward to you joining us next time.
Speaker 8 01:09:11 The information opinions and recommendations presented in this podcast are for general information only. And any reliance on the information provided in this podcast is done at your own risk. The views, thoughts, and opinions expressed by the speakers in this podcast belong solely to the speakers and not necessarily to the speakers, employer, organization, committee, or other group or individual.
