So good afternoon everyone. Thank you for being here today. I'm very glad to be here with you and to present this joint work with Jad Amir, I would like to thank them and other guys that participated to which, which are involved actually in this, in this project. So we will start by providing you some context and motivation, particular regarding the, the implementation profile for the Italian digital identity ecosystem. And then we, we will go into some tackling s with Amir, and then Jada will explain, we will show us some future direction for the, the digital, the European Digital Identity Wallet.
So in Italy we have two digital identity schemes. Basically we have speed, the public digital identity system, and CHI a D, which is based on the, the electronic ed card. And so we, as a national printing office, and Min, we handle the, the, the production, the issuing of the ed card and the physical card, and also the digital identity, which is linked to the IIC card. So last, during last year, we started by, we started an identity, a digital identity transaction from Samuel to protocol to open Deconnect. So there are several reasons beyond this choice. It's easy to integrate, it's fast to integrate, it fits better on mobile device, for example. It has a, it is a consolidated standard with a lot of consolidated specification and best current practice. So the, the, we developed the Italian profile based mainly on two pillars. The, the first one is the open de opening, Deconnect Igo profile, and also the related documentation from wealth as well and all the best current practice.
And we took from this, those documents all the security, they really want security aspects. And we put in our profile implementation profile how all parties involved in a federation system can reach the trust. Each other is typically out scope of the protocol itself, of the specification itself, of the standard itself. However, in the government use cases, this is a crucial aspect. That's why we came to the second pillar, which is the opening deconnect federation, which helps us to handle the, how to manage the, the trust between each parties of the Federation of Federation system. So we basically, we started from a problem. The problem, so is this, there are different parties that are involved in a federation and they share information about the user authentication. This is the problem. This led us to a need. They must trust each other. So a trust model is needed somehow. And we find out a solution which is based on opening the Connect Federation 1.0, which is basically AAR model of trust, I would say. And why, why we, why is it so useful for us? Yeah. Just because it's dynamic, it's scalable and it's a transparent solution.
And so it, it has a lot of, a lot of other nice properties that make the, the O Federation a good candidate also for, for example, the European digital wallet as well. So we, what we have done now, now we have, we developed an implementation profile, Ford C Core Federation. We de developed an provider in production in and the trust anchor in production. Actually for what I know we have the first implementation of federation and we are the, an enthusiastic early adopter, I would say. I'm very glad for this. And we are working on some other extension to our profile such as, for example, the for session management for native app, mobile native app and credential issuance. And we are planning also to include in our profile other specification like D assurance and financial api. We, we also develop some automatic tools that helps us to make some security assessment for relying party component or trust and core component or an intermediate component and so on. So I finished my presentation. I leave the floor to Amir to go into technical details. Thank you.
Thank you Francesco, for the, for the introduction part. So now I'm going to explain some of the security considerations that we put in the Italian Italian profile. So the first one is regarding the flow. I think everyone is familiar with the authorization code flow is the, the response type code is is the, it provides a best way in order to avoid the token, the token leakage. That is, you saw it, you can see it in the implicit flow. What authorization code, code follow itself is not, is not enough. So that's why we are adding the wonderful perimeter p in in order to mitigate the code, the code injection and coly attacks. That provides a way that if in somehow the code leaked to the attacker to avoid the attacker to be able to inject the code into a session and access the user's data. The third consideration that we had is the usage of the open connect request parameter.
So it provides a way to satisfy message integrating. And how it is doing it is, is like a single object that you can sign it an option, you can encrypt it and in this way you are avoiding tampering of the, the message in the, in the user agent by data hacker. And regarding some of the parameters that we have in the, in the request. So in order to enable the strong a strong authentication, we are using the c r values as we have three, three levels for the speed and two levels by now for the, sorry, and three levels for the, for the CHI andr values is a way to enable this different strong authentication methods. And for data minimization, we are using the claim perimeter of that is introduced in the open ID connect core and it was optional in the core, but as it provides a way to satisfy data minimization by asking the specific claims to be returned in the ID token and user influence point, it provides US data minimization.
And then we have the non and estate as a mitigation of csrf. So in the authorization response, in addition to the state, we had another best practice, which is the issue. Each parameter that is a countermeasure in order to avoid the mix of attack. And at the token and pointent, we are using a more strong client authentication method, which is private key that provides, as I mentioned, it provides a, a stronger way to ate the client at the, the relying party at the token in point I the ID token. So we are using the per voice subject identifier that provides a way to mitigate, to avoid users tracking using this parameter. We have the announced that as I mentioned is a mitigation for the, for both CSF and ID token reply. We have the 80 hash for detecting of injection of Texas token and JTI is another way for the relying party in order to avoid, in order to detect the reply of already process ID tokens. So regarding the access token, we are using the RFC 90 68, which is the job's profile for access token. And and the idea beyond that is that it provides a way for the resource server to be able to locally validate the claims inside the access token without involvement of the IDP or op.
And by the time we are not considering the send constraining send constraint method for the access token because by the time the only resource protected endpoint that we have is the userin point point that returns and encrypted geo. So, so far we are fine. That's why we are not considering center constraint tokens. So this is the summary of the mitigations that we have in the place. So we have the issue for mitigating the mix up attack the private key for a strong client authentication. And on the privacy side as I was mentioning, so we have the per voice subject to avoid user tracking using so object data minimization, we have it with the claim and then we have the user constant using the prompt. So just to summarize, what are the main differences between the Italian profile and the igo profile? So in our profile, we are mandating the usage of ACR values requests and pixie while in the authorization request, while they are optional in the igov. And then it's the usage of the each parameter in the authorization response. And as Francesco already mentioned that we are adopting the ODC federation. So in a state of the dynamic client registration, we use the automatic client registration of the ODC federation in order to register the client on fly in the authentication request. So given that I leave the floor to Jada to speak about the future of the Italian ecosystem.
Thank you me. So in the last part of this presentation, we are going to describe the activities that we are performing in the context of the ad wallet. So as most of you probably already know, the European digital identity wallet was introduced in the revised IDAs regulation and as the main goal of enabling user to be in control of their data. So we practically with the wallet a user can obtain and store different types of credential, can then department time sorry, of documents such as driving license or passport. And then can exchange these document with application both in physical and remote scenarios. And then the wallet must also support an electronic qualified electronic senior. So one aspect that I want to highlight is that with the introduction of the wallet, we have a shift in the authentication paring. Indeed in the classical traditional ED schemes, we usually have an entity like the identity provider that is responsible of sharing assertion about the user identity to each requesting parties.
While with introduction of the wallet, the user first obtains different credential from different issuers. And then in a second phase he is the user that is going to present this credential to the different applications. So as you can see in this phase, the issuer or in general an identity provider is not involved anymore to test the functionality of a wallet. The European Commission selected for projects that are large scale pilots and we are involved in three of them potential NOBI and DC for eu. And in this context we are providing several concrete proposals that are base and are going to extend the current Italian infrastructure following the European architecture reference framework. And specifically we start to work on the trust model. And our proposal is based on OpenID Connect Federation on the pit issuance. And in this case we are basing our solution on D for verifiable credential issuance. And related to the different use cases we are working on MDL and in particular we have a first design for the proximity supervised scenario based on the ISO 83 13 5. And we are now working on remote flow based on for verifiable presentations coming back on the PD funds.
I want to give you an better idea of the flow. I'm sorry for this slider all mixed up. But you can get, so as I told you, we base our design on openly connect for verifiable credential issues. So the idea is that first the the, the voltage is going to retrieve some metadata inside the metadata that are information like the credential that are supported by the issuer and then points and so on. So all the information needed by the wallet to interact with the issuer. After that, the wallet is going to perform an authorization request and then there is the user authentication. And in the context of the Italian scenario, we are going to use our national identity providers, so speed chair both with level high as required in the revised IDAs regulation. After that, the wallet is going to obtain a code and then is going to exchange this code to obtain an access token. And then with this access token can request the paid credential. And in this request together with the access token, the wallet is going to also provide a proof of possession of a key that is managed by the wallet. And this information and this proof of possession, the key is going to be used by the issuer to bind the credential. So the bid with the that particular wallet.
So all these steps are specified in the open ID for vci. What we are now working on is to define the, the trust model. So as we already said, the Italian ecosystem is based on openly connect federation currently. So we want to extend this to support also these scenarios. So we need to support now new roles like the pit provider and the wallet provider. And in addition we want also to find a way to be sure that the pit that is issued in a device is issued in a device that is not compromised and that the wallet is the genuine one. And so these two are two ongoing work for us overall. These are the security and privacy aspects that we are considering. So we can notice that now instead we want to support standard constraint tokens and we also need to add new, new parameter to mitigate attack that are specific for this new flow like his, like the use of the sinan to mitigate the reply attack related to privacy compared to the previous, the current Italian digital solution, what we cannot is the support for selective disclosure by reducing credential in format that support this functionality like his sd.
So this concludes the overview. So it's very on high level view of what we are doing in the Italian digital and ecosystem. I want only to add that as Francisco mentioned, we are also working together with this design activity in some automatic tools. So we already have released a tool that is called TS assistant to test the TS configurations is open source and is available on GitHub. And we are now working on another tool called that as the goal of a test. So it will lead to test implementation of openly connect core igov and federation. So this is an ongoing work and we hope that soon this tool will be available. So this conclude our presentation. Thank you.
So thank you very much for, for that. That's a very comprehensive set of things that you've covered there, but is there actually anything that still keeps you awake at night?
I, I would say so on the, on the automatic tools. So finishing with the Open iconic Federation test plans would be something that we would like to do it as soon as possible. And next, which is very important for me would be the petitions flow that we are working on that. But they are still some points regarding the managing your trust that as Jo mentioned, the presentation that still needs some tuning to be finalized.
Yeah. So do you think that the process, the flow, the technology that you've created there is going to be used across the EU or will it just be used in Italy
Regarding that? So at for the pedia, I would say, so we were, we have a collaboration with some members of open different foundation with Christina and Torsten. So at as a result of that we submit a discussion paper to the open foundation, sorry, to the European Commission that I think beside that, that's it, that you can see the reflect of that in the, in the rf. That's that protocol is there, but I mean we are trying our best to have a solution because our solution, I think it would be generalized for all the European members. It's so it's not something that's very specific for
The, we are following all the standards specifications. So are yeah, I think yes. You hope
That
Going? Yeah, I mean the, the part that would be different, so it's from my perspective would be maybe each member satisfied on is on trust model maybe so maybe not all the members states are satisfying with all, with all mythology based on Connect Federation. But I think still the other part should work.
Very good. So there are no questions online, I'm sure there must be some questions in the audience. Nobody got any questions? This is obviously a, a, a critical piece of technology that's being created. I think Michael Jones has got something to ask.
Yes. So which Open ID connect implementation do your federations use and was there any difficulty integrating those with the Open Id Connect Federation in particular in terms of the metadata?
So
It is for you
Yes, metadata, which open Id connect.
Which implementations did, are you using or did you create your own
For open Id connect. So the way how, how to, how the client is gonna be registered, for example. Yeah, we use the automatic client registration Yeah. As a method. And this is the way how we exchange metadata. So the automatic client client registration is basically a way where the client, when the client make the authentication request, this is, there is a mechanisms that on the fly the Open connect can register the client. So there is no need to preregister phase. Like for example in the client registration, we adopted this one as a mandatory in our profile. So that's why
I understand at the protocol level. I have a question about the implemented code,
The code
That you're using, because you would have to do new programming to support automatic client registration. To add it to existing open Id connect implementations.
So you your group implement the
We implemented, we have the first implementation, which is already in production. We use the, we we, so we use some libraries and some open source solution. Yeah.
Thank
You.
Okay, another question. Thank you.
Speed is established to level of shown substantial and the EU digital identity wallet will require level of assurance high. You'll have a period therefore in which you'll probably have a mixed assurance user base. What impact will that, if any, will that have on the architectures that you've just outlined?
If you get it
Can.
So you are saying if, if there is an identity based on level substantial
At the moment, at the moment all the speed users are based on level of assurance. Substantial, yeah. The digital identity wallet will require users to be assured to level of assurance high. So that you will then, at a certain point you're gonna have to upgrade users and you're going to end up with a mixed set. Some will be assured to level of assurance high and some to level of assurance substantial. What, how will you, what impact will that have upon this architecture?
So ready to the level So what I explained before is ready to the Ians. So for retrieving the p it is required now in the revised regulation 12,
The, the t a d digital identity is already, has already the highest dealer assurance. So from this point of view, I, there is a, we are already compliant with the, yeah,
Sorry John, I think John's found another question at the back. Thank
You. Hello, this is Paul. What is your view on trust management Is open, ID connect federation enough to Yeah. Make the, the trust management for you or do you plan to use like Etsy trust lists or train? Have you done any re research on how to establish the trust management?
Yeah, for the moment we want to try with open eConnect federation. So we want to see if he's manageable to cover all the aspects like that. Then we will see in the future if it works. Yeah,
There are some challenges, eh? Yeah, because we have new participant in this new ecosystem in the wallet, so we have to understand how to manage all the parties involved, eh, not only the issuers or verify, but only especially the wallet distance is maybe, I think it's the most important thing that we have to handle with.
Okay. So we have time for one further question. Thank you. Yeah.
Just quick question. The Italian government talk a few months ago about revision of speed ecosystem, they talked about over merging maybe or with, with the ca do you see any impact on your project for the future or that or your architecture say, will be not affected by that?
So they were all architecture. I i I think that is not affected on this because, so they basically, so they, in order to obtain the p d, what they a RF is say is saying is that, eh, the national identity a does notify the scheme is needed. So this is, I think the architecture on the overall I think is not, is gonna be affected on this. I think
We speed that year or together
It's the same.
So as far as you have only one notified e rd scheme in level high you are, you are
Fine. Yeah. The, the only requirement is that must be notified as yeah, at the moment.
So thank you very much indeed for your great presentation and all your work. Thank you. Thank you so much.
You're welcome.
Thank you. Thank you.
