The Era of Continuous Identity

Existing digital identity and access management technology, infrastructure, architecture, and process is still rooted in the original needs of shared resource computing. We create “an account” for each individual “user” (which we generally assume is a human person; or at minimum is a thing that can ultimately be related to a human person). When the user wants to access a protected resource, we execute a point-in-time transaction triggered by the request to authenticate them, ensuring to an appropriate level of certainty that they are the same person for whom we originally created the account. We may then carry out some additional access control assessment: do they have the right to access the data or execute the process that they are requesting? In more advanced cases, we might even go as far as carrying out a step-up or step-down process to grant or remove additional rights on a temporary basis.

This is all highly transactional and very binary—you’re either ‘human’ (or associated with a human), or out of scope; you have the relevant permission, or you don’t—and we typically evaluate and validate these things only once, at the start of a process (and sometimes not even then, relying instead on stored, stale data).

What’s changing and why?

With the advent of digital identity wallets, verifiable credentials, shared signals, and more advanced authorisation capabilities, however, I believe we’re about to enter an era of continuous validation. Rather than a series of gates in the process, instead imagine a continuous flow of data that you can evaluate in real time, allowing you to be more, or less, certain at any given point that a user is who they claim to be, and has the permissions to do what they want to do. Your risk tolerance may also change over time depending on a variety of input factors and contexts.

Today: Reactive Validation

diagram showing a reactive, point-in-time, validation process

Today, we make decisions reactively to each user request. We may then either use a cached decision, whose accuracy necessarily diminishes over time, or make a fresh decision. A fresh decision will be based on some combination of:

  • data we have collected at or immediately after request time, either directly from or contextually about the user;
  • previously requested and cached data, which will have some level of staleness

Tomorrow: Continuous Validation

diagram showing a proactive and continuous validation process

Increasingly, however, we have the opportunity to make decisions continuously based on a variety of signal inputs, including user-provided input, geolocation, user behavior, third-party fraud and risk signals, and so on.

This approach has some very real benefits for security, privacy, and user experience. You can evaluate contextual and data signals—some passively gathered, others actively requested—but you need only ever store a bare minimum of these. This mitigates your own data collection and management risks; but it could also mean collecting data from the user at a reduced frequency. It also leads to a smoother user journey: fewer interruptions to collect or verify data (but with increased levels of security), and the potential to gracefully steer a user away from activities you aren’t currently sufficiently sure they should be doing. Finally, it reduces the need to aggressively proof identity at the start of a transaction when you don’t know for sure that this will be required.

So how do we get there?

Shared Signals approaches underpinned by standards such as CAEP and RISC, coupled with emerging ideas around ‘smart identity wallets’, provide the early building blocks for this continuous architecture. In my view, there is sufficient traction to suggest that the picture I’m painting here is likely to become real over the next 3-5 years.

The bulk of our identity systems and processes, however, aren’t yet geared up for this new world. We still assume that users have permanent ‘accounts’. We still ’log in’ and ’log out’. Our identity verification, authorization, and access control systems are all built to make point-in-time and reactive decisions.

I suggest that we need to start now to fundamentally redesign our identity infrastructure. Architects need to consider the benefits and implications of having a continuous flow of identity claims and contexts upon which to base access decision, and start to design accordingly. Business process teams need to review their IGA processes and protocols, and to consider whether other new technologies such as AI can help in designing flexible and continuously responsive access control rules. And identity product vendors need to prepare their customers—and their products—for the coming wave of continuous identity.