The State of Identity on the Web

The evolution of identity on the web is happening at a rapid pace, with many different projects and efforts converging around similar ideas with their own interpretations and constraints. It can be difficult to parse through all of these developments while the dust hasn’t completely settled, but looking at these issues holistically, we can see a much bigger pattern emerging. In fact, many of the modern innovations related to identity on the web are actually quite connected and build upon each other in a myriad of complementary ways.

The rise of OpenID Connect

The core of modern identity is undoubtedly OpenID Connect (OIDC), the de-facto standard for user authentication and identity protocol on the internet. It’s a protocol that enables developers building apps and services to verify the identity of their users and obtain basic profile information about them in order to create an authenticated user experience. Because OIDC is an identity layer built on top of the OAuth 2.0 framework, it can also be used as an authorization solution. Its development was significant for many reasons, in part because it came with the realization that identity on the web is fundamental to many different kinds of interactions, and these interactions need simple and powerful security features that are ubiquitous and accessible. Secure digital identity is a problem that doesn’t make sense to solve over and over again in different ways with each new application, but instead needs a standard and efficient mechanism that’s easy to use and works for the majority of people.

OpenID Connect introduced a convenient and accessible protocol for identity that required less setup and complexity for developers building different kinds of applications and programs. In many ways, protocols like OIDC and OAuth 2.0 piggy-backed on the revolution that was underfoot in the mid 2000’s as developers fled en-mass from web based systems heavily reliant on technologies like XML (and consequently identity systems built upon these technologies like SAML), for simpler systems based on JSON. OpenID built on the success of OAuth and offered a solution that improved upon existing identity and web security technologies which were vulnerable to attacks like screen scraping. This shift towards a solution built upon modern web technologies with an emphasis on being easy-to-use created ripe conditions for adoption of these web standards.

OIDC’s success has categorically sped up both the web and native application development cycle when it comes to requiring the integration of identity, and as a result, users have now grown accustomed to having sign-in options aplenty with all their favorite products and services. It’s not intuitively clear to your average user why they need so many different logins and it’s up to the user to manage which identities they use with which services, but the system works and provides a relatively reliable way to integrate identity on the web.

Success and its unintended consequences

While OIDC succeeded in simplicity and adoption, what has emerged over time are a number of limitations and challenges that have come as a result of taking these systems to a global scale.

When it comes to the market for consumer identity, there are generally three main actors present:

1. Identity Providers
2. Relying Parties
3. End-Users

The forces in the market that cause their intersection to exist are complex, but can be loosely broken down into the interaction between each pair of actors.

In order for an End-User to be able to “login” to a website today, the “sweet spot” must exist where each of these sets of requirements are met.

The negotiation between these three parties usually plays out on the relying party’s login page. It’s this precious real-estate that drives these very distinct market forces.

Anti-competitive market forces

In typical deployments of OIDC, in order for a user to be able to “login” to a relying party or service they’re trying to access online, the relying party must be in direct contact with the Identity Provider (IdP). This is what’s come to be known as the IdP tracking problem. It’s the IdP that’s responsible for performing end-user authentication and issuing end-user identities to relying parties, not the end-users themselves. Over time, these natural forces in OIDC have created an environment that tends to favour the emergence and continued growth of a small number of very large IdPs. These IdPs wield a great deal of power, as they have become a critical dependency and intermediary for many kinds of digital interactions that require identity.

This environment prevents competition and diversity amongst IdPs in exchange for a convenience-driven technology framework where user data is controlled and managed in a few central locations. The market conditions have made it incredibly difficult for new IdPs to break into the market. For example, when Apple unveiled their “Sign in with Apple” service, they used their position as a proprietary service provider to mandate their inclusion as a third party sign in option for any app or service that was supporting federated login on Apple devices. This effectively guaranteed adoption of their OpenID-based solution, allowing them to easily capture a portion of the precious real-estate that is the login screen of thousands of modern web apps today. This method of capturing the market is indicative of a larger challenge wherein the environment of OIDC has made it difficult for newer and smaller players in the IdP ecosystem to participate with existing vendors on an equal playing field.

Identity as a secondary concern has primary consequences

Another key issue in the current landscape is that for nearly all modern IdPs, being an identity provider is often a secondary function to their primary line of business. Though they have come to wear many different hats, many of the key IdPs’ primary business function is offering some service to end-users (e.g. Facebook, Twitter, Google, etc.). Their role as IdPs is something that emerged over time, and with it has surfaced a whole new set of responsibilities whose impact we are only just beginning to grapple with.

Due to this unequal relationship, developers and businesses who want to integrate identity in their applications are forced to choose those IdPs which contain user data for their target demographics, instead of offering options for IdP selection based on real metrics around responsible and privacy-preserving identity practices for end-users.

This cycle perpetuates the dominance of a few major IdPs and likewise forces users to keep choosing from the same set of options or risk losing access to all of their online accounts. In addition, many of these IdPs have leveraged their role as central intermediaries to increase surveillance and user behavior tracking, not just across their proprietary services, but across a user’s entire web experience. The net result of this architecture on modern systems is that IdPs have become a locus for centralized data storage and processing.

The privacy implications associated with the reliance on a central intermediary who can delete, control, or expose user data at any time have proven to be no small matter. New regulations such as GDPR and CCPA have brought user privacy to the forefront and have spurred lots of public discourse and pressure for companies to manage their data processing policies against more robust standards. The regulatory and business environment that is forming around GDPR and CCPA is pushing the market to consider better solutions that may involve decentralizing the mode of operation or separating the responsibilities of an IdP.

Identity Provider lock-in

Lastly, in today’s landscape there is an inseparable coupling between an End-User and the IdP they use. This effectively means that, in order to transfer from say “Sign In With Google” to “Sign In With Twitter,” a user often has to start over and build their identity from scratch. This is due to the fact that users are effectively borrowing or renting their identities from their IdPs, and hence have little to no control in exercising that identity how they see fit. This model creates a pattern that unnecessarily ties a user to the application and data ecosystem of their IdP and means they must keep an active account with the provider to keep using their identity. If a user can’t access to their account with an IdP, say by losing access to their Twitter profile, they can no longer login to any of the services where they’re using Twitter as their IdP.

One of the problems with the term Identity Provider itself is that it sets up the assumption that the end-user is being provided with an identity, rather than the identity being theirs or under their control. If end-users have no real choice in selecting their IdP, then they are ultimately subject to the whims of a few very large and powerful companies. This model is not only antithetical to anti-trust policies and legislation, it also prevents data portability between platforms. It’s made it abundantly clear that the paradigm shift on end-user privacy practices needs to start by giving users a baseline level of choice when it comes to their identity.

A nod to an alternative model

Fundamentally, when it comes to identity on the web, users should have choice; choice about which services they employ to facilitate the usage of their digital identities along with being empowered to change these service providers if they so choose.

The irony of OpenID Connect is that the original authors did actually consider these problems, and evidence of this can be found in the original OIDC specification: in chapter 7, entitled “Self Issued OpenID Provider” (SIOP).

Earning its name primarily from the powerful idea that users could somehow be their own identity provider, SIOP was an ambitious attempt at solving a number of different problems at once. It raises some major questions about the future of the protocol, but it stops short of offering an end-to-end solution to these complex problems.

As it stands in the core specification, the SIOP chapter of OIDC was really trying to solve 3 significant, but distinct problems, which are:

1. Enabling portable/transferable identities between providers
2. Dealing with different deployment models for OpenID providers
3. Solving the Nascar Problem

SIOP has recently been of strong interest to those in the decentralized or self-sovereign identity community because it’s been identified as a potential pathway to transitioning existing deployed digital infrastructure towards a more decentralized and user-centric model. As discussion is ongoing at the OpenID Foundation to evolve and reboot the work around SIOP, there are a number of interesting questions raised by this chapter that are worth exploring to their full extent. For starters, SIOP questions some of the fundamental assumptions around the behaviour and deployment of an IdP.

OpenID and OAuth typically use a redirect mechanism to relay a request from a relying party to an IdP. OAuth supports redirecting back to a native app for the end-user, but it assumes that the provider itself always takes the form of an HTTP server, and furthermore it assumes the request is primarily handled server-side. SIOP challenged this assumption by questioning whether the identity provider has to be entirely server-side, or if the provider could instead take the form of a Single-Page Application (SPA), Progressive Web Application (PWA), or even a native application. In creating a precedent for improving upon the IdP model, SIOP was asking fundamental questions such as: who gets to pick the provider? What role does the end-user play in this selection process? Does the provider always need to be an authorization server or is there a more decentralized model available that is resilient from certain modes of compromise?

Although some of these questions remain unanswered or are early in development, the precedent set by SIOP has spurred a number of related developments in and around web identity. Work is ongoing at the OpenID Foundation to flesh out the implications of SIOP in the emerging landscape.

Tech giants capitalize on the conversation

Although OIDC is primarily a web-based identity protocol, it was purposefully designed to be independent of any particular browser feature or API. This separation of concerns has proved incredibly useful in enabling adoption of OIDC outside of web-only environments, but it has greatly limited the ability for browser vendors to facilitate and mediate web-based login events. A number of large technology and browser vendors have picked up on this discrepancy, and are starting to take ownership of the role they play in web-based user interactions.

Notably, a number of new initiatives have been introduced in the last few years to address this gap in user privacy on the web. An example of this can be found in the W3C Technical Architecture Group (TAG), a group tasked with documenting and building consensus around the architecture of the World Wide Web. Ahead of the 2019 W3C TPAC in Japan, Apple proposed an initiative called IsLoggedIn, effectively a way for websites to tell the browser whether the user was logged in or not in a trustworthy way. What they realized is that the behavior of modern web architecture results in users being “logged in by default” to websites they visit, even if they only visit a website once. Essentially as soon as the browser loads a webpage, that page can store data about the user indefinitely on the device, with no clear mechanism for indicating when a user has logged out or wishes to stop sharing their data. They introduced an API that would allow browsers to set the status of user log-ins to limit long term storage of user data. It was a vision that required broad consensus among today’s major web browsers to be successful. Ultimately, the browsers have taken their own approach in trying to mitigate the issue.

In 2019, Google created their Privacy Sandbox initiative to advance user privacy on the web using open and transparent standards. As one of the largest web browsers on the planet, Google Chrome seized the opportunity provided by an increased public focus on user privacy to work on limiting cross-site user tracking and pervasive incentives that encourage surveillance. Fuelled by the Privacy Sandbox initiative, they created a project called WebID to explore how the browser can mediate between different parties in a digital identity transaction. WebID is an early attempt to get in the middle of the interaction that happens between a relying party and an IdP, allowing the browser to facilitate the transaction in a way that provides stronger privacy guarantees for the end-user.

As an overarching effort, it’s in many ways a response to the environment created by CCPA and GDPR where technology vendors like Google are attempting to enforce privacy expectations for end-users while surfing the web. Its goal is to keep protocols like OIDC largely intact while using the browser as a mediator to provide a stronger set of guarantees when it comes to user identities. This may ultimately give end-users more privacy on the web, but it doesn’t exactly solve the problem of users being locked into their IdPs. With the persistent problem of data portability and limited user choices, simply allowing the browser to mediate the interaction is an important piece of the puzzle but does not go far enough on its own.

Going beyond the current state of OpenID Connect

Though it is a critical component of modern web identity, OIDC is not by any means the only solution or protocol to attempt to solve these kinds of problems.

A set of emerging standards from the W3C Credentials Community Group aim to look at identity on the web in a very different way, and, in fact, are designed to consider use cases outside of just consumer identity. One such standard is Decentralized Identifiers (DIDs) which defines a new type of identifier and accompanying data model featuring several novel properties not present in most mainstream identifier schemes in use today. Using DIDs in tandem with technologies like Verifiable Credentials (VCs) creates an infrastructure for a more distributed and decentralized layer for identity on the web, enabling a greater level of user control. VCs were created as the newest in a long line of cryptographically secured data representation formats. Their goal was to provide a standard that improves on its predecessors by accommodating formal data semantics through technologies like JSON-LD and addressing the role of data subjects in managing and controlling data about themselves.

These standards have emerged in large part to address the limitations of federated identity systems such as the one provided by OIDC. In the case of DIDs, the focus has been on creating a more resilient kind of user-controllable identifier. These kinds of identifiers don’t have to be borrowed or rented from an IdP as is the case today, but can instead be directly controlled by the entities they represent via cryptography in a consistent and standard way. When combining these two technologies, VCs and DIDs, we enable verifiable information that has a cryptographic binding to the end-user and can be transferred cross-context while retaining its security and semantics.

As is the case with many emerging technologies, in order to be successful in an existing and complicated market, these new standards should have a cohesive relationship to the present. To that end, there has been a significant push to bridge these emerging technologies with the existing world of OIDC in a way that doesn’t break existing implementations and encourages interoperability.

One prominent example of this is a new extension to OIDC known as OpenID Connect Credential Provider. Current OIDC flows result in the user receiving an identity token which is coupled to the IdP that created it, and can be used to prove the user’s identity within a specific domain. OIDC Credential Provider allows you to extend OIDC to allow IdPs to issue reusable VCs about the end-user instead of simple identity tokens with limited functionality. It allows end-users to request credentials from an OpenID Provider and manage their own credentials in a digital wallet under their control. By allowing data authorities to be the provider of reusable digital credentials instead of simple identity assertions, this extension effectively turns traditional Identity Providers into Credential Providers.

The credentials provided under this system are cryptographically bound to a public key controlled by the end-user. In addition to public key binding, the credential can instead be bound to a DID, adding a layer of indirection between a user’s identity and the keys they use to control it. In binding to a DID, the subject of the credential is able to maintain ownership of the credential on a longer life cycle due to their ability to manage and rotate keys while maintaining a consistent identifier. This eases the burden on data authorities to re-issue credentials when the subject’s keys change and allows relying parties to verify that the credential is always being validated against the current public key of the end-user. The innovations upon OIDC mark a shift from a model where relying parties request claims from an IdP, to one where they can request claims from specific issuers or according to certain trust frameworks and evaluation metrics appropriate to their use case. This kind of policy-level data management creates a much more predictable and secure way for businesses and people to get the data they need.

OIDC Credential Provider, a new spec at the OpenID Foundation, is challenging the notion that the identity that a user receives has to be an identity entirely bound to its domain. It offers traditional IdPs a way to issue credentials that are portable and can cross domains because the identity/identifier is no longer coupled to the provider as is the case with an identity token. This work serves to further bridge the gap between existing digital identity infrastructure and emerging technologies which are more decentralized and user-centric. It sets the foundation for a deeper shift in how data is managed online, whether it comes in the form of identity claims, authorizations, or other kinds of verifiable data.

Broadening the landscape of digital identity

OIDC, which is primarily used for identity, is built upon OAuth 2.0, whose primary use is authorization and access. If OIDC is about who the End-User is, then OAuth 2.0 is about what you’re allowed to do on behalf of and at the consent of the End-User. OAuth 2.0 was built prior to OIDC, in many ways because authorization allowed people to accomplish quite a bit without the capabilities of a formalized and standardized identity protocol. Eventually, it became obvious that identity is an integral and relatively well-defined cornerstone of web access that needed a simple solution. OIDC emerged as it increasingly became a requirement to know who the end-user (or resource owner) is and for the client to be able to request access to basic claims about them. Together, OIDC and OAuth2.0 create a protocol that combines authentication and authorization. While this allows them to work natively with one another, it’s not always helpful from an infrastructure standpoint to collapse these different functions together.

Efforts like WebID are currently trending towards the reseparation of these concepts that have become married in the current world of OpenID, by developing browser APIs that are specifically geared towards identity. However, without a solution to authorization, it could be argued that many of the goals of the project will remain unsatisfied whenever the relying party requires both authentication and authorization in a given interaction.

As it turns out, these problems are all closely related to each other and require a broad and coordinated approach. As we step into an increasingly digital era where the expectation continues to evolve around what’s possible to do online, the role of identity becomes increasingly complex. Take, for example, sectors such as the financial industry dealing with increased requirements around electronic Know-Your-Customer (KYC) policies. In parallel with the innovation around web identity and the adoption of emerging technologies such as VCs, there has been a growing realization that the evolution of digital identity enables many opportunities that extend far beyond the domain of identity. This is where the power of verifiable data on the web really begins, and with it an expanded scope and structure for how to build digital infrastructure that can support a whole new class of applications.

A new proposed browser API called Credential Handler API (CHAPI) offers a promising solution to browser-mediated interactions that complements the identity-centric technologies of OIDC and WebID. It currently takes the form of a polyfill to allow these capabilities to be used in the browser today. Similar to how SIOP proposes for the user to be able pick their provider for identity-related credentials, CHAPI allows you to pick your provider, but not just for identity — for any kind of credential. In that sense, OIDC and CHAPI are solving slightly different problems:

• OIDC is primarily about requesting authentication of an End-User and receiving some limited identity claims about them, and in certain circumstances also accessing protected resources on their behalf.
• CHAPI is about requesting credentials that may describe the End-user or may not. Additionally, credentials might not even be related to their identity directly and instead used for other related functions like granting authorization, access, etc.

While OIDC offers a simple protocol based upon URL redirects, CHAPI pushes for a world of deeper integration with the browser that affords several useability benefits. Unlike traditional implementations of OIDC, CHAPI does not start with the assumption that an identity is fixed to the provider. Instead, the end-user gets to register their preferred providers in the browser and then select from this list when an interaction with their provider is required. Since CHAPI allows for exchanging credentials that may or may not be related to the end-user, it allows for a much broader set of interactions than what’s provided by today’s identity protocols. In theory, these can work together rather than as alternative options. You could, for instance, treat CHAPI browser APIs as a client to contact the end-user’s OpenID Provider and then use CHAPI to exchange and present additional credentials that may be under the end-user’s control.

CHAPI is very oriented towards the “credential” abstraction, which is essentially a fixed set of claims protected in a cryptographic envelope and often intended to be long lived. A useful insight from the development of OIDC is that it may be helpful to separate, at least logically, the presentation of identity-related information from the presentation of other kinds of information. To extend this idea, authenticating or presenting a credential is different from authenticating that you’re the subject of a credential. You may choose to do these things in succession, but they are not inherently related.

The reason this is important has to do with privacy, data hygiene, and best security practices. In order to allow users to both exercise their identity on the web and manage all of their credentials in one place, we should be creating systems that default to requesting specific information about an end-user as needed, not necessarily requesting credentials when what’s needed is an authentic identity and vice versa.

Adopting this kind of policy would allow configurations where the identifier for the credential subject would not be assumed to be the identifier used to identify the subject with the relying party. Using this capability in combination with approaches to selective disclosure like VCs with JSON-LD BBS+ signatures will ensure not only a coherent system that can separate identity and access, but also one that respects user privacy and provides a bridge between existing identity management infrastructure and emerging technologies.

An emergent user experience

Using these technologies in tandem also helps to bridge the divide between native and web applications when it comes to managing identity across different modalities. Although the two often get conflated, a digital wallet for holding user credentials is not necessarily an application. It’s a service to help users manage their credentials, both identity-related and otherwise, and should be accessible wherever an end-user needs to access it. In truth, native apps and web apps are each good at different things and come with their own unique set of trade-offs and implementation challenges. Looking at this emerging paradigm where identity is managed in a coherent way across different types of digital infrastructure, “web wallets” and “native wallets” are not necessarily mutually exclusive — emerging technologies can leverage redirects to allow the use of both.

The revolution around digital identity offers a new paradigm that places users in a position of greater control around their digital interactions, giving them the tools to exercise agency over their identity and their data online. Modern legislation focused on privacy, portability, security and accessible user experience is also creating an impetus for the consolidation of legacy practices. The opportunity is to leverage this directional shift to create a network effect across the digital ecosystem, making it easier for relying parties to build secure web experiences and unlocking entirely new value opportunities for claims providers and data authorities.

Users shouldn’t have to manage the complexity left behind by today’s outdated identity systems, and they shouldn’t be collateral damage when it comes to designing convenient apps and services. Without careful coordination, much of the newer innovation could lead to even more fragmentation in the digital landscape. However, as we can see here, many of these technology efforts and standards are solving similar or complementary problems.

Ultimately, a successful reinvention of identity on the web should make privacy and security easy; easy for end-users to understand, easy for relying parties to support, and easy for providers to implement. That means building bridges across technologies to support not only today’s internet users, but enabling access to an entirely new set of stakeholders across the globe who will finally have a seat at the table, such as those without access to the internet or readily available web infrastructure. As these technologies develop, we should continue to push for consolidation and simplicity to strike the elusive balance between security and convenience across the ecosystem for everyday users.

Where to from here?

Solving the challenges necessary to realize the future state of identity on the web will take a collective effort of vendor collaboration, standards contributions, practical implementations and education. In order to create adoption of this technology at scale, we should consider the following as concrete next steps we can all take to bring this vision to life:

Continue to drive development of bridging technologies that integrate well with existing identity solutions and provide a path to decentralized and portable identity

• E.g. formalization of OIDC Credential Provider to extend existing IdPs

Empower users to exercise autonomy and sovereignty in selecting their service provider, as well as the ability to change providers and manage services over time

• E.g. selection mechanisms introduced by SIOP and WebID

Adopt a holistic approach to building solutions that recognizes the role of browser-mediated interactions in preserving user privacy

• E.g. newer browser developments such as CHAPI and WebID

Build solutions that make as few assumptions as necessary in order to support different types of deployment environments that show up in real-world use cases

• E.g. evolution of SIOP as well as supporting web and native wallets

Ensure that the development of decentralized digital identity supports the variety and diversity of data that may be managed by users in the future, whether that data be identity-related or otherwise

Taking these steps will help to ensure that the identity technologies we build to support the digital infrastructure of tomorrow will avoid perpetuating the inequalities and accessibility barriers we face today. By doing our part to collaborate and contribute to solutions that work for everybody, building bridges rather than building siloes, we can create a paradigm shift that has longevity and resilience far into the future. We hope you join us.