The good afternoon. Well, I'm Jose DeMarco. I work for the Department for Digital Transformation of the presidency of the councils of the Minister of the Italian government. Yes. Really. And today I want to talk about the Italian digital identity systems and in particular about the trust infrastructure, the requirements we have satisfied with our choices and many other stuffs.
And two days ago I had the pleasure to do a presentation about OpenID Federation within the OpenID Foundation workshop where I have delved more into technical details and also general properties like delegation of trust and transitive trust. The today I want to ex talk about the benefits and the problem I have solved in Italy and together with other colleagues like Francesco Merino that today is here with me. He works for the National Painting Services, which in Italy is a supplier of the Ministry of Interiors.
And also Francesco wants to share with us some insights about the registration service for the public and private relying parties and the performance of the infrastructure currently in production. First of all, I would like to provide some insights about regarding, regarding the Italian scene, I would say, and the current configuration of the digital identity system In Italy. There are two digital identity system based on well established the technology like ML two and Open Connect. The systems are respectfully known as with the name of speed and GID speed.
The one from the left is a public digital identity system managed by a governmental agency called aji with identity providers operated, sorry, operated by private organizations. It has adopted ML two in 2016 and in 2022, along with another digital identity system called GID, it announced the adoption of open ID connect. GID is the public digital identity system linked to the electronic identity card that allows all the citizen processing the identity card to authenticate to remote public administrative services.
The implementation in ML two bot speed and GID was not compatible between them.
Only with the adoption of of open I connect, we have introduced, we have realized compatible implementation that allows the same implementation of relying party to work with both system and, and therefore to get out user authenticated to both speed and the GID identity provider. Another point in common is that GID and the speed are both identified as European Digital Electronic Identification Scheme. And today only GID went in production using Open I connect. Speed is still working on ML two, even if it does announced the migration.
I would say two years ago the news from Italy is that two months ago, all legislative decree as defined a digital identity system based on wallet technology. But therefore there will be other leg regulation that will continue establishing the IT wallet system. And we will be glad in the future to share here some updates.
In this slide I have depicted the evolution of the digital Italian, the Italian digital system on, yeah, it's a timeline and today I want to focus exclusively on the decision made in the context of of federated infrastructure of trust and in particular in relation to the things that has characterized our implementation using on Open I Federation and well Open I Federation is a technical, is a technical specification.
They show us how to evaluate the trust from a technical perspective because the term trust may mean many things and is a technology that allow us to build a scalable trust infrastructure. When we, when we delved into Open I Federation, we was looking for the resolution of some common problem. In particular, we was looking for a method to publish or make publicly available the metadata of the line party. We know that Open ID connect discovery only covers the metadata of the identity providers or would say Open ID providers and also open id.
Dynamic client registration allow dynamic client registration only provide the, the schema of the metadata in the parameters to be included over there, but they doesn't, they don't provide a well-known endpoint where their metadata of can be provided and also a way to create a federated ecosystem, therefore distribute how to distribute sign metadata and also a way to provide any other additional information of administrative nature.
And not only con concerning not only about the technical capabilities, I would say, and therefore when we have started implementing federation, we have learned many other things because even if, if we were looking in something that I have just summarized, we have also found a way to create a federation that uses term intermediates. Therefore a way to scale the registration system and avoid a single authority that is forced therefore to register all the participants.
And also another way to about the scalability, a scalability that is about each participant, because each participant is able to join two different ecosystem and multiple federation without changes its configuration.
Something completely different from the experience made with summer two, where speed service provider should have change its metadata and configuration to join into the GID Simul two federation. In addition to this, a single entity configuration that's the federation metadata can carry multiple metadata.
Therefore a single entity can provide relying party open ID provider resource server metadata in a single well known that is also signed. And the open I federation is flexible because it allows us to create custom, any kind of custom metadata. Therefore it can be used even outside of open ID and o out to zero. And there is also a way to provide a sort of verifiable assertion that allow us to divide the administrative information from the technical capabilities.
Therefore, we was able to, we were able to define technical capabilities into protocol specific metadata and all the administrative and bureaucratic information related to the status within the Federation of Identity using trust marks.
This allow us to use a very good design.
And another very interesting thing that well, each participant is allowed to change their metadata without passing again through the registration services because the metadata can be the same for multiple ecosystem and each ecosystem can force some changes to the metadata of this participant in a dynamic way without requiring the, the implementers of that entity should have made change. On, on, on, on the metadata.
On the, in this slide, I want to represent two models. On the left we have a typical star architecture that, well, it's centralized. We have a single entity that's a trust list. Therefore the, the federation authority and the trust list collects and publish and made available all the information of all the participants. In the right we have distributed and hierarchical model where we also have described the three trust anchor corresponding to the three Italian federation.
And below them we may see different several intermediates and therefore in the bottom the leaves, the so-called entity that implements protocol specific features. This represent the way we can scale a federation in a hierarchical way and the way we can distribute over multiple trust anchor that may share the same trust framework or not. Another thing that made concrete using Open D Federation is the metadata exchange.
The metadata are verifiable, cryptographic made verifiable and can be dynamical dynamically changed according to the trust framework as mentioned before, without requiring the implementation to do some particular change. And also security because each metadata therefore is updated when the policies changes within our federation. And here I would like to give you an example.
Let's suppose that signature algorithm made became weak or unsecure and therefore, well, in the old world, in the summer to World Trust anchor should have sent thousands of email to each participant requesting the removal of that particular algorithm.
Using federation, the trust anchor just have to publish a metadata policy and in a certain time window this change will be propagated to all the participants.
And therefore in federation we have resolved the problem of no reputability of the historical signature because a metadata in a federation trust chain can be also verified in in the future when all the keys changed of all the participants and also of the trust anchor. Because the trust anchor published a registry of the historical keys. Therefore each trust chain containing a metadata of a participant can be verified, verified also in the future.
This allow us also to reduce the costs less bureaucracy in the old world every time the a metadata should have been updated with the new contact email of the technical team. Well the implementation should have been re-accredited or the registration should have been updated to from the federation authority.
With federation, no, every participant can do the whatever change they want on the, on the, on its metadata. And the security is Richard with policy and dynamic trust chain. And we have, or I have also mentioned the propagation about the, the changes related to the, the policies.
And therefore we, thanks to the meta data policy, we forced the relying party to not request more data than required. And we also was able to not reinvent the wheel because we have found federation otherwise we was for, we were forced to create a brand new directory with a bunch of signed jot and a creative way to distribute this. And why not using a standard or contributing to a standard has reduced the cost of searching or designing brand new stuffs.
And for this reason, I'm, I feel very grateful to our community in particular to OpenID Foundation because it allows us to join in, in, in the evolution of this specification because we, I particular, but I can say we believe that open standards are important and the value of the open standards is that they are standardized within open standardization process. And this means inclusion and also less, I would say less cost in security analysis. And here I would leave the floor to Francesco that would probably share with us more information about concrete benefits.
Thank you. Thank you Giuseppe.
Good afternoon to everyone. Well, hi, I'm Francesco Merino. As Giuseppe said before, I work for the Italian National Printing Office and we produce the main identity document in Italy such as the DE card passport permit card and so on. And we manage also the DJ identity, which is based on the DE card. And we are also involved in the new, new DJ identity wallet ecosystem in Italy. But today I would like to tell you a journey into our world of digital identity and trust framework.
Well, until one year ago, more or less, the world of our DJ identity was based on, I would say not really efficient trust framework. And the integration and the deployment was not so easy. It was based on bilateral communication, usually via mail. And so you can imagine how slow, how painful or I would say so very time consuming. It was. So we decided to, we managed the trust using a central federation registry, but we realized that it turned out to be, I dunno, like putting everything into overstuff at suitcase and, well, it doesn't scale at all.
So the metadata was bloated with mixed sub configurations for trust authorization authentications. And the same for administrative and technical process.
All the, the administrative and technical process were coupled whole coupled together with a lot of bureaucracy within the technical stuff. So there, there was no co way to describe proxy within federation. And last but not least, I would say the cryptographic material, the same key were usually be used for everything.
So image, you know, for example, like it's like, I dunno, used the same password for all your account, you know, it's little bit problematic. Well then we decide to, we decide to adopt open federation and last year we developed a trust anchor based on opening federation and we integrated into our, into the backend of our onboarding system, which interacts with the front end of the, of the web, web application, which acts as a user interface for all the organizational entity handling both administrative and technical staff.
Well, so the the this user application is well is able to manage all the, all the administrative staff. For example, the application submission for federation membership for relying party or other entities.
And this, it still is a know, a user manual interaction is entered by manual interaction between the system, but it happens only once at the very beginning on the registration process and the rest of the technical stuffs. Technical tasks are completely, are fully automated. The system is able to check automatically all the, the, the, the staffs and generate the support in each statements and the federation trust mark for the entity without any usual any additional user interaction with onboarding system.
The same applies for the intermediates that can request for the membership and obtain all the subordinate statement and, and federation trustmark. And when the interate is registered well is it is allowed to register by itself all the relying party you want at the same way without any additional interaction with the onboarding system. So the delegation of trust that we can see here is very, very important 'cause it makes our system really, really sc scalable.
Okay. So what have we learned by our experience?
Well, first of all, scalability and automation of registration processes are probably the main outcomes we achieved. This is thanks to two main key factor, probably the degradation mechanisms that I mentioned before and the federation web services that led us to some quite impressive results. I would say on the left hand side, you can see the relying parties that are directly registered by the federation trust anchor by weeks.
On the, on the right hand side you can see the relying party, which are directly registered by the federation intermediates. And you, as you can see in just one week, an intermediate was able to register more or less 500 relying parties in the ecosystem.
And we have also more or less 50 relying party registered weekly by the trust anchor as well.
And I, I, I would say that I don't we without federation, I think that this would never would be possible or something like that. So let's break it down even more on the right, on the right hand side, we can see the total of reliant party from the beginning of this year to the last month. And as you can see, we, we have 2000 relying party year to date with our average growth rate of 8% is very, very good results. And by November, 2023 until now, we have over, over 2,600 line party in product production.
Some of them are registered by the trust anchor and the others are registered by the intermediates. We have 10 intermediates within the ecosystem and they was able to register 1000 of reliant party autonomously.
Well, there is another important lesson that we learn and is about transparency. Sorry.
Okay, this one I,
I'd kind of like to hint on the time a bit Sorry, the time, so time
Yeah, yeah, yeah. I finished.
Okay, this is the last one. So the, the last, so the last lesson learned was about the transparency. The federation is publicly available and navigable by anyone through the federation. API for example, I was able in few line of code to see inside the ecosystem by just fetching the listing point of trust, anchor and intermediates and the result you can see on the right hand side.
So conclusion, I could say that the, so this journey from I would say blurry trust framework to the one based on Unity federation was are, are revolution from our point of view, this is due to delegation mechanisms and federation and point that makes scalable, makes efficient and transparent old ecosystem. So when you think to the trust framework, remember that it's more gen, it's more than just making client server able to authenticate each each other in a secret way. It's about creating scalable, transparent, and efficient system that can handle anything in the future process. Okay.
Perfect.
Thank you.
Thank you. I think this was very insightful. Raise your hands please for this presentation.
