Hybrid Central/Decentralized Identity: Deployment Strategies for SSI

So welcome everybody. I'm Mattia oh, thank you. This is this working. Yeah. Okay.

So yeah, today, as I said, we are going to talk about the hybrid centralized and decentralized identity and the development strategies that we in monarchy are actually putting in place as an orchestration player to, to bridge these two, two different words. We have a demo. So if you want, we can, you can play with it. You can download our wallet or use any SSI compatible wallet with indie or based on Hyperledge areas. So what's monarchy.

Well, I'm working for them as an solution architect. We are basically a Italian scale up.

Well, I would say European now that's been trusted by half million user. We are certified open ID scheme Fido, well actually working on fighter and we are partner with CD for the S sovereign, actually from sovereign part of the D D I F member. And as of today, we are also in the steering committee of the trust over IP foundation. I want you to focus on three topics that are security, the compliance, and there is management as they will be recurring topics during my, my presentation today. So as I said, we have a stand an edema.

So if you want to have a chat, just please pass by on the upper floor booth number 38, right in front of the knot floor, they cannot room. So I guess this is to assume that everybody here knows what an identity and access management solution looks like. Just to recap, we have a user that this laser, yeah. We have a user that use an identity element to access different services. Okay. Since this has been around for quite a while, they are known to be stable, widespread, and interoperable, and we all know that there are different standards and protocols. Okay.

And it's safe to assume that practically every single vendor supports the vast majority of them when not all. So what's good about the centralized identity?

Well, they are power powerful, definitely in the sense that they've been around for the best part of the last 10 years, the centralized management enables some of feature and controls over, for example, compliance or the, the security status. On the other hand, though, the fact that you've been around for so long, maybe implies that they are difficult to steer in another direction.

So they are consolidated and eventually fossilized the fact that they are centralized management, they have centralized management features means that perhaps they are this single point of failure where every single attack passed by. So the return of investment for an attack and obtaining, for example, a data leak comes from precisely these this point. So we're to go from, from here, we have been talking about the centralized identity and now the federated with let's say the last couple of years, but the future, the future is going somewhere else.

So let's take a step back before actually going to look at the future. And let's talk about a little bit, the flow of a centralized of federated solution we'll know that a user have different identity according to the different identity providers. And in general, we have a module called identity governance that dictates the rules for the providers, and eventually the authorization source that provides the policies to be evaluated by the service provider so that the user can access the different applications regarding the security compliance and risk management.

Well, even if it's a single point of failure, we can have huge investments on the service provider and the identity provider, so that they act as a protect gates. That can be, let's say they can enforce specific rules and prevent access to an authorized third parties. So they are certifiable in some sense, in the sense that we can prevent access to this solution, to these sorry, resources and assets, and we can comply with standards and regulation. And also from the risk management point of view, everything is basically well known.

So we know which threats model we have, we know which are the actors, and we know how to model this. Okay. So it seems a pretty good solution overall. And that's why the industry standards are focused on this.

However, we know that the identity providers and service provider needs to have specific and strong, secure connection between each other, which in turn are exponentially growing. When we are the new identity providers and service providers. And also we know that from the theory, we cannot have something that has both the property of being human readable, secure, and decentralized. We can only pick two of them in the sense that we want something decentralized and secure. It's gonna be difficult for it to be human readable. Okay.

So if this is a, let's say point of the state of the art for a centralized identity, let's have a look at about the decentralized one. In this sense, we have user that uses one or more wallet, which different and multiple identities, and is going to decide which one to use for every service. Eventually it can use more than a one identity to access the same services, obtain obtaining different resources. In this case, we will know that self-sovereign identities disruptive trustless and user-centric for nature.

And in this case, there are multiple approaches to these to achieve the, these objective. The main difference between them is practically on what kind of data we want to put on the chain. We have the check D and sovereign offshore, for example, where we only put the schemes and credential definition on the chain, thus enabling us a complete of chain solution, which we believe is the way to, to do things so ASI well, it's evolving fast in the sense that we don't know that it has been growing extremely fast in the past few years.

And actually the, the speech that came that a couple of friends give us during this week basically proves it it's user centric in the sense that it it's growing precisely from the user to cover the user's issue. And somehow is easy to model in the sense that we have less components.

However, easy to model does not mean that we don't have a complex infrastructure in the sense that if we want to start using it for real, the infrastructure is going to grow. Okay. On the other hand, we know that it might be hard to interoperate, as Marcos was saying just a few minutes ago, we have multiple CHES, not all of them are working together, and it's gonna be a difficult issue to find the standards so that they may interoperate.

And also depending on the type of distributed ledger we're going to use in my, or may not be heavy on the computation, however, nonetheless, the future is user-centric and evenly self-sovereign. And we in monarchy strongly believe about this evolution. So as we did for the centralized version, let's have a look about the workflow.

In general, we start with the issuers that put some credential, schema and definition, perhaps Vian, endorser, but not necessarily on a distributed ledger and then generates the credential for users so that they can access directly the decentralized applications, which have internally an authorization source. And then the access to the service. They may or may not use a specific Oracle to access external data that are not on the chain, which led to potential to potential problem known as the, the Oracle problem.

And eventually we will have verifiers that bear mind do not take care of authorizing or not a transaction. They just check if the verifiable credential is actually in, let's say correct, and we can prove the integrity of the credential. Okay.

So from the security and compliance risk management standpoint, well, from a security point, we can say several things that also applies sometimes to the centralized word, better native embedded in decentralized one, we have this selective disclosure option, which basically permits the user to select which credential they want to use and which part of the credential they want to use.

And we have the credential also, let's say there are techniques called zero knowledge proof that I'm pretty sure you all know about that permits to prove some claims without actually giving information about the claim itself, which in turn enables some sort of circle of trust. That's called trustless trust in the sense that we can build frameworks without having a specific chain and without having a specific let's say derive the authority.

But on the other hand, from the risk management perspective, the big, the big issue here is the fact that most of the efforts are community driven, which is an opportunity because people like us, even as small as we are, we can steer and we can interact and participate at highest level. On the other hand, though, it's gonna be a financial challenge in the sense that the funding here is fundamentally given by volunteers and not only in terms of economic effort, but also in terms of human resources and effective application.

So let's put them together and see, let's go directly to the hybrid proposal that we have in the sense of, they looks like something that's completely aligned and on the opposite side of the, of the world. So how to hybrid them. That's the question that we are going to answer now, first point to not reinvent the wheel.

We have tons of services and tons of solutions that apply just we need just to update them and create some sort of hybrid identity governance that also includes the issuers and validates them by creating an authorization Oracle that can be used both by the service provider to access legacy applications, but also as input for the event or the centralized applications. So from here, let's go and integrated the technology. The first part is gonna be enabling verifiable credential to access the service provider.

And secondly, the identity provider to go to the decentralized application, let's start from this one. If we meet a verifiable credential through specific trusted issuer, then the service provider itself can use it to embed the identity of the user of the legacy user so that it can access both the legacy application via the flow that we see before, but also to link this identity and embedded it within a verifiable credential to access the centralized word directly over here, clear there's no direct connection because I would just overcrowd the, the slide, but that's the whole point.

We can mix them to use legacy, the entities to access the new, the new solutions. On the other hand, if we want to do the opposite, we can take the current, the verifiable credential for the users, and then within the service provider that needs to be of course, updated and basically evolves to a hybrid service provider. We can bind it to us an, an existing entities and an existing identity, or for example, to create an ephemeral one that exists just in time and specifically for accessing the legacy application.

So that basically this identity binder only needs to verify the credential is effective and comes from a trusted issuer so that the policy, the policies will apply and the user will be enabled to access the legacy application. So just to recap and close it a little bit earlier, there are, let's say two steps from federated where we are now to the hybrid world. And then from the hybrid to the sovereign world, start from the, the federated let's recap about security compliance and risk management. We want to propose actually.

And what we do as an orchestrator is practically to use and perform the authentication part with the self-sovereign identity in a sense that we will enable specific users to access the resources independently from the identity provider. So removing the identity provider from the equation, but we will do the authorization with plastic solutions in the sense that the enterprises will be able to control and perform compliance checks, but also security measure on the application and sales.

So again, classic AGA solutions should be considered and should be included. Sorry, the verifiable credentials should be included within the IGA techniques. And we will need a map, at least at the beginning between the verifiable credential and the identities okay. Where clearly the gateways will stay. And there's no way that they're gonna go away for now. So they just need to accept the collect and verify the, the verified credentials and clearly the selective disclosure and privacy by defaults needs to be applied everywhere. Cause that's it.

So from hybrid sovereign, well, that's a question for another day and invite you to come upstairs and have a chat about it. Okay. So I am Mattia thank you for attending and I am open to questions.