Hyperledger Foundation Hyperledger Global Forum 2021, 11 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: An Open Source Approach to Enable SSI Credentials at Scale - Michelle Ghazal & Nate Sulat, Kiva

Description

An Open Source Approach to Enable SSI Credentials at Scale - Michelle Ghazal & Nate Sulat, Kiva

In this session, Michelle and Nate will provide an overview and demo of Kiva’s use of Hyperledger Aries which allows people to extend existing applications with the capabilities that SSI credentials provide. This software was used for a pilot by the government of Sierra Leone to verify the identities of bank customers and grant access to digital identity wallets held in escrow on their behalf. Our initiative, Kiva Protocol, was awarded the Global Prize for the 2020 World Bank Mission Billion Challenge. This open-source system is available on GitHub and this session will show you how to get started. Kiva Protocol packages together tools out of Hyperledger Aries, Hyperledger Ursa, and Hyperledger Indy to digitize the civil registry and enable an ecosystem of standards-compliant verifiable credentials.

Sessions Details & Slides (if available)- https://sched.co/j3dx
Access All Sessions: https://events.linuxfoundation.org/hyperledger-global-forum/program/schedule/

----
Hyperledger – Open Source Blockchain Technologies

Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use

Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory

Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter

Follow-us on Twitter @Hyperledger

Learn about Hyperledger Membership: https://www.hyperledger.org/about/join

#Hyperledger #HyperledgerGlobalForum2021 #Blockchain

A

So, hey everyone, um I'm michelle! This is me, we're both front end engineers working for kieva protocol on an open source sdk for the issuance and verification of self-sovereign credentials. And so um what does that mean glad? You asked um there are two main open source repositories for you to check out. um The issuer.

A

Sdk allows you to issue credentials to a person and the verifier sdk allows you to run proof, requests and verify that certain truths about a verified, credential uh that that was issued, and so uh this is an interoperable system that uses the hyperledger aries protocol. So any verifiable credentials issued through hyperledger areas should be compatible with our open source tools, which nate can say a little bit more about.

B

Thanks michelle um by the way, are you sharing your screen, because I can't see it.

A

B

um No worries so, if you know all about verified credentials, you can go for yourself a cup of coffee now. uh But if you don't here's a helpful diagram of the kind of system that kiva is trying to support, it's actually the the previous one. Michelle. um If you don't mind, uh first things: first, verifiable credentials in kiva's. Universe are cryptographic credentials built using hyper ledger aries, uh since kiva's mission is to make a more financially inclusive world.

B

We're mostly issuing credentials that contain biographical data about someone so that they can identify themselves to a financial institution, think, first name last name birthday, etc. 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 issue 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.

B

That's been vouched for by a trustworthy issuer, and you can see issuer holder inspector at the top row of this. uh 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 whole to provide certain pieces of data and that that data satisfy certain requirements.

B

For example, imagine an inspector wanted to make sure that a holder is over 18 years old before they can take out a loan, uh and if the holder's credential satisf request criteria, it will reveal data that can be used by the inspector.

B

The actual last piece of this puzzle is, in fact, a registry where the status of issue credentials is tracked. If the issuing organization revokes an issue credential, the holder's presentation to the inspector will fail.

B

uh 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 holders wallets uh during cuba's project at the bank of sierra leone.

B

The government's national civil registration authority served as the id database, for example, uh and these could be held with a holder's agent in most cases 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.

A

So these are two screenshots of the issuer, sdk workflow, so you can just see what it looks like, but um so you can see this in practice. uh We're going to give a demo of the whole thing in a bit, but uh you know the important thing with all. This is just that, while we're making the platform we came upon a few problems. um The first problem is sorry.

A

The first problem is: um uh how do you do issuing and verification for more than one kind of credential uh verification, 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.

A

um The second problem is uh ui customization, and so, even though we have a system that can process verifiable credentials from anywhere and and containing anything, it won't be as viable as a product unless it can be customized by an issue or a verifier to reflect their branding. To put simply no other organization will use cuba's platform if there's a big immovable kevo logo on it. So we need to. We need some way to make the logo and probably colors, fonts, etc configurable.

A

So this is a white label product. um The third problem that we have is uh to solve is uh authentication, so you might not want people outside of your organization to be able to hit your back end and experience messages. So in kiva's case we require bearer tokens within our request, headers. In order for requests to succeed.

A

You know this isn't a universal requirement, but when you need support for auth tokens, you really do need it.

B

So this is all well and good, but you're, probably thinking at this point. I thought this is the demo. Why aren't you showing me how to do this listener? The weight is almost over uh here. Are the steps you'll need to take to get started uh first step is create a configuration file. The second is to write an agent class, and the third step is to go for yourself. Another cup of coffee, because you're basically done uh the configuration file, is just a json file that has certain values.

B

Predefined, for example, we support internationalization, so one of our config values is locale which can set the language for you. Controller url base is your backend 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 um now. These are just static values, but the agent class is a little more in-depth.

B

There are four steps that you need to do in order to complete your aries process. The first is send a connection.

B

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 no from your server.

B

um 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 uh source and schema. uh We don't know what kind of server response means rejected or accepted from any given server, and we don't want to know what controller url we should even be aiming at uh for requests or what to do with the response. When we receive them, uh you can see these screenshots once we hit the key kiva api uh michelle. Can you just hit the next slide?

B

Please all right. um Once we hit the kiva api.

A

That's right, I think it is this one, because I was here and then I went here.

B

Okay, well, um then, we're missing an image, but once we hit the keyboard api, we actually need to transform a response uh into base64 encoding uh in order for our qr uh codes to render correctly and to be useful for our mobile agent, which you'll see in the demo later um even more simply we have a method for saying is the response uh is the definition of the response connected and it's just checking this the uh response to see if certain attributes are available and if they are, we say. Yes, it's accepted.

B

If certain attributes are another way, we say it's rejected and then the ui can change based on those responses. um So, armed with this knowledge, what should your final product look like and I'll have michelle field this one because she's the senior engineer- and I badly need my own cup of coffee now so take it away. Michelle.

A

All right, so we have a uh which is probably what you came here for um so I'm just gonna start it up. uh We have credential issuance to mobile uh wallet app.

A

um We also have other authentication methods like um we were using this to take uh fingerprints, so biometric data can be used as an authentication method or sms otp, but I think this is the clearest way to show uh what exactly is going on, because we have a wallet over here on the right which is like you're held on your phone and then there's a web sdk where we're just filling out some of this uh information like uh pii personally identifiable information.

A

Michelle are you sharing your screen? Is it I'm sorry this is. um I don't know why the um the screen share cut out.

B

A

Sorry about that, so should I just I guess I can just go back here. um We actually have 30 minutes, so I think we'll be okay.

B

A

Yeah um so, uh but you heard everything I said right, yes, okay great, so uh I can actually just go: go through this um and actually talk about the consent screen. So we have a consent screen here. um It has all of our personally identifiable information that we we ask the user if they are willing to share that with the institution that wants to issue this particular credential.

A

And so you know we have the ability to capture an image or upload an image uh fill out the credential with the person's pii.

A

B

A

I should actually full screen this, um and then we get a qr code which allows this mobile wallet on the right uh to form a connection with the web sdk and make secure messages between between the mobile device and the web. Sdk.

A

And so then the credential pops up and you hit accept.

A

And then it pops up in the wallet- and you can see all of the fields here.

A

And then, when it comes to verification, uh it's a similar sort of workflow, but you know we, we use the verifier tool, uh grab, consent from the user and then uh scan a qr code to form a connection again because um we want that consent every single time.

A

um And then we just run the proof request and then uh it shows up on the mobile app side, but it also shows up on the web sdk as well um and then uh yeah. We built our own registry and this is not part of the uh open source suite. But um it's it's that aries protocol supports. So you know we have a credential, revocation and a few other features kind of in the works.

A

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.

A

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 um and perform ekyc 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 um we haven't tested this on the ground.

A

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 back-end that keepa 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.

A

The system also supports multiple languages. I think nate mentioned that before, but um you can only use one language per deployment and then um so you can't switch languages using a drop down menu. For example, uh we we have created different credentials and proof types such as checking whether 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.

A

So you don't need to know a person's age, but you may just want to know that they're above 21 for example, um so 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.

A

So um 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.

A

um So we finished with uh quite quite a bit of time to so.

B

Helen actually responded we're actually one minute before the end of our session. So okay.

A

B

A

Nailed it right on time.

B

Awesome um sorry that there's not very much time for questions but, um as we said, please uh check out the github repos and uh feel free to reach out to me and michelle um on you know the web somewhere we'll be happy to feel the questions. So thank you so much for attending everyone.