Managing Self-Sovereign Identities as an Institution with Lissi

Hello everybody. My name is agan I'm from the main incubator. We are the research and development unit of commerce bank. We have been looking deeply into the topic of self identity, decentralized identity in general, over the last three years.

And yeah, we kicked off with a lot of other, other partners developing software and yeah, getting, trying to figure out how this concept works and putting it into practice. And that's, that's where the name Lucy actually comes from. And we said, okay, we want to make this big, we wanna start something which gets rolling.

And with, with us, the main incubator now heading the I union coor and being involved in other yeah, big broche as well. I think we are really much, yeah. Being true to ourself and our mission to kickstart the development and the whole ecosystem. And today I wanna give you a brief look into what we're developing. We're developing two aspects in regards of our target audience. One is for the institutions which uses software in order to execute use cases.

On the other hand, obviously we have the least wallet for end consumers, which then use that in order to interact with the institutions on their parties. And today we wanna focus on the institutional part. So I wanna show you how it works in practice. So first the first amendment, I'm gonna show you some practical or theoretical backgrounds behind that, what we are doing actually, and how it works. And afterwards, I'll show you her practical demonstration here inside.

What, what the, of the, the program actually looks like. So let's jump just right in. I think most of you are familiar of within the different interactions with the ecosystem and, and most are familiar with the first triangle.

And here we see it a little bit different with the main street free stakeholders, the issuer, the holder, and the verifier, the issuer being, for example, emergent, a company where byproduct and you get a receipt, for example, it can also be a public institution like a university, which issues your diploma degree, or yeah, a government stakeholder, which gets you, whatever permit, for example, you, you, you're looking for, and you can all store this kind of different credentials in your wallet.

You as an end consumer have, then that this kind of management application in order to manage this kind of contact, but also the credentials itself. And then obviously we want to present these credentials to third parties as well, being emergent or whatever third party needs this kind of credential in order to give you access to something or execute a use case.

And we have the Lucy wallet for the holder, but for the other parties, for the issuer and for the wire, we have, we also need, we need software in order to execute these, we need software, we speak the language, the protocols, and make it easy for institutions to communicate with the consumer. And that's where our that's where our leasing institution agent comes into place. So it's mainly focusing on issuance and the verification part of it. And when we take a look into the verification, you have different kinds of verification because the information that could also be self attested.

So we not necessarily always need to ask verified information. For example, if you ask for a delivery address, then the person might be not at home, but at a friend's place or for, from girlfriend wherever. So they cannot actually provide verified information or also about food preferences. When we are, when an airline ask for if, how the meal should contain meat, or if it's vegan, we're not, that's not something we should ask or we need to ask for verified information because they're self attested.

And, but also there are other clients which need to be verified. Obviously, if you take want to open a bank account, we need a, we need to do the KYC to know your customer process, where we need a verified ID from the government, but it could also be that you say, okay, you need just the information of a certain threshold, for example, that you're 18 or older or your potential landlord who says, okay, I need a, I need a information that you yearly income is above 30, 30,000 euros, for example, but you don't wanna provide the exact numbers on what you actually earn.

So that's something which we call a serial knowledge proof where you can actually provide information and just say, okay, I I'm above a third threshold or below or equal to. And then the third, the thing which you see below is the verify data registry we use, I union for that. But in general, you can, there will be a lot of networks which will be used in order to verify the authenticity of credential. So this might be also be the European blockchain service infrastructure or any other network like Alaska in Spain or others in Europe or outside of Europe.

So the leasing institution agent is a rather generic application while we developed it with the needs of the commerce bank in mind, it's also applicable for other sectors industries, for example, the finance at this insurance industry, public institutions or universities. So it's, it is actually managed or developed that you can develop your own use cases, regardless of what kind of needs you have.

However, it's specifically targeted for big corporates. So it's not necessarily maybe the, the best fit for our small enterprise.

We also, you, you offer a user interface so you can actually click your way through it. So you don't necessarily need a technical personal in order to, to manage it and execute use cases. That's something which we got our feedback is also very valuable for our customers.

However, obviously we also offer the integration via API endpoint, which the end connect to your backend or your, to your customer relationship management system, whatever you're using. So basically that these courses just work on, on a bigger scale instead of doing that manually.

And we offer that on premise, meaning that we just give you access to our dock hub, and you can run that in your own infrastructure, which is obviously very important giving that big enterprises, not necessarily want to also want to use software a services for all these different applications, but rather be independent, hate to have data sovereignty over their own infrastructure, their own environment. And that's what we're offering with our institution agent. In that case, we, we make it possible for, to implement these use cases, use the centric by default because the user has their wallet.

It might be the wallet might be any other wallet, which has supports the same standards. And so they automatically put the user in control, but the company is in control at the same time. And we can establish direct customer relationship with that, meaning that we have a encrypted communication channel, which a company can use in order to send information or request information from a user. And also the whole topic of data sovereignty, which, which I mentioned already is that not only for user, but for the company and also this whole topic is privacy enhancing.

Not only that we'd follow, obviously the GDP, the requirements, but also offer a selective disclosure for example, on and see your knowledge proof so that you only need to ask for the information or can constructive the information requests according to your needs, whatever information you need from our customer. And we offer custom UI branding. So if this is something which other people might see external personal, what, for example, then you can adjust it to, to your needs regarding to the, to your user interface for pointing solar, put your logo or your brand behind it.

You can create this kind of encrypted communication channels, this we codes or links. And we also have the, obviously the credential issuance, these might be via established connection already, or that you say you have a connection, less connection, credential issuance. And we have also connections, also images for these connections, also these credentials.

However, these are not standardized yet. We're working on that, that we make sure that these are more compatible and with other software providers as well. And we also offer these kind of Medicaid. So knowledge proofs, the proof requests that you have filters and constructs are on demand, and also can send us these via connections or connectionless. And we also offer that option to be have reallocations for these kind of credentials. And with these, we have a lot of different use cases.

As I said, we work, we mainly work together with the stakeholders, with an ID union, where we have worked together with a lot of big corporates, which use our institutional agent to implement pilot use cases and from different sectors it's could be, for example, the educational use cases within a diploma use case, for example, could also be something in an identity access management system where you're giving a signal sign on credential to a user or anything else, which you can imagine. So it's very easy to implement different use cases, depending on your needs.

You can construct it however you want, and that's it from a theoretical part. So yeah, if you want to learn more about the application, the application, what we're offering, we offer our institution agent for test purposes for free.

So yeah, if you would like to get to know this and experiment with it, without any strengths attached, you can use it and yeah. Just get a feeling for it. If you suit your needs. And at this point, I would like to be, to show you some more, some more detail, how that actually works on a practical level. I have here and left side.

I have my, I have my institution agent. And on your right side, you see the phone now, which is now the Institute, the list wallet, as I said, it could be any other wallet also, which you can use. So on the left side, we see here, the dashboard, we got the institutional side and on the right side, we have the end consumer, which then communicate with each other. And here we have an insurance company, which we set up as a demo agent, which we use for demonstration purposes.

And you see the, the different kind of connections, which we established already, the credentials, which you issued and the, the proof or information requests we received, we can very easily create new connections here. And I have an overview of the different kind of connections, which have already been sent out to the user or also be accepted. And we can do that pretty easy right here. So I can just create a new link I'd say here, Adrian, and create that.

And I, here I have either the option to scan a core code or could just copy a link, which is then a DICOM link, which I could integrate on a website, for example, or an app. So basically this is very easy that you have both options. And if you open a DICOM link on a, on the phone, the operating system automatically recognizes the link and knows which kind of application your on your, on your phone can use it and, and, and speaks the language of it. So basically it shows you the different wallets which you have and can use it to, to open this kind of request for the sake of simplicity.

I just, I just use the choir code here and we see that the most. So the example insurance wants to connect with me. I can accept that. And he'd also asked me if I want to automatically accept future requests from, or a connection request. I say at this point, no, it's okay. And now we've already seen here a little, little, right? I just get that done already. My phone just went away. Where's my phone. I me check. And here this square code, as it's really easy to, to implement that my phone doesn't really want to connect right now. I'm not sure why, but we figure it out. No worries.

And now we can also, we have this established connection, which we can use now, in order to exchange information in general, here, we have three more columns here. This below is the so-called schema. Schema are basically the sum of all attributes, which contain, which credential contains. For example, the ID card in Germany, it contains 13 different attributes being your, your name, your surname, your address, and so on. And the sum of all these kind of attributes is the so-called schema. And here we can create schema here. We see already something which we implemented.

We can also based on these schema, we can then create credential definitions. For example, if we have one schema created for credit card, then obviously we have a lot of different companies, which issue credit cards on the same schema, but they all create their own credential definitions in order to be unique in that regard and, and the credential definition from dogie bank, then it's obviously different from commerce bank, for example, and here we have different credentials.

I just, as an example, would like to implement here already an employee card for this insurance. Now, I just hope that my phone sparking and I send it here, I can hear send it to our connection. We see here that, that here, this connection is here and I can implement it now, different information here and write it in, basically that automatically for demonstration purposes, I'm writing that here right now And insurance. So this is then issued by the company as a credential to, to the employer. We see here on the wallet, we see the one and that's what we were saying. Okay.

There's something in the wallet we have. Now, the insurance card being issued here, I can take a look what's written in there. What kind of attributes and say, okay, nice. It works. And my screen copy doesn't work. So this kind of credential now is in the wallet. This is bad. So we see it here or not.

Oh, is it not working? So we see the, an insurance company card here as an employee card. And now we could go to another institution, for example, this is now Moosa store. We are like having a store now, which we, we use to interact with, for example, would like to buy a product. But we get, as, as an employee from the insurance, we get a discount for example, 20%, or we want to access their, their internal Porwal. And we can't do that from, as an employee from the insurance. The thing is that this is a totally different institution and they might not necessarily know each other.

However, that's a good thing about identity. We just need to know the public key of the institutions, which issue the credential, and then can verify the, of the employee card as a, as a third party, which is not directly connected to the institution which issued this kind of credential. And this is the nice thing that we can, for example, verify employee cards or membership cards whatsoever as the third party. So what we do here, I created that proof already and insert it here. So can just insert this proof request, do it. Connectionless I'm scanning the I'm scanning this right now.

Hopefully my wallet will work now. It doesn't really want to, so it's always a good thing about demonstrating something life. You never know what's happening. So basically what I'm doing is scanning here, this kind of art code, see this information request and see, okay, they want this kind of information with me from me. Obviously I can say, now this is not GDPR compliant. Why do you need the date of the, the issuance whatsoever? So I could also say, okay, let's just ask for the, the employer, instead of all this, the different kind of information, this will also be possible.

So depending on your needs, you can of construct it according to your needs. And now I'm verified that as a store from a different third party, meaning that we can grant them access to our internal employee Porwal or give them 20%, which they get as a discount. And that's how institutional agent works very easy in terms of creating these kind of proof requests, scheme, masks, and clinical definitions, and connecting that with your backend in the cooperative world. So that's it from my side. Thank you very much. And if you got questions, I'm looking forward to it.