“There are standards groups I watch because they are exploring something new, and standards groups I watch because what they do is already embedded deeply enough in the Internet that changes deserve particular attention.”

The IETF OAuth Working Group is firmly in the second category.

OAuth has been around for nearly two decades. (Do you feel old now? I feel old now.) If you have ever used one service to sign in to another, allowed an application to access your calendar, connected a third-party tool to your cloud account, or given an application permission to act on your behalf without handing over your password, there is a good chance OAuth was somewhere in the machinery.

That maturity is part of why I take the current discussions in the OAuth WG Very Seriously. The group is not simply chasing the latest technology trend. Over a series of virtual interim meetings in September, with more meetings scheduled in October, it has been examining whether some long-standing OAuth assumptions still hold as authorization becomes more dynamic, cryptographic protections become more important, and software agents begin acting with less direct human involvement.

If you need a refresher on how work moves through the IETF, including the important distinction between an individual Internet-Draft and work actually adopted by a Working Group, see my earlier Field Guide to Digital Identity Standards Bodies. I’m not going to repeat all of that here. The short version is that the proposals discussed below are at different levels of maturity, and being discussed by the OAuth WG does not mean they have been accepted as standards.

So, getting back to what interests me, it’s about the set of questions the group is asking.

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!

How much proof should travel with an OAuth request?

The September 14 interim focused on a proposal called OAuth Proof of Possession Tokens with HTTP Message Signatures. Here’s what that’s about:

Many OAuth access tokens are bearer tokens. A bearer token works a little like cash: possession is what matters. If I legitimately receive the token, I can use it. If you steal it from me, in many systems you can use it too.

That is obviously not ideal.

One way to improve on bearer tokens is to bind a token to a cryptographic key controlled by the software that is supposed to use it. Now, possession of the token alone is not enough. The software must also prove that it holds the corresponding key.

OAuth already has a mechanism called DPoP, or Demonstrating Proof of Possession, for doing this (see RFC 9449). The proposal discussed in September takes a different approach: use standardized HTTP Message Signatures so that the software cryptographically signs relevant parts of the HTTP request itself. The access token is bound to the signing key, and the receiving service can verify both.

Why add another mechanism? That’s the question that occupied much of the discussion, according to the meeting minutes.

HTTP Message Signatures can protect more than just possession of the token. A signature can cover other pieces of the request as well: particular headers, for example, or information about the body of the request. That can provide stronger evidence about exactly what was sent and by whom. But additional capability does not automatically justify another standard.

Participants pushed on whether there are sufficiently important use cases that cannot already be handled by DPoP or other existing mechanisms. They also raised a deeper question: associating software with the right cryptographic key is hard, so should that problem really be solved specifically inside OAuth, or at a more general HTTP layer?

That question should sound familiar to anyone following the related work happening around workload and software identity. We are seeing several efforts try to establish stronger cryptographic identity for software making HTTP requests. They do not all start from the same trust model, and they are not necessarily interchangeable. I point to the draft HTTP Message Signatures for automated traffic as an example of something similar but different.

So the issue here is more than this specific draft. It’s about where caller identity belongs in the architecture. If software increasingly needs to prove not just that it has permission but also what software it is, which layer should establish that fact? OAuth may use the answer without necessarily owning the entire answer.

First, prove that there is a problem

The September 21 interim was, in some ways, even more interesting. (Thank you, scribes!)

The subject was the draft OAuth Protected Authorization, a proposal that changes how certain information moves through browser-based OAuth flows. Among other things, it proposes moving the authorization code—the temporary credential returned during an OAuth authorization—from the URL into an HTTP header, with additional browser involvement. Magic!

The motivation makes sense. URLs have historically been awkward places to put sensitive information, though we do it anyway because they are so darn convenient. But putting convenience aside, the problem here is that URLs can turn up in logs, browser history, diagnostic systems, and other places you may not have intended. Attackers who obtain an authorization code may attempt to redeem it.

But OAuth has not stood still while those attacks were being discovered! Modern OAuth deployments have protections such as PKCE, which makes a stolen authorization code considerably less useful because the attacker needs another secret value associated with the original transaction.

So the working-group discussion kept returning to a basic question:

What attack does this proposal prevent that current OAuth protections do not adequately address?

Participants examined several attacker models and existing mitigations. Eventually, the chairs took an informal poll on whether the group agreed there was a problem to solve. The result was three yes, five no, and one person expressing no opinion.

That was not a formal vote—IETF decisions aren’t made that way—but it was a useful indication that the proposal had not yet established its premise with the room.

The response was not simply “no.”

It was more like “write down the threat model clearly enough that we can determine whether this new mechanism is necessary.” I’m paraphrasing, but that’s the idea.

And that may sound procedural, but it is actually one of the most important disciplines in standards development. It is very easy to move directly from:

We found a possible attack → here is a new protocol feature.

A mature standards process should force a few more steps:

What exactly is the attack? Who can carry it out? What existing protections already apply? Where do those protections fail? What requirement follows from that failure? Only then: what new mechanism do we need?

Every new security mechanism has a cost. Someone has to implement it. Different implementations have to behave consistently. Developers have to understand when to use it instead of something else. And eventually, someone has to maintain it.

“More secure” is not free.

Then came the agents

On September 28, the conversation shifted to agentic systems, with Anthropic and OpenAI presenting authorization problems they are encountering in real deployments. The meeting agenda simply called the session “Anthropic & OpenAI Agentic Use Cases.” These discussions were particularly interesting because some (most?) of the problems attributed to agents are not actually new.

Agents may need to discover services dynamically rather than being configured in advance. They may need to establish themselves with authorization servers that have never encountered them before. The systems need to deal with consent, refresh tokens, stolen bearer tokens, and authorization across organizational boundaries.

Those are recognizable OAuth problems, even if agents increase their scale or urgency. The presenters explicitly described the problems as practical deployment issues rather than theoretical concerns. But agents also make some existing ambiguities much harder to ignore.

Consider a human using an AI service that operates an agent, which invokes another agent, which then calls a protected API. Who is acting? There is the human. There is the application or agent platform. There may be a particular agent. There may be another agent acting underneath that one. And there is the particular task the human asked the system to perform. Those are not necessarily the same identity, and they do not necessarily have the same authority.

Traditional OAuth is very good at questions roughly shaped like:

Can this application act with these permissions on behalf of this user?

Agentic systems increasingly need answers to questions shaped more like:

Can this particular software actor, operating on behalf of another actor, under authority ultimately derived from this person or organization, perform this specific action against this resource for this particular purpose?

That is a much richer authorization problem, which is a nice way of saying a super challenging problem.

An individual Internet-Draft (meaning one not yet adopted by the group), scheduled for discussion at the October 19 interim, tries to catalog these scenarios and compare them with what OAuth can already represent. The draft, Agent Authorization Use Cases and Gaps, identifies issues such as multi-step delegation chains—for example, a person authorizing Agent A, which delegates work to Agent B, which delegates again to Agent C—and the lack of standardized ways to carry some of the context needed to explain that chain. I look forward to that conversation.

How much authorization belongs in the token?

But wait, there’s more! There is another pressure here as well.

OAuth permissions are often represented through things such as scopes: labels that say an application may read a calendar, write a file, or access some other category of resource. That works reasonably well when permissions are relatively stable and broad. It becomes much less satisfying when the decision depends on context.

Suppose I ask an agent to reschedule one meeting because my flight was canceled. I may be comfortable with it modifying that meeting. I may not want to grant it general permission to modify every event on my calendar for the next month.

The more autonomous the software becomes, the more tempting it is to move toward authorization decisions made per request, taking into account who is acting, what they are trying to do, which resource is involved, and under what delegated authority.

But at that point, we should ask whether we are still extending OAuth or asking OAuth to become a general-purpose authorization policy system.

That question came through in the September agent discussion. Participants discussed richer, contextual authorization and moving decisions closer to the resource being accessed rather than relying entirely on the client software to police itself.

At the same time, one participant pointed out a useful boundary condition to apply to the topic: OAuth is fundamentally a framework for delegated access. Some forms of dynamic permissioning may be a different problem.

To put that another way, I think the architectural question for OAuth is:

Are agents revealing missing pieces in OAuth, or are agents asking OAuth to solve problems outside its natural scope?

Those lead to very different standards work.

October will test some possible answers

The next interims suggest the group is not assuming there is one obvious answer. Which is a good thing, because there isn’t one.

The October 5 meeting is devoted to the AAuth Protocol, another individual draft specifically aimed at agent-to-resource authorization. It includes explicit ideas about agent identity, cryptographic proof of possession, multiple authorization relationships, and information describing the mission under which an agent is operating.

Then, the October 19 meeting steps back again to Agent Authorization – Use Cases and Gaps.

I like that ordering.

We have concrete deployment problems. We have proposed architectures. We have efforts to catalog use cases and determine which capabilities existing OAuth mechanisms already provide.

That is a more sane sequence than deciding first that “AI needs a new authorization protocol” and working backward from there. I feel like that’s what many of the standardization efforts around AI are doing, and it’s annoyingly inefficient.

Agents may be the stress test, not the whole story

So, I would not describe all of this as OAuth reinventing itself for AI. The working group has plenty of other work underway, and several of the September questions predate the current enthusiasm around agents. Bearer-token theft is old. Client identity is old. Browser security is old. Delegation is certainly old.

What agentic systems are doing is putting more pressure on assumptions that were manageable when software clients were comparatively predictable, integrations were often established in advance, and a person was visibly involved at key moments.

Those assumptions become harder to maintain when software discovers services dynamically, crosses organizational boundaries, delegates work to other software, and makes many decisions without putting a consent screen in front of a human every time.

That does not mean OAuth needs to absorb every one of those problems. In fact, one of the most useful things happening in the working group right now is the willingness to ask whether it should.

OAuth is an old enough and successful enough standards effort that additions carry real consequences. New mechanisms do not enter an empty ecosystem; they enter one with enormous deployment, established security practices, existing extensions, and developers who already have plenty to understand.

The interesting thing to watch over the next several months is therefore not which shiny new draft “wins.” It is where the OAuth Working Group is drawing its boundaries.

• Which new problems genuinely require extensions to OAuth?
• Which can be solved with mechanisms we already have?
• Which belong at a different layer of the Internet architecture?

And, perhaps most importantly, when software acts with increasingly complicated chains of delegated authority, how much context does the infrastructure need before it can meaningfully answer the oldest authorization question of all:

Should this actor be allowed to do this?

If you’re not watching what’s coming out of the OAuth working group and you’re interested in delegation issues, including those highlighted by agentic AI, you really should be.

📩 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

Welcome to the 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 OAuth Is Asking Hard Questions

Let’s talk about OAuth.

OAuth has been around for about two decades, which means it’s one of those standards efforts that I personally tend to take very seriously when it starts asking some hard questions about what on earth it’s doing.

At its simplest, OAuth is a framework for letting one piece of software get limited permission to access something on your behalf without giving that software your password.

It separates the question of who you are from the question of what a particular application is allowed to do.

If you’ve ever had an application access your calendar, connected a third-party tool to a cloud account, or given software permission to act on your behalf, OAuth was probably somewhere in that machinery.

It is a very mature protocol, with a great deal of documentation around it.

That maturity matters.

There are standards groups working on entirely new ideas where experimentation is expected. OAuth is different because it is already widely deployed.

Any new mechanism has to enter an ecosystem with:

• Years of implementation experience
• Existing security practices
• Established deployment patterns
• Developers who already understand the protocol

So the question becomes: why would you change it?

---

What OAuth Needs to Look Like Next

I’ve been paying attention to a series of OAuth working group interim meetings that took place in September, with more coming up in October.

If you want the links to the drafts, agendas, and meeting minutes mentioned here, refer back to the written version of this post. I’m also not going to explain the IETF process in detail here. I’ve got a separate field guide for that, also linked from the written post.

What interests me in these conversations is not any one particular draft.

It’s the set of questions the group is asking about what authorization needs to look like.

As software becomes more autonomous, cryptographic protections become more important, and agents begin acting with less direct human involvement.

That creates pressure on assumptions that have been built into authorization systems for years.

---

Protecting OAuth Access Tokens

One of the September discussions focused on a proposal for using HTTP message signatures with OAuth proof-of-possession tokens.

The basic problem it is trying to solve is straightforward.

Many OAuth access tokens are called bearer tokens. A bearer token works a little like money: if you possess it, you can use it.

That is very convenient.

However, it also means that if someone steals the token, they may be able to use it too.

One way to improve on that is to bind the token to a cryptographic key controlled by the software that is supposed to use it.

The token by itself is no longer enough. The software also has to prove that it holds the corresponding key.

OAuth already has a mechanism for doing this kind of thing called DPoP.

The proposal discussed in September takes another route by using HTTP message signatures, potentially giving developers more flexibility.

Instead of proving only that the sender possesses a key associated with the token, the software can sign additional parts of the HTTP request as well.

That sounds pretty useful.

But the working group asked an important question during the meeting: is this useful enough to justify yet another mechanism?

---

When Is a New Security Mechanism Worth It?

That question is a recurring theme in mature standards work.

The question is not simply whether a proposal can provide more security or more flexibility.

Instead, it’s whether the additional capability solves an important enough problem to justify:

• The implementation cost
• The interoperability burden
• The long-term complexity
• The ongoing maintenance required

The discussion also raised a larger architectural question.

If software increasingly needs to prove not just that it has permission, but also what software it is, where should that identity live?

Is that actually a problem for OAuth?

Or is it a problem for HTTP?

Or is it some other layer of the architecture that should establish that identity, with OAuth simply consuming the information?

That question overlaps with other work happening around workload identity and authenticated HTTP requests.

It matters because there are now several different efforts trying to solve some version of the problem of proving which software is making a request.

Those efforts don’t all start from the same trust model, which makes the boundaries important.

---

Rethinking Authorization Codes

The next interim meeting, on September 21, was interesting for a different reason.

The topic was a proposal called OAuth Protected Authorization.

Among other things, it changes how an authorization code moves through a browser-based OAuth flow, taking it out of the URL and putting it into an HTTP header.

Again, the motivation is easy to understand.

URLs are not always a great place for sensitive information because they can show up in:

• Logs
• Browser histories
• Diagnostics
• Other places where you may not have intended them to appear

However, OAuth has also developed defenses over time.

For example, PKCE makes a stolen authorization code much less useful by requiring another value tied to the original transaction.

So the working group kept coming back to the same basic question:

What attack does this new mechanism stop that the current OAuth protections don’t already handle well enough?

Eventually, the chairs took an informal poll on whether the group agreed that there was a problem here to solve.

Most of the people in the room who responded weren’t actually convinced about that.

This wasn’t a formal vote, which matters in the IETF because they don’t do formal votes like that.

Still, the outcome was useful because it showed where the discussion was really happening.

---

Why Threat Models Matter in Standards Development

The reaction wasn’t simply, “No, it’s a bad idea.”

It was closer to:

Could you write down the threat model clearly enough that we can tell whether a new mechanism is actually necessary?

That may sound procedural, but I think it is one of the most important disciplines in standards development.

It’s very easy to go from:

“We found a possible attack”

to:

“Here’s the new protocol feature.”

A better process forces several steps in between.

First, you ask:

• What exactly is the attack?
• Who can carry it out?
• What protections already exist?
• Where do those protections fail?
• What requirements follow from that failure?
• Only then, what new mechanism should we add, if any?

That discipline matters because more security is not free.

Every new mechanism has to be implemented correctly. Different implementations have to interoperate. Developers have to understand when to use it, and someone has to maintain it for years.

---

What Agentic AI Changes About OAuth

At the next interim meeting, on September 28, the conversation moved to agents.

Anthropic and OpenAI presented authorization issues they are seeing in agentic AI systems. This is where the broader story starts to come out.

Some of the problems associated with agents aren’t actually new.

Agents may need to:

• Discover services they’ve never encountered before.
• Establish themselves with authorization servers without pre-existing relationships.
• Deal with consent.
• Refresh tokens.
• Handle stolen bearer tokens.
• Manage authorization across organizational boundaries.

Those are all OAuth problems, and they are problems we’ve been discussing for years.

Agents make them more difficult, perhaps, or make them happen at a much larger scale.

But they’re not entirely new.

The interesting question is who exactly is acting.

---

Who Is the Actor?

Imagine a person using an AI service.

That service operates an agent. The agent invokes another agent. The second agent calls an API.

Who is the actor?

There is:

• The human
• The agent platform
• A particular agent instance
• Potentially another agent underneath it
• The task the human originally asked the system to perform

Those identities are related, but they are not the same. They also do not necessarily have the same authority.

Traditional OAuth is very good at questions that look something like:

Can this application act with these permissions on behalf of the user?

Agentic systems increasingly need to answer something more like:

Can this particular software actor, acting on behalf of another actor under authority ultimately derived from this person or organization, perform this specific action against this resource for this purpose?

That’s a much richer authorization problem.

It also creates pressure on another old OAuth concept: scopes.

---

When OAuth Scopes Become More Contextual

Scopes work reasonably well when permissions are broad and relatively stable.

For example:

• Read this calendar.
• Write this file.
• Access this resource.

They work less well when the decision depends heavily on context.

Suppose I ask an agent to reschedule one meeting because my flight was canceled.

I may be comfortable giving it permission to change that meeting.

I probably don’t want to grant it broad permission to modify every meeting on my calendar for the next month.

So authorization starts to become more contextual.

You have to ask:

• Who is acting?
• What are they trying to do?
• Which resource is involved?
• What authority was delegated?
• Does that authority still apply to this particular request?

---

Is This Still an OAuth Problem?

At some point, however, we have to ask whether this is still an OAuth problem.

OAuth is fundamentally a framework for delegated access.

If we keep adding more context, richer policy, multistep delegation, change, and per-request decisions, are we extending OAuth?

Or are we asking OAuth to become a general-purpose authorization policy system?

I think that’s one of the most important questions in the current discussion.

Are agents exposing missing pieces of OAuth?

Or are agents asking OAuth to solve problems outside its natural scope?

Those lead to very different standards work.

The upcoming interim meetings in October may help clarify some of this.

One meeting is devoted to AAuth, an individual proposal for agent-to-resource authorization that includes explicit ideas around:

• Agent identity
• Proof of possession
• Multiple authorization relationships
• Information about the mission an agent is carrying out

A later meeting steps back again to examine agent authorization use cases and gaps.

---

Don’t Start With the New Protocol

The sequencing is encouraging.

There are concrete deployment problems. There are proposed architectures. There are efforts to identify where existing OAuth mechanisms already work and where they may not.

That is much healthier than deciding first that AI needs a new authorization protocol and working backwards from there.

I would also resist the headline that OAuth is reinventing itself for AI.

Bearer token theft isn’t new.

Client identity issues aren’t new.

Browser security certainly isn’t new.

Delegation is not new, either. We’ve been talking about it for a very long time.

What agents are doing is placing more pressure on assumptions that were easier to live with when software clients were more predictable, integrations were often configured in advance, and a human was directly involved at important points in the flow.

Those assumptions become harder to maintain when software:

• Discovers services dynamically across organizational boundaries
• Delegates work to other software
• Acts repeatedly
• Operates without putting a consent screen in front of the person every time

Because, frankly, that would be really annoying.

---

Where Should OAuth Draw the Line?

It doesn’t mean that OAuth should absorb all of these problems.

In fact, one of the most useful things happening in the working group right now is the willingness to ask whether it should.

So the interesting thing to watch over the next couple of months is not which new draft wins.

It’s where the OAuth working group draws its boundaries.

Which new problems generally require extensions to the protocol?

Which can be solved with mechanisms we already have?

Which belong somewhere else in the Internet architecture?

And when software acts with increasingly complicated chains of delegated authority, how much context does the infrastructure need before it can answer the oldest authorization question of them all?

---

Should This Actor Be Allowed to Do This?

Should this actor be allowed to do this?

That’s the fundamental question.

The challenge is that increasingly autonomous software makes the answer more complicated.

The OAuth working group’s current discussions are therefore worth watching, not simply because they may produce new mechanisms, but because they are asking where authorization belongs, what information it needs, and how much complexity OAuth should absorb.

I’ll update this post if I learn more information.

I hope you’ll go back to the written version and check the links.

I’ll talk to you next week.

---

About the Digital Identity Digest

And that’s it for this week’s episode of the Digital Identity Digest.

If it helps make things a little clearer, or at least a little more interesting, share it with a friend or colleague and connect with me on LinkedIn @hlflanagan.

If you enjoyed the show, be sure to subscribe and leave me a rating and review on Apple Podcasts or wherever you listen to podcasts.

You can also find the written full post at Spherical Cow Consulting.

Stay curious, stay engaged, and let’s get these conversations going.