Okay, so good morning everybody. I'm Mattia Zago and I'm working as a solution architect for monarchy.
Okay, today with me today there's Matt Mateo, please. Matt Mateo.
Thank you Mattia. Good morning everyone. I'm a Mat Meina. I'm a a self-sovereign identity specialist for monarchy and today we will play a role game.
Amazing. So let's say that I am the classic identity and access management that you all know and love and perhaps you have already implemented in your enterprise. Okay? Matteo on the other hand will be the new guy.
Yeah, thank you. Mattia. I will represent what for us is the future. So I will the decentralized guy. So I will talk about the centralization of data and identity.
Okay? So let's see if we can work together and combine the legacy world, the one that we know that's there and is working with something that is coming and we believe that is coming. Let's see if we can move from hybrid identity and access management.
Sorry, from classic identity access management to hybrid identity and access management. So let's start from the beginning.
Okay, so let's start from identity actually given the fact that we are almost at the end of this conference. Let's start from the end. Identity and workforce identity. So click mate, workforce identity. We are going to talk about those identities that are persistent throughout the life of the user. We're going to talk about trust, we're going to talk about central authority and centralized control. This is from my side. On the other hand, the future is coming and Matteo will talk you about the verifiable credentials.
Yeah, exactly. We are also to talk about very fiber credentials.
So Mattia, you know like me, that with this technology we have decentralized solutions, we have solutions that are not tied directly to some technologies and you have explicit trust and you can put data directly to user ends. But however, to be more precise, we are here to talk about interoperable very fabric credentials. So what does it mean? We wanted to see if we can answer to these questions. So I want to ask you if you can remember these questions because they are the goal of our journey.
We want to see if we can have a solution that is tech independent, if we can put the choice to the users and if we can do it in a cross compatible way and yeah, if, if we can have an easy integration.
Okay, so let's say that we are going to move toward the hybrid dent in access management and remembering those questions that will come back at the end. We will go through central authority and central control but still with use our own credential that are managed by the enterprise.
Okay, so this time, let's start from the beginning. You know that an identity access management is an orchestration platform at the end and bear mind the orchestration keyword will come back because we are orchestrating between multiple identity providers, perhaps internally such as, I dunno held up or it can be external with different technologies. We have some elements of governance and we have perhaps something like privileged access management. Okay? At the very core of it, there's a single sign-on, single sign-on.
Of course you know better than me that has three major actors, the user identity provider and the service provider. The link between the service provider and identity provider is the classic federated single signon protocol. You have some or out open and de connector and whatever you want on the user side, you perhaps you perhaps have password with or without multifactor authentication and eventually you will have password solutions such as fi.
Okay, so Matteo, I'm pretty sure that you know what we're talking about, right?
Yeah.
Mattia, I see your point of view but you know, I think that we can do better. What do you think about web free and SSI solutions?
Well, on the paper I can say, I can say that they are wonderful, they are more secure. You have data serenity, so you put data in user hands and they become identity provider of of himself. And if you use open standards, you have a solution that is more interoperable. And if you decide to use a public blockchain, well you can say, you can say sorry, what the reason on the on the chain and more important we have a solution that is already compliant with the SSI philosophy and I can say in two words that we have a solution that is truly decentralized. I have a question for you.
Where will the verifiable credentials or presentation fit in your model?
Well thank you for the question indeed. This is a question for the audience because we have three links here. The first one could be the one between the service provider and the identity provider. So if you click, we know that this cannot change, we're not going to add new standards, come on. It's something that has been there and it's working.
You have some, you have out, you have open connect and you have people more important than us and very skilled that are designing new solutions to adapt this protocols to the self-sovereign identity world. So definitely we are not going to change that. But Mattel, what about changing the other link from the user to the service providers or using the verifiable presentation directly to connect to the services?
Yeah, I think it could work, but maybe all on the paper there are some problems that we can ignore. Mattia, we put a lot of responsibility to the users, so we need more conscious users and if we decide to use a truly centralized, sorry, a true self custody model, this implies that we don't have recovery options. So this me, this means also that we have no central authority, so we don't have an actor in the middle who can make decisions for you. And the most important one I think is that the, that an integration could be very expensive.
So at the end of this, yeah, it's really similar to the pure SSA model, but maybe it'll be ready in a future. Yeah,
Indeed probably will be ready in maybe in new time in which something that we will have. So the only thing that's left is to put verifiable presentation, a verifiable credential on the link between the users and the entity provider. Let's them try out the technology, let's them, let's convince our customers, our clients and our workforce that they can use this new marvelous technology. It's something that this can, in your mind, can work.
Yeah, definitely. I think it could work if you think you have a solution that is passwordless is distributed, I think if quite flexible and you put the choice to the users.
Yeah,
Indeed. You know what, what I like, I like that the architecture doesn't really change because it's still the same identity and access management except this time it's fully hybrid because we supported the centralized technology. But tell you what, because is it something that we can implement today with our current technology?
Yeah, Mattia, I can tell you more and spoiler alert, there are not only Sovereign or Hyperledger in these solutions, there are other examples on the market that work well that are ready. The first example could be a solution that combine Meta flask and SSIS app from blockchain lab. The first one is the most famous Ethereum wallet on on their networks and on on IF networks. And the second one is a map that you can install on meta. So basically you can store verifiable credentials on it. So you can use them for, well, whatever you want, you can use them on chain or off chain, it doesn't matter.
And the second example could be this one from Polygon EM three Polygon is one of the most famous layer two on Ethereum. And item three is a company which works with VE knowledge proofs. So basically they developed tools like Silk or che Yes, that well make life a lot easier with the video knowledge proofs and again you, you can use verifiable credentials for whatever you want on chain and of chain verification.
Yeah, so at the end I can say that it works. Basically the, the idea is we have a standard, we have, we have a, we have a web free wallet. So I can say at the end that we have a trusted and verifiable authentication method. So this convince you
Yeah, I'm not there yet.
Sorry, let's try it again. I mean how does this work? I mean I know that credentials are a standard and for me there are just another format as XML or whatever we have at moment. So there simply just object, what am I missing here?
you missed the, the most important piece of information, the proof A proof makes verifiable credential verifiable. So basically the data is why we can simply use a wallet signature to sign a JW T and put it in a credential. So basically the is we, we have the pair from which we can derive decentralized identifiers. So now if more clear?
Yeah, okay, let's walk through it again. We said at the beginning that the single sign on works with having an actor that wants to access a service provider and the service provider sends back the the, the link click sends back the link to the identity provider with A or open ID C connect or open Id connect protocol.
But what now, I mean at this point we should ask the user something
if fear that the magic happens because now the provider could simply send the verifiable presentation request to the web free wallet and well it, it can simply do that using dcom protocol sends the request directly to the to the wallet or why not? It can simply ask to the user to type the presentation directly inside a textbook. It doesn't matter. The second step is well the user needs to fulfill this presentation and how can do that? Well it can simply put take a, sorry, can take a credential from there.
Another one from here. Again, it doesn't matter. I
Mean you need to trust them, right?
Yeah,
Obviously. Okay, yeah obviously then the user sends back the presentation response to the identity provider and here the identity provider needs to decide if it can trust the user. So then and only then the provider sends back the response to the service provider Now it should be definitely more clear.
Yeah, it I have another, another last question for you. What about interoperability?
They, we talk about it at the end at the beginning of this speech, but we didn't go instead of it. So what do you think?
Yeah, indeed. Interoperability. So what about interpretability? You basically said four questions that yas need to remind and was that, could we find something that is technological independent that let the user choose and pick which solution they want to use? They cross compatible and it's easy to integrate. So please bear with me. Do we have an answer to these questions?
Mattia, I think that if you really understand what I was talking about, now you are able to answer to this question. So please try trade out.
Oh okay. So technological independent, well we can use practically any solution. It can be epilog, it can be checked, it can be any solution that it's based on a single standard. So I guess that's the, it's definitely technological independent is the choice in the user hand?
Well no, it's the choice is in the identity provider hands because they need to decide which technology they support and what do they want to implement. Is it cross compatible I guess?
Yes, because at the end the user can use whichever credential they want from any given sources if the identity provider trusts it and it's easy to integrate but definitely at least perhaps not easy but straightforward and not so expensive of changing all the service providers. So definitely yes. You know what, I think that the key here is not to take at these, take a look at these independently, but is to go and have a look at the, let's say as an outsider view. So the key at here at the point is identity orchestration and what you think Matteo is the key identity orchestration.
Definitely the key is identity orchestration.
But speaking about orchestration, we are, we know that today there are softwares that can orchestrate because it's nothing new. I mean there are orchestrator in all different solution and all different technologies at this stage. You can take something like a user lance on a starting blocker and then needs to be bind to, needs to begin, sorry, to a session to perform the single sign-on.
So today you simply drag and drop the blocks and create input credential perhaps asking for a multifactor authentication and that will be the classic identity access management approach. Perhaps you will have policies and governance, but if I understand you correctly, and I think I do, your idea is to move from this one to something that is the hybrid identity and access management from which we will stop asking credential, we will stop asking for password. We will stop asking for multifactor authentication and we will start ask via did com or via web three connections for ssi.
We will ask for verifiable credential via proof requests and we will ask for verifiable attributes that we can use to claim and bind the identities to emeral sessions. At the end we will reach always the same endpoint, which is the beginning of the single sign on protocol. So if you understand this correctly and you are aligned with me, we agree that the key is the identity orchestration that's the way forward. So that will be it for us and thank you very much. We will be taking questions.
Thank you. So do we have any questions from the audience?
I just put it in the qa.
I mean you are combining thousands of different thousands, but a lot of different technologies. So
Committee .
Thank you. So how would you test such a solution? It must require thousands of test cases.
Indeed. The point here would not be to test each one individually, but would be to have something much as the certification process that several standard have. Like think about the open-end deconnect. If we have a test suit that is designed to cover all the different aspects of the protocol and the data model, we can say that we are aligned to that.
Then it's a matter of the issuer and the wallets to conform to that standard. We will be the end receiving, sorry, we will, we will be the receiving end of the technology. So as soon as we offer an interface that is standardized and can work, then we don't need to test for all the different options.
This, this answering question. Okay.
Any other questions? Good. So we leave it at that. Thank you for your presentation. Thank you much and this is your applause. I hope.