 So, hey everyone, I'm Michelle. This is me. We're both front-end engineers working for Kiva Protocol on an open-source SDK for the issuance and verification of self-solving credentials. And so, what does that mean? Glad you asked. There are two main open-source repositories for you to check out. The issuer SDK allows you to issue credentials to a person and the Verifier SDK allows you to run proof requests and verify the certain truths about a verified credential that was issued. And so, this is an interoperable system that uses the Hyperledger Aries protocol. So any verifiable credentials issued through Hyperledger Aries should be compatible with our open-source tools, which Nate can say a little bit more about. Thanks, Michelle. By the way, are you sharing a screen because I can't see it? Oh, I'm sorry. No worries. So, if you know all about verifiable credentials, you can go pour yourself a cup of coffee now. But if you don't, here's a helpful diagram of the kind of system that Kiva's trying to support. It's actually the previous one, Michelle, if you don't mind. First things first, verifiable credentials in Kiva's universe are cryptographic credentials built using Hyperledger Aries. Since Kiva's mission is to make a more financially inclusive world, we mostly issue credentials that contain biographical data about someone so that they can identify themselves to a financial institution, think first name, last name, birthday, et cetera. The person holding this credential is known as a holder. The holder is issued credentials by, you guessed it, an issuer. And the nice thing about the issued credential is that they can't be forged. This help for the holder who doesn't need to worry about people questioning the integrity of their credential. But it's also helpful for the inspector who will know right away if the holder has information in their credential that's been vouched for by a trustworthy issuer. And you can see issue a holder inspector at the top row of this diagram. The inspector uses areas to create a proof request. Prove to me that you are who you say you are. You have data that you say you have. They can request that a holder provide certain pieces of data and that that data satisfies certain requirements. For example, imagine an inspector wanted to make sure that a holder is over 18 years old before they can take it out alone. And if the holder's credential satisfies the proof request criteria, it will reveal data that can be used by the inspector. The actual last piece of this puzzle is, in fact, a registry where the status of the issued credentials is tracked. If the issuing organization revokes an issued credential, the holder's presentation to the inspector will fail. This is how the whole system operates in practice. And you can see here the ID database from a trusted organization that acts as a source of truth for data that gets wrapped in credentials and then issued to holder's wallets. During Kiva's project with the Bank of Sierra Leone, the government's National Civil Registration Authority served as the ID database, for example. And these can be held with a holder's agents, in most cases a smartphone, or in guardianship, where the wallet lives in the cloud. And the holder gives the cloud guardian permission to do certain things with the credential. So these are two screenshots of the issuer SDK workflow. So you can just see what it looks like. So you can see this in practice. We're going to give a demo of the whole thing in a bit. But the important thing with all of this is just that while we're making the platform, we came upon a few problems. The first problem is, sorry, the first problem is how do you do issuing and verification for more than one kind of credential? Verifiable credentials can be issued by lots of different types of entities, and there's no standard for what information can be wrapped inside of it. So we need to have a system that can process a verifiable credential without carrying who's issuing or verifying it, and without having a strong opinion about the data schema of the information contained in the verifiable credential. The second problem is UI customization. And so even though we have a system that can process verifiable credentials from anywhere and containing anything, it won't be as viable as a product unless it can be customized by an issuer or a verifier to reflect their branding. To put it simply, no other organization will use Kiva's platform if there's a big immovable Kiva logo on it. So we need some way to make the logo and probably colors, fonts, et cetera configurable. So this is a white label product. The third problem that we have is to solve is authentication. So you might not want people outside of your organization to be able to hit your back end and exchange messages. So in Kiva's case, we require bare tokens within our request headers in order for requests to succeed. This isn't a universal requirement, but when you need support for off tokens, you really do need it. So this is all well and good, but you're probably thinking at this point, I thought this is a demo. Why are you showing me how to do this? Listener, the wait is almost over. Here are the steps you'll need to take to get started. First step is create a configuration file. The second is to write an agent class. And the third step is to go pour yourself another cup of coffee because you're basically done. The configuration file is just a JSON file that has certain values predefined. For example, we support internationalization. So one of our config values is locale, which can set the language for you. The controller URL base is your back end gateway URL. And the verification options array is just a list of options for actually completing the issuing or verifying flow. We won't go into all the config values because the config system is still very much alive and might change. Now these are just static values, but the agent class is a little more in depth. There are four steps that you need to do in order to complete your areas process. The first is send a connection. Then you have to check the status of that connection request until it switches to accepted. And once you've done that, send your credential offer or your proof request. And then, again, check the status of it until you get a yes or a no from your server. The agent class is designed to abstract these processes so that we can solve item one from one of the previous slides that we showed you, source and schema. We don't know what kind of server response means rejected or accepted from any given server. And we don't know what controller URL we should even be aiming at for a request. Or what to do with the response when we receive them. You can see that these screenshots, once we hit the Kiva API, Michelle, can you just hit the next slide, please? Oh, right. Once we hit the Kiva API. Oh, that's right. I think it is this one because I was here and then I went here. Oh, okay. Well, then we're missing an image. But once we hit the Kiva API, we actually need to transform a response into base 64 encoding in order for our QR codes to render correctly and to be useful for our mobile agent, which you'll see in demo later. Even more simply, we have a method for saying, is the response, is the definition of the response connected? And it's just checking the response to see if certain attributes are available and if they are, we say, yes, it's accepted. If certain attributes are another way, we say it's rejected. And then the UI can change based on those responses. So aren't with this knowledge, what should your final product look like? And I'll have Michelle field this one because she's a senior engineer and I badly need my own cup of coffee now. So take it away, Michelle. All right, so we have a demo, which is probably what you came here for. So I'm just gonna start it up. We have credential issuance to a mobile wallet app. We also have other authentication methods, like we were using this to take a fingerprint, so biometric data can be used as an authentication method or SMS OTP, but I think this is the clearest way to show what exactly is going on because we have a wallet over here on the right, which is like held on your phone. And then there's a web SDK where we're just filling out some of this information, like a PII, personally identifiable information. Michelle, are you sharing a screen? Is it, I'm sorry, this is, I don't know why the screen share cut out. There we go. Sorry about that. So should I just, I guess I can just go back here. We actually have 30 minutes, so I think we'll be okay. Oh, great. Yeah, so, but you heard everything I said, right? Yes. Okay, great, so I can actually just go through this and actually talk about the consent screen. So we have a consent screen here. It has all of our personally identifiable information that we ask the user if they are willing to share that with the institution that wants to issue this particular credential. And so, you know, we have the ability to capture an image or upload an image, fill out the credential with the person's PII. I've done here. I should actually full screen this. And then we get a QR code, which allows this mobile wallet on the right to form a connection with the Web SDK and make secure messages between the mobile device and the Web SDK. And so then the credential pops up and you hit accept and then it pops up in the wallet. And you can see all of the fields here. And then when it comes to verification, it's a similar sort of workflow, but you know, we use the verifier tool, grab consent from the user and then scan a QR code to form a connection again because we want that consent every single time. And then we just run the proof request and then it shows up on the mobile app side, but it also shows up on the Web SDK as well. And then, yeah, we built our own registry and this is not part of the open source suite, but it's areas protocol supports. So, you know, we have a credential revocation and a few other features kind of in the works. So next is open questions. So since this is an open source white label project, these configuration files make it a lot easier. The configuration files that Nate was talking about earlier make it a lot easier to integrate what we have to fit the needs of any institution that would need a working credential system for their own use case. But the work of doing this integration with that institution is not removed completely. I would say that, you know, for our pilot in Sierra Leone, we were able to take our existing code and apply it to a legacy banking system and perform EKIC in a community bank in Sierra Leone within a matter of two weeks, but we've moved forward since then and we have made the integration process happen even more quickly for future cases. And so my guess is it'll be quite a bit less than two weeks, but we haven't actually, we haven't tested this on the ground. We have tested it internally. And so, you know, currently you can't just import your own agent and have it work. That's a no, but you can take the existing backend that Kiva has available or you can extend our code to work with your own agent and you can add steps into our workflows and change the code if you like. The system also supports multiple languages. I think Nate mentioned that before, but you can only use one language per deployment. And then, so you can't switch languages using a dropdown menu, for example. We have created different credentials and proof types, such as checking whether a credentials issue date was before or after January. Or if you wanted to check the age of a person and issue driver licenses, for example, you'd be able to do that without disclosing the attribute itself. So you don't need to know a person's age, but you may just wanna know that they're above 21, for example. So that would be possible or seeing if a particular credential has been revoked or not, but there's still a lot of work left to be done to streamline the process of creating new credential types as well. As we move forward with this open source project, we welcome any contributions towards these efforts. And so as we said it from the beginning, you should feel free to check out these repos and we truly mean that. Please check them out and start playing with them. And until then, thanks for watching our demo. So we finished with quite a bit of time to... So Helen actually responded, we're actually one minute before the end of our session. So... Okay, great. Nailed it. Nailed it, right on time. Awesome. Sorry that there's not very much time for questions, but as we said, please check out the GitHub repos and feel free to reach out to me and Michelle on the web somewhere. We'll be happy to feel the questions. Thank you so much for attending, everyone.