Revisiting Non-Human Identity

Chart of non-human identity actions

Originally published on April 5, 2024 by Heather Flanagan (“The Evolving Landscape of Non-Human Identity”); updated on August 22, 2024, for IDPro

Post written as an individual member of IDPro.

I think 2024 is going to be the year I point to for when I truly discovered non-human identities. What a crazy, complex space! After attending this year’s IETF meetings, where some of the most engaging—and frankly, alarming—conversations centered around physical and software supply chains, I realized how much this space has changed from what I initially encountered in my digital identity career.

The Shift from Access Cards to Cloud Computing

Back when I first managed digital identity at a university, our challenges with non-human identity were limited to access cards. These cards, which were provisioned through the HR system, represented a square peg in a round hole situation—fitting non-human entities into a system designed for people was an exercise in policy gymnastics. 

But that kind of non-human identity is so very much not what we’re talking about today. The focus now is on how cloud computing has fundamentally changed the landscape.

Cloudy with a Chance of Storms

Cloud computing is often hailed as the solution to cost and efficiency challenges in IT. By offloading computing power to external providers, companies can avoid the hefty costs associated with maintaining their own data centers. More power! Less money! What could possibly go wrong? Well, funny you should ask: this shift has introduced significant identity management issues, particularly in authorization.

Processes and APIs—unlike people—don’t follow a predictable lifecycle of hiring and firing. These digital entities might not be associated with any human at all, yet they require strict authorization controls to operate within their designated scope. In a single cloud environment, this might still be manageable, but across multiple cloud environments, the complexity skyrockets.

The Complexity of Multi-Cloud Authorization

When authorization needs to occur across different environments, the challenges multiply. Code formats vary, sources of truth differ, and the sheer number of processes and APIs can dwarf the number of human employees in a company. This type of non-human identity doesn’t behave like human identities; it operates independently, often in ways that humans wouldn’t recognize as normal behavior.

Take batch processing, for example. Whether it’s training an AI model or handling bank payroll transactions, these processes run without human supervision and don’t act on behalf of a user. What might look like suspicious behavior for a person—such as simultaneous logins from multiple locations—is just routine operation for a cloud-based application.

The Role of DevOps, IT Admins, and IAM Practitioners

In cloud environments, it’s typically DevOps and IT teams who develop and manage the applications necessary for business operations. These teams often specialize in specific cloud environments, making it difficult to find generalists who understand identity management across the board.

The problem is, identity management has traditionally focused on people. IAM teams are beginning to realize there’s an authorization problem in the cloud, but solutions are still sparse. DevOps teams, aware of the identity challenges, often face difficulties managing API permissions without compromising security. However, they aren’t turning to IAM teams for help, partly because it wouldn’t occur to them, and partly because the scale of the problem would overwhelm traditional IAM approaches.

Standards to the Rescue?

This brings me back to the enlightening hallway discussions in the IETF. The reason I became aware of these authorization challenges was due to conversations around three emerging standards efforts:

SCITT: Rethinking Authorization in the Software Supply Chain

SCITT is focused on the software supply chain, which involves the components, libraries, tools, and processes used to build and publish software. Imagine a world where a standardized, computer-readable Software Bill of Materials (SBOM) could be used to determine in real-time whether a software package is safe to run, based on any security vulnerabilities associated with its components. SCITT aims to make this a reality, offering a new approach to authorization.

Right now, the working group is discussing three drafts: 

WIMSE: Defining Workload Identity

Workload identity is still a concept searching for a universal definition. I favor Microsoft’s definition: “an identity you assign to a software workload (such as an application, service, script, or container) to authenticate and access other services and resources.” With so many applications and services running across multiple clouds, there needs to be a standardized way to handle identity across these environments. WIMSE is working on just that, focusing on least-privilege access and visibility across platforms.

IETF 120 was only the second time this working group has met, and they are making fabulous progress in no small part thanks to their chairs, Justin Richer and Pieter Kasselman. (Did I mention both are IDPro members?) That group has quite a few documents in development right now. You can find the list on the working group’s website.

SPICE: Bridging Human and Non-Human Identities

Finally, SPICE is tackling the challenge of creating a credential format that’s lightweight enough for workload identities but still robust enough to handle the nuances of human identities. It’s a delicate balance, given that human identities require considerations like privacy and revocation, while workload identities need to operate at high speeds with minimal overhead.

Full disclosure on this one: when I first really started understanding the challenges of the non-human space during IETF 119, my first thought was “I am in no way experienced enough to be able to help solve this problem as an architect.” My second thought was “Stop whinging: how CAN you help solve this problem, then?” And so I volunteered to be co-chair of this newest of the three critical working groups. I may not be able to solve the problem, but that’s not always what’s needed. A team requires people who can facilitate and ask stupid questions just as much as they need people who can architect clever technical solutions.  

SPICE just adopted its first two documents, “SPICE SD-CWT” (draft-ietf-spice-sd-cwt-00) and “Use Cases for SPICE.” That latter one is not intended to ever become an RFC; it’s more to inform the requirements for all the other specifications this group will produce. 

The Future of Non-Human Identity

Non-human identity represents identity at a scale and speed we’ve never seen before. The traditional tools and standards we use for human identity simply don’t work in this new environment. As I continue to explore this space, I’m following experts like Pieter Kasselman (Microsoft) who are deeply involved in these discussions and pushing the boundaries of what’s possible.

If you want to learn more, everyone is always welcome to join the working group mailing lists or ask questions in the IDPro Slack.

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

Heather Flanagan, Principal at Spherical Cow Consulting, comes from a position that the Internet is led by people, powered by words, and inspired by technology. She has been involved in leadership roles with some of the most technical, volunteer-driven organizations on the Internet, including IDPro as Principal Editor, the IETF, the IAB, and the IRTF as RFC Series Editor, ICANN as Technical Writer, and REFEDS as Coordinator, just to name a few. If there is work going on to develop new Internet standards or discussions around the future of digital identity, she is interested in engaging in that work. You can learn more about her on LinkedIn or reach out to her on the IDPro Slack channel.

Lets get in touch ...

Please use the below contact form to leave your message with us. We will be pleased to respond as soon as possible.

Contact Us

Name(Required)
You may contact us by filling in this form any time you need professional support or have any questions. You can also fill in the form to leave your comments or feedback.