97 field names, zero agreement: the OAuth agent delegation drafts

OAuth can say who the client is. It cannot say that the client is an agent acting for a human, or that the agent handed the job to another agent. Eighteen active Internet-Drafts are trying to fix that. We measured how much they agree.

The answer is: almost not at all. On 2026-09-02 we pulled every active OAuth draft from the IETF datatracker, downloaded the eighteen whose titles mention agents or AI, and diffed their proposed wire vocabulary against OAuth 2.1 and the RFCs they all build on. Across 423 pages of specification text we found 97 new field names. Ninety-six of them appear in exactly one draft.

That is not a standards process converging. That is eighteen parallel answers to the same question, published faster than anyone can read them.

Method

Everything below comes from the datatracker REST API and from the raw draft text on ietf.org, fetched on 2026-09-02. No secondary sources.

We queried the document API for active drafts, filtered by name and by title, downloaded each draft at its current revision, and tokenized the text for snake_case identifiers. The baseline vocabulary — what already exists in OAuth — is the union of the identifiers found in draft-ietf-oauth-v2-1-15, RFC 8693 (Token Exchange), RFC 9068 (JWT access tokens) and RFC 9396 (Rich Authorization Requests). Anything outside that union, used three or more times in a draft, counts as proposed new vocabulary.

The counting is mechanical and reproducible. The interpretation is ours.

The census

There are 280 Internet-Drafts in the datatracker whose name contains the string agent. 166 of them are active right now. All 166 have a latest revision dated 2026. All 166 belong to group id 1027, which is the datatracker's bucket for Individual Submissions — not one of them is a working group document.

Narrow to OAuth. There are 95 active drafts with oauth in the name. Fifteen belong to the Web Authorization Protocol working group. Of the remaining 80 individual submissions, 34 mention agents, AI or autonomy in their title or abstract, and 18 put it in the title.

None of the 18 is a working group document. The fifteen that are read like a different decade: OAuth 2.1 itself, draft-ietf-oauth-client-id-metadata-document, identity chaining, transaction tokens, first-party apps, attestation-based client auth, SPIFFE client auth, SD-JWT VC, status lists. Useful, adjacent, and in several cases the actual substrate the agent drafts assume. But the working group has adopted nothing that names an agent.

The affiliations are a map of who is worried. Huawei has three separate drafts. China Mobile has two, one of them co-authored with CNNIC and Huawei. Amazon has one. The rest are small vendors and independents: Tenuo, Attest, TwoGenIdentity, Zentity, Jarwin, AgentAdmit, and three drafts from authors listing themselves as Independent.

Four names for one integer

The clearest way to see the fragmentation is to pick a single design decision every one of these systems has to make, and count the names.

Take delegation depth: the maximum number of hops a chain of authority is allowed to travel before a verifier rejects it. Every serious delegation design needs it, because without it a compromised sub-agent can extend the chain forever. Four of the drafts specify it. They specify it four different ways.

// draft-niyikiza-oauth-attenuating-agent-tokens-01
{ "del_depth": 0, "del_max_depth": 3, "par_hash": "..." }

// draft-yakung-oauth-agent-attestation-00 (ACAP)
{ "att_depth": 0, "att_chain": ["jti"], "att_pid": null }

// draft-valverde-oauth-pact-00, inside delegation_chains
{ "depth": 1, "max_depth": 3, "chain": [...], "parent_jti": "..." }

// draft-araut-oauth-transaction-tokens-for-agents-02, inside chain_metadata
{ "hop_count": 2, "current_actor": "...", "min_assurance_level": "..." }

Same integer. Same invariant — a verifier compares current depth against a cap and refuses. Four names, four container shapes, four sets of processing rules. A resource server that wants to enforce depth limits has to implement all four or pick a winner before there is one.

The pattern holds across the whole corpus. Of the 97 novel identifiers we extracted, exactly one is used by more than a single draft: agent_id, which appears eight times in the ACAP attestation draft and nine times in China Mobile's revocation draft — and even there it does not mean quite the same thing.

Five mechanisms for one problem

The naming collision is downstream of a deeper one. The drafts do not even agree on which layer of the stack the delegation chain lives in.

Each of these is defensible. Together they are unimplementable. A gateway that sits between agents and models cannot support a header-carried chain, a nested act claim, an offline-attenuated capability token and a CIBA-mediated consent flow at once and call the result interoperable.

What the implementations look like

Three of the drafts include an implementation status section. We checked them.

The Agent-Delegation draft is honest about its own state: a single-author, zero-dependency Node.js proof of concept at hamr0/justabit, which the text describes as not externally reviewed and not adopted by any organization. The repo was created on 2026-08-14 and has zero stars.

The ACAP attestation draft cites a Go server at chudah1/attest-dev plus TypeScript and Python SDKs. The repo exists, has one star, and was last pushed 2026-05-06. The npm package @attest-dev/sdk is real, at version 0.1.0-beta.6, published 2026-04-14. The PyPI package attest-sdk is at 0.1.0b5 with five releases.

The agent grants profile notes that a product called Grantex offers "an implementation-specific JSON API inspired by this profile" as of 2026-08-30 — which is a careful way of saying the profile is not implemented as written.

And the draft that started the whole line, the WSO2 on-behalf-of extension, expired on 2026-02-27 and was never adopted. Its ideas survived; its document did not.

Meanwhile, in production

Here is the number that reframes the rest. The MCP 2026-07-28 authorization specification — four files, 53,622 bytes, the auth layer that actual agent deployments run on today — contains zero occurrences of the words delegation, on-behalf and actor, and zero references to token exchange or RFC 8693.

It contains seventeen references to client-id-metadata-document.

That is the whole state of play in two numbers. The shipping stack solved which client is this by pointing the client ID at a URL, which we measured across 3,450 authorization servers last week. It has not even started on on whose behalf, through how many hands. And the correlation runs the other way too: only two of the eighteen agent drafts mention CIMD at all, while nine reference DPoP and ten reference token exchange. The people writing agent delegation drafts and the people shipping agent authorization are reading different documents.

The gap that touches money

The one document in the set with a plausible claim to consensus is not a mechanism at all. draft-chen-oauth-agent-authz-use-cases-03, revised 2026-08-25 by authors from China Mobile, CNNIC and Huawei, is a use-case and gap analysis with eleven scenarios. It names six major gaps. Two of them matter directly to anyone moving value.

Gap three is the inability to represent delegation chains: standard tokens cannot securely express User to Agent A to Agent B, which the draft calls a critical blocker for multi-agent business processes. Its worked example is a payment chain — a travel agent delegating to a flight booker delegating to a payment processor hitting a bank API.

Gap six is sharper. The draft distinguishes grant-layer authority, which is what OAuth is good at, from execution-layer evidence: a non-repudiable cryptographic proof that the user sanctioned this specific action at the moment it happened. In the insurance claim scenario, the requirement is stated precisely — the evidence must bind the specific payment details, amount and recipient, to the full verifiable delegation chain. Grant-layer tokens, the draft says, prove potential, not the legitimacy of an executed transaction.

Read that from the payments side and something odd appears. Execution-layer evidence is the one part of this problem that is already solved and deployed. An EIP-3009 authorization is exactly a signed statement binding sender, recipient, amount and a validity window to a nonce, and x402 carries it over HTTP as the payment payload. The settlement layer has had non-repudiable per-action evidence since before the agent boom. What it does not have is the identity half: the signature proves a key authorized a transfer, not that a human authorized the agent that holds the key.

The two halves are being built in different buildings, by different people, at very different speeds. On-chain, the delegation primitives ship and get used — ERC-7710 delegations and spend permissions are deployed contracts with real transactions. Off-chain, the equivalent question has 97 candidate field names and no working group.

Where the IETF is actually heading

There is institutional movement, just not where the drafts are. Three agent-related efforts exist as groups rather than documents: catalist, a coordination BOF created 2026-06-11 and now concluded; agentproto, an Agent Communication Protocols BOF created 2026-07-24; and DAWN — Discovery of Agents With Names — a proposed working group created 2026-08-24, whose charter reached revision 00-03 on 2026-08-28.

DAWN is the one closest to chartering, and its scope is discovery: how a client finds an agent, learns its type, its reachability and its protocol options, probably over DNS and mDNS. Read the out-of-scope list and the shape of the next two years appears. Explicitly excluded from the initial phase: stable identifiers of AI agents, tools and skills; registration of agents in discovery servers; and trust management and trust evaluation beyond defining exchange protocols.

So the first agent working group the IETF charters will standardize how to find an agent, and will explicitly decline to standardize how to name one durably or how to trust it. The delegation chain question does not have a home yet.

What it means for LLM4Agents

The practical conclusion is a negative one, and it is worth stating plainly: none of these eighteen drafts should be implemented by a gateway today. Ninety-six of 97 proposed field names have exactly one author behind them. Shipping any of them buys interoperability with nobody and a migration cost later.

What does change for us is the threat model. We are an OpenAI-compatible gateway where agents pay per use in stablecoins. Today a request arrives with a key or an x402 payment payload, and both answer who is paying. Neither answers who authorized this spend, through how many intermediaries. When a sub-agent three hops from a human burns a budget, our logs record the payer, not the chain. That is fine while fleets are small and single-tenant. It stops being fine the moment an agent our customer does not operate spends our customer's money, and the dispute lands on us.

The gap analysis gives that the right name: grant-layer authority versus execution-layer evidence. We already produce excellent execution-layer evidence — every settled request has a signed authorization binding amount and recipient. What we cannot produce is the chain above it. That is the asymmetry to close, and it is closeable without waiting for the IETF, because the chain can be recorded and attested locally long before it can be verified interoperably.

There is also an opportunity in the fragmentation. A gateway that already sees every request an agent makes is the natural place to observe a delegation chain even when no standard exists to enforce one. The eighteen drafts disagree about the wire format; they agree almost completely about the data model — an ordered chain of actors, a depth, a parent link, a set of narrowing constraints. That model is stable enough to record against today.

Staying on the frontier

Concrete steps, in the order we would do them.

First, record the chain we can already see. Add an optional caller-chain field to request metadata: an ordered list of actor identifiers, a hop count, and the identifier of the root principal. Emit it on OTel spans and on billing records. This costs nothing in standards risk because it is our own telemetry, and it turns "who spent this" into "who authorized this" the day a customer asks.

Second, enforce depth locally. The four drafts disagree on the field name and agree on the invariant. Implement one cap per API key — maximum hops before a request is refused — with the limit set by the account owner. Depth limiting is the single highest-value primitive in the entire corpus and it needs no counterparty to cooperate.

Third, bet only on working group documents. The safe integrations are the fifteen adopted drafts, not the eighteen individual ones. CIMD is already the MCP path for client identity. Identity chaining and the Identity Assertion JWT Authorization Grant are the adopted answer to cross-domain delegation for enterprises. Transaction tokens are the adopted answer to propagating call context across services. If we need a delegation story for an enterprise customer next quarter, it is built from those three, not from any draft in this audit.

Fourth, use the nested act claim as the neutral format. When we do have to serialize a chain, RFC 8693's act is the only representation that is both shipped and referenced by more than half the proposals. It is descriptive rather than enforcing, which is a real limitation, but it is the format most likely to survive whichever draft eventually wins.

Fifth, watch two documents, not eighteen. The use-cases and gap analysis draft is where working group consensus will show up first — if the OAuth WG adopts anything agent-shaped, it will most likely be that document or a mechanism written against its gap list. And the DAWN charter tells us when agent identity finally gets a home, because the moment stable agent identifiers move from its out-of-scope list into a charter, the delegation question has somewhere to go.

Sixth, close the loop with the payment layer. Our differentiator is that we already hold execution-layer evidence for every request. Binding a recorded caller chain to the payment authorization for the same request — same nonce, same amount, same recipient — produces something none of the eighteen drafts can produce on its own: proof that a specific chain of agents caused a specific transfer. That is worth building before the standard exists, not after.