KuppingerCole's Advisory stands out due to our regular communication with vendors and key clients, providing us with in-depth insight into the issues and knowledge required to address real-world challenges.
Compare solution offerings and follow predefined best practices or adapt them to the individual requirements of your company.
Meet our team of analysts and advisors who are highly skilled and experienced professionals dedicated to helping you make informed decisions and achieve your goals.
Meet our business team committed to helping you achieve success. We understand that running a business can be challenging, but with the right team in your corner, anything is possible.
Italy has two National Digital Identity schemes, namely: SPID and CieID (leveraging the national ID card). Both of them are based on SAML2 and are on their way to supporting OpenID Connect. The reasons for this decision are numerous, and they are primarily related to OpenID Connect Core features such as flexibility, ease of implementation, better support for mobile applications, and widespread adoption, particularly in the private sector. To manage this transition, we considered several documents by the OAuth working group describing security best Current Practices and the OpenID Foundation specifying a profile for iGov and a framework for federation. In particular, the latter defines a hierarchical federation model with high security, interoperability, scalability, and transparency based on dynamic delegation mechanisms; Italy is an enthusiastic early adopter.
In this talk, we introduce the Italian OpenID Connect profile based on the iGov and federation profiles and explain the main security measures that we considered within our design from the aforementioned standards and available best current practices. We also discuss how the Italian OpenID Connect profile contributes to the iGov and OpenID Connect Federation documents. We conclude the presentation with a brief discussion of eIDAS 2.0 and some of the ongoing preliminary works in the context of the Italian digital identity ecosystem to move toward an SSI-based solution using the Italian OpenID Connect profile as a starting point.
Italy has two National Digital Identity schemes, namely: SPID and CieID (leveraging the national ID card). Both of them are based on SAML2 and are on their way to supporting OpenID Connect. The reasons for this decision are numerous, and they are primarily related to OpenID Connect Core features such as flexibility, ease of implementation, better support for mobile applications, and widespread adoption, particularly in the private sector. To manage this transition, we considered several documents by the OAuth working group describing security best Current Practices and the OpenID Foundation specifying a profile for iGov and a framework for federation. In particular, the latter defines a hierarchical federation model with high security, interoperability, scalability, and transparency based on dynamic delegation mechanisms; Italy is an enthusiastic early adopter.
In this talk, we introduce the Italian OpenID Connect profile based on the iGov and federation profiles and explain the main security measures that we considered within our design from the aforementioned standards and available best current practices. We also discuss how the Italian OpenID Connect profile contributes to the iGov and OpenID Connect Federation documents. We conclude the presentation with a brief discussion of eIDAS 2.0 and some of the ongoing preliminary works in the context of the Italian digital identity ecosystem to move toward an SSI-based solution using the Italian OpenID Connect profile as a starting point.
The European Union’s regulation on Digital Identity, eIDAS, is currently being overhauled to adopt decentralized identity principles. The goal is to provide all citizens and residents across the EU with highly secure and privacy preserving digital wallets that can be used to manage various digital credentials, from eIDs to diplomas to payment instruments. Decentralized identity principles aim at giving freedom of choice and control to the end-user. Ensuring security and interoperability, however, will be challenging — especially in the enormous scale in terms of users and use cases the EU is aiming at. The choices made in eIDAS will have a huge impact on digital identity in the EU and beyond.
The so-called “Architecture and Reference Framework” (ARF) defines the technical underpinnings of eIDAS v2. Many experts from the member states and the Commission have been working on this framework over the last year, trying to select the best combination of technologies and standards out of the enormous number available in the market today. This talk will introduce the ARF and explain what architectural patterns and technical standards are adopted and how the challenges mentioned above are addressed in order to leverage on the vision of the eIDAS v2 regulation.
OpenID Foundation Workshops provide technical insight and influence on current digital identity standards while also enabling a collaborative platform to openly address current trends and market opportunities. The OpenID Foundation Workshop at EIC includes a number of presentations focused on 2022 key initiatives for the Foundation.
Digital identity has been under a constant evolution for the last 30 years. It started from a simple access control via user account within a system to a shared credential among the systems, then to the federated identity and bring-your-own-identity (BYOI). Modern usages are not only for access control but include such purposes like digital on-boarding (account opening), employee and customer relationship management. Among the many technologies out there, OpenID seems to have gained popularity in the market that you are probably using it without knowing it. This session explains the positioning of OpenID in the digital ID landscape and explores the future potential for both corporations and individuals for the coming years.
To enhance interoperability between digital identity schemes and digital trust services across borders, the eIDAS regulation provides a legal framework for electronic signatures in the EU, defining how to use them to ensure their validity across Europe. eIDAS2 now includes plans for the creation of a European Digital Identity Wallet (EUDIW). Cloud signatures are expected to play a vital role across this new ecosystem by enabling natural and legal persons to electronically sign and seal documents and transactions with high-assurance remote digital signing certificates. Cloud signatures based on the Cloud Signature Consortium (CSC) Standard can help achieve cross-border interoperability via specifications and certification for the usage of Remote Electronic Signatures and Seals in this new pan-European digital identity ecosystem.
Join us to learn about the new CSC Standard general architectural framework in specific eIDAS context (Kim Nguyen, CSC Board Member, D-Trust) and for a technical deep-dive into the recently launched CSC Standard version 2.0 (Luigi Rizzo, Chair of the CSC Technical Committee, InfoCert).
A lot of innovation around physical products is created by connectivity, allowing them to become part of the consumer's larger digital ecosystem and the providing enterprise. Gartner says in its megatrends for the next decade: "Anything costing more than a few USD will be "intelligent and networked". Examples are electronic wall boxes to charge cars or remote-control for dishwashers, cars, etc. Key Takeaways: |
- What are the essential protocols to bring identity and IoT together |
The existing eIDAS governance framework for digital identity is fragmented for different regulated markets in different EU countries. Today identity provider solutions for finance, healthcare and other regulated markets follow central approaches for the management of identities and consent in high secure data center environments and using legacy standards (e.g. OIDC, central public key infrastructure).
eIDAS 2.0 creates a EU wide identity ecosystem with adapted new standards, new stakeholders and a focus on using mobile devices. The existing roadmap allows to anticipate three to five years (or more) transition. For banking, insurance, healthcare or the public sector it is time to adopt these standards in their digital transformation strategy.
Based on the Gematik requirements for a federated identity provider with central OIDC compliant resource and authorization server Comuny shifted relevant identity provider functions (data storage + token generation) on the mobile device.
The speakers will describe challenges and solutions for this regulated market. They also discuss the chance to combine existing central OIDC flows with mobile decentral, wallet based principles as a bridge into the new eIDAS 2.0 governance framework. The audience will get a clear understanding about requirements, opportunities and practice details to create the transition into eIDAS 2.0 identity ecosystem.
Learn how Raiffeisen Bank International heads toward decentralized identity to empower their customers across Europe and set the gold standard for privacy protection.
The increased mobility of users and their demand for personalized, unified omnichannel access experiences has stretched federated IAM beyond its limits. Meanwhile, the need for organizations to collaborate more to compete, and build communities of trust and value for those same users affordably and securely, cannot be met by existing federated IAM solutions. Learn how Raiffeisen Bank International (RBI) will embrace the new paradigm of decentralized identity to improve existing experiences and create the opportunity for new, valuable user experiences and increased levels of engagement and collaboration withbusiness partners across multiple jurisdictions, without the need to replace their infrastructure. Simultaneously, understand why starting their journey now, enables RBI to future-proof their ecosystem to rapidly support the EU Digital Wallet and official digital credentials that will become available. Get a glimpse into the solution architecture being deployed at RBI and an understanding of the benefits and how they can be communicated to executive leadership and business partners. Yes, decentralized identity may be great for web3 someday; however, learn from RBI how it can also solve today’sproblems in a practical way and work in harmony with existing IAM systems enhancing existing federationplatforms.
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
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.