Extended Model for Efficient Federated Identity Management with Dynamic Levels of Assurance Across eIDAS, REFEDS, and Kantara Frameworks for Educational Institutions

Abstract

The electronic identity (eID) concept plays a crucial role in building trust and security in electronic transactions and communications. In federated systems, where multiple organizations and users share and use common resources, effective identity management is critical. In this context, the use of an identity provider proxy (IdP proxy) has the potential to facilitate and enhance the interoperability and security of electronic identities. This research examines the role, benefits, and challenges of using an IdP proxy in federated systems. Additionally, this study focuses on the use of IdP proxies for the management of electronic identities in federated systems and compares the approaches and practices employed in three significant frameworks: eIDAS (electronic identification, authentication, and trust services), REFEDS (research and education federations), and the Kantara Initiative. Considering the identity architectures of the eIDAS, REFEDS, and Kantara frameworks—each of which exhibits special and unique features—as a reference point to analyze identity attributes, we use the AARC blueprint model, the main component of which is the IdP proxy, as an intermediary for the management of identity attributes.

1. Introduction

In the era of digital transformation and online services, identity federations serve as the foundation for ensuring the identification and authentication of users across various platforms and systems. Identity federations such as eIDAS, REFEDS, and Kantara play critical roles in managing security and facilitating the trusted sharing of information through different protocols and policies for defining levels of assurance (LoAs). This introduces significant challenges in terms of cooperation and interoperability among diverse federations, necessitating suitable mechanisms for attribute alignment and LoA adaptation.

The IdP proxy emerges as a critical component in addressing these challenges. Acting as an intermediary between service providers (SP) and identity providers (IdP), the IdP proxy enables dynamic attribute adjustment, policy harmonization, and LoA adaptation based on the specific requirements of the considered federations and services.

This study explores the role of the IdP proxy in implementing dynamic levels of assurance in the context of multiple identity federations. The second section focuses on the harmonization of attributes and adaptation of protocols. The following section addresses the technical and practical challenges associated with harmonizing LoAs across eIDAS, REFEDS, and Kantara, proposing solutions to establish a sustainable and secure digital identity ecosystem. The fourth section examines how the IdP proxy can enhance technical and operational interoperability among the eIDAS, REFEDS, and Kantara frameworks. Finally, the concluding section provides a detailed approach utilizing this model which enables dynamic LoA adjustments, ensuring a sustainable balance between security, efficiency, and trust in federated systems.

1.1. Electronic Identity (eID)

Electronic identity in a federated system refers to a method for managing and utilizing user identifications across multiple independent domains or systems while maintaining control of interoperability and security [1]. In federated systems, electronic identities allow users to access resources and services in various domains without the need to create and manage separate accounts for each one. Some of the key elements of user electronic identities in federated systems are as follows [2]:

• Single sign-on (SSO) technology, which allows users to authenticate once and gain access to multiple resources, without needing to log in again for each service;
• Identity providers, which enable the management and verification of user credentials and provide authentication information to other services within the federation;
• Security protocols, which are used to facilitate the secure exchange of authenticated requests between the identity provider and service providers, such as SAML (Security Assertion Markup Language), OAuth, and OpenID Connect [3];
• Attribute management, where specific user attributes (e.g., name, email address, and roles) are often shared across different domains to enable access decisions based on pre-defined rules;
• Privacy and control, where ensuring user privacy is critical, and users often have control over what information is shared with other domains within the federation.

By enabling integrated and more secure identity management methods, federated systems offer increased convenience for users and improved efficiency for organizations. This is especially beneficial for organizations with international or inter-organizational operations, in which users often need to access resources across various technological environments [1].

1.2. Identity Federation

An identity federation refers to an agreement between multiple organizations that allows for the sharing and use of identity information for authentication and authorization purposes [4]. This approach implies a trust system between two or more parties, and is designed to authenticate users and transmit the necessary information to authorize their access to various resources [2]. In this way, the identity federation provides users with a smoother and more efficient experience when accessing the systems and services that they use. Federated identity enables authorized users to access multiple applications and domains using a single set of credentials, such as a username and password, or other authentication technologies, such as biometrics [5]. This eliminates the need for users to provide separate credentials for each application, reducing the need for management of multiple passwords (especially when users need to access services from different organizations), while maintaining the security and integrity of their data [6].

In practice, federated identity links a user’s identity to multiple identity management systems, allowing them to access various applications securely and efficiently.

1.2.1. Use of the Hub and Spoke Model in Identity Federation

Several architectural patterns are often used in the context of identity systems, especially in identity federations, in which various institutions must share information about their users. As a model that helps to facilitate interactions between institutions, the hub and spoke model can be used. This model contains a central hub, which acts as an intermediary between the participants (speakers) [1]. Users connect to a central point, which then manages requests for authentication or other services. In this model, all service providers (SPs) and identity providers (IdPs) connect to an SAML proxy, which is a central node that acts as an intermediary between these SPs and IdPs.

When an SP needs to verify a user from a given federation, instead of connecting directly to the user’s IdP, it sends the request to the SAML proxy, which then acts as an intermediary and forwards the request to the appropriate IdP. After the IdP verifies the user’s identity, it sends the response back to the SAML proxy, which then forwards this response to the SP. The operational process of the hub and spoke architecture can be better understood through the (Figure 1):

1.2.2. The Use of the Mesh Model in Federated Identity Management

Another model that can be used to facilitate interoperability between organizations is the mesh architecture, which operates without a central node. Instead, each participant in the federation can connect directly to each other. This structure offers more flexibility and load balancing but can be more complex to manage, as each participant must manage their relationships with all other participants.

In the mesh architecture, each SP is (potentially) connected to each IdP, where the SP is the service or application that seeks to verify the identity of users to allow them access, while the IdP is the entity that verifies the identity of the users and provides their credentials (e.g., an institution that manages user logins).

For example, a student from university A (IdP) can use their credentials to access various services offered by other universities (SP) without needing to create new accounts at each university. Thus, an SP can connect with multiple IdPs, and each IdP can connect with multiple SPs, creating flexibility in user authentication. This idea is visualized in the following Figure 2:

For consistency between the attributes of different federations, attribute aggregation is a process that requires the provision of more than one source of information about a user to perform authorization. When users wish to provide information about their attributes to service providers, the information is sent through an identity provider (IdP) [9]. The attributes received from IdPs can be supplemented with additional information, based on the organization’s requirements (e.g., for security purposes). This process can be accomplished through the use of various protocols, which facilitate the exchange and management of data in a secure and efficient manner.

1.3. Identity Profile and Authentication

In federated systems, the identity profile represents a set of attributes that characterize a user’s identity, based on the standards and policies of different organizations. These profiles enable the creation of a unique identity for the user, facilitating the use of the single sign-on (SSO) mechanism. Through this mechanism, users gain easier and more secure access to various federated services without the need to perform authentication for each service. The key components of identity profiles in federated systems are the attributes that identify the user, such as their name, surname, email address, and role within the organization. To ensure a high level of authenticity, user identity authentication is performed through multi-factor authentication (MFA). This process may involve the use of passwords, digital certificates, or biometric technologies, which are combined to enhance the security and reliability of the system.

1.4. IdP Proxy

The identity provider proxy (IdP proxy) is an intermediary component in federated identity management systems [10]. It is used in environments where multiple entities interact securely to exchange identity data that a user possesses (typically managed by the IdP) and to offer various services based on that identity information (managed by the SP) [11].

When a user attempts to access a service in a federated system, the process begins with their request being sent to the identity provider proxy (IdP proxy). Once the request reaches the IdP proxy, it intermediates the authentication by directing it to a trusted IdP. The IdP then verifies the user’s credentials, confirming whether their identity is accurate and authorized to access the requested service [10]. This architecture provides a high level of abstraction and security, avoiding direct communication between the IdP and each service provider (SP). This avoids the need for application/service providers to implement multiple authentication protocols/providers/federations, thus enabling easier integration, as the authentication process can be performed centrally and more efficiently.

For the user, this results in a more unified and seamless experience, as they only need to go through the authentication process once [2]. Through the utilization of an IdP proxy, organizations can centralize their security policies and better manage user credentials across a variety of services and different frameworks.

2. Identity Federations: eIDAS, REFEDS, and Kantara

Electronic identity security in federated systems is a critical component to ensure that user identities are protected, authentication processes are secure, and personal data are safeguarded against unauthorized access [2]. For this reason, international and national initiatives and regulations have defined rules regarding the use of management, communication, and security standards, providing different levels of protection. The most widely used and accepted identity federations are as follows:

• eIDAS 2 (European Digital Identity Framework) [12]—The European Union regulation No. 1183/2024 creates a unified legal framework for electronic identification, authentication, and trust services between EU member states. This helps to enhance trust and security in the digital environments used within the EU.
• REFEDS (Research and Education Federations) [11] is an international organization that supports the development of identity federations for research and educational institutions worldwide. This organization provides a standardized way to describe how identity information is verified and secured in a digital environment [13]. The REFEDS organization profiles define the levels of security and trustworthiness of the identity information provided and used in online services and other digital resources. The description of identity assurance profiles helps organizations and users to understand how interconnected and secure the identity verification process is within digital environments [14].
• Kantara Initiative [15] is a global non-profit organization that develops standards, policies, and practices for digital identity management, verification, privacy, and trust. The organization uses identity profiles to help organizations and governments in creating secure and consistent systems for managing user identities across various digital platforms and services [16]. This helps to increase user safety online and reduces the risk of fake identities and online fraud.

2.1. Identity Federation Levels of Assurance

Level of assurance (LoA) profiles represent a set of rules that define the level of security and trustworthiness in the process of authenticating user identities in federated systems [17]. LoA profiles are used to assess how trustworthy a verified identity is, representing the complexity of processes used for its protection and authentication. In the identity federation context, LoAs are defined as protocols/procedures for establishing user identity and methods for the authentication of electronic identities, ensuring a uniform level of security for electronic services and transactions [18].

2.1.1. e-IDAS 2 LoA Profiles

The eIDAS profiles focus on the identification of the identity of users, setting specific standards to ensure the security of electronic identities [19]. This ensures that identification systems and trust services recognize these standards and are interoperable between EU member states [17]. The eIDAS framework includes different levels of assurance, defined in three main categories: low, substantial, and high [20]. These levels describe the specific requirements for electronic authentication, including how identity data are collected, stored, and used to ensure integrity and confidentiality.

Figure 3 illustrates the three levels of identity assurance within the eIDAS security framework. This framework, which has been adopted by the European Union, aims to provide a clear set of standards for electronic identification and digital trust services across all EU member states [6]. The three levels of security presented in the chart provide a clear framework for how electronic identities should be handled in the context of digital services. Each level is designed to meet different requirements for security and trust, ensuring that users have a safe and secure experience when engaging in online activities.

2.1.2. REFEDS Identity Assurance Profiles

The REFEDS profile for multi-factor authentication (MFA) defines a standard signal to request and report the use of MFA in federated authentication. It describes the requirements for providing a higher level of security than simple password authentication, without limiting the specific methods used [5]. This profile allows a service provider (SP) to request MFA from an identity provider (IdP), which then sends a signal to confirm successful authentication. The profile supports SAML 2.0 and OpenID Connect, including guidelines for authentication timeout and re-authentication when using multi-factor authentication. Some technologies that are stronger than MFA are not included in this profile [21]. The following diagram presents the main components and interactions of the REFEDS profiles, using different levels of security and focusing on the exchange of attributes and authentication mechanisms in a federated environment.

The structure shown in Figure 4 helps to create an integrated and secure environment for users, also providing a solid foundation for the further development of identity management practices at an international level.

2.1.3. Kantara Profiles

Kantara profiles represent an advanced system for defining security levels to enable reliable and secure identity management in various digital environments [22]. Kantara profiles focus on three key aspects designed to support a range of needs in the context of identity management and federated exchanges; namely, identity assurance levels (IAL), authentication assurance levels (AAL), and federation assurance levels (FAL) [23].

Using these profiles, Kantara provides a clear and structured approach to electronic identity management, ensuring that identity authentication and verification processes are secure and reliable for all parties involved [24].

Figure 5 provides a depiction of the LoA profiles in Kantara [15], illustrating how each level contributes to creating a strong and secure system for identity management in federated environments.

2.2. Dynamic (Elevated) LoA Needs

Dynamic LoA adjustment is an advanced approach to defining the level of security for authentication and identity verification based on the risk and requirements specified for a given service. As each of the eIDAS, REFEDS, and Kantara systems define different levels of security, this presents a challenge relating to implementation, with the systems requiring higher LoAs for certain services. In such a scenario, the system needs the elevated LoA for the authenticated user in order to proceed with the requested service. This problem increases in complexity when the service allows access to users from different federations.

Figure 6 shows the level of security for identity authentication and verification based on the specified requirements of a service. For user authentication and authorization, eIDAS and Kantara require digital certificates or biometric authentication, while REFEDS relies primarily on passwords and OTPs. The use of these methods requires dynamic LoA mapping, ensuring that a given level of security in one federation matches the requirements of another federation.

Table 1. The use of different authentication and identity verification methods in federated systems.

Federates	eIDAS	REFEDS	Kantara
Password		X
OTP (One-Time Password)	X	X	X
Digital Certificate	X		X
Biometric Authentication	X		X

lists the different methods of authentication and identity verification used in federated systems. Given that each federation uses different levels of security, dynamic LoA adjustment is used to adapt these levels in order to avoid any issues that may arise when implementing interoperability between them.

When evaluating electronic identity security models in federated systems, it is essential to understand that each system follows different standards for the protection of user identities and ensuring secure transactions. Systems such as eIDAS, REFEDS, and Kantara apply different levels of security to address user authentication and authorization requirements in digital environments [25]. The following table presents a clear comparison of the security levels applied in each of these systems.

Table 2. Comparison of security levels implemented in the federated systems eIDAS, REFEDS, and Kantara.

Federation		eIDAS			REFEDS			Kanata
LoA Defenition		Low	Substantial	High	Low	Medium	High	LoA 1	LoA 2	LoA 3	LoA 4
Authentication	Username	X			X			X
	Pasword	X						X
	email				X
	OTP	X	X		X	X		X	X
	Digital certificate	X	X	X	X	X	X	X	X	X
	Biometic	X	X	X	-	-	-	X	X	X	X
Identity Profing	Minimum data	X			X			X
	Identity document	X	X		X	X		X	X
	Biometric validation	X	X	X	X	X	X	X	X	X
	Multi factor Authentication	X	X	X	X	X	X	X	X	X
	Physical identification	X	X	X	X	X		X	X	X	X

demonstrates how each standard manages risk assessment, authentication procedures, and security measures in order to ensure the appropriate level of security in federated systems. The three frameworks (eIDAS, REFEDS, Kantara) use different levels of security and require different methods of authentication and identity verification. Kantara provides a more detailed categorization of the levels starting from LoA 1 to LoA 4, while eIDAS and REFEDS rely on three main levels of security (i.e., low, medium/substantial, and high). This visual representation helps to illustrate the clear hierarchy of security measures and practices that should be followed to protect electronic identities in a federated environment.

2.3. Different Policies

eIDAS, REFEDS, and Kantara operate on different identity management systems. Depending on the policies they follow, the definition of standards for authentication and verification of user identities also varies. As mentioned above, eIDAS sets strict standards for electronic identification across all EU member states, based on legal certainty and compliance; REFEDS focuses on security and authentication in the research and education sector, offering flexibility to academic and research federations; Kantara is based on global digital security standards and compliance with NIST guidelines, empowering organizations to manage identities and authentication securely in both the government sector and private companies. Harmonizing policies to achieve a common level of trust is a challenge for organizations operating with overlapping systems.

2.4. Protocols Within Federated Identity Management

Identity management systems use many standardized protocols, such as SAML, OAUTH, OpenIDConnect, CAS, LDAP, and Kerberos. Most of the protocols are used for single identity systems and do not support federated identity management (FIM).

SAML, OAuth, OpenID Connect, and CAS support FIM functionality. SAML supports extended authentication across organizations (SAML-extended); OpenIDConnect uses a different scenario for adoption across various technologies (in development); OIDC builds on OAuth 2.0 by adding an identity layer to provide an ID token for the user; CAS supports single sign-on (SSO) for FIM, but is mainly used in limited environments such as university campuses; and LDAP and Kerberos do not support FIM, and are mostly used for authentication and identity management in local environments (e.g., on-premises).

SAML is a well-known standard that enables the secure and structured exchange of information regarding user identities [2]. This protocol uses the XML (eXtensible markup language) format for encoding and transferring the data necessary for authentication and authorization processes. Through SAML, users can authenticate once and then access various services without needing to log in every time—a process known as single sign-on (SSO) [2].

The model in (Figure 7) includes the key components of the SAML protocol, integrating various steps for user authentication.

• The user requests access to a service or application that is protected and federated with the SP.
• The SP detects that the user is not authenticated and redirects the user to the IdP by sending a SAML authentication request.
• The IdP receives the authentication request and authenticates the user through the appropriate login.
• SP sends a request to create SAML Assertions to IdP for successful authentication.
• After successful authentication, the IdP creates a SAML assertion containing the authenticated user information.
• The IdP redirects the user to the SP, including the SAML assertion in an HTTP POST response.
• The SP receives the SAML assertion, verifies it (checking the signature and validity of the assertion), and then recognizes the user as authenticated.
• Once authenticated, the user gains access to the application or service requested from the SP.

2.5. Different Protocols

Analyzing the identity security profiles of the three main systems—namely, eIDAS, REFEDS, and Kantara—it is important to note that these federations follow different approaches for the implementation of protocols, which creates significant challenges for their technical coordination and the secure exchange of authentication and authorization data between the parties involved.

For user authentication and authorization, eIDAS supports the SAML protocol, which provides a high level of security in the exchange of data. eIDAS aims to provide a stable and reliable structure for identity verification, meeting the legal requirements of the European Union. REFEDS, which is oriented towards the academic and research sector, also uses the SAML protocol for reliable authentication at the international level. However, in response to the needs of modern applications, REFEDS also integrates the OpenID Connect protocol, relying on OAuth 2.0 to provide simple and flexible authentication mechanisms. Kantara, unlike the others, follows a comprehensive approach using a wider range of protocols. It implements SAML for more traditional and consolidated systems while, for more dynamic and flexible needs, it uses OpenID Connect and OAuth. In addition, Kantara supports other standards that meet the requirements of mobile applications and cloud-based services, ensuring access and reliability in a diverse technological ecosystem.

The use of different approaches means that interoperability between these systems requires the use of common mechanisms such as protocol translation, thus harmonizing the LoA to meet the specific requirements of each federation.

As shown in

Table 3. The federation protocols used by eIDAS, REFEDS, and Kantara to harmonize security levels (LoA).

Protocols	eIDAS	REFEDS	Kantara
SAML	X	X	X
OpenID Connect		X	X
OAuth			X

, eIDAS exclusively uses the SAML protocol, while REFEDS and Kantara also include the OpenID Connect protocol. The SAML protocol uses XML for message encoding, is slower to process, and is more difficult to handle, while OpenID Connect relies on JSON for data exchange, is more flexible, and is easier to handle. Each of these protocols provides unique mechanisms for the management and transfer of identity data.

Due to these structural and functional differences, integration and cooperation between federations can be challenging. The lack of harmonization between protocols creates technical obstacles hindering the synchronization of user data and the construction of an interoperable and sustainable system for digital identity management. To address these challenges, it is necessary to implement translation mechanisms between the utilized protocols, thus enabling the exchange of data in a secure and reliable manner.

3. Interoperability Between eIDAS, REFEDS, and Kantara

eIDAS, REFEDS, and Kantara present different approaches to user identity management, including different requirements regarding identity attributes; policy frameworks that differ in the definition of standards for identity management, authentication, and verification; different levels of assurance (LoAs); and different protocols for communication. These differences create barriers to achieving full interoperability between different systems and platforms, especially in cross-border and inter-organizational contexts.

3.1. Extended IdP Proxy

The identity provider proxy (IdP proxy) is an intermediary component between users and services that protects and manages user identities [26]. The IdP proxy acts as an intermediary, enabling reliable communication between IdPs and SPs without direct contact between the two parties [10]. This ensures that different systems—which exhibit have varying standards and technologies—can communicate effectively and securely with each other. It also helps to translate and harmonize the various authentication protocols that may be used by different service providers; for example, it might receive an SAML token from an IdP and generate an associated OIDC (OpenID Connect) token for an SP.

Using an IdP proxy in the SAML authentication model assists in managing the authentication and authorization of requests from most users through a single intermediary (proxy) [8]. This is particularly beneficial in scenarios where there are multiple IdPs and SPs operating within a large federation. The IdP proxy handles requests from the SP and forwards them to the appropriate IdP.

3.2. Management of Security and Privacy

An IdP proxy provides advanced control over the attributes shared with service providers. This means that both users and administrators have the ability to precisely determine which personal data will be shared and with which entities. This selective control is essential in environments such as eIDAS, REFEDS, and Kantara, where trust and compliance with privacy regulations are critical [4]. Furthermore, the use of encryption ensures that the data remain secure during transmission, thus protecting user privacy. The IdP proxy also reduces complexity and the time users spend on individual authentications for each service [10]. Once the user is authenticated through an IdP proxy, they can access various services without further authentication.

3.2.1. Benefits of IdP Proxy in eIDAS (Electronic Identification, Authentication, and Trust Services)

The IdP proxy plays an important role in enhancing user identity security within the eIDAS (electronic identification, authentication, and trust services) framework. The eIDAS framework sets strict standards for electronic identification and trust services across the EU, ensuring that user identities are protected with robust security mechanisms [27]. By acting as an intermediary between SPs and IdPs, the IdP proxy further enhances these security mechanisms through the integration of strong authentication and advanced identity management processes, allowing users to perform authentication through a single point [20]. This makes the authentication processes more secure, as all access requests pass through a central node, where stringent security controls can be enforced.

Instead of requiring a user to be individually authorized with multiple SPs, the user is authenticated once through the IdP proxy, which then intermediates further requests [6]. This reduces the number of direct interactions between users and applications, lowering the attack surface to protect against identity breaches.

A critical aspect of security within eIDAS is the use of multi-factor authentication (MFA), which involves the use of more than one element to verify a user’s identity [5]. The IdP proxy can facilitate the implementation of multi-factor authentication, allowing users to pass through multiple security levels, ensuring access only if they meet all pre-defined requirements.

In a system based on the use of an IdP proxy, every authentication and authorization action can be logged for audit and monitoring purposes. This allows organizations to track the history of authentications and detect suspicious activities in real-time, enhancing accountability and security [18]. The IdP proxy can act as a central point for aggregating these data, helping organizations to comply with the eIDAS legal requirements for transparency.

The IdP proxy significantly enhances user identity security within the eIDAS framework through the addition of a robust layer of protection for authentication, authorization, and access management. It contributes to the implementation of secure identity practices, including multi-factor authentication, strong encryption, and the use of digital certificates, all in accordance with advanced security standards.

3.2.2. Benefits of IdP Proxy in REFEDS (Research and Education Federations)

The IdP proxy has a significant impact on user identity security when used within the REFEDS (research and education federations) framework, which focuses on security and authentication in the research and education sector. REFEDS is a collaborative framework that aims to standardize identity federations globally, allowing for the secure exchange of identities among research and educational institutions and organizations [26].

The IdP proxy ensures that users do not directly share their credentials with the services requiring authentication. Instead, the IdP proxy manages this interaction, acting as a bridge between the user and the services [21].

The IdP proxy is designed to meet the unique requirements of academic and research institutions, which often have specific needs for authenticity, authorization, and access to multiple resources. This allows institutions to enhance their user identity management through shared authentication centers, reducing the need for multiple logins and credentials for users [28]. As many scientific and educational applications require a high level of customization and secure access, the IdP proxy enables implementations that are tailored to these requirements [29].

The IdP proxy supports open standards such as SAML (Security Assertion Markup Language) and OIDC (OpenID Connect), facilitating access to research and educational resources globally.

With the IdP proxy, users can seamlessly access services and resources regardless of the technological infrastructure of different service providers. This helps to harmonize the academic environment and minimize technical barriers. All data passing through the IdP proxy are protected with advanced encryption, ensuring that communication between users and services is secure and protected from interference.

3.2.3. Benefits of IdP Proxy in Kantara Initiative Framework

The IdP proxy in Kantara serves as a powerful platform that enables organizations to create and maintain a secure, reliable, and extensive authentication ecosystem across various sectors and technologies, while simultaneously meeting diverse operational and security requirements [15].

The use of an IdP proxy in the context of Kantara implies a solution that empowers organizations to flexibly and securely perform identity management and authentication. For instance, the government sector may require stringent security mechanisms, while private companies may focus on the speed and efficiency of access.

Different systems may have unique authentication and access requirements, and the IdP proxy allows for customization of these processes to meet specific objectives, such as implementing multi-factor authentication [23].

The IdP proxy provides the capability to implement varying levels of security tailored to the diverse needs of organizations. Multiple security levels are designed in order to enhance protection against cyberthreats while maintaining the integrity and confidentiality of user data. These levels range from single-factor authentication to multi-factor authentication (MFA) and the end-to-end encryption of data [30]. This facilitates the implementation of identification and authentication processes without requiring users to continually re-authenticate, enhancing both the user experience and overall security.

4. New Proposed Model

The process of requesting access and providing services to users utilizing the LoA, in collaboration with an IdP proxy, is clearly and concisely illustrated in Figure 8. This process involves a series of interconnected actions that encompass user authentication and authorization, and its implementation is carried out using the standardized Security Assertion Markup Language (SAML) protocol, which provides a secure and reliable mechanism for exchanging authentication and identification data between various parties, such as the user, the SP, and the IdP, guaranteeing the integrity and privacy of these data during transmission.

This process not only ensures that users are securely authenticated and authorized to access the requested services, but it is also supported by advanced LoA control mechanisms to ensure that only users with appropriate authentication levels can access critical or sensitive resources. In this way, the IdP proxy plays a key role in centralizing user identity verification processes and mediating security exchanges between different entities, simplifying the complexity of identity management in a distributed environment.

The respective steps of this process are described in detail below, including all phases involved in exchanging authentication requests, transmitting authentication messages, and delivering service assets, always adhering to the requirements for compliance with security, data integrity, and authentication standards.

• The user requests access to a service or application that is protected and federated with the SP.
• The SP detects that the user is not authenticated and redirects them to the IdP proxy by sending an SAML authentication request.
• The IdP Proxy sends the authentication request to the SP.
• The SP receives the request, analyzes the user, and selects the appropriate IdP to authenticate the user.
• The IdP proxy redirects the user to the IdP for authentication.
• The IdP authenticates the user and generates an SAML assertion containing the authenticated user information.
• The IdP redirects the user to the IdP proxy, including the SAML assertion in an HTTP POST response.
• The IdP proxy receives the SAML assertion from the IdP, verifies it, and then sends a new assertion to the SP.
• The SP receives and verifies the new SAML assertion from the IdP proxy, then grants access to the service for the user.

4.1. Unification of Attributes Between Federations

To create an architecture that relies on a federated identity for research and education, in order to improve collaboration between such organizations, it is very important to analyze identity attributes according to different architectures, as each of the federations follows different identity and access standards [8].

Identity attributes are managed by ensuring compatibility between different federations, with the aim of providing users with secure and convenient access to international research resources. Comparing these federations will help to identify different strategies for managing identity attributes, as well as improve interoperability between them [4]. This structure allows for secure and efficient communication between federations, optimizing the distribution of identity attributes and ensuring that users have secure and convenient access to international research resources.

4.2. Selecting Identification Attributes Through an IdP Proxy

To centralize identification attributes through an IdP proxy that enables user authentication across different federations—in our case study, involving eIDAS, REFEDS, and Kantara—an advanced system is required that supports all necessary protocols for attribute exchange and transformation, in accordance with the specific requirements of each federation. Such an approach necessitates the development of a unified attribute structure through which the IdP proxy can translate these attributes into standardized and understandable formats for each federation [9]. This ensures an inter-federative approach to user identification across different federations, enhancing interoperability in identity management.

5. Extended Model for Efficient Federated Identity Management with Dynamic Levels of Assurance

To enable interoperability between eIDAS, REFEDS, and Kantara federations, thus providing a unified and secure ecosystem for digital identity management globally, organizations must implement attribute mapping to align and translate identity data between systems; policies that define common levels of trust and security; dynamic LoA alignment mechanisms that adapt to contextual and risk requirements; and protocol interoperability between SAML, OpenID Connect, and the other technologies used by these federations. To enable an integrated approach and interoperability between different federations, implementing an IdP proxy represents an optimal solution. This component plays a key role as a central point for communication and authentication management, ensuring compatibility between systems operating with different protocols and standards.

Mapping of Attributes Between Federations

Each organizational structure uses different formats and requirements for identity attributes, including personal data, unique identifiers, and information needed for authentication. The mapping of attributes between federations requires careful analysis of their definitions and structures in order to avoid data gaps and ensure the integrity of identities. Some identity federations define a minimal set of mandatory attributes. The legally verified and mandatory attributes required by eIDAS are person identifier, family name, name, and date of birth, while the optional attributes include birth name, place of birth, current address, and gender [31]. Some national eID profiles may also include additional elements (e.g., “citizenOf”). The mandatory attributes required by the REFEDS federation are: The eduPerson schema (e.g., eduPersonPrincipalName, eduPersonAffiliation, eduPersonEntitlement, eduPersonOrcid, etc.), which is used primarily in research and education federations, and the SCHAC schema (e.g., schacPersonalUniqueID, schacDateOfBirth, schacCountryOfCitizenship), which extends eduPerson for global academic communities.

The Kantara Identity Assurance Framework refers to a set of attributes (e.g., given name, last name, DOB, address, email, phone, etc.), primarily in the context of assurance and verification levels (IAL1/IAL2/IAL3). Kantara does not prescribe strict naming conventions for attributes in the same sense as do the SAML/LDAP schemas—rather, it refers to the types of attributes that need to be verified or maintained.

Table 4. Attributes for user identification in eIDAS, REFEDS, and Kantara frameworks.

No:	Attribute (Purpose/Semantic Meaning)	eIDAS	REFEDS (Commonly Used)	Kantara (IAF/NIST 800-63)
1	A unique, persistent, non-reassigned identifier for the subject. Typically used for long-term identity correlation.	PersonIdentifier (Mandatory)	eduPersonUniqueId or schacPersonalUniqueID	UniqueID (or similar)
2	The subject’s legal last name or surname.	FamilyName (Mandatory)	sn (LDAP “surname”)	FamilyName
3	The subject’s primary given name.	FirstName (Mandatory)	givenName	GivenName
4	The subject’s date of birth (e.g., YYYY-MM-DD).	DateOfBirth (Mandatory)	schacDateOfBirth (if used)	DOB
5	The subject’s name at birth if different from current FamilyName/FirstName.	BirthName (Optional)	—	—
6	City, region, or country where the subject was born.	PlaceOfBirth (Optional)	schacPlaceOfBirth (if used)	—
7	The subject’s gender marker (e.g., “M”, “F”, “X”).	Gender (Optional)	schacGender (less common)	—
8	The subject’s current residential/postal address.	CurrentAddress (Optional)	—	Address
9	The subject’s email address, often used as a primary digital contact.	— (Not in base eIDAS set)	mail	Email
10	The subject’s telephone contact number.	—	telephoneNumber (less common)	Phone
11	The country (or countries) of which the subject is a citizen.	— (Some eIDAS profiles define “citizenOf”)	schacCountryOfCitizenship	—
12	Common in academia to indicate membership/role at an institution (e.g., “student@univ.edu”).	—	eduPersonScopedAffiliation, eduPersonAffiliation	—
13	Often used as a login identifier in academic federations (e.g., “username@institution”).	—	eduPersonPrincipalName	—
14	The subject’s ORCID iD, commonly used in research communities.	—	eduPersonOrcid	—
15	Specifies rights or privileges assigned to the subject (e.g., “license to use resource X”).	—	eduPersonEntitlement	—
16	Allows an IdP to express identity assurance qualifiers (e.g., identity verification level).	—	eduPersonAssurance	—
17	The subject’s preferred language or locale (e.g., “en”, “fr”).	—	preferredLanguage (not standard, but used in some LDAP schemas)	—
18	A name string suitable for display (e.g., “Dr. Jane Smith”).	—	displayName (commonly used)	DisplayName or FullName
19	The subject’s additional forename(s) or initial(s).	—	Could be part of givenName or separate attribute in some deployments	MiddleName (if used)
20	A chosen or informal name different from the person’s legal name.	—	eduPersonNickname (rarely used)	—
21	Honorific or title (e.g., “Mr.”, “Dr.”), if separately stored.	—	Sometimes schacSn1/schacSn2 or local attribute	NameTitle (if used)
22	The name of the subject’s affiliated organization (e.g., an employer, a university).	—	o (LDAP “organizationName”)	—
23	The department or unit in which the subject works/studies.	—	ou (LDAP “organizationalUnitName”)	—
24	The postal or ZIP code in the subject’s address.	— (part of CurrentAddress if used)	postalCode (if used)	Part of Address
25	The city/locality or state/province in the subject’s address.	— (part of CurrentAddress)	l (LDAP “localityName”) or st (“stateOrProvinceName”)	Part of Address
26	The country in the subject’s address.	—	c (LDAP “countryName”)	Part of Address
27	The subject’s time zone (rarely used as an identity attribute).	—	Not typically standardized in REFEDS	—
28	A user’s photograph, if stored. Rare in official ID frameworks, but sometimes used in enterprise directories.	—	jpegPhoto or thumbnailPhoto (LDAP)	Photo (if used)
29	X.509 certificate(s) associated with the subject.	—	userCertificate (LDAP)	—
30	A contact detail for IM (Jabber, Slack, etc.), if stored.	—	mozillaSecondEmail/custom LDAP attributes	—
31	The country portion of place of birth, if separately stored.	PlaceOfBirth can include country	schacPlaceOfBirth (may store country sub-field)	—
32	Indicates whether the name is a legal name, preferred name, alias, etc.	—	Some deployments add a “type” attribute or flags	NameType (if used)
33	The user’s “login handle” for single sign-on, which may or may not be the same as the unique identifier.	—	Typically eduPersonPrincipalName or local LDAP “uid”	Username (if used)
34	Indicates the strength of identity proofing or credential security. Not strictly a personal attribute, but often included in identity federation contexts.	Not an attribute, but eIDAS LoA (Low/Substantial/High)	eduPersonAssurance or refedsAssurance	AssuranceLevel (Kantara IAL/AAL)

presents all the attributes used to identify users in the eIDAS, REFEDS, and Kantara frameworks

All of the attributes mentioned above, which are used in different federations, should be consolidated into a common set of attributes that can be adapted and linked through the IdP proxy component. This component must be capable of implementing logic for the translation of various attributes into a format that is suitable for each federation [32].

When the IdP proxy is used between federations such as eIDAS, REFEDS, and Kantara, several unifying attributes are necessary to ensure simplified, secure, and unified access to various services. The IdP proxy acts as an intermediary node, serving as a link between IdPs and SPs, and requires a common set of attributes to enable interaction between different federations.

One of the key attributes within SAML authentication assertions, defined in all federations, is the name identifier (or NameId) [33]. This attribute can have different formats, but the most common formats are:

• urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
• urn:oasis:names:tc:SAML:2.0:nameid-format:transient

The properties of NameId formats are presented in

Table 5. Name identifier attribute formats within SAML2 authentication assertions.

Identifier/Attribute	Persistent	Revocable	Reassignable	Opaque	Targeted	Portable	Global	Qualifier
SAML2 Transient NameID	No	N/A	N/A	Yes	N/A	N/A	Yes	N/A
SAML2 Persistent NameID	Yes	Yes	No	Yes	Yes	Yes	No	Issuer ID

. NameId is a unique, persistent, non-reassigned identifier for the entity. This attribute contains a unique identifier that is understandable and acceptable to all participating federation members. We refer to this attribute as a persistent identifier.

Based on Table 5, where some attributes use N/A (Not Applicable), meaning they are not applicable to that type of identifier because they do not make sense in the context of its function, and considering that not all federations use the same attribute to represent the NameID for user identification and authentication, and that not all federations require the same credentials for user identification, there is a need for the harmonization and mapping of NameID attributes within the IdP proxy [34].

The formats of persistent identifiers vary across different federations. eIDAS uses the eIDAS unique identifier (EUID) in the format COUNTRYCODE-UUID, which combines a country code and a unique number to ensure a stable identity for citizens and organizations utilizing government services [33]. REFEDS employs attributes such as eduPersonUniquedID, formatted as username@domain, which are unique within an educational institution and remain unchanged over time. The Kantara Initiative supports the use of persistent identifiers (PIDs), which can be a SHA256-based hash (SHA256_HASH), to ensure a high level of privacy, and it remains persistent even when the user changes institutions or services.

As each federation uses different identifier formats, the main challenge is adapting and converting them into a format which is acceptable to the receiving federation. When a user performs authentication, the IdP proxy utilizes a transformation method for the NameId format, based on the source federation (e.g., eIDAS unique identifier from eIDAS, eduPersonUniqueId from REFEDS, and persistent identifiers from Kantara) and applies a transformation algorithm that adapts the identifier according to the REFEDS format.

When a user registered in the REFEDS federation authenticates to an eIDAS-based service, their unique identifier—known as eduPersonUniqueId—must be transformed into an eIDAS nique identifier. This transformation is carried out through a structured process.

First, the IdP proxy analyzes the eduPersonUniqueId to extract the domain of the academic institution where the user is registered; in this case, “university.edu”. From the domain, the user’s country of origin is determined using a predefined mapping table. For example, if the institution’s domain is university.edu, the system categorizes it as MK for North Macedonia.

To ensure the identifier is both unique and persistent, the IdP proxy generates a UUID (universally unique identifier). This identifier is an alphanumeric string that does not repeat, guaranteeing that the user’s identity remains unaffected by future changes.

In the final stage, the IdP proxy concatenates the national prefix with the generated UUID, thereby creating a complete eIDAS unique identifier. This composite identifier ensures a robust and stable structure, adhering to the privacy and security standards required in an inter-federation environment.

If the function transformRefedsToEidas() uses the country code “MK” for the domain “university.edu” and generates a random UUID, then the result may look like this: [eIDAS ID: MK-3f9b2a1d4c7e8f6a]. The transformation of attributes from REFEDS to eIDAS is detailed below, based on a practical implementation of this procedure using the PHP programming language. This process involves defining security levels and utilizing standard methods for the transformation and unification of attributes, in compliance with the requirements of inter-federation identity management.

• function transformRefedsToEidas($eduPersonUniqueId) {
•   // Extract the domain to determine the country
•   $parts = explode("@", $eduPersonUniqueId);
•   if (count($parts) != 2) {
•     throw new Exception("The identifier format is not valid.");
•   }
•   $username = $parts[0];
•   $domain = $parts[1];
•   // Assign the country based on the domain (this can be customized)
•   $countryMap = [
•     "university.edu" => "MK", // North Macedonia
•   ];
•   $countryCode = $countryMap[$domain] ?? "XX"; // XX for unknown cases
•   // Generate a unique UUID for this user
•   $uuid = uniqid("", true); // Simulating a UUID
•   // Create the eIDAS ID format
•   $eidasId = strtoupper($countryCode) . "-" . md5($uuid); // Hash for uniqueness
•   return $eidasId;
• }
• // Testing the function
• $eduPersonId = "john.doe@university.edu";
• $eidasId = transformRefedsToEidas($eduPersonId);
• echo "eIDAS ID: " . $eidasId;

The interaction between different identity federations requires a clear mechanism for transforming user identifiers while preserving privacy, security, and compliance with the standards of each federation.

When a user registered in eIDAS wants to authenticate to a REFEDS-supported service, the IdP proxy converts the eIDAS unique identifier into a format suitable for REFEDS, using eduPersonTargetedID as the unique identifier for this federation. To protect user privacy and data integrity, the IdP proxy does not directly transfer the eIDAS unique identifier to REFEDS. Instead, it stores a hashed version of it, using a secure algorithm (e.g., SHA-256) to generate a unique, irreversible identifier. This hash ensures that the original information remains unrecoverable, while still allowing the user to be uniquely identified within the REFEDS federation. Next, the IdP proxy analyzes the eIDAS unique identifier and extracts the COUNTRYCODE to determine an appropriate domain for the REFEDS federation. For example, if the user is registered with an eIDAS service operating in North Macedonia (MK), the suitable domain might be idp.mk.refeds.org.

To create an identifier that aligns with REFEDS standards, the IdP proxy extracts a portion of the UUID from the eIDAS unique identifier to construct a unique username. The final identifier for the REFEDS federation follows the standard eduPersonUniqueId format, represented as an email-style address, which will be formatted similarly to [ID: a1b2c3d4@university.edu]

The transformation of attributes from eIDAS to REFEDS is illustrated through a PHP-based implementation below. This implementation demonstrates the methodology for processing and harmonizing user attributes, while ensuring the integrity of data and compliance with international identity management standards.

• function transformEidasToRefeds($eidasId) {
•   // Parse the eIDAS format
•   $parts = explode("-", $eidasId);
•   if (count($parts) != 2) {
•     throw new Exception("The eIDAS ID format is not valid.");
•   }
•   $countryCode = $parts[0];
•   $uuid = $parts[1];
•   // Map of countries to REFEDS domains
•   $domainMap = [
•     "MK" => "university.edu",
•   ];
•   $domain = $domainMap[$countryCode] ?? "unknown.edu";
•   // Generate a username based on UUID
•   $username = substr($uuid, 0, 8); // Use the first 8 characters of the UUID
•   // Form the REFEDS identifier
•   $eduPersonId = $username . "@" . $domain;
•   return $eduPersonId;
• }
• // Testing the function
• $eidasId = "DE-a1b2c3d4e5f67890abcdef1234567890";
• $refedsId = transformEidasToRefeds($eidasId);
• echo "REFEDS ID: " . $refedsId;

The Kantara Initiative requires a high level of protection for personal user data. To meet this standard, the IdP proxy must support advanced authentication methods, such as multi-factor authentication (MFA), and known identity assurance levels referred to as levels of assurance (LoAs). LoA-based security levels are utilized by both the eIDAS and REFEDS federations; however, while eIDAS employs high-security levels for government services, REFEDS focuses on access for academic purposes.

In the Kantara Initiative, users are identified through persistent identifiers (PIDs), and the attributes that can be utilized are those that support secure authentication, including the following: persistent identifiers (PIDs), used to uniquely and consistently identify users across different systems and services; multi-factor authentication (MFA), which allows for the verification of users by requiring two or more forms of authentication; and LoA, which ensures high levels of trust through the use of strong authentication methods such as two-factor authentication and knowledge-based verification. In this context, attributes such as eduPersonUniqueId and eduPersonAssurance are used to securely establish and verify the user’s identity.

If a user registered in Kantara wants to access services provided by eIDAS, the IdP proxy uses the eduPersonUniqueId attribute to generate an eIDAS unique identifier. This procedure ensures the creation of a secure and unique identifier for the user, meeting the strict requirements of identity management in inter-federation environments. The transformation process is carried out in several steps: First, the user’s trust level is determined based on the LoA concept. As eIDAS operates with different levels of assurance (ranging from LoA/low to LoA/high), the eduPersonAssurance attribute from Kantara is mapped to these levels. This step is essential to determine the security measures to be used during authentication.

After determining the security level, a PID is used, which is a persistent identifier used in the Kantara environment. In this case, the PID reflects a unique identifier, to which a national prefix is added (e.g., “MK-” for Macedonia), helping to categorize the identifier by geographic or institutional location. Then, to ensure global uniqueness, a UUID (globally unique identifier) is generated and joined to the modified PID. As a result, a unique hash is created, forming a common identifier in the format required by eIDAS, with the following format: Kantara Persistent ID:

• 8c6976e5b5410415bde908bd4dee15dfb16e2536a4f1f6d6b88f0b8d1e7a5679.

As an example, a PID in Kantara formatted as PID-1234567890 will be transformed by adding the national prefix “MK-” and integrating a unique UUID, resulting in a correctly formatted and standardized eIDAS unique identifier.

This transformation mechanism not only guarantees the assurance of identity, but also respects international data management and privacy standards. Through the use of advanced cryptographic methods and standardized algorithms for UUID generation, the system ensures the secure and reliable handling of user data, minimizing the potential risks of information retrieval or manipulation. In this way, the interaction between Kantara and eIDAS systems becomes stable, secure, and in line with strict industry requirements.

• function transformKantaraToEidas($kantaraPID, $kantaraAssurance) {
•   // Mapping LoA from Kantara to eIDAS
•   $loaMapping = [
•     "low" => "LoA/low",
•     "medium" => "LoA/substantial",
•     "high" => "LoA/high"
•   ];
•   // Determining the country prefix for eIDAS
•   $countryCode = "MK"; // Can be retrieved from Kantara attributes
•   // Using PID and creating the eIDAS Unique Identifier
•   $hashedId = hash("sha256", $kantaraPID); // Hashing PID for high security
•   $eidasUID = strtoupper($countryCode) . "-" . substr($hashedId, 0, 16); // Creating eIDAS UID
•   // Mapping LoA from Kantara to eIDAS
•   $eidasLoA = isset($loaMapping[$kantaraAssurance]) ? $loaMapping[$kantaraAssurance] : "LoA/low";
•   return ["eIDASUID" => $eidasUID, "LoA" => $eidasLoA];
• }
• // Testing the function
• $kantaraPID = "PID-1234567890";
• $kantaraAssurance = "high";
• $eidasData = transformKantaraToEidas($kantaraPID, $kantaraAssurance);
• echo "eIDAS Unique Identifier: " . $eidasData['eIDASUID'] . "\n";
• echo "eIDAS Level of Assurance: " . $eidasData['LoA'] . "\n";

To allow users to be identified without the need for different credentials to access various federations, a token which is acceptable across all federations is needed to link the user’s credentials.

Figure 9 illustrates the operation performed at the service layer using the IdP proxy. This type of operation requires a clear action from the user. If the translation or generation of the token occurs in one of the federations where the user wishes to authenticate, the token translation acts as a “bridge” between the user’s authentication and authorization and the final created credentials [32]. The TTS retrieves user information (e.g., name, email, LoA, etc.) to generate the credentials that will be used to access the service on behalf of the user. In this case, additional information for the user must be provided [8].

The generation of certificates is crucial for each federation to meet various security requirements. eIDAS primarily uses certificates based on the eIDAS LoA scheme, while REFEDS employs the eduGAIN certificate, supporting the “eduPersonPrincipalName” and “eduPersonUniqueId” attributes for unique user identification, but also uses SAML (Security Assertion Markup Language)-based authentication certificates. The Kantara Initiative uses multi-factor authentication (MFA) certificates and also supports the identity assurance framework (IAF). These certificates and security levels are integrated into the IdP proxy to align with the specific requirements of each federated system, ensuring secure access in accordance with privacy and security standards.

6. Conclusions

The integration of an IdP proxy as an intermediary within federated identity systems provides a sustainable solution for addressing the complexities of interoperability, dynamic LoA requirements, and policy alignment among the eIDAS, REFEDS, and Kantara frameworks. By enabling the translation of attributes, adaptation of protocols, and harmonization of assurance levels, the IdP proxy plays a pivotal role in creating a unified and secure system for electronic identity management. This approach not only enhances technical and operational interoperability but also strengthens trust and collaboration among federations, ensuring that identity-related solutions are user-centric, secure, and efficient across diverse electronic environments.

This study provides a detailed examination of federated identity management through the implementation of an extended identity provider proxy (IdP proxy) model. It specifically addresses issues regarding interoperability and dynamic LoAs among the major identity frameworks—namely, eIDAS, REFEDS, and Kantara—within the context of educational institutions. The key findings indicate that the extended IdP proxy can significantly enhance authentication processes by efficiently translating attributes, harmonizing protocols, and dynamically managing assurance levels across different federations. This greatly contributes to the achievement of technical interoperability, increasing trust and ensuring compliance with various regulatory requirements.

SAML remains the most common protocol across eIDAS, REFEDS, and Kantara, while the additional integration of OpenID Connect (OIDC) and OAuth—particularly within REFEDS and Kantara—adds complexity to the protocol harmonization process. The extended IdP proxy resolves this issue by implementing protocol translation mechanisms that enable seamless data exchanges across these frameworks.

Attribute harmonization emerges as a fundamental challenge, as each federation defines a specific set of mandatory and optional identity attributes. This issue was examined in detail in Section 5, and the harmonization mechanisms and their impacts on cross-federation interoperability were thoroughly analyzed. The extended IdP proxy model enables the harmonization of attributes across different federations through attribute translation and the use of hashing algorithms to convert them into standardized and interoperable formats, thereby reducing the risk of attribute mismatches between disparate systems. This approach not only enhances the consistency and accuracy of user identification in a cross-federation context, but also contributes to the development of a more reliable and efficient ecosystem for electronic identity management. The practical implications of this model include improved technical interoperability, facilitation of inter-institutional integration, and enhanced user experience in environments with varying security and compliance requirements.

Considering the varying authentication requirements driven by the sensitivity of services and risk assessments across different federations, the extended IdP proxy model provides a dynamic approach for the management of levels of assurance. Utilizing algorithms to map LoA levels (e.g., mapping Kantara LoA to eIDAS security standards), the model ensures smooth and secure access control across federations, adapting authentication levels dynamically in response to contextual and federation-specific risk profiles. This method significantly enhances flexibility, security, and convenience for users, overcoming the limitations of the static LoA mechanisms traditionally utilized in cross-federation scenarios.

The central role of the IdP proxy as an intermediary node greatly enhances security and privacy within identity federations. In particular, centralized authentication management allows for stricter control over security practices such as multi-factor authentication (MFA), encryption, and compliance monitoring.

The implementation of an extended identity provider proxy (IdP proxy) model represents an advanced and sustainable approach to improving federated identity management practices, particularly in environments where various standards and requirements coexist, such as those integrating eIDAS, REFEDS, and Kantara. Through the harmonization of authentication protocols, the translation of attributes, and dynamic LoA management, this model ensures high interoperability, enhances security, and strengthens inter-federation trust. Additionally, it significantly improves the user experience by providing a secure, tailored, and streamlined approach. However, this approach requires a sophisticated technical infrastructure, good institutional coordination, and a commitment to continuous compliance with standards and regulatory requirements.

This study creates several promising directions for future research, such as integrating emerging technologies including blockchain and decentralized identity (self-sovereign Identity) to further enhance security and user autonomy.