“Once upon a time, digital systems were built around a beautifully simple idea: one user, one identity, one device, one intent. That model worked, for some value of “worked.” Mostly, it was good enough to solve 80% of the use cases. As always, the remaining 20%, which is where delegation lives, will take the majority of the effort to achieve.”
You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.
And be sure to leave me a Rating and Review!
Delegation, especially in the digital world, spans every sector and silo you can think of, from personal issues to business needs. A caregiver needs to manage prescriptions for an incapacitated family member. An executive assistant files expense reports on behalf of a CEO. An AI agent moves money between your bank accounts, ideally without draining your savings in the process. Real life involves multiple actors, multiple roles, and a messy, shifting web of consent and authority.
Unfortunately, most of our digital systems still behave as if we’re playing a single-player game. Delegation, the ability for one party to act clearly and securely on behalf of another, is not a nice-to-have. It never really was; just ask anyone who had to get into someone else’s accounts after that someone else passed away. But agentic AI has turned what was treated as an edge case into a foundational requirement for how we live and interact online.
In my first post on delegation, I wrote about why this matters. Now let’s consider what today’s technical foundations offer and why what we have today isn’t enough.
OAuth: Great for Authorization. Awkward for Delegation.
If you work anywhere near digital identity, you know OAuth 2.0 (I’d like directly to the spec, but there are SO MANY SPECS in the OAuth family. It’s crazypants.). OAuth 2.0 is the backbone of how we let one service act on behalf of a user. It’s how you click “Sign in with Google” or allow a fitness app to access your calendar.
For basic authorization, OAuth is brilliant. But for complex, human-centric delegation? Not so much.
In most OAuth implementations, delegation looks like “Alice-to-Alice” sharing. Alice authorizes a service, and when that service acts, it looks like Alice herself is taking the action. There’s no clear, auditable distinction between actions initiated directly by Alice and actions performed on her behalf.
When the stakes are low, that’s fine. When delegation needs to be explicit, limited, and verifiable, you know, in healthcare, finance, or enterprise environments, it starts to fall apart.
RFC 8693: Token Exchange – Helpful, but Not Plug-and-Play
There is important work happening inside OAuth to handle more sophisticated delegation patterns.
RFC 8693 (OAuth 2.0 Token Exchange) defines a way to trade one token for another. It creates the foundation for services acting “on behalf of” a user and enables more traceable chains of authorization.
This is real progress. It opens the door to:
- Services that act as authorized intermediaries,
- Audit trails that reflect delegated authority,
- Clearer boundaries between who initiated which actions.
But it has its own issues.
As shared by engineers working with these standards today, RFC 8693 is a framework, not a turnkey solution. It’s incredibly useful if someone does the heavy work of designing the exact policies, constraints, and usage patterns that fit a specific environment.
There are no general-purpose, plug-and-play implementations. To put it another way, RFC 8693 gives you the ingredients. It doesn’t bake the gluten-and-dairy-free-but-still-tasty cake.
OAuth 2.1: Important Cleanup, Not a Delegation Revolution
OAuth 2.1 is currently moving through the IETF process; that means it is still a draft, and you shouldn’t think of it as a stable specification. It consolidates best practices from OAuth 2.0 and improves security by:
- Requiring Proof Key for Code Exchange (PKCE) for all clients,
- Removing risky flows like the Implicit and Resource Owner Password Credentials grants,
- Tightening rules around redirect URIs to prevent common attacks.
These are much-needed improvements to make OAuth deployments more secure and consistent.
However, OAuth 2.1 does not introduce major new delegation capabilities. If you were hoping for a seamless way to model multi-actor delegation as a standard feature, OAuth 2.1 will disappoint you. It’s a maintenance and modernization release, not a redesign of delegation models.
What’s Still Missing?
When people talk about “richer delegation models,” they are typically looking for capabilities that OAuth alone doesn’t fully deliver today:
- Contextual constraints: Delegating narrowly, following the model of “only access this resource, only for this task, only during this window.”
- Clear actor chains: Recording “Bob is acting for Alice” rather than obscuring delegation behind a generic authorization.
- Lifecycle management: Ensuring delegation expires automatically when the situation changes (e.g., a role change or time limit).
- Auditability: Maintaining reliable logs that show exactly who acted, when, and under what authority.
- Transitivity control: Defining whether and how a delegated authority can be further delegated to others.
OAuth, with extensions like Token Exchange and Rich Authorization Requests (RAR), can enable some of this when carefully implemented. (Those last three words should fill you with trepidation, just sayin’.) But it doesn’t guarantee it, and it leaves much of the structure up to each deployment. (What could possibly go wrong?)
That gap matters, especially as systems get more complex, regulatory scrutiny increases, and agentic AI becomes more common.
Exploring Other Delegation Models
Recognizing these gaps, others in the identity community are exploring additional models beyond pure OAuth:
- User-Managed Access (UMA): Built on top of OAuth 2.0, UMA allows resource owners to define fine-grained sharing policies. It offers strong concepts for delegation but has seen limited real-world adoption due to its complexity.
- Verifiable Credentials and Decentralized Identifiers (VCs and DIDs): These technologies allow an agent to present cryptographically verifiable proof of delegated authority. They are still maturing but hold significant promise for trusted delegation between humans, organizations, and AI agents.
- Enterprise Mission Profiles: Some organizations are developing tailored delegation frameworks for specific industries, building on OAuth or PKI to meet regulated needs without relying on consumer-grade assumptions.
Each approach recognizes the same fundamental reality: digital systems must become much better at supporting explicit, constrained, auditable delegation.
Why I’m Writing About This
To be clear, I’m not one of the people writing these specifications. I’m not here to offer a new protocol or propose another working group. No, seriously, we do not need another working group. My goal is to build a bridge between people who have resources to throw at this problem and the groups working on the problem now. .
There is a growing group of implementers, architects, and security leads who are starting to notice the cracks:
- Delegation models are messy.
- AI agents are bumping into walls.
- Critical systems are relying on brittle workarounds.
At the same time, important, thoughtful work is happening in standards bodies like the OpenID Foundation and the IETF to address delegation challenges, but those efforts aren’t widely understood yet.
If you’re feeling frustrated that “surely OAuth already handles this,” or worried that your project’s AI agent has no clean path to delegated authority, you’re not wrong.
The people working on these specs know there’s a gap. They’re working hard to close it. They are amazing. But building better delegation models will take time, feedback, and collaboration from across the industry, not just inside the standards track.
Delegation Isn’t Solved Yet, But It’s Solvable
Delegation today is a patchwork of partial solutions. But it doesn’t have to stay that way.
With better tools and more attention to what real-world delegation actually requires, we can build systems that reflect the complex, messy, multi-actor world we live in. It’s not going to change quickly, but that doesn’t mean we shouldn’t be focusing our attention on fixing the problems.
If you enjoyed this post, you might find a few other posts on my blog of interest:
- Agentic AI and Authentication: Exploring Some Unanswered Questions
- Understanding NHIs: Key Differences Between Human and Non-Human Identities
- Unlock the Secrets of OAuth 2.0 Tokens (and Have Fun Doing It!)
📩 Want to stay updated? I write about digital identity and related standards—because someone has to keep track of all this! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here]
Transcript
[00:00]
Welcome to A Digital Identity Digest, the audio companion to the blog at Spherical Cow Consulting. I’m Heather Flanagan, and every week I break down interesting topics in the field of digital identity—from credentials and standards to browser weirdness and policy twists.
If you work with digital identity but don’t have time to follow every specification or hype cycle, you’re in the right place.
Let’s get into it.
Why Are We Talking About Delegation Again?
[00:00:26]
Welcome back. Today, we’re revisiting the topic of delegation, but this time we’re diving into the technical side—what today’s systems offer, why it’s not enough, and where the real gaps lie.
[00:00:41]
If you’re familiar with OAuth, hang in for 30 seconds. If not, no worries—here’s the short version:
[00:00:50]
OAuth is a protocol that lets you authorize one service to access something you control without handing over your password.
[00:00:57]
It’s why you can “Sign in with Google” or allow a calendar app to sync your schedule—without giving up full control of your account.
OAuth: The Backbone of Modern Delegation
[00:01:04]
OAuth is the underlying plumbing for online access delegation. When it works well, it’s great. But when it falls short (and spoiler alert: it does), it results in messy workarounds and real security gaps.
[00:01:25]
Originally, digital systems were built around a clean model: one user, one identity, one device, one intent. And while that worked for about 80% of use cases, the remaining 20%—where delegation lives—takes the most effort to get right.
Real Life Is Messy: The Rise of Multi-Actor Systems
[00:01:47]
Fast forward to today: real life is messy, with overlapping authority and complex actors.
[00:02:00]
Think about it:
- A caregiver managing a family member’s medical appointments
- An executive assistant filing expenses for a CEO
- An AI agent managing your bank accounts (ideally without buying a Tesla)
[00:02:15]
Delegation has never been a “nice-to-have” feature. It’s always been critical—just ask anyone who’s had to manage a deceased relative’s online accounts.
[00:02:25]
Now, with AI entering the picture, delegation has gone from edge case to foundational design problem—and most systems aren’t ready.
What OAuth Gets Right (and Where It Breaks)
[00:02:39]
OAuth 2.0 is well-known in identity circles. It’s a powerful authorization protocol, especially for simple use cases like:
- Signing in with Google
- Granting apps access to calendar or contacts
[00:03:17]
But for complex, human-centered delegation, things start to fall apart. Here’s what typically happens:
- Alice authorizes a service
- The service acts
- Logs show Alice did it—even though it was the service
[00:03:41]
That’s okay when the stakes are low. But when it’s an AI agent booking travel, paying bills, or managing healthcare? Not so much.
[00:03:52]
You don’t want to give your AI or family member unlimited, untraceable access.
[00:04:03]
But you also don’t want it blocked at every turn. Systems need to recognize that it’s acting with limited, delegated authority.
The Need for Rich, Constrained Delegation
[00:04:12]
Without rich, constrained delegation, you either:
- Grant too much access and lose control
- Or block useful actions completely
[00:04:22]
Neither option is ideal. And OAuth—at least as widely implemented—wasn’t designed for this kind of nuanced delegation.
RFC 8693: Token Exchange to the Rescue?
[00:04:32]
OAuth isn’t standing still. One key development is RFC 8693—the token exchange spec. It enables services to act on a user’s behalf with audit trails and chains of authority.
[00:05:06]
Sounds promising, right?
[00:05:06]
But here’s the catch: RFC 8693 is a framework, not a turnkey solution. It gives you the ingredients, not the cake.
[00:05:31]
If your project assumes token exchange will “just work” for delegation—good luck. You’ll need to profile it properly, define scopes, and create policies tailored to your environment.
What About OAuth 2.1?
[00:05:40]
OAuth 2.1 is in the works. It tightens up security and standardizes key improvements:
- PKCE is now mandatory
- Risky flows (like resource owner passwords) are removed
- Redirect rules are stricter
[00:06:13]
These are great changes. But let’s be clear: OAuth 2.1 is a maintenance release. It’s not a new model for delegation.
What We Actually Need for Delegation
[00:06:39]
When people say we need “richer” delegation, they mean:
- Contextual constraints
(e.g., access this resource for this purpose within this timeframe) - Clear actor chains
(e.g., Bob is acting for Alice—and the system knows it) - Lifecycle management
(e.g., permissions expire automatically with role changes) - Auditability
(e.g., logs that track who did what, when, and on whose behalf) - Transitivity control
(e.g., delegate-of-a-delegate rules with tight boundaries)
[00:07:59]
Especially with AI, you may want a delegate (human or agent) to be able to re-delegate—but only for specific purposes and within strict limits.
The Problem with Current Systems
[00:08:08]
Without fine-grained control, delegation chains either collapse into chaos or simply don’t work.
And right now, very few systems—or standards—can handle controlled, conditional re-delegation well.
Other Delegation Models to Watch
[00:08:42]
Outside of OAuth, some promising models include:
- User Managed Access (UMA)
Fine-grained sharing policies—but limited adoption - Verifiable Credentials & DIDs (Decentralized Identifiers)
Let agents cryptographically prove they’re authorized—but still maturing - Enterprise Mission Profiles
Customized frameworks tuned for high-compliance environments like banking
[00:09:31]
All of these agree on one thing: one user, one device, one intent no longer reflects the real world (if it ever did).
Why This Matters
[00:09:44]
I’m not writing OAuth specs, and I’m not proposing another working group (please, no more working groups).
[00:09:53]
What I am trying to do—through this podcast and blog—is build a bridge.
Because:
- More architects and implementers are realizing delegation is messy
- AI agents are bumping into walls
- Critical systems are relying on brittle workarounds
So, Where Do We Go from Here?
[00:10:14]
Standards bodies like the OpenID Foundation and IETF are doing excellent, thoughtful work. But that work isn’t always widely understood or accessible.
[00:10:45]
If you’re frustrated that “surely OAuth handles this”—you’re not alone. It doesn’t. Yet.
[00:11:04]
Delegation isn’t solved—but it is solvable. With better tools and more attention to real-world needs, we can build systems that reflect the messy, beautiful, multi-actor world we live in.
And while it won’t happen overnight (hello, technical debt), it’s absolutely worth doing.
Thanks for Listening
[00:11:27]
That’s it for this episode of A Digital Identity Digest.
If this helped make things clearer—or at least more interesting—share it with a friend or colleague. You can connect with me on LinkedIn @hlflanagan.
If you enjoyed the show, don’t forget to subscribe and leave a review on Apple Podcasts or wherever you listen.
You can also read the full post at sphericalcowconsulting.com.
Stay curious. Stay engaged. Let’s get these conversations going.