 Hi, everyone. Welcome. I'm Heather Dahl, CEO of Indies GeoTech. For those of you who've just joined us, we're going to be talking about starting simple to feel decentralized identity. You know, when beginning the journey of decentralized identity deployment using hyper ledger, Indie, Aries, and Ursa, the simpler you start, the easier it is, and it's more likely to make you successful. So that's why we're going to talk about with the panel that we have today, which includes liquid avatar technology and Indie GeoTech. You can join our conversation too by posting to the Q&A section that's on the right hand side of your screen. But first, let's start off with introductions. We'll have our two panelists introduce themselves. RJ, do you want to take the lead? Hello, everyone. My name is RJ Reiser. I'm the Chief Business Development Officer at Liquid Avatar, which means I have the best job at the company. I get to take cool technology that comes out of these foundations that we're talking about today and apply it to real life solutions and get to meet really neat, interesting people that address everyday type problems that we all face around digital identity and your online identity. And Ken? Hi, I'm Ken Ebert. I'm the CTO at Indie GeoTech. We're a company that focuses on the growth and adoption of decentralized identity. We work with our partners to help them from training, architecture, consulting, whatever it takes to get their product through successful deployment into real life production. So I'm going to begin with you, RJ. Tell us about the beginning when you started down the road of decentralized identity. Thinking about projects within Hyperledger like Indie, Aries, and Ursa, what was the problem that you at Liquid Avatar were trying to solve? Yeah, so we've been in identity and identity solutions for the last three years. And what we found is that it's a one and done. And you have these islands of your connections with different companies and they own your data. And we thought there was a better way to do it, where how do we create a system, a tool where the user, the consumer, is in control of their identity? And we empower them to use and share what they want, when they want, and with whom they want. And it seems that's kind of simple, but then you add another layer on it and say, hey, there can't be a central authority. It needs to meet all the growing regulations of all the different government entities that are out there. It needs to be interoperable. It needs to be inclusive. And most importantly, it needs to be secure. And so we had that framing of, okay, how do we go to the next gen for identity? And we had a great opportunity to meet with Indie and move forward. So Ken, pick up there and talk about these first conversations that you had with RJ when Liquid Avatar called up and explained these problems that RJ was working on. What approach did you take in framing possible solutions for the Liquid Avatar team? So the first thing we have to do is take all of the big ideas. If you don't have a big vision, you're not going to go anywhere. But that big vision can sometimes inhibit the actual implementation. So our first challenge was to try to take RJ's enormous vision of how to use decentralized identity to solve real-world problems and pick one problem and then classify the parts of the, of the, were necessary to get that minimum ecosystem put together so that they had an issuer defined who is going to hold the credentials and how they were going to be held and who's going to be the first verifier. It's not that they are, that the scope of the project won't go beyond that. But if you don't pick a basic place to start where you control most of the variables and don't have to wait for anybody external to come along and exist for you to be successful. So that scaling that, the big picture down to what is going to be our first step. That was the first challenge. And RJ, how did you work on defining what the first step was going to be? Yeah, so it's actually getting like-minded individuals. So, you know, having a partner that understands that, you know, we needed a new system on enabling people to share PII, personally identifiable information. So that whole first step for us was, you know, finding the right partner that wanted to develop this system. And we introduced everybody and brought everyone together. And this trust triangle we believe is the direction that everyone needs to go. Now, I've shared this trust triangle that's very familiar to those in decentralized identity. Maybe new for those who are joining us to learn about decentralized identity. This probably is a blast from the past because this is actually the image that you and Ken first talked over in those first conversations. So maybe because, you know, the goal of the sessions really were committed to education and sharing our lessons learned with everyone, like us through the conversations that you had in those early days on this, how it helped you. Yeah, so it was all about starting small and then being in a position to scale, right? So it could be very daunting. You can go in and do a scenario where, you know, you have a paralysis through analysis to try to cover every single possible solution. And what we want to do is let's start with a good pain points around PCR tests and smart start with a small community where it was just granting access into certain facilities and there's existing governance that we have today. So let's leverage existing governance and structures and keep it, you know, a closed loop type solution and roll out the technology. You know, one of the things that was very clear in earlier discussions is that we can't come up with every possible scenario or challenge the project's going to run into. So let's get started and start moving down the path and then adapt and change as we go. I think one of the key things that we talked about was some of the needs that RJ identified for the basic holders, the people who are going to hold these credentials and looking at possible methods to incorporate open source solutions that already existed to meet those needs. And we looked at a mobile wallet and decided that a mobile wallet was probably not going to meet the needs, but that a custodial type of wallet where a cloud agent can be hosted on behalf of each user and then use a mobile agent, a mobile application with a mini agent in it to control that. And so we looked at that as offering the most flexibility so that if they had more than one device or they wanted to access their agent through a web interface that gave the most flexibility. So we took each of the components, we looked at the issuer and how would that issuance occur? What are our initial schemas going to look like? I think RJ came up with five schemas right out of the two that were interesting and we tried to pick which is the highest value schema that we can focus on first. That issuer schema got defined and then how was the relationship with the holder going to be established? Is it based off of pre-existing relationship or is it going to be a new establishing a new relationship? And how do we cover both of those use cases? Once the holder had a credential in hand or in their wallet, in their agent in the cloud and controlled by their mobile device, then who are they going to present it to? Once we had a closed loop system defined, we were able to start putting into place what are the steps that might be required to implement that. And that roadmap, we haven't stuck to the original roadmap that it changed as implementation went along, but it gave us a good basis for setting out for our first use case. How many use cases have you come up with since the first use case, RJ? It's quite a few, right? And it's difficult to choose which ones we'll do next, but it's scaling rather rapidly, so there's lots of different use cases. We're probably well over 10 different types of credentials, so it's very exciting. I wanted to add one other item to that is that one of the most important pieces was that there's no one central authority, one point of failure. And creating that mobile agent where it's not tied to a device is agnostic. So if you lose your device, you can use your biometrics to get back to your credentials through other methods. And that was one of the key features that we were able to build out by using this technology stack. Yeah, that was a key part of it is that the account recovery problem became a much simpler challenge to tackle because we were able to say the more reliable cloud hosting would take care of that. If the consumer drops his phone overboard and it goes to the bottom of the lake, it's not as a critical catastrophe for them. They get a new phone and they can re-establish that connection and their identity, all the credentials that they've had, the relationships that they've set up are still existing. And so that's one of the particular challenges that you were concerned about. For sure. So for those of you who've just joined our conversation, we're talking about starting simple to scale decentralized identity with RJ Reaser of Liquid Avatar Technology and indeed CSK and Evert. You can also join us by posting to the chat or Q&A feature that's located on the right-hand side of this window for today. I think RJ, it's important to point out or at least take a minute or two to focus on one of the things that we're trying to do with Liquid Avatar is build upon an existing system, an existing company. You didn't come to this with scratch, right? You were not building from absolute ground up. You had an existing solution that you were trying to transition and leverage verifiable credentials with this. Can you talk to us a bit about how the decentralized identity model was actually helpful? Yeah, so the system was we would go through a KYC process where people would use a government-issued identity or credential and create or verify their identity. And it would be a one and done for an individual company. And we were like, how can we change that instead of having the company be in control? And for me, I'd have to do it at four, five, six different companies and share that information at each one. How can we change that and allow me to go through and create a credential that proves who I am and then only share the pieces of that credential with each of those at different individual companies. One story that everyone here always uses in our different networks is all about trying to prove your age today. When you prove your age, you're given all this personally identifiable information that they can use to actually cause harm. So all they really know is that I'm over a certain age. So if there's an age issue with a credential, we don't have to share the birth date. We can just share that I'm over a certain age and so on and so forth. So I saw that that these standards, right, using Aries and Hyperledger was really the only tool for us that made sense and how to move forward and build out that platform where the power shifts from the companies to the individuals. And it's in line with all the regulations that are out there right now today as well. The liability also shifted from the companies back to the individuals, which is a benefit to the company as well so they can avoid some of that liability. That selective disclosure and predicate proofs that you were talking about are great tools for privacy preservation for the end users, but they're also good tools for helping limit the liability and exposure that the companies have to data that can be toxic to them. They need to see some data. They need something to rely on, but if you can limit the data that's being shared through the zero knowledge type methods and selective disclosure predicate proofs and so forth, then you have the ability for the companies to get the bits and pieces that they need to make good business decisions and to rely on the data without exposing them to all of the PII that subjects them to lots of different regulations. I always, you know, when I sit here and I meet with different companies, it's you kind of see a relief on their face that there's actually tools that allow them to be compliant now. I mean, it's such a challenge with a lot of these regulations. How do you do it? And, you know, every industry is a little bit different, has different requirements, but for what I've seen for the lion's share of them, they now have the tools, right, that they can actually feel comfortable that they're compliant with all these different regulations. So we have a question here from Patrick based on what you're talking about. He asks, do you see self sovereign networks without a central authority that adds new peer networks working in the future? If I understand you correctly, you are currently deciding who is a trusted issuer and how is that decided? There's a couple of aspects issuers that are interesting in the system. One is how does somebody become capable of becoming an issuer? And one of the things that I think that RJ and Liquid Avatar were looking for was what is a mechanism to allow companies to adopt the technology without having it to be completely embroiled in all the details all the way down. And that was one of the challenges of how do we make it easy for issuers to get onboarded and be able to quickly be able to issue a credential? So that's one aspect of the issuance process. Do you want to talk any more about the issuance on that side before we talk about verification and trusting? Yeah, so there's a lot to it and I'll try to unpack a little bit. So the first piece is how do we do it today, right? And when I go to prove my age, we already have a system, a governance system out there. They will accept a driver's license from the province or the state that I'm from. But if it starts to be a driver's license from Ken's driver's license shop, you're not going to accept that credential. So how do you create that framework or governance around to say these are the proper companies that can issue or organization institutions that can issue in the ecosystem? So it goes back to let's not try to create a governance package that covers every possible scenario out there. Let's start with a closed loop scenario like the one we're rolling out with. There's existing regulations for PCR tests and who can do a PCR test. And document those regulations, apply them to our little ecosystem and allow on our platform for them to issue those credentials. And then it's interoperable, right? So now you can have anyone that's fallen the same technology stack, if you will, and tools can apply and join the ecosystem and move forward. So I think there's two critical parts to it is enabling people to become issuers. Whether you trust them or not is irrelevant at that point. It's can they issue and get a credential out there. On the flip side, like RJ talked about, you now have to establish rules. But the rules can be per verifier or per verifier type of organization or vertical. And they can determine their own rules and say, yes, there are drivers license issued by the province of Ontario. There's one issued by the state of New York. And I accept both of those. I don't accept Ken's instant drivers license issuance process, although some people might find that to be amusing and allow that type of credential as well. But the point is to allow broad issuance and then jurisdictional or vertical or an organization to determine its own rules. And they might go on some guidelines that the federal government might issue guidelines to say, these are the people we know to be trusted issuers. And I'm going to use that list when I do a verification and rely on somebody else's due diligence that I trust to help establish guidelines for who might be a trusted issuer. Or I might make up my own rules that say, you know, you haven't, as a federal government, you haven't considered that I like foreign drivers licenses that were issued in the EU. And so I'm going to also accept those in addition to the ones that are listed on your recommended guidelines. But that that's a decision that can be made by individual verifiers, they can publish their own trusted list of people that they rely on, or they can rely on other people. But it gives a flexibility to the system that allows it to grow and allow for these ad hoc type of relationships to occur without having to predetermine it all ahead of time and publish it in a grand scheme that was once and done. So I read this question again, so I'll be really direct. So yes, self sovereign identity hands down, absolutely. And then the second part of your question is, you know, right now we're decided who can be trusted, but that can be expanded and the scope can be increased as it grows. Our main intent here with this first ecosystem is let's work through and find some of the challenges that you can't come up with, you know, sitting in a meeting in the boardroom saying this is how we're going to roll it out. And we've got quite a few participants in it and we're rolling out, we'll keep making tweaks. And the intent is then we scale it with these communities across the board. And one that I'd add, you know, is trust over IP, right? So they're using this whole stack and putting together protocols, governance packages, white papers that will allow this type of an ecosystem to grow. The reality is these open source technologies, allowing everyone to play, in my opinion, is the only way this is going to be adopted globally and be able to scale and get mass adoption. So one of the things that Ewing kind of both talked about is this concept of a closed loop ecosystem. And I'm going to share this slide because some of us are visual learners. And I think this helps explain what you're talking about. Maybe Ken, you can dissect this image and then RJ, talk about what it means to you at Liquid Avatar. This diagram is more busy than it probably needs to be. But at the bottom, you have some kind of a network that helps provide the validation of the public keys and the trust that it's built on. But on the left, you have a particular issuer who is going to issue a credential to the employees on the right. So it's an HR person. They have a UI that allows them to interact with their agent. Their agent may be looking at the HR server in the background to say, we'll look at our HR database to determine what employees are. We already have a relationship with them with email or whatever. We can send out an invitation and allow the mobile agents that the employees have on the right to connect with our cloud company agent and receive a credential, an employment credential. Once they have that credential, they can use that with a benefits partner, for instance, who it becomes the verifier. So you're representing all the bits and pieces of that trust triangle. You're looking at the issuer, the HR department on the left. You're looking at the holder agents on the right. And you're looking at a verifier, the benefits partner with their agent. We have a meat eater, cloud agent in there too. That's basically to provide routing for those mobile agents that move around and don't have fixed endpoints. But you're putting together the trust triangle and you're managing all three parties. That's the important part for us getting started. You have all three parties identified. So RJ went through and identified an issuer for their first system. They identified how they were going to do their agents that represent the holders or employees or whoever it is, and they looked at who's going to be the verifier. So you've got a simple one. You don't have to stand up your own network. That's something. There's an ADCO network. There's a sovereign network. There's the Fendi network. There are networks that you can rely on that are already stood up that allow you to put your schemas and your did documents out there so that the whole thing works. But you're looking at what is the simplest ecosystem? Are there other partners that could come in later? I think RJ can think of more places to use those credentials beyond the initial one. But in the beginning, you want to keep it in a kind of a closed loop system so that you can get the whole thing working. Once you have it working, then the expansion glory goes on and lots of different use cases will pop up. RJ, what does this image mean to you with your work at Liquid Avatar? Just the flexibility. That's the key. For me, this is the flexibility with the individual, the consumer, the employees. How do you put the power in their hands? Then just increase it to your everyday life scenarios. For us, this particular diagram is all around the companies that you work for getting access. What's important here that I want to touch in on is this system with all these tools, we're able to, for the HR and the company, you can have like a PCR test. They don't want the PII or control or own the PII that's associated with that PCR test that they're going to have or any kind of a medical type test. With this system, it allows that the employees have full control and they share the pieces that need to be shared. They don't have to share everything or the whole record, which gives a lot of power across the board to all these participants. I think that's for me the foundation of why I made the decisions we made because from day one, we've always wanted an environment where you can share what you want, when you want, with whom. This is the technical diagram for that. I was going to say that there's stages to the whole thing too. You put together a quick prototype that shows how it can work. If you're happy with that, you go on to the next phase. If not, you can make some small tweaks before you've tried to roll the thing into an entire production scaled out system. You try it out in prototype. Once you're happy with the prototype, you try it out with real users on a small scale so that you get an idea of are there any things that we overlooked or ease of use things that might be involved that you can polish up before you go to production. Once you get into production, then you're starting to worry about things like how do I scale it? Scaling is an awesome problem to have. It means that you've been successful at getting into production. Then look at how to scale things and make it more efficient and how to make it cost less per user. Those questions come up at that point. But if you try to deploy at scale from the beginning by skipping all the other steps, you miss out on the learning that can occur there and the cost savings that can result from taking a small course change early rather than trying to do it once you've got a full production system at scale. One of the things, Ken, when you talk about this image that's maybe a little bit too busy or overcomplicated, let's face it, for some people going into decentralized identity, they're overwhelmed before they even get to the prototype because you've got tools, you've got platforms, communities, governance, standards. I'm probably even missing parts of it. It's a very busy space. How do you even start to make sense of all these pieces to allow yourself to even move forward with the prototype? I have one thought on that. That's the focus on the credential. I think that's what RJ does a good job of, is saying we're going to look at an identity credential and a validated email address or something very simple like that. But once you start to look at what the credentials are, then you can say, how can these be combined to provide a stronger assurance? Or what are other credentials that could be added to the system in a stepwise fashion? Or where else can these credentials be used? And I think that's the key question, is where else can they be used? Because you think of one use case of how to use them. When driver's license were first issued as a piece of cardboard or laminated piece of plastic, they were intended to prove that you're able to drive. But other people came along and said, hey, I can use this. I trust this. I can use it to verify your address. I can use this to verify your name. I can look at your photo and see that your name and your photo are associated. There's other use cases that pop up. And that's the same thing with the digital credentials, the verifiable credentials. And once you have a system for allowing easy creation of credentials by trusted parties or by anybody, and then you can figure out which of those you're going to trust and where they might be useful and applicable. And I think that's part of the natural growth of a system. But by doing it stepwise, you can get something up and running and have that conversation and have a credential that you can actually go out and share that makes it a lot easier to talk with a potential customer than if you have a twinkle in your eye and no working software. I know RJ, that's something we talked about in the early days. There's so many moving parts in this space. So many pieces. Where do you begin? And what is your advice to someone that just started looking into this, trying to figure it out? Yeah, I'm going to kind of divide the question up a little bit, right? And so, you know, the first piece is, I think, that a lot of the folks that are going to be on our call and listening to this are going to be more technical. And they want to know how they get into this space or how their business gets into this space. And, you know, there are so many smart individuals that are here. I've always been impressed over the last two and a half years, all the different working groups that I've joined and how wicked smart they all are. But there's one little little item that everyone can get. And that is, everyone produces all these white papers. Get a hold of these white papers. They have them front and center on their websites. And go through those white papers and you start to get an idea. We all have, you know, dead time. I'll be sitting in between baseball games with my kids reading white papers and my wife looks at me like I'm crazy. And you just got to grind through the papers and try to figure this stuff out. I think that's core one. And then join some of these working groups. Get on and just listen. In everybody's at the same spot you are. It's not like you got to get on there and lead the discussion right away. Just get in there and join these working groups and participate. So that's the one piece. The other piece is, and this is the one that I really, really wrestle with is how do we explain this to the individual users? How do I explain it to, you know, everybody that I come across, people I used to work with or my family numbers, what are you doing? And you try to explain to them what this digital credential is. And I don't have the magic solution on that one. I think it's going to be the same way we learned other apps and other technologies. Just put it in their hands, let them use it, maybe a test environment, working on some cool stuff around there. You get to use it. You get to experience it. And once you see it and feel it and say, hey, here is a credential that looks just like my driver's license. It has 10 fields. Hey, here's a place where I can do a QR scan. And then they ask me that they want these four fields. Guess what? I'm going to let them see one field or I'm going to let them see that I'm over 21 or over whatever age it is and use it in a safe environment. And then all of a sudden, they're going to be just knocking our door down, add this to everything else, keep adding, try it over here, over there, and then it'll just continue to grow. And I think it's those pieces. And there's lots of companies out there that have access to different wallets that you can get to. And we just need to get individuals in there using these credentials and really good use cases. And I think the one that we're working on right now around PCR tests is going to be a really neat use case where people are going to want to embrace it and use it because the trust level is so high with the accuracy and the security that I think it's going to be a note. I hope it's going to be a note, right? Well, for those of you who have joined us, we're talking about starting simple to scale decentralized identity. We have RJ Reaser of Liquid Avatar Technologies and Ken Ebert of Indecio Tech. If you want to join our conversation, just add to the chat or the Q&A slide here on the right hand side of your window. Ken, I cut you off. So I'm going to jump back to you. I was going to say that there are many credentials that have a physical counterpart right now. And some of them have problems associated with them. They have fraud. They have high cost to prevent fraud. You have to put little holograms and things and try to put a protective coatings on them and things like that. And so by moving to a digital verifiable credential, this can help reduce cost and fraud in those credentials. And so for many issuers, it can be a case of taking an existing credential that they already have and transforming that into a verifiable credential. That gives them a mechanism that reduces their overall cost and allows for people to trust and verify those credentials more readily. There are some places where there aren't existing credentials where it would be a great idea to cook up a new one that might prove something and help establish things. And because the cost can be embedded in a verifiable credential issuance system that is cheaper to maintain than a printing press, you're able to get those credentials into the hands of holders and establish relationships of trust and also be able to let the end users benefit from the thing that you've done. You may put together an employee credential to allow them to safely come into a factory so they can help build cars during COVID, but you may find that that employee credential when shared appropriately might work with partner organizations, services, and other partners that might have a relationship with your company that your employees can benefit from. Your benefits organization, your travel and vacation service that you offer them, a health screening, whatever types of things and those employee credentials can be used in ways that you hadn't anticipated when you first set out to open your factory for a safe manufacture. And I think what you hit on with relationships is key for our conversation moving forward. We spent the first half of the hour really focused on the starting simple and for those who are just beginning the journey to decentralized identity, now for our second half, let's focus on the stealing decentralized identity. And I think that's where these relationships really come into play. So RJ, you're at the point now where you've crossed over, you've already started, you've had success, and now steal is reality and what you're dealing with. Can you talk to us a bit about what it's like now to deal with the stealing part? To deal with which part? I'm sorry, you broke up just for a second. Oh, yeah. We're talking about stealing decentralized identity. Now it's built and we've started and we've started simple. How do you scale the simple closed loop ecosystem out, which is your reality right now? Yeah, so we're actually on the whiteboard doing that now. I think there's lots of really good options. So what I believe it is, is now connecting the two different, all the different multiple ecosystems that are out there, all the different credentials that are out there, all of them have lots of strengths that they can provide. And then it's just finding the ones that are the ideal fit. So we have, I'm not sure what all I can talk about, unfortunately, but what's neat is there's some natural fits and progressions that I never even knew existed that are now coming to fruition, not taking it to the next step and to the next level. And it's a challenge in the fact that you don't want to boil the ocean. You don't want to try to be everything for everyone. You got to make sure you keep laser focused and choose the correct projects that you can get quick wins on. And you can get deliver results that you can leverage to go to the next phase. And what we're all focused in right now is, I think is really important, is what's the first government entity, division, institution that's going to embrace this, right? There's a couple of them, but at some point there's going to be that tipping point. And again, these are just my opinions here. I think everybody wants to move forward. All these institutions want to move forward, but they don't want to be number one. And they don't want to be the last one, right? So they want to be like third or fourth so that people can work out the bugs, and then they come in. They don't want the egg on their face if it doesn't work or whatever the problems are. And they don't want to be last because if they're last, the issue in itself. So everybody's at that starting line ready to go and they want some of these use cases that we have and some of these successes. And so it's got, it's really exciting point right now. There's huge momentum in that direction. So more to come, right? I think that's a really funny image. It's a race where nobody wants to be first and nobody wants to be last. And they're all waiting for somebody to take the first step. But that's one of the reasons why taking that first step and putting out a very small scale project, it breaks the ice. And people excited, they can see that it does work. And they're more willing to take their own first step once that somebody else has already taken the first step. And I think that's really cool. When you look at scaling, there's a number of ways to talk about scaling. And you've talked about one of them. And that's kind of like the partners. But there's there's scaling of individuals. So you might be successful in a trial in a small subset of your organization, you took the HR department and put them in. Then you can scale it out to the other employees. So that you have a small group that you work with at first and scale the number of people that's the holders being scale. You could also scale it to other people's holders. So it's not just your factory. It's it's more people that are involved. You can also look at issuers. And that typically talks about credentials that are being scaled. So the different you can take the same credential that you use in your in your first system and take it to another issuer and say, would you like to issue too? That's one way you can come up with new types of credentials that might be issued. You started off with a simple email verification credential or employee verification credential. Now you can expand that to say, we're going to combine that with a another type of credential, we're going to do a background check credential, it's going to be issued by federal government to investigate it you and prove that you have a security clearance. So you can take the number of types of credentials that are being issued and scale those up to and have them interact with your system that already has a number of credentials existing. You can also scale the verifiers, the people on that. And that all three of those are all four of those are interesting things. Number of issuers, number of credentials, number of holders and number of verifiers. And each of those, like RJ mentioned, can be done on a single relationship. You're not trying to do it all at once. You're saying, hey, we've got the system. Here's another way, another high-value place where we think there's going to be a good interaction and a good fit for another partner to come in. And now instead of an issuer or a verifier in one set of holders, you've now brought in another partner and then another and then another. And as you do that, it creates a tornado effect and the value grows beyond what you envisioned in the first place to create what I would call an open system. It's not closed loop anymore. It's an open system where many people can come and they bring their own governance rules of what they trust and don't trust. They can bring new types of credentials that they're going to issue. And the people who are already participating can say, hey, that is an interesting credential. I would like to rely on that as well. But it gives that growth can happen on those four different dimensions at least. There may be more that I haven't thought of, but it's a great place to start and it's a good story to tell. Ken, Mark wrote us here. He writes, that seems like the skill problem for decentralized identity is the same problem as for many other areas of blockchain interoperability. Are you involved in interop work broadly or focused only on did? You have to start somewhere. So the first area that we've chosen to focus on is interoperability within the Aries community. And one of the first things we looked at is how do we scale beyond a single Indie network? That seemed like a pretty basic question, but it wasn't answered at the time we embarked on it. It's one of the reasons we stood up the IndieCO network is to begin testing of cross Indie network did resolution. There are other types of credentials that are out there. And there are different did systems as well that different signature types and so forth. And most of that work is happening. I think one of the places of effort is in the Indie community in the Aries community on focusing on how can we bring in new types of resolvers? How can we bring in different ledger types, different signature types and those types of things? How do we increase our interoperability testing capability so that we can prove reliably that the interoperability is occurring? There's other types of interoperability with, for instance, paper credentials of vaccinations. How do you bring those into an ecosystem and bring them out of the stone age and into the paper age and into the digital age and provide a way to reliably convert a less trustworthy credential into something that can be more trustworthy? So there's a number of areas where interoperability is important. There's interoperability with legacy systems as well. So RJ has already experienced some of this as how do you tie a system into an existing system so that you can get data to put in a credential? Or once you've verified a credential, how does it interact with a system that already exists? And so there's integrations as well as an aspect of how does the whole ecosystem play nicely with others. RJ, your thoughts? Yeah, so it's a foundation for interoperability, right? Every working group, Aries, Hyperledger, Trust Over IP, that is one of the core foundations for self-sovereign identity. And I never realized how complicated of a word that is because we can have vertical interoperability, right? And that's the key. One of the strengths with this credential and self-sovereign identity is that I can't just move this credential everywhere. So that's the strength is that it is locked to a bound identity to that agent. I just can't take that credential and put it on a different agent and move it different wallet, different agent. So that's a strength that builds the trust, but you want it to be interoperable so that no one's tied into a single company or what have you. And so there will be a process that these working groups are working on so that you can change from one agent to another. It isn't fully defined, but today you have interoperability, vertical interoperability, all the way down to, you know, the networks or the utilities is one term they use on the blockchain on which utility they're using. So there's interoperability that exists today that allows choice with the consumers. And I'll see it will grow. It'll grow quickly to even be more diverse and dynamic on interoperability. But you don't want to have interoperability at the downside or decreasing the security in the trust layer. We need to make sure that that digital trust is there and it's maintained, but it's still interoperable. So RJ has been a strong proponent, I think, of interoperability at the wallet level as well. So interoperable wallets so that they're compatible with each other, that's one aspect of it. But the migration capability of wallet interchangeability is another aspect and it's a different term, but the ability to migrate your credentials from one wallet to another, that's a slightly different story and an area that needs attention as well. So I think that there's a whole bunch of interoperability terms and you can talk about it at the network level, the protocol level, if it did come, you can talk about it at areas and types of credentials they support. You can talk about it also at, I think RJ has taken the lead on trying to think ahead on how wallets might be interoperable or manageable or back-uppable and restoreable to a different wallet. Those are topics that also are of prime concern in terms of interoperability. So we want to thank Mark for writing his question. For those who just joined us and you might have a question for RJ or can just use the Q&A or chat feature that's located on the right-hand side of your window. So one of the things that at these conferences events, you'll hear a lot of presentations that are glossed over and it's highly successful and it appears to be so easy because the success went from problem solution to celebration, three slides. But here we're all about keeping it real because the only way we can reliance the adoption of decentralized identities by learning from each other. But I want to go to you RJ and talk about one of the challenges or obstacles that, one, you weren't expecting and two, that you had to overcome in order to move a milestone. That's a good question. I don't know how to answer it. I think there were challenges across the board. So when you're starting something completely new like we are, there's a lots of education that has to go on. And so that was kind of the first step is how do you meet with your partners and explain what a digital identity is and how you empower the consumer and how that is beneficial for all parties involved. And then the other question for me was where do you get the bench? Where do you get the people that are going to help you build it out? I mean, you just can't find engineers that have the skill set needed to roll these projects out. So the nice thing is finding the partners that can help us roll these things out. Those were the two biggest challenges and working within DCO and finding the right partners helped us with that so that everybody's on the same page. We're starting something that not a lot of organizations have done before. And it's cutting edge, which is exciting. I mean, that's what I love about these projects. It's cutting edge. We can say we're one of the first ones to do a digital identity used in these type of scenarios. But with that is you've got to find the right people that are ready to roll out their sleeves and handle those challenges that are associated with being first out there or one of the first. There's lots of companies that have done some great work. One of the fun problems is a technical problem was that the mobile wallet interface was written in React Native and integrated into an existing app that was written in Flutter. And so those are some of the kinds of problems that I think are fairly typical of trying to do that. But that type of integration is not uncommon. That's going to be a challenge. It's not an insurmountable challenge, but that type of challenge will happen with enterprise agents being integrated with backend systems. That will happen with mobile wallets being integrated with existing applications. And you're going to find that. Another interesting challenge we ran into was a couple of holes in some of the protocols. They were mostly there and did most of what needed to be done, but there was some gaps in the protocols. And that's the kind of things that you discover when you do an implementation rather than a whiteboard discussion. And so that learning experiences help fill in the gaps on both the conversion to Flutter and protocol missing components to make the protocols stronger and more interoperable and useful. So that learning experience comes early on. And I think it positions RJ and his team in a position of advantage to be able to take what they've learned and build on top of that for the next round of benefit that they're going to provide to their customers. So we have 10, nine minutes left in our session here, governance. I want to take a few minutes to talk about governance because what we hear from companies, organizations that early in the journey, governance does become a challenge of almost a blocker because as you described it, RJ is analysis paralysis. How did you work through governance in very early days, RJ? And what does governance mean now that you're starting to scale? Yeah, so for us, I mean, just to boil it down is the closed loop helps, right? So you don't have to cover every single possible scenario. But the other one is just use the existing governance we have today, just like the credentials. Most of these credentials that are the first credentials out of the box are ones that we have paper versions. So we're just using the existing governance that we already have around, you know, the medical health industry and just leveraging those and meeting those because they have to meet those requirements anyways. Just because it's a digital form, you still have to meet hip and all the other regular requirements that they have. So how does this platform help enable it? And we found that, you know, with these governance package, you keep them simple and get them out. It actually allows you to be more compliant because you're given the control to the individuals. I think that you made a couple of key points. One of them is model the existing governance that exists today. Second is keep it simple by bounding the problem. You don't try to solve all the problems. You solve the one particular problem that you're working on. Another step that we did was introduce, even though there's not a defined standard around it yet, we proposed what could be a working standard for machine readable governance and we're implementing that. There will probably need to be adjustments to that as time goes forward and standardization occurs. But innovating around that helped make it so that as changes were needed to the governance that they're made in configuration files rather than having to rebuild the entire applications. One of the things RJ, you brought up is educating how do you start talking to folks about decentralized identity? Then at the point of scaling where you're trying to bring in new partners, once again, you're going through this exercise. What are some tips that you've learned along the way and when you get up to that the next time it makes the chances for you to fall out of the park much better? Yeah, just listen. Join all these working groups, listen, listen, and try to contribute and help as much as you can. Then don't be afraid to take that step and move forward. That's the key one. When I started with the company, we have a lot of forward-thinking individuals at our organization and it was fun to bring the idea of where we think digital identity is coming and have everybody in the organization embrace it. Don't be afraid to take the first step and have fun with it. I think that by limiting the scope of what you tried to do in your first step, you've limited your risk and you got the opportunity to learn from that and grow as well. I think that keeping the scope narrow at the beginning helped make it more feasible to take those first steps and to get into the market to figure out what are the needs, the true needs, and adapt to that as you learn from your initial findings. One of the projects that I know RJ Liquid Avatar announced that they're part of the steering committee of CARDIA, which is a new Linux Foundation Public Health project. Talk to us about CARDIA and your role in that and how others can participate and help support the scaling of CARDIA. I boil it down to be in turn key. We've already figured out the path on how to move forward with this. How do we bundle that together to help enable other ecosystems, other partners to move quickly down and learn from our lessons learned? Again, it goes back to sometimes it doesn't seem when you're building organizations, it's not as clear, but how do you create a new industry, a new standard that's embraced across the board with all different organizations? It's not based on a closed system. It's open standards and everybody contributes. CARDIA is that foundation for it. We've created this path and we're bundling it up and we'll show this roadmap to others that want to move forward and we're excited about it. We were happy to join as one of the founding members and we're going to leverage everything that we're learning to put into the system so that others that want to move forward and create these types of platforms have a roadmap that they can follow. So Ken, maybe you can explain a bit more about CARDIA from a technical point of view and how that might be a place for organizations to start a closed-loop ecosystem and then scale it. So CARDIA is basically based on open source technology. It builds on top of ARIES agents, ARIES ACAPI, ARIES framework JavaScript in the by-fold projects and then provides the unique characteristics of needed by public health and travel in particular to safely exchange health status type credentials. The cool thing about the CARDIA project is that it's not just a specification, it's an implementation. It's at least a reference implementation and a deployable reference implementation at that. That allows for people to take that open source code, customize it, modify it for their particular case and then deploy that to take advantage of the work that's already gone on and the learning that's gone on. One of the things I like about having RJ on the liquid avatar on the steering committee of CARDIA is that they are willing to put out a proposal and then guide it to adapt it to real-world conditions and learn from what's happened to make it stronger and more broadly useful. And so it's not a hypothetical, it's a practical, take a few steps, adjust, take a few steps and adjust. And that mechanism, the steering committee is ideal for helping guide what has been learned and where we might go next in terms of setting out a roadmap for enhancements and improvements. The CARDIA as it exists today is fairly basic, but it provides most of the functionality that's needed for a successful deployment. And for those organizations who want to work more closely with RJ and Ken, CARDIA, you can find more information at cardea.app. And the meetings are every Thursday at noon Eastern time. We have one last question, we have two minutes RJ, so let's see. The question is, what are possible ways to monetize digital identity solutions, which in your business development role is a great question for you, or is this even planned? Yeah, so still to be defined, right? So there's a couple different ways or ideas on how it's going to be monetized, but it's not clearly defined yet. One of them is on the issuer side. So lots of companies are looking for issuers of credentials to subsidize everything that needs to happen in order for this to be profitable and be able to be scalable. There's other entities that are looking at the verifiers. So if you can have a higher level of trust, things can be more secure. What's the value to the verifier and what are they willing to pay to do it? I think there is somewhat of a consensus that this is not going to be a business model that charges the individual or the consumer. It's going to be the other pieces. Then you kind of step further out and look at all of the other benefits to having a higher trust layer on the internet slash your digital identity. What does it do to fraud and how much money is saved on fraud? So therefore, what fees can be reduced and or shared with other players in the ecosystem? You can look at password reset, right? So how much time and effort and cost is going into password reset that if you can have a biometrally secured agent that holds your digital credential and you use that for access to all our different tools and email and zoom and everything else, how much money does that save a company that can then use in the ecosystem to help support the network? It's not clearly defined just like every other industry that's nascent and starting, but there's lots and lots of potential. I'm not sure which one's going to win. There's lots of people looking at it and trying to figure it out, but there's value there. There's need there. There's a pain there across the board with all the users, and I'm sure it will rise to the top and show itself at some point. You build a good app that everybody wants to use. You build functionality that addresses the pain, organizations, entities. They'll find a way to help subsidize and support it. And so we're going to have to leave the conversation there. I want to thank RJ and Ken for joining us today. You can connect with both of them on LinkedIn. I want to thank David who's been in the wings making sure that technically was successful. I want to thank all of you for joining us. I'm Heather Dahl and we wish you a very enjoyable rest of the global forum. Thank you. Thank you, Heather. Thank you, Ken. Thanks, everyone.