Identity: The Evolution of IdM

Traditional Identity

Traditional digital identity, dating back to the 1990s, is rooted in the architecture of computer networks and follows the client-server paradigm. In this model, identity is represented by online accounts, typically created with a username and password. Users had to create separate accounts for each website or domain, resulting in fragmented identities across multiple services. For example, a user needed to register separately for each application, leading to isolated and disconnected digital identities.

To address this fragmentation, identity architects introduced a distinction between the component delivering the service — the Service Provider (SP) — and the component managing identities — the Identity Provider (IdP). However, this separation was mostly semantic: users remained limited to their organization's scope, and applications could not interoperate. This separation between logical domains is illustrated in Figure 1. In this model, users still had to manage multiple identities — one for each IdP or issuer. The red boxes in the figure highlight these logical domains, where applications are tightly bound to their respective IdPs and cannot share identities or data across domains.

Examples include both protocols and software. RADIUS (Remote Authentication Dial-In User Service) is a protocol widely used for controlling access to networks — for instance, when a user connects to a corporate Wi-Fi or VPN, their credentials are verified via a centralized RADIUS server. Another example is CAS (Central Authentication Service), a system that allows users to authenticate once and then access multiple internal applications within the same organization. This approach improves usability but it does not support identity reuse across different organizations.

With traditional identity management models, users had to maintain separate identities for each organization they interacted with.

Federated Identity

Starting in the mid-2000s, loosely coupled applications—such as microservices and mobile web apps—began to require access to user attributes beyond their original domain. In particular, applications started requesting identity assertions—a verified set of user attributes—from external portals. For example, a ride-sharing app that lets users log in via Google or Facebook (the Identity Provider) can securely access user attributes like location or payment methods to support seamless interaction with other services. As a result, the strict separation between domains became a limitation, highlighting the need for a new approach to identity provisioning.

To address this limitation, identity providers—previously tied to specific domains—were decoupled from individual applications and placed outside their original scope. This shift enabled identity assertions to be reused across a wider range of services. For the first time, protocols such as SAML, OAuth, and OpenID Connect (OIDC) were introduced to broker identity across domains by defining the relationships among users, identity providers, and service providers. These developments marked the emergence of federated identity management, as illustrated in Figure 2. As a result, users could access multiple services without needing to create separate accounts or log in repeatedly.

While protocols define the relationships between entities, trust is conveyed through digital artifacts known as tokens. These tokens include metadata such as the issuer, subject, expiration time, and other claims, and act as carriers of trust across applications and domains. Although initially simple, they can be seen as precursors to modern identity proofs, as they encapsulate assertions about an entity's attributes. Over time, tokens were extended to include policy-related information—such as consent decisions—paving the way for early user-centric identity approaches. These aimed to give individuals greater control over how their data and sharing policies were managed.

Self-Sovereign Identity

Since the latter half of the 2010s, the growing emphasis on empowering individuals to control their personal information — driven by decentralized technologies and regulations such as the European General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) — has led to the concept of Self-Sovereign Identity (SSI). SSI promotes a more equitable, interoperable, and privacy-respecting identity model, where individuals are the sole authority over their identity attributes. They retain exclusive custody of their credentials and full control over data sharing and consent management. Unlike traditional models, identity attributes are no longer bound to the issuer; instead, users can present verified assertions to any relying party, regardless of its domain or scope.

Today, Self-Sovereign Identity and user-centric identity are often used interchangeably to describe a vision of identity management that mirrors the offline exchange of claims. Table 1 provides an overview of the identity management across key dimensions.

Aspect	Traditional Identity	Federated Identity	Self-Sovereign Identity (SSI)
Control	Organization-controlled	Shared between IdPs and organizations	Fully user-controlled
Data Custody	Stored by each service provider	Centralized by identity providers	Stored and managed by the user
Interoperability	Limited to single domain	Cross-domain within federation	Cross-domain without pre-established trust
Identity Reuse	Not possible	Within federated systems	Across any service
Trust Model	Based on organizational boundaries	Based on federated agreements	Decentralized, cryptographically verifiable
User Privacy	Limited control and visibility	Moderate control (e.g., consent screens)	Full control; selective disclosure
Credential Issuance	By each service	By trusted identity providers	By any issuer; user collects and reuses
Representative Example	Separate account for each site	Single Sign-On	Presenting a digital credential to any verifier

Table 1. Comparison of Identity Management Models.

Initially, Self-Sovereign Identity did not define a concrete model for managing attributes. However, the W3C Verifiable Credential Data Model 2.0 later introduced a conceptual framework that specifies how attributes are exchanged among three functional roles: the Issuer, the Holder, and the Verifier, optionally supported by a data registry. Unlike traditional identity models, any previous role—such as user, identity provider (IdP), or service provider (SP)—can assume any of these functional roles. For instance, a university may act as an Issuer when issuing diplomas, as a Verifier when validating student records, and as a Holder when presenting legal information about itself.

The proposal from the W3C, illustrated in Figure 3, provides a basic framework that allows implementers to experiment with a wide range of technologies.

The W3C's model was later adopted and extended by the Decentralized Identity Foundation, and implemented in early projects such as Sovrin. It was further refined by the Trust Over IP Foundation (ToIP), which today offers one of the most comprehensive models for interoperable digital trust ecosystems. The ToIP provides a structured approach to identity management, and sets requirements for the design of protocols.

In summary, the evolution of identity management has followed a clear trajectory—illustrated in Figure 4—shifting from account-based models to functional, class-based structures.

On the left side of Figure 4, the Network stage depicts identity as tightly coupled with the Internet's client-server paradigm, where it exists as domain-specific accounts. As cross-domain interactions emerge, these accounts are enriched through relationships between entities. Eventually, with the rise of decentralized identity, new models developed by initiatives such as Sovrin, the Decentralized Identity Foundation (DIF), and the Trust Over IP Foundation (ToIP) support a more fluid and interoperable ecosystem. These models represent early attempts to structure the domain of knowledge, with ToIP in particular providing concrete requirements for designing new decentralized identity protocols.

Rather than focusing solely on the technical requirements of each identity model, the evolution of digital identity can also be understood through the lens of principles and ethical values. From traditional identity to federated systems and, ultimately, Self-Sovereign Identity, this progression reflects a broader shift toward user empowerment, privacy, interoperability, and individual control. Understanding this evolution is essential for designing identity systems that are not only technically robust, but also aligned with fundamental rights and democratic values.