Christian Nennemann
1ec1f69bee
Release prep: - Version bump to 0.3.0 (pyproject.toml, cli.py) - Rewrite README.md with current stats (475 drafts, 713 authors, 501 ideas) - Add CONTRIBUTING.md with dev setup and code conventions Blog site: - Add scripts/build-site.py (markdown → HTML with clean CSS, dark mode, nav) - Generate static site in docs/blog/ (10 pages) - Ready for GitHub Pages deployment Academic paper (paper/main.tex): - Update all counts: 474→475 drafts, 557→710 authors, 1907→462 ideas, 11→12 gaps - Add false-positive filtering methodology (113 excluded, 361 relevant) - Add cross-org convergence analysis (132 ideas, 33% rate) - Add GDPR compliance gap to gap table - Add LLM-as-judge caveats to rating methodology and limitations - Add FIPA, IEEE P3394, W3C WoT to related work with bibliography entries - Fix safety ratio to show monthly variation (1.5:1 to 21:1) Pipeline: - Fetch 1 new draft (475 total), 3 new authors (713 total) - Fix 16 ruff lint errors across test files - All 106 tests pass Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
373 lines
24 KiB
HTML
373 lines
24 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<title>The OAuth Wars and Other Battles — IETF AI Agent Analysis</title>
|
|
<link rel="stylesheet" href="/blog/css/style.css">
|
|
</head>
|
|
<body>
|
|
<div class="container">
|
|
<nav><a href="/blog/" class="site-title">IETF AI Agent Analysis</a>
|
|
<a href="/blog/posts/01-gold-rush.html">Rush</a>
|
|
<a href="/blog/posts/02-who-writes-the-rules.html">Rules</a>
|
|
<strong>Wars</strong>
|
|
<a href="/blog/posts/04-what-nobody-builds.html">Builds</a>
|
|
<a href="/blog/posts/05-1262-ideas.html">Converge</a>
|
|
<a href="/blog/posts/06-big-picture.html">Picture</a>
|
|
<a href="/blog/posts/07-how-we-built-this.html">This</a>
|
|
<a href="/blog/posts/08-agents-building-the-analysis.html">Analysis</a></nav>
|
|
<h1 id="the-oauth-wars-and-other-battles">The OAuth Wars and Other Battles</h1>
|
|
<p><em>14 competing proposals, 155 protocols with no interop layer, and 25+ near-duplicate drafts. Inside the IETF's AI agent fragmentation problem.</em></p>
|
|
<p><em>Analysis based on IETF Datatracker data collected through March 2026. Counts and statistics reflect this snapshot.</em></p>
|
|
<hr />
|
|
<p>Fourteen separate Internet-Drafts are trying to solve the same problem: how should AI agents authenticate and get authorized using OAuth? They are not collaborating. They are not compatible. And they are all submitted in the same nine-month window.</p>
|
|
<p>This is the fragmentation problem, and it is not limited to OAuth. Across the IETF's AI agent landscape, our analysis found the same pattern repeated in agent discovery, multi-agent communication, intent-based routing, and 6G agent requirements. Teams are working in parallel, not together, and the cost is measured in wasted effort, confused implementers, and the growing risk of incompatible deployments.</p>
|
|
<h2 id="the-oauth-cluster-14-ways-to-solve-one-problem">The OAuth Cluster: 14 Ways to Solve One Problem</h2>
|
|
<p>The most crowded corner of the AI agent standards landscape is OAuth for agents. Every proposal is trying to answer the same fundamental question: when an AI agent acts on behalf of a user -- or on its own -- how does it prove its identity and obtain permission?</p>
|
|
<p>The depth of this cluster is not surprising when you look at the ecosystem's foundations. Our cross-reference analysis of all 434 drafts found that <strong>OAuth 2.0</strong> (RFC 6749) is cited by <strong>36 drafts</strong>, <strong>JWT</strong> (RFC 7519) by <strong>22</strong>, <strong>OAuth Bearer</strong> (RFC 6750) by <strong>9</strong>, and <strong>DPoP</strong> (RFC 9449) by <strong>9</strong>. The OAuth stack is the single most-referenced functional standard in the entire corpus after TLS. The agent identity problem runs through the landscape like a root system.</p>
|
|
<p>Here are all 14 drafts:</p>
|
|
<table>
|
|
<thead>
|
|
<tr>
|
|
<th>Draft</th>
|
|
<th>Approach</th>
|
|
<th style="text-align: right;">Score</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-aylward-daap-v2/">draft-aylward-daap-v2</a></td>
|
|
<td>Comprehensive accountability protocol</td>
|
|
<td style="text-align: right;">4.75</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-goswami-agentic-jwt/">draft-goswami-agentic-jwt</a></td>
|
|
<td>Agentic JWT for autonomous systems</td>
|
|
<td style="text-align: right;">4.5</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-chen-oauth-rar-agent-extensions/">draft-chen-oauth-rar-agent-extensions</a></td>
|
|
<td>RAR extensions for agent policy</td>
|
|
<td style="text-align: right;">4.2</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-aap-oauth-profile/">draft-aap-oauth-profile</a></td>
|
|
<td>OAuth 2.0 profile for autonomous agents</td>
|
|
<td style="text-align: right;">4.2</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-barney-caam/">draft-barney-caam</a></td>
|
|
<td>Contextual agent authorization mesh</td>
|
|
<td style="text-align: right;">4.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-liu-agent-operation-authorization/">draft-liu-agent-operation-authorization</a></td>
|
|
<td>Verifiable delegation via JWT</td>
|
|
<td style="text-align: right;">4.1</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-rosenberg-oauth-aauth/">draft-rosenberg-oauth-aauth</a></td>
|
|
<td>OAuth for agents on PSTN/SMS</td>
|
|
<td style="text-align: right;">3.6</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-oauth-ai-agents-on-behalf-of-user/">draft-oauth-ai-agents-on-behalf-of-user</a></td>
|
|
<td>On-behalf-of-user extension</td>
|
|
<td style="text-align: right;">3.7</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-jia-oauth-scope-aggregation/">draft-jia-oauth-scope-aggregation</a></td>
|
|
<td>Scope aggregation for multi-step workflows</td>
|
|
<td style="text-align: right;">3.5</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-liu-oauth-a2a-profile/">draft-liu-oauth-a2a-profile</a></td>
|
|
<td>A2A profile for transaction tokens</td>
|
|
<td style="text-align: right;">3.6</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-song-oauth-ai-agent-authorization/">draft-song-oauth-ai-agent-authorization</a></td>
|
|
<td>Target-based authorization</td>
|
|
<td style="text-align: right;">2.8</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-song-oauth-ai-agent-collaborate-authz/">draft-song-oauth-ai-agent-collaborate-authz</a></td>
|
|
<td>Multi-agent collaboration authz</td>
|
|
<td style="text-align: right;">3.5</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-chen-ai-agent-auth-new-requirements/">draft-chen-ai-agent-auth-new-requirements</a></td>
|
|
<td>New auth requirements analysis</td>
|
|
<td style="text-align: right;">3.8</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-yao-agent-auth-considerations/">draft-yao-agent-auth-considerations</a></td>
|
|
<td>Auth considerations analysis</td>
|
|
<td style="text-align: right;">3.1</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<p><em>(Scores are LLM-generated relative rankings from abstracts, not human expert assessments. See <a href="../methodology.md">Methodology</a>.)</em></p>
|
|
<p>The quality range is enormous -- from 2.8 to 4.75 -- and the approaches barely overlap. Some extend OAuth 2.0 with new grant types. Others define entirely new token formats (Agentic JWT). Still others propose mesh architectures or accountability layers on top of existing auth flows. Two drafts (song-oauth-ai-agent-authorization and song-oauth-ai-agent-collaborate-authz) come from the same Huawei team and address different facets of the problem. Two more (chen-oauth-rar-agent-extensions and chen-ai-agent-auth-new-requirements) come from a China Mobile team.</p>
|
|
<p>The gap our analysis identified in this cluster: most focus on <strong>single-agent authorization</strong>. Few address chained delegation across multiple agents, and none standardize real-time revocation in agent-to-agent workflows. An agent that obtains a token and delegates a sub-task to another agent -- which then delegates further -- creates a chain of trust that no single draft adequately covers.</p>
|
|
<p>A note on terminology: "consent" in the OAuth context means a technical authorization flow where a user delegates access scopes to a client. This is distinct from GDPR consent (<em>Einwilligung</em>) under Art. 6(1)(a) GDPR, which must be freely given, specific, informed, and unambiguous, and is revocable at any time. When AI agents further delegate to sub-agents, the chain of GDPR-valid consent may break entirely -- a problem none of these 14 drafts addresses. The controller-processor relationship under Art. 28 GDPR imposes additional requirements (data processing agreements, sub-processor authorization) that go beyond what any OAuth extension can express on its own.</p>
|
|
<h2 id="the-agent-gateway-melee-10-drafts">The Agent Gateway Melee: 10 Drafts</h2>
|
|
<p>If OAuth for agents is about identity, the agent gateway cluster is about communication architecture. Ten drafts are competing to define how agents from different platforms and ecosystems collaborate:</p>
|
|
<table>
|
|
<thead>
|
|
<tr>
|
|
<th>Draft</th>
|
|
<th>Approach</th>
|
|
<th style="text-align: right;">Score</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-li-dmsc-macp/">draft-li-dmsc-macp</a></td>
|
|
<td>Multi-agent collaboration protocol suite</td>
|
|
<td style="text-align: right;">4.2</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-agent-gw/">draft-agent-gw</a></td>
|
|
<td>Semantic routing gateway</td>
|
|
<td style="text-align: right;">3.9</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-cui-dmsc-agent-cdi/">draft-cui-dmsc-agent-cdi</a></td>
|
|
<td>Cross-domain interop framework</td>
|
|
<td style="text-align: right;">3.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-han-rtgwg-agent-gateway-intercomm-framework/">draft-han-rtgwg-agent-gateway-intercomm-framework</a></td>
|
|
<td>Gateway intercommunication</td>
|
|
<td style="text-align: right;">3.6</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-li-dmsc-inf-architecture/">draft-li-dmsc-inf-architecture</a></td>
|
|
<td>DMSC infrastructure architecture</td>
|
|
<td style="text-align: right;">3.1</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-liu-dmsc-acps-arc/">draft-liu-dmsc-acps-arc</a></td>
|
|
<td>Agent collaboration protocols arch</td>
|
|
<td style="text-align: right;">3.6</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-yang-dmsc-ioa-task-protocol/">draft-yang-dmsc-ioa-task-protocol</a></td>
|
|
<td>IoA task protocol</td>
|
|
<td style="text-align: right;">3.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-yang-ioa-protocol/">draft-yang-ioa-protocol</a></td>
|
|
<td>IoA protocol</td>
|
|
<td style="text-align: right;">3.6</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-fu-nmop-agent-communication-framework/">draft-fu-nmop-agent-communication-framework</a></td>
|
|
<td>Network AIOps comm framework</td>
|
|
<td style="text-align: right;">3.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td><a href="https://datatracker.ietf.org/doc/draft-campbell-agentic-http/">draft-campbell-agentic-http</a></td>
|
|
<td>HTTP best practices</td>
|
|
<td style="text-align: right;">--</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<p>A revealing pattern: five of these ten drafts reference "DMSC" -- Dynamic Multi-agent Secured Collaboration -- a concept pushed primarily by Chinese institutions through the IETF's DMSC side meeting. This cluster represents an organized attempt to define the agent collaboration architecture, but even within that effort, multiple competing proposals have emerged.</p>
|
|
<p>The gap: no draft in this cluster addresses <strong>dynamic trust establishment between gateways</strong>, or how to handle conflicting semantic schemas across ecosystems. If Agent Gateway A speaks MCP and Agent Gateway B speaks A2A Protocol, these drafts describe the need for translation but do not provide it.</p>
|
|
<h2 id="the-near-duplicate-epidemic">The Near-Duplicate Epidemic</h2>
|
|
<p>Our embedding-based similarity analysis produced a more troubling finding: <strong>25+ draft pairs</strong> have cosine similarity above 0.98. Many are functionally identical proposals submitted under different names:</p>
|
|
<table>
|
|
<thead>
|
|
<tr>
|
|
<th>Draft A</th>
|
|
<th>Draft B</th>
|
|
<th>Reason</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td>draft-a2a-moqt-transport</td>
|
|
<td>draft-nandakumar-a2a-moqt-transport</td>
|
|
<td>Same content, different name</td>
|
|
</tr>
|
|
<tr>
|
|
<td>draft-abbey-scim-agent-extension</td>
|
|
<td>draft-scim-agent-extension</td>
|
|
<td>Same draft, dual submission</td>
|
|
</tr>
|
|
<tr>
|
|
<td>draft-rosenberg-aiproto</td>
|
|
<td>draft-rosenberg-aiproto-nact</td>
|
|
<td>Renamed</td>
|
|
</tr>
|
|
<tr>
|
|
<td>draft-rosenberg-aiproto-cheq</td>
|
|
<td>draft-rosenberg-cheq</td>
|
|
<td>Renamed</td>
|
|
</tr>
|
|
<tr>
|
|
<td>draft-cui-nmrg-llm-nm</td>
|
|
<td>draft-irtf-nmrg-llm-nm</td>
|
|
<td>WG adoption (individual to IRTF)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>draft-ar-emu-hybrid-pqc-eapaka</td>
|
|
<td>draft-ietf-emu-hybrid-pqc-eapaka</td>
|
|
<td>WG adoption</td>
|
|
</tr>
|
|
<tr>
|
|
<td>draft-zheng-agent-identity-management</td>
|
|
<td>draft-zheng-dispatch-agent-identity-management</td>
|
|
<td>Same draft, different WG</td>
|
|
</tr>
|
|
<tr>
|
|
<td>draft-sun-zhang-iaip</td>
|
|
<td>draft-sz-dmsc-iaip</td>
|
|
<td>Same draft, different WG</td>
|
|
</tr>
|
|
<tr>
|
|
<td>draft-zeng-mcp-troubleshooting</td>
|
|
<td>draft-zm-rtgwg-mcp-troubleshooting</td>
|
|
<td>Same draft, different WG</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<p>Some of these duplications are legitimate IETF process: a draft moves from individual submission to working group adoption (like draft-cui-nmrg-llm-nm becoming draft-irtf-nmrg-llm-nm). Others reflect authors shopping the same draft to multiple working groups. And a few appear to be genuine content duplication -- the same ideas submitted under different author combinations.</p>
|
|
<p>The practical effect: the 434-draft corpus includes substantial double-counting. After de-duplication, the true number of distinct proposals is somewhat lower -- removing the 25 near-duplicate pairs yields roughly 409 distinct drafts, and further accounting for related-but-not-identical submissions brings the number down further. But even with generous de-duplication, the volume is extraordinary.</p>
|
|
<h2 id="the-a2a-protocol-zoo">The A2A Protocol Zoo</h2>
|
|
<p>Zooming out from individual clusters, the broadest fragmentation is in the <strong>155 A2A protocol drafts</strong>. These span everything from low-level transport (A2A over MOQT/QUIC) to high-level semantic routing (intent-based agent interconnection) to specific use cases (MCP for network troubleshooting).</p>
|
|
<p>The most common technical idea in the entire corpus -- "Multi-Agent Communication Protocol" -- appears in <strong>8 separate drafts</strong> from different teams. Eight teams are independently designing how agents should talk to each other.</p>
|
|
<table>
|
|
<thead>
|
|
<tr>
|
|
<th>Competing Area</th>
|
|
<th style="text-align: right;">Drafts</th>
|
|
<th>Distinguishing Fact</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td>OAuth for agents</td>
|
|
<td style="text-align: right;">14</td>
|
|
<td>No draft handles chained delegation</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Agent gateway/collaboration</td>
|
|
<td style="text-align: right;">10</td>
|
|
<td>5 are DMSC-linked; no trust framework</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Agent discovery</td>
|
|
<td style="text-align: right;">6</td>
|
|
<td>Range from DNS-based to full directories</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Intent-based routing</td>
|
|
<td style="text-align: right;">5</td>
|
|
<td>Requirements-heavy, protocol-light</td>
|
|
</tr>
|
|
<tr>
|
|
<td>6G agent requirements</td>
|
|
<td style="text-align: right;">6</td>
|
|
<td>Wish lists, not specifications</td>
|
|
</tr>
|
|
<tr>
|
|
<td>SCIM/identity registry</td>
|
|
<td style="text-align: right;">6</td>
|
|
<td>3 are near-duplicates</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<p>The discovery cluster is particularly illustrative. Six drafts propose different ways to find AI agents: <a href="https://datatracker.ietf.org/doc/draft-narajala-ans/">draft-narajala-ans</a> (score 4.2) proposes a DNS-based Agent Name Service. <a href="https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-bandaid/">draft-mozleywilliams-dnsop-bandaid</a> (3.6) also uses DNS but via SVCB records. <a href="https://datatracker.ietf.org/doc/draft-pioli-agent-discovery/">draft-pioli-agent-discovery</a> (3.2) defines a lightweight registration and discovery protocol. <a href="https://datatracker.ietf.org/doc/draft-gaikwad-woa/">draft-gaikwad-woa</a> (3.2) proposes a Web of Agents format using JSON Schema. None of them reference each other.</p>
|
|
<h2 id="the-deeper-fragmentation-different-technological-dna">The Deeper Fragmentation: Different Technological DNA</h2>
|
|
<p>The protocol-level fragmentation documented above is only the visible layer. Beneath it, our RFC cross-reference analysis reveals a more fundamental divide: the two major drafting blocs are building on <strong>entirely different technology stacks</strong>.</p>
|
|
<table>
|
|
<thead>
|
|
<tr>
|
|
<th>Foundation</th>
|
|
<th>Chinese Bloc</th>
|
|
<th>Western Bloc</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td><strong>Network management (YANG/NETCONF)</strong></td>
|
|
<td>Strong (RFC 6241, 8639, 8641, 7950)</td>
|
|
<td>Absent</td>
|
|
</tr>
|
|
<tr>
|
|
<td><strong>IoT security (COSE/CBOR/OSCORE/CoAP)</strong></td>
|
|
<td>Absent</td>
|
|
<td>Strong (RFC 9052, 8949, 8613, 7252)</td>
|
|
</tr>
|
|
<tr>
|
|
<td><strong>PKI/Certificates (X.509)</strong></td>
|
|
<td>Absent</td>
|
|
<td>Strong (RFC 5280)</td>
|
|
</tr>
|
|
<tr>
|
|
<td><strong>Lightweight auth (EDHOC, CWT)</strong></td>
|
|
<td>Absent</td>
|
|
<td>Strong (RFC 9528, 8392)</td>
|
|
</tr>
|
|
<tr>
|
|
<td><strong>Web APIs (HTTP Semantics)</strong></td>
|
|
<td>Weak</td>
|
|
<td>Strong (RFC 9110)</td>
|
|
</tr>
|
|
<tr>
|
|
<td><strong>TLS 1.3</strong></td>
|
|
<td>Moderate (8 citations)</td>
|
|
<td>Strong (18 citations)</td>
|
|
</tr>
|
|
<tr>
|
|
<td><strong>OAuth 2.0</strong></td>
|
|
<td>Present (11 citations)</td>
|
|
<td>Present (7 citations)</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<p>The Chinese bloc -- Huawei, China Mobile, China Telecom, China Unicom, and associated research institutions -- builds agent infrastructure on <strong>YANG/NETCONF</strong>, the network management protocols that underpin autonomous network operations. The Western bloc -- Ericsson, Cisco, ATHENA, and European research labs -- builds on <strong>COSE/CBOR/CoAP</strong> (IoT security) and <strong>HTTP/TLS/PKI</strong> (web infrastructure).</p>
|
|
<p>The <strong>only shared foundation</strong> is OAuth 2.0, which both blocs cite at comparable rates. This is why the OAuth cluster has 14 competing proposals: it is the one piece of common ground, and everyone is fighting over it.</p>
|
|
<p>This means fragmentation goes deeper than protocol design. Even if the community agreed on a single agent communication pattern, the underlying plumbing is incompatible. A Chinese draft building on NETCONF and a Western draft building on CoAP cannot interoperate without a translation layer -- and that translation layer, as we document in the gap analysis, does not exist.</p>
|
|
<h2 id="what-fragmentation-costs">What Fragmentation Costs</h2>
|
|
<p>The costs of this fragmentation are not theoretical:</p>
|
|
<p><strong>For implementers</strong>: Which OAuth extension do you implement? Do you support SCIM agent schemas or Web of Agents? If your agent needs to discover another agent, do you look in DNS, a well-known URI, or a dedicated directory? Today there is no canonical answer, and choosing wrong means re-implementation when the IETF eventually converges.</p>
|
|
<p><strong>For the IETF process</strong>: Working groups spend time evaluating competing proposals that could be spent converging on solutions. The OAuth working group alone faces 14 agent-related drafts. The volume creates overhead that slows progress on any single proposal.</p>
|
|
<p><strong>For security</strong>: When multiple incompatible authentication and authorization schemes exist, implementations inevitably take shortcuts. The most dangerous agents will be those that implement the easiest -- not the most secure -- available standard.</p>
|
|
<p><strong>For the ecosystem</strong>: Each month that fragmentation persists, real-world agent deployments make choices. Those choices entrench specific approaches, making convergence harder and interoperability more expensive. The window for a unified standard narrows with every proprietary deployment.</p>
|
|
<p><strong>A note on IETF IPR policy</strong>: Implementers considering building on any of the OAuth or protocol drafts discussed above should be aware that Internet-Drafts may be subject to intellectual property rights (IPR) claims. Under BCP 79 (RFC 8179), IETF participants are expected to disclose known IPR. Check the <a href="https://datatracker.ietf.org/ipr/">IETF IPR disclosure database</a> before implementing.</p>
|
|
<h2 id="the-convergence-signals">The Convergence Signals</h2>
|
|
<p>Not everything is divergence. A few positive patterns emerged from the data:</p>
|
|
<p><strong>EDHOC is converging.</strong> The lightweight authenticated key exchange protocol has multiple working-group-adopted drafts (<a href="https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc-psk/">draft-ietf-lake-edhoc-psk</a>, <a href="https://datatracker.ietf.org/doc/draft-ietf-lake-authz/">draft-ietf-lake-authz</a>, <a href="https://datatracker.ietf.org/doc/draft-ietf-emu-eap-edhoc/">draft-ietf-emu-eap-edhoc</a>) with coordinated authorship. This is what healthy standards development looks like: multiple drafts from different teams that explicitly build on each other.</p>
|
|
<p><strong>SCIM agent extensions show maturity.</strong> The Okta team's <a href="https://datatracker.ietf.org/doc/draft-abbey-scim-agent-extension/">draft-abbey-scim-agent-extension</a> (score 3.8) and <a href="https://datatracker.ietf.org/doc/draft-wahl-scim-agent-schema/">draft-wahl-scim-agent-schema</a> (score 3.9) represent a practical approach: extend an existing, widely-deployed protocol (SCIM) rather than invent a new one. This pragmatism is a convergence signal.</p>
|
|
<p><strong>The verifiable conversations approach is gaining traction.</strong> <a href="https://datatracker.ietf.org/doc/draft-birkholz-verifiable-agent-conversations/">draft-birkholz-verifiable-agent-conversations</a> (score 4.5) and the WIMSE/ECT work on execution context tokens represent a "record everything, verify later" approach to agent accountability that multiple communities can support.</p>
|
|
<h2 id="what-needs-to-happen">What Needs to Happen</h2>
|
|
<p>Three structural interventions would accelerate convergence:</p>
|
|
<p><strong>1. Working groups need to pick winners.</strong> The IETF process allows competing proposals, but at some point working groups must adopt specific approaches and redirect competing efforts. In the OAuth agent space, the highest-quality proposals (DAAP, Agentic JWT, RAR extensions) should be evaluated head-to-head, not allowed to proliferate indefinitely.</p>
|
|
<p><strong>2. Interoperability testing, not just drafting.</strong> The 155 A2A protocol proposals exist mostly as text. Interop testing -- where implementations from different teams prove they can work together -- would quickly reveal which proposals have real engineering substance and which are paper exercises.</p>
|
|
<p><strong>3. The translation layer must be built.</strong> Rather than picking one A2A protocol, the community may be better served by a thin interoperability layer that lets agents using different protocols communicate through gateways. Our gap analysis found this cross-protocol translation gap entirely unaddressed -- zero technical ideas in the current corpus.</p>
|
|
<hr />
|
|
<h3 id="key-takeaways">Key Takeaways</h3>
|
|
<ul>
|
|
<li><strong>14 competing OAuth-for-agents proposals</strong> illustrate the depth of fragmentation; none handle chained delegation across agent networks</li>
|
|
<li><strong>155 A2A protocol drafts</strong> exist without an interoperability layer; the most common idea in the corpus appears in 8 separate drafts from different teams</li>
|
|
<li><strong>25+ near-duplicate pairs</strong> (>0.98 similarity) inflate the draft count; after de-duplication, roughly 409 distinct proposals remain</li>
|
|
<li><strong>Convergence signals exist</strong> in EDHOC authentication, SCIM agent extensions, and verifiable conversations -- areas where teams explicitly build on each other</li>
|
|
<li><strong>Fragmentation goes deeper than protocols</strong>: Chinese and Western blocs build on different RFC foundations (YANG/NETCONF vs COSE/CBOR/CoAP); the only shared bedrock is OAuth 2.0</li>
|
|
<li><strong>The missing piece</strong> is a cross-protocol translation layer; no draft in the corpus addresses how agents using different protocols can interoperate</li>
|
|
</ul>
|
|
<p><em>Next in this series: <a href="04-what-nobody-builds.md">What Nobody's Building (And Why It Matters)</a> -- The 11 gaps in the IETF's AI agent landscape, and the real-world consequences of leaving them unfilled.</em></p>
|
|
<hr />
|
|
<p><em>Data from the IETF Draft Analyzer's embedding-based overlap analysis (nomic-embed-text) and cluster detection at 0.85/0.90 similarity thresholds.</em></p>
|
|
<div class="post-nav"><a href="/blog/posts/02-who-writes-the-rules.html">← Who Writes the Rules</a><a href="/blog/posts/04-what-nobody-builds.html">What Nobody Builds →</a></div>
|
|
<footer>
|
|
<p>IETF Draft Analyzer — Data collected through March 2026.
|
|
<a href="https://github.com/cnennemann/ietf-draft-analyzer">Source on GitHub</a></p>
|
|
</footer>
|
|
</div>
|
|
</body>
|
|
</html> |