Workload Identity - Key Takeaways from IETF 122

TL;DR (But You’ll Want to Read More):

From securing microservices to identifying AI agents, IETF 122 was packed with major developments in workload identity. New standards are emerging that will shape how software authenticates, authorizes, and integrates across clouds, domains. If you care about the future of zero trust, workload identity, or AI on the web — this one’s for you.

Workload Identity, a problem made for standards

Standards form the backbone of the world’s identity infrastructure. Standards define the interfaces, data formats, usage patterns and protocols we need to ensure the right human, workload or machine has access to the right resources, at the right time, and for the right reason.

So how do we do that? It starts by ensuring every workload—whether a basic batch job or a complex AI agent—has an identity for authentication and authorization. 

Using standards to do this gives us clear, interoperable interfaces so workloads—AI or otherwise—can securely authenticate, get authorized, and access data across diverse environments at scale. Standards capture industry expertise, letting everyone benefit from proven best practices for securing workload identities. Standards make everything better! 

Last week, the Internet Engineering Task Force (IETF) met in Bangkok for IETF 122 to bring together engineers, researchers and technologists from around the world to debate, explore and develop the standards –  including identity standards – that the internet is built on. 

WIMSE

The Workload Identity in Multi-Service Environments (WIMSE) working group was specifically chartered a year ago to develop workload identity standards. In its first year it evaluated numerous proposals and adopted three working group drafts. 

1. WIMSE Architecture: This standard outlines the main building blocks and architectures for workload identity. If you're defining a workload identity strategy, this is required reading.
2. WIMSE Service-to-Service Authentication: This specification introduces a new token type, the Workload Identity Token, and defines ways in which workloads can use it to authenticate to one another. It was designed to be compatible with SPIFFE, and the SPIFFE community is already exploring adoption.
3. Workload Identity Practices: There are numerous usage patterns for workload identities that are already widely deployed. This document is a handy reference for existing practices and patterns. It covers existing practices for cloud service providers, Kubernetes, and CI/CD patterns. A must-read for anyone new to the workload identity space.

But wait, there's more! I'm excited about the new WIMSE Credential Exchange draft that outlines patterns and approaches for using a workload identity credential to obtain additional credentials to interact with resources and systems. This is a critical integration capability. It is the glue needed to connect modern workload identity infrastructure with existing identity systems. 

OAuth

The OAuth working group always has a packed agenda, and IETF 122 was no exception. OAuth is a broadly adopted authorization delegation protocol. It has an extended protocol specification family spanning well beyond the IETF, totalling more than 100 documents! Two new standards currently under development will have an important impact in securing workload identity, especially when it comes to interacting with OAuth systems:

1. Transaction Tokens: Transaction tokens provide a mechanism to avoid sending OAuth Access tokens from one microservice to another within a trust domain. The Transaction Token Service can reduce the scope of access granted to individual microservices while binding a user identity, a workload identity and transaction context together to enable fine-grained authorization decisions.
2. Identity and Authorization Chaining Across Domains: A service often requires access to resources across clouds, service providers of company boundaries. This draft specifies how to access resources across domains using standard OAuth protocols. It is a natural companion to transaction tokens when designing a least privilege or zero-trust architecture for microservices using OAuth.

In addition to the above, the following work in OAuth is on my watchlist:

• The Attestation Based Client Authentication specification introduces a new pattern for client authentication. Although it is envisioned for use with digital wallets, it is worth remembering that a wallet is just a workload too. 
• Another topic that is increasingly prominent is that of deferred key binding. It is common practice to delegate identity functions to proxies and brokers, a pattern that is common in both human and workload identity (e.g. Istio Ambient mode). After years of debate, we still have not solved 'sender-constrained' tokens when the workload is not directly interacting with the authorization server. Following discussions at IETF 122, there will be an interim meeting before IETF 123 to discuss this topic more deeply. This is on my "watch list" of new standards work that will impact workload identity.

Post Quantum Cryptography

Post Quantum Cryptography (PQC) has been a theme over the last 4-5 years at the IETF. PQC adoption goes well beyond updating the standards. Deploying these new algorithms on the timescales published by the National Institute of Standards and Technology (NIST) will require massive change management programs. The work continues for this once-in-a-generation shift in cryptographic capabilities.

Artificial Intelligence (AI)

No gathering of technologists would be complete without AI as a topic of conversation. Two meetings with AI as a theme stood out at IETF 122.  

1. Bot Authentication: IETF 122 started with an official side meeting to discuss Bot authentication on the Web. When bots and web-crawlers access web pages designed for humans, it is important to distinguish them from humans. Captchas and technologies like Privacy Pass are two technologies meant to let content publishers distinguish between humans and non-humans. The rise of powerful AI introduces a new wrinkle. How to tell if the AI is a delegate of a human, or just a more sophisticated web crawler? How can these Agentic Ais be authenticated? The good news is that there are many options, including SPIFFE certificates for client authentication. How and when to use them is something we need to standardise.
2. AI Preferences: The AI Preferences Working Group is a new working group that focuses on mechanisms for the expression of preferences about how content is collected and processed for AI model development, deployment, and use. These mechanisms will allow content publishers to indicate how they want their content to be used for, and by, AI. 

One thing that stood out was that it is essential that AI workloads can be identified and authenticated. AIs will be interacting with systems that were designed for human end-users (web sites) and engineers (APIs), and they will do so in ways that are unexpected. To manage the risk from these unexpected usage patterns three things are needed:

1. Every AI must be credentialed
2. Least privilege authorization policies must be put in place. 
3. Asynchronous mechanisms to obtain additional permissions from end-users and system administrators must be deployed.
   

Authentication and fine-grained authorization is not new, but AI will make them indispensable, and it is encouraging to see the early engagement in the IETF.

See you at IETF 123! 

IETF 122 is behind us. I can't wait for IETF 123 to see the progress being made on these critical standards for workload identity practitioners.

Pieter Kasselman

Workload Identity Enthusiasts, WIMSE Chair, Director of Product Engineering at SPIRL

‍