# The eIDAS Regulation: A Survey of Technological Trends for European Electronic Identity Schemes
## 10 eIDAS 2.0 Regulation
To elaborate on this point, let us consider the following example. The ARF document states \"Secure access to locally or externally stored cryptographic functions will be necessary to implement most of the functionalities of the EUDIW (e.g., qualified electronic signature, authentication, selective disclosure). In the case of externally stored cryptographic functions, the wallet shall provide a minimum set of local cryptographic functions that enable secure access to them. Overall cryptographic methods and functions shall fulfill existing and upcoming requirements originating in standards, implementing acts and certifications based on these\". However, what would be beneficial is to provide some insights regarding the technical aspects that should be considered to implement this functionality in a secure way. In the following, we highlight some challenges derived from the ARF and eIDAS 2.0 proposal [5; 70], which are important to be considered in the EUDIW implementation to  
Figure 7: Comparison of different identity management systems. avoid possible failure as it has happened for the German digital driver's license and the ID Wallet app [71]. * **Persistent and unique identifier:** Article 11a of eIDAS 2.0 regulation states that the minimum data set of user identification data shall contain a unique and persistent identifier for all European citizens and residents. This parameter should design carefully as it can create additional privacy risks and allows online services to track the user's activity. A more privacy-friendly approach would be adopting a service-specific pairwise identifier model or pseudonymization;
* **Standards and technology immaturity:** To support the implementation of different functionality requirements of EUDIW, new standards and technologies are needed. There are different working groups, such as Decentralized Identity Foundation (DIF) ([[https://identity.foundation](https://identity.foundation)]([https://identity.foundation](https://identity.foundation)), accessed on 1 November 2022), OpenID Foundation (OIDF) ([[https://openid.net](https://openid.net)]([https://openid.net](https://openid.net)), accessed on 1 November 2022), World Wide Web Consortium (W3C) ([[https://www.w3.org/Consortium/](https://www.w3.org/Consortium/)]([https://www.w3.org/Consortium/](https://www.w3.org/Consortium/)), accessed on 1 November 2022), and ISO 18013-5 [72] to name a few of them, which are working on this dimension to provide the basic building blocks to build the EUDIW on top of it. However, most of these standards are in their early stages;
* **Interoperability:** It is worth mentioning that the current eID schemes that are operating within the MSs will continue to operate for quite some time after the final release of EUDIW. This can lead to potential challenges for SPs that are supporting several eIDs, including the EUDIW, for their services. A possible solution to this issue would be using an identity gateway (a.k.a broker) between the EUDIW and/or governmental eID means and the SPs. However, it is important to design the identity gateway based on privacy-by-design principles to prevent the identity gateway from profiling the user's online activity. A potential solution can be the adoption of a blind broker architecture model [73]. As a final remark, it is worth mentioning that, while in the case of eIDAS regulation [1] the notification process of eID means was not necessary, this has been changed in the eIDAS 2.0 regulation [5], and all MSs must notify at least one eID means. The European Commission road map for the adoption of the eIDAS 2.0 regulation is presented in Figure 8.