OAuth for AI agents: What four extensions cover, and the gaps they leave

extract

OAuth for AI agents: What four extensions cover, and the gaps they leave RAR, DPoP, CIMD and Transaction Tokens get cited as the answer for AI agents. What each one actually binds, and three problems none of them solves yet. OAuth for AI agents means using OAuth to authorize software that acts for a person, often across several services and through other agents, long after the person stopped watching. A scoped access token answers one question, whether this client may call this API. Agents raise three more: on whose behalf, under what instruction, and how do you take it all back. Four OAuth extensions (RAR, DPoP, CIMD and Transaction Tokens) answer parts of the first question well. None of them answers the other three. An AI agent holding an access token is a strange kind of OAuth client. It acts for a person who stopped paying attention hours ago, it fans a single instruction out across several services, and it sometimes hands part of the job to another agent nobody registered. Four extensions get named as the fix: Rich Authorization Requests, DPoP, Client ID Metadata Documents and Transaction Tokens. Each solves something real. A gap analysis published in October is the clearest public accounting of where the set runs out. What is the gap analysis, and how much weight does it carry? Revision 04 of "Agent Authorization use cases and gap analysis" went up on October 11, 2026, written by Meiling Chen and Jia Chen of China Mobile, Jiankang Yao of CNNIC, Peter Chunchi Liu of Huawei, Yuning Jiang and Xiang Liu. It catalogs thirteen agent use cases, from a personal digital assistant to automated security incident response, grouped into personal, enterprise and security categories. Section 5 measures four existing OAuth extensions against them. Read it as one group's map, not a verdict. It's an individual Internet-Draft with an IESG state of "I-D Exists", and the datatracker page says so plainly: The draft says it "does not propose new solutions or protocols." Its aim is a shared understanding of the problem space, and it names three recurring gaps: the Authorization Context Gap, the Delegation Chain Gap and the Mass Revocation Gap. The vocabulary worth borrowing is its two-layer split. Grant Layer Authority is "the set of permissions established at the time of authorization, typically represented by scopes in an access token": what an agent may do in principle. Execution Layer Evidence is "a verifiable, non-repudiable record, generated at the moment a specific, critical action is taken," proving a principal consented to that action's concrete parameters. All four extensions below live at the grant layer. All three gaps live at the execution layer. What does RAR give an agent? RFC 9396, a Proposed Standard since May 2023, adds an authorization_details parameter: a JSON array of objects, each with a required type field that determines what else the object may contain. It also defines common fields reusable across APIs: locations, actions, datatypes, identifier and privileges. The RFC's own example: That's the agent-sized version of a permission: a verb, a target, and the parameters that make it reviewable. One trap: "When different common data fields are used in combination, the permissions the client requests are the product of all the values," so an object listing two actions and two datatypes asks for all four combinations. Splitting them across objects gets you the narrow grant you meant. authorization_details and scope can appear in the same request, though the RFC recommends that a given API use only one. RAR's authority is fixed at request time. An agent that only learns the amount, the recipient or the file path three steps into a task has nothing to put in the object. Section 5.1 of the gap analysis is blunt: Its suggested direction is "bounded capabilities": the user grants a budget or a constraint envelope, the agent builds RAR-shaped requests at runtime, and the authorization server checks each one against the pre-approved bounds. That doesn't exist as a spec. You can approximate it with narrow, short-lived grants per task step, enforced in your own policy layer. What does DPoP prove about an agent? RFC 9449, published in September 2023, binds a token to a key pair, so a stolen token is inert without the private key. We've covered the mechanics in depth: DPoP (RFC 9449) explained walks through the proof JWT and server-issued nonces, sender-constrained tokens covers why mTLS and DPoP both exist, and Google's DPoP rollout shows a large provider binding only refresh tokens. For agents, the limit is key lifecycle. DPoP assumes a fairly stable client with a persistent key, and as the draft puts it, "This assumption breaks down when a primary agent needs to delegate a task to a dynamically created, ephemeral sub-agent." Section 5.2 is also precise about what DPoP certifies: A "multi-hop DPoP" model, where a parent derives a constrained token bound to a child's ephemeral key without a round trip to the authorization server, is listed as future work, not something you can implement against. How does CIMD identify an agent nobody registered? Client ID Metadata Documents turn the client_id into a URL that the authorization server fetches for the client's metadata. It's an OAuth Working Group draft (draft-ietf-oauth-client-id-metadata-document-02, updated July 6, 2026, by Aaron Parecki and Emelia Smith). The MCP authorization spec says authorization servers and MCP clients "SHOULD support OAuth Client ID Metadata Documents," and notes that Dynamic Client Registration "is deprecated and retained for backwards compatibility." (Our CIMD vs DCR post covers the comparison. If you build MCP servers on WorkOS, AuthKit supports CIMD; it's off by default and you enable it in the Dashboard.) The constraints are tighter than they look: - A client identifier URL must use https, must contain a path component and must not contain a fragment. - URLs "MUST be compared using simple string comparison," so a trailing slash or an explicit :443 makes it a different client. - The fetched document's client_id must match the URL, and the authorization server "MUST NOT automatically follow HTTP redirects" to get it. - Shared secrets are out: no client_secret, no client_secret_basic, client_secret_post or client_secret_jwt. Public keys go in jwks or jwks_uri. - Servers advertise support with client_id_metadata_document_supported. CIMD runs out in three places. Its metadata has no concept of an agent: no autonomy level, no risk profile, no operational policy. The spec's own introduction concedes that "clients that do not control a stable public URL, such as clients under active development on a developer's local machine" are less well served. And the limit that matters for chains: The proposed additions (agent_type, max_autonomous_budget, human_in_the_loop_policy, signed inline metadata a parent can vouch for, and a parent_agent_id for trust chains) are sketches in a gap analysis, not registered parameters. What do Transaction Tokens carry, and how far? Transaction Tokens aren't an RFC. draft-ietf-oauth-transaction-tokens-11 is an OAuth Working Group draft at "WG Consensus: Waiting for Write-Up", last revised July 30, 2026, with a milestone to submit it to the IESG in December 2026. The authors are Atul Tulshibagwale of CrowdStrike, George Fletcher of Practical Identity and Pieter Kasselman of Defakto Security. A Txn-Token is a short-lived signed JWT asserting a user or workload identity plus an authorization context, passed along the call chain inside one trust domain. The externally visible endpoint exchanges the incoming OAuth access token for a Txn-Token before calling anything internal. Each trust domain has exactly one logical Transaction Token Service, and remote requests to it must use RFC 8693 token exchange. The request names the trust domain and includes a subject token and the desired scope, and may add the caller's IP address and user agent. Lifetimes are "on the order of minutes or less." The draft is explicit that a Txn-Token is neither an authentication credential nor an OAuth access token. The limit is in the definition: the trust domain boundary. The pattern suits one trusted system and doesn't stretch to multi-hop delegation through untrusted third-party agents, with no standard way to reduce permissions or enforce them across organizations. The gap analysis proposes an "Attenuating Agent Token" that lets a parent formally narrow permissions before handing off to a child. One caveat about the map here. Section 5.4 treats Transaction Tokens as "a common architectural pattern, often implemented using JWTs, where initial user context is encoded into a token and propagated through a series of internal microservices," rather than engaging the working group draft's mechanics. Read only that and you'd miss what constrains an implementation: one service per trust domain, mandatory RFC 8693 exchange, and lifetimes measured in minutes. The conclusion about trust boundaries holds, because the spec scopes itself the same way. Read the spec anyway. Why doesn't intent reach the consent screen? The gap analysis illustrates this with a user who asks an assistant to plan a trip, and an assistant that needs to book a flight days later. The authorization server sees the second event with none of the first attached: There's no standard claim for intent, no standard way to bind a consent event to the instruction that caused it, and no standard proof that a human rather than the agent approved. The draft's security considerations are direct about that last one: "AI agents can click "Approve" buttons themselves, so a simple click is no longer proof of human consent." Until something standardizes it, intent lives in your application. Carry a task identifier through every token request belonging to that task, store the originating instruction against it, and show that instruction on the consent screen. For actions where a mistake is expensive, require confirmation on a channel the agent can't reach. Why can't a resource server see the whole delegation chain? The draft's example is a travel agent that delegates flight booking to a flight booker, which calls a payment processor, which calls a bank API: Each hop verifies the hop in front of it. The backward check, proving this request descends from the user's original grant, is the one that doesn't close. Without a standard for it, every implementation improvises, and improvised delegation is where confused deputy attacks live. The nearest answers are at different stages. draft-ietf-oauth-identity-chaining-17, for chaining identity across domains, has been submitted to the IESG and sits in the RFC Editor queue. A transaction-token chaining profile is earlier: draft-fletcher-oauth-txn-token-chaining-profile-00 (September 2026), which replaced an earlier Fletcher draft. What works today is RFC 8693 token exchange at each hop, with a per-hop audience and a grant narrower than the hop above it. That gives you attenuation and an audit trail you can reconstruct from your own logs, but the verification is yours, not the protocol's. We walked through those nested chains in AI agents and the multi-hop delegation problem and the on-behalf-of pattern in OAuth's On-Behalf-Of flow for AI agents. For delegation across an enterprise's apps, ID-JAG is a related token-exchange profile; Inside the ID-JAG covers how it works. Why is revoking a principal's grants still a loop? RFC 7009 dates from August 2013, and its revocation request takes exactly one thing: The cascading behavior is narrower than people assume. Revoking a refresh token SHOULD also invalidate access tokens from the same grant, but only if the server supports revoking access tokens at all; if it doesn't, those access tokens aren't immediately invalidated. Revoking an access token MAY take the refresh token with it. And the server verifies that the token was issued to the client making the request, so a client revokes its own tokens. That's the wrong shape for an administrator trying to cut off a compromised person. So "revoke everything this user granted" is a loop, and the loop has a cost: There's an early individual draft in this space, draft-ni-oauth-batch-authorization-delegation-00 (July 2026). Meanwhile, you can build the kill switch yourself. Record a revocation epoch per principal and per client, bump it in one write when something goes wrong, and check it at the resource server on every request that matters: Keep access token lifetimes short enough that expiry is a real control behind it. The cost is a lookup on the hot path. The alternative is the window. (For the session side of the same problem, see session revocation explained.) What should you build while the specs catch up? Three of the four extensions are grant-layer controls: RAR shapes the permission, DPoP binds the holder, CIMD identifies the client. The fourth carries context only as far as your own trust boundary. Whichever of them your stack uses, intent, lineage and bulk revocation remain your application's problem, and will stay that way through at least the next round of drafts. The design mistake is treating those three as missing features to wait out. They're the places where your own data model has to carry the meaning: a task identity that outlives a single token, a delegation record written at every hop, and the revocation epoch above. Build them now, and when something like parent_agent_id ships as a registered parameter, you're renaming a field you already have. Skip them, and broad, long-lived permissions start looking reasonable, which is exactly the "god tokens" problem the gap analysis warns about.