Digital ecosystems of federated identity can provide new and interesting benefits; however, they have not yet reached full maturity. It is essential to continuously stay up to date with technological and security improvements, including carefully considering all identity recognition requirements that are expected of the consumer-provider relationship. The many services offered through the Internet require a technological method that is both practical and secure to accurately verify ownership of a digital identity to access desired resources. In addition, in certain situations it is critical to be able to prove with certainty the identity of the individual who is using the digital authentication credentials.
Access to digital resources is an operation fundamentally governed by technology. It is implemented by having a client in the role of requesting access to resources to communicate with a server in the role of resource manager through four steps:
- Identification—Presentation of one's credentials to access the resource
- Authentication—Recognition of ownership to use those credentials
- Authorization—Assignment of access rights linked to those credentials
- Accountability—Tracking of activities to demonstrate the correctness of the operations
These steps constitute the mechanism for recognizing the consumer (i.e., a real individual acting as a digital user) and authorizing access to the resources managed by the service provider. This is a secure and uncomplicated system when the authentication domain involves users from a single organization, but it becomes more complex when it involves users associated with different domains than those of the provider. In this case, the solution is provided by a federated identity system.1 Within the recognition mechanism, a trusted third party (i.e., identity provider [IdP]) is introduced between the consumer and the service provider for the sole purpose of guaranteeing the identity of a consumer who wants to access the service provider's resources.
The use case of a federated identity digital ecosystem is based on the interaction of three actors (figure 1). Figure 2 shows the same representation but according to a time sequence. The consumer, or client, is a digital user who possesses a right to access the resource and is often referred to as the resource owner. Through the user agent (e.g., an application or browser installed on the client’s device), the consumer requests access to the resources stored by the resource server from the process that manages access to the service provider's resources, known as the relying party. The relying party prompts the user for credentials and the recognition token issued by the IdP (i.e., the trusted actor arbitrating the identification match). The relying party verifies with the authentication server that the recognition token is valid. If the verification result is positive, the relying party requests the resources from the resource server and sends them to the user agent to be presented to the user.
1. The user (i.e., the resource owner) requests access to a service or resource through a browser or application.
2. The user agent (i.e., the client or web browser) contacts the relying party to access the service or resource.
3. The relying party initiates the authentication process via the user agent.
4. The user agent requests the access token from the authorization server.
5. The authorization server requests credentials from the resource owner via the user interface.
6. The resource owner uses its own credentials to authenticate itself on the authorization server.
7. The authorization server returns the recognition token to the user agent for access.
8. The user agent requests resources by sending the token to the relying party.
9. The relying party presents the token to the authorization server to obtain confirmation of identity.
10. The authorization server responds to the relying party adding the data it needs to securely send the resource.
11. The relying party notifies the resource server of the user agent request adding the information to encrypt.
12. The resource server sends the protected resource to the relying party.
13. The relying party sends the protected resource to the user agent.
14. The user agent presents the plain-text resource to the resource owner.
The access process is triggered by the user and concludes with access to the resource being granted (or denied in the case of authentication failure). This model requires that the actors, consumer and service provider already have their identification data registered on the IdP's system before access to resources can be activated. The IdP on which the entire digital ecosystem is based is at the center of the data network—but this topology is not optimal in terms of service continuity. Another problem is the provision of personal data to various IdPs if resources from different ecosystems need to be accessed.
This model is simple and effective. However, as large as it is, the ecosystem does not represent the entire Internet, nor does it provide robust mechanisms to create links between digital identity and physical identity. The IdP is a critical resource that is required to undergo constant technological upgrading, offer protection of the personal data collected, and guarantee service availability. The identification process is well-defined and highly functioning within a specific ecosystem, but it lacks a satisfactory overall solution across ecosystems. The issue of federated identity should be reconsidered holistically, starting with the functionality expected by the consumer rather than the perspective of technological enhancement of the ecosystem.
Limits and Expectations of Federated Identity
There are at least three different types of identification to consider: the device, the digital user and the physical individual. The solutions for identifying devices are plentiful, secure and suitable for various needs. For example, the smartphone is automatically geolocalized in its movement using International Mobile Equipment Identity (IMEI)2 and Integrated Circuit Card ID (ICCID)3 codes. The solutions for recognizing the validity of a digital user have varying degrees of reliability depending on the needs of the operation or the value of the protected resources. They also have different costs and implementation or use complexities. Solutions range from a simple personal identification number (PIN) to sophisticated measures such as those in the strong authentication class. The wide range of options makes it relatively simple to find a solution that is appropriate for its intended use.
A registration mechanism that is mindful of the individual’s rights regarding personal data and, therefore, only requests the data necessary for identification and guarantees lawful processing of the data creates trust.
In contrast, identifying with certainty which individual possesses a username on the Internet does not have the same simplicity and available tools or solutions. There are situations wherein one’s real identity must be made certain for legal reasons (either for service delivery or to enable public authority investigations). In addition, there may be a need to ensure lawful anonymity. However, in many cases, it may be unnecessary to do so if the use of digital identity alone already meets the requirements to access resources. For example, within an organization, digital identity is adequate because it is combined with the physical controls already applied to the individual entering the building. The same is true for a newspaper subscription or online purchase, wherein the most important thing is the payment made and not necessarily who initiated it.
The manner of assigning access credentials to an individual is also of particular importance. The process of combining individual data with those of digital identity affects the risk of privacy, fraud and identity theft. A registration mechanism that is mindful of the individual's rights regarding personal data and, therefore, only requests the data necessary for identification and guarantees lawful processing of the data creates trust. Legitimate respect for privacy is a right that cannot be infringed on, but at the same time it must be possible for authorities to take action in cases of alleged crime.
As mentioned, the identity recognition system must be able to transcend the limits of the single authentication ecosystem without requiring a new registration or complex protocols to federate digital ecosystems with each other. Rather, the solution must be built by acting on the authentication mechanism, creating a system of trust on the identity attributed to the single user by means of verifiable guarantees at the time of the access request. Of course, this must be achieved while abiding by the laws of the country of origin of the individual, with the goal of allowing:
- Service providers to eliminate the idea that the identity authentication process has no value for business objectives
- Users to use a single identity with eventual legal value in accessing networked services regardless of their home ecosystem
- Authorities, if appropriate, to intervene to prosecute crimes without infringing on individual freedoms with overly intrusive methods
Achieving a Sustainable Federated Digital Identity Scheme
To reexamine the functioning model of the federated identity, it is necessary to holistically review all areas in which weaknesses have been identified to determine the objectives. There are nine principles that may be used to model the desired federated identity system according to an operational paradigm based on trust, which is only built through a transparent and verifiable mechanism:
- The digital identity can be cancelled or deleted without impacting the physical identity.
- The digital identity must be linkable to the physical identity in a verifiable manner.
- Only the authority that legally manages the individual's physical identity can verify this link.
- The authentication system must be flexible (i.e., able to adapt to technological evolutions or emerging needs).
- The authentication system must be accessible to all (i.e., without discriminatory costs).
- The authentication system must be secure (i.e., continuously aligned with security best practices).
- The authentication system must be privacy-friendly (i.e., not requiring any personal information unless strictly necessary).
- The authentication system must be resilient (i.e., with availability appropriate for needs and the ability to cope with adversity).
- Authentication system technology must be open (i.e., able to evolve based on transparent shared standards and verifiable developments).
These principles should be followed consistently despite limitations. The modeling of the desired identity system can be developed starting from the current model of federated identity and adapting it until it follows all nine principles. To foster mutual trust between the actors involved in the identification process, a twofold change in the federated identity model is necessary:
- Ensure mutual recognition to assure the consumer of the identity of the provider.
- Ensure the ability to validate consumer and supplier digital identities against their real-world identity.
Creating a Symmetric Authentication Scheme
A federated identity digital ecosystem based on symmetric authentication4 represents a scenario wherein one does not need to change one's IdP to access resources in another ecosystem (figure 3). Figure 4 shows the same representation but according to a time sequence. The authentication flow is conceptually not too dissimilar from the current scheme, except that the authentication is dual in that both the client (resource owner) and the server (service provider) must authenticate themselves on their own IdP. Then, the respective authentication servers, client-side and server-side, exchange recognition tokens over a dedicated IdP connection and close the authentication cycle.
1.-2. The relying party requests authentication from the service provider’s authentication server and receives the server token.
3.-5. The resource owner requests access to the resource via the user agent and the relying party activates the authentication process with the server token.
6.-9. The user agent requests the client token from the client’s authentication server and sends the relying party’s server token. The client’s authentication server requests credentials from the resource owner and returns the client token to the user agent.
10.-11. The user agent requests the resource from the relying party by sending its client token. The relying party requests the client’s authentication server to verify the client token.
12.-15. Both the service provider’s and the client’s authentication servers verify the tokens. The client’s authentication server informs the user agent of the outcome and the service provider’s authentication server responds to the relying party.
16.-17. The relying party notifies the resource server of the user agent's request. The resource server returns the protected resource to the relying party.
18.-19. The relying party sends the protected resource to the user agent. The user agent presents the plain-text resource to the resource owner.
Every digital authentication ecosystem is based on an IdP and composed of all resources that rely on the same IdP to authenticate. IdPs must be in peer-to-peer relationships with each other, and it is most appropriate for them to communicate over a dedicated overlay network. This increased complexity has a negligible impact on the overall authentication process and has several advantages:
- The same username is recognized in all ecosystems adhering to this scheme, so the trusted provider does not need to change.
- Those who authenticate are assured of the identity of the counterparty, which reduces the risk of fraud.
- In the event of a compromise of one's IdP, it can be changed without losing its effectiveness by requesting a digital identity from another, which leads to greater resilience.
To easily identify the name of the IdP associated with the authentication credentials without requiring additional information from the user or extracting it from the authentication message, one can use the structure of the username by following the same technique used for an email address.5 The username will consist of a prefix (i.e., the name chosen by the user for identification in the ecosystem) concatenated with the @ symbol and followed by a suffix identifying the domain of the IdP that provided the username.
Forming Two Categories of Identity Providers
Accessing digital ecosystems other than one's own with the same username is useful for reducing communications of personal data, but it does not completely resolve the issue of their treatment. Sometimes IdPs require an excessive amount of personal data to have a guarantee of physical identity when registering a new user. Ideally, the user should be able to provide consent when selecting which personal data to disclose to the IdP.
Instead of using personal data for this purpose, the solution is a highly trusted IdP that acts as a guarantor to other IdPs of the user's identity. This feature effectively divides IdPs into two categories: the IdPs that manage only the digital identity and the IdPs that can also manage individuals’ personal data and are therefore the individuals’ custodians (figure 5). Figure 6 shows the same representation but according to a time sequence. This second type of IdP is known as an identity custodian (IdC). Ideally it should be the same public authority that is responsible for physical identification cards and should follow the same rules for collecting registration data.
1.-3. The resource owner requests the new identity via the user agent, and the relying party activates the authentication process with the IdP token.
4.-7. The user agent requests the identification token from the IdC and sends the IdP token. The IdC requests credentials from the resource owner and returns the identification token to the user agent.
8.-9. The user agent requests the new identity from the relying party by sending the identification token. The relying party requests the IdP to verify the identification token.
10.-13. The IdP and IdC verify the tokens. The IdC informs the user agent of the outcome and the IdP responds to the relying party with the new identity.
14.-15. The relying party sends the new identity to the user agent. The user agent presents the new identity to the resource owner.
In this scenario, it is likely that the IdPs define their own rules for the handling of personal data, but they must use a common standard with other IdPs for the management of authentication messages. IdCs, the sole guarantors of the link between physical and digital identity, issue a digital identity with legal value to identify the individual with certainty in all digital processes that require it (e.g., registering with an IdP to issue a new normal digital identity).
Registration Mode
The registration of the identifying information of an individual to allow authentication on a network can take place in three different ways depending on the final recipient of the personal data. The goal must always be to minimize the data conferred and, before doing so, allow the data subject to express consent.
Registration With the IdC
The IdC has the legal authority to hold all personal data essential to accomplish the process of recognizing the real individual and is subject to the laws of the individual's home country. The amount of personal data treated by the IdC for the issuance of the legal digital identity is equal to the necessary data for the issuance of a physical identity card, plus any data needed for the identification protocol in the digital ecosystem.
Registration With the IdP
The registration sequence begins with the user's request to the IdP for a digital identity. The IdP forwards the request to the IdC for confirmation of the identity and, upon successful completion, issues the digital identity. The IdP needs only administrative data points and any parameters issued by the IdC to implement identity verification. Any additional data can only be provided after the data subject's consent. The IdC keeps track of all requests it receives. To avoid inconsistency of data over time, it is also necessary for the data subject to formally manage the termination of the relationship with the IdP and notify the IdC.
Registration With the Service Provider
The service provider needs to know only the data necessary to provide the service and nothing more. To avoid the repeated registration of personal data with various service providers, it is possible to transfer the data request from the service provider to its IdP. The latter routes the request to the user's IdP, which goes back to the IdC. The IdC requests the user's consent to send and arranges to forward what is requested in an encrypted manner. The deencrypted key is provided to the user who forwards it (automatically by the user agent) to the service provider closing the request.
In the case of changing the data registered with the IdC, it would not be too complex to manage synchronization across all service providers in push mode. The IdC keeps track of all service providers contacted in the past by the user, and the user can choose which one to update automatically. Even the notice of removal of personal data may be formalized with an exchange of messages from the IdC to the service providers when the service is closed. Of course, it is the responsibility of the final recipient to update their database. Thus, in case of a dispute, there would be evidence of the removal request.
Operating Mode
Upon analyzing the identification process with respect to user needs, two modes of authentication emerge, each with different transaction flows. The flow to access online services with use of IdPs only is simple and quick, while the other flow, with specific needs for legal evidence of the operation, is more complex and requires additional steps.
Simple Authentication
Recognition for access to services is entirely managed by the IdP, without involvement of the IdC, in all cases where simple digital authentication satisfies all service delivery requirements (e.g., ecommerce, wherein it is crucial to have a valid payment service associated with the username but real identity is not considered a critical factor).
Legal Authentication
In this case, the request can only be resolved with confirmation of the IdC, which implies that the process is tracked and preserved for legal proof purposes. This process is used for access to services where it is necessary to formally attribute the identity of the physical individual (e.g., applying for a new passport6 or electronic voting7).
To improve the service provider's ability to control access to authorization of services, some data may be left in the management of the IdP (shared with the resource server) to be used as a filter (e.g., a flag to attest to the age or nationality). These may be provided by the IdC during user registration and could possibly be updated by the IdC if a change should occur.
Digital identity may be used as a generic contact tool. This enables the IdP to provide new services and improve its business perspective. For example, a username could also be used as an email address. The IdP associates the user (public) with the personal email box (hidden). Then, it rotates the incoming messages on the personal email box so that the possible response shows the user as the sender. In addition, it may create rules to route only some messages and not others.
Digital identity could also be used as a telephone identifier; the telephone device contacts the IdP, which activates a routing service on the final number without making it known to the caller. A digital identity could be used as the client name for a messaging application, again with the IdP routing the request to the desired application. The IdP can be seen as a system that creates, stores and manages digital identities, but also acts as a type of domain name system (DNS) server for translating (i.e., anonymizing) information and as a router for routing data to the right recipient. Combined, these capabilities can generate new applications to increase the (business) value of the IdP offering Authentication-as-a-Service (AaaS).
Conclusion
Basing digital identity recognition on trust is possible if the actors who request access and those who provide a service have the availability of a usable, secure and transparent mechanism. Trust is placed on an intermediary, chosen independently by each actor on the basis of convenience. These intermediaries communicate with each other within their own digital ecosystems to ensure proper security in the exchange of authentication messages. The entire burden of recognition falls on the IdPs, simplifying the service provider system and offering the consumer a streamlined and controlled process of registration and identification.
Trust in identity is guaranteed by a reliable subject even when operating in a new digital ecosystem. This is possible without exposing the consumer's personal data to risk. The proposed federated identity system has a symmetric authentication process to allow each actor to recognize the other with security. This mechanism allows the consumer to be assured of the identity of the service provider, strengthening the security of transactions. At the same time, personal data are handled by those who have the authority to do so and are disbursed with the consent of the data subject.
The symmetric system allows control over the identity of the service provider by strengthening security against fraud. For example, if social media required users who post content to use identity credentials based on the mechanism of trust, misinformation would be better controlled. In this way, everyone is responsible for what they publish, with the guarantee of maintaining anonymity to the public while being identifiable by authorities. This does not decrease freedom on the Internet, but it improves the legitimate and informed use of digital tools.
Endnotes
1 Microsoft, “Federated Identity for Web Applications,” 1 October 2013, http://msdn.microsoft.com/en-gb/library/ff359110.aspx
2 International Telecommunication Union, Technical Report: QTR-RLB-IMEI: Reliability of International Mobile Station Equipment Identity (IMEI), Switzerland, 2020, http://www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-CCICT-2020-PDF-E.pdf
3 International Telecommunication Union, “E.118: The International Telecommunication Charge Card,” http://www.itu.int/rec/T-REC-E.118
4 Sbriz, L.; “A Symmetrical Framework for the Exchange of Identity Credentials Based on the Trust Paradigm, Part 1,” ISACA Journal, vol. 2, 2022, http://h04.v6pu.com/archives
5 Internet Engineering Task Force, “Internet Message Format,” October 2008, http://datatracker.ietf.org/doc/html/rfc5322
6 Sbriz, L.; “A Symmetrical Framework for the Exchange of Identity Credentials Based on the Trust Paradigm, Part 2,” ISACA Journal, vol. 2, 2022, http://h04.v6pu.com/archives
7 Sbriz, L.; “How to Digitally Verify Human Identity: The Case of Voting,” ISACA Journal, vol. 1, 2023, http://h04.v6pu.com/archives
LUIGI SBRIZ | CISM, CRISC, CDPSE, ISO/IEC 27001 LA, ITIL V4, NIST CSF, UNI 11697:2017 DPO
Is a lead auditor and a senior consultant on risk management, cybersecurity and privacy issues and has been the risk monitoring manager at a multinational automotive company for more than seven years. Previously, he was head of information and communications technology operations and resources in the Asia and Pacific Countries (APAC) region (China, Japan and Malaysia). Before that, he was a worldwide information security officer for more than seven years. He developed an original methodology for internal risk monitoring, merging an operational risk analysis with a consequent risk assessment driven by the maturity level of the controls. He also designed a cybermonitoring tool based on open-source intelligence (OSINT) and an integrated system involving a risk monitoring maturity model and internal audit. Sbriz was a consultant for business intelligence systems for several years. He can be contacted on LinkedIn at www.linkedin.com/in/luigisbriz or http://sbriz.tel.