Authentication authority. Access security authority. Identity intelligence authority

These terms should look familiar. They're similar to the common terminology used to discuss the identity and access management (IAM) infrastructure, but something is different.

Perhaps you feel inclined to correct them. To make them match the language and concepts you already know. But before you do, read on.

As companies improve on traditional approaches to applications and move resources and people out of the network perimeter, companies are presented with tremendous business opportunities. But those tasked with identity architecture must overcome what can feel like insurmountable hurdles to support their organisation's digital transformation.

It's obvious that a new approach to enterprise security is needed. As attack patterns have become more sophisticated, so have standards-based application and authentication architectures. As we evolve beyond simple two-party web SSO use cases to modern many-party, many-channel systems, we must rethink how we address identity and access management.

Emerging identity tools are allowing us to expand our thinking, but we're constrained by the current identity architecture and terminology. We need a modern reference architecture. One that allows resources across a diverse set of domains and platforms to be secured and controlled in a homogeneous way. One that encompasses these multiple domains and combines software and services in public and private clouds, as well as legacy on-premises environments.

But defining a rational, modern identity architecture also requires a new lexicon. We have to move away from protocol-bound SAML terminology to solve today's deeper and broader identity challenges. We must remove the silos of separate software solutions and define new terms that allow us to describe multi-domain, multi-network interactions that can be examined for protocol detail. By identifying the highest-level components of the identity architecture, we can share and understanding of the identity of all software, users and devices.

If the end goal is truly to have the same understanding of the identity of all software users and devices - and I think we can agree it is- - then we must decouple the authority and control relationships within the architecture from currently used protocol terms. We must rethink and relabel the components of the identity architecture to intentionally allocate complexity and risk and take into account modern identity standards.

With this refreshed thinking, we can also create a common new language. This language will allow us to define how identity data is marshalled across domains and describe multiple use cases and protocols for the future. We can explain infrastructures in terms of authorities, resources, services and domain boundaries, instead of using outdated jargon.

By accurately describing the collaboration between domains, we can make great strides in communicating our architectures up the chain and among our colleagues. And once we can do that, we can implement coordinated solutions that allow us to take full advantage of today's and tomorrow's business growth opportunities.