Where AI Agent Authorization Standards Stand - RFCs, IETF Working Group Documents, Individual Drafts, and Specifications from Other Bodies

\n\n

\nFirst Published: 2026-10-10
\nLast Updated: 2026-10-10
\n

\n\n\n\n\nFor AI agent authorization, it's easy to get the impression that numerous standards documents, with agent in their titles, are being released. When counting through the IETF's datatracker, of the Internet-Drafts containing the string agent in their titles, 48 had new versions published in the 11 days from September 24, 2026, to October 4, 2026 (UTC). These 48 drafts made 70 new-version submissions during that same period. However, all 48 were individual drafts, and not a single Working Group (WG) document, identifiable by names beginning with draft-ietf-, was among them. On the other hand, a WG document that specifically addresses the authentication and authorization of AI agents is outside this count: the WIMSE (Workload Identity in Multi System Environments) WG's draft-ietf-wimse-aims-00 (September 15, 2026) is titled AI Identity Management System. The abstract of this document states:
\n
\n

This document proposes best practices for authentication and authorization of AI agent interactions.

\n
\nThe number of documents with agent in their titles, and the stage of standardization each document has reached, are separate questions. It's impossible to determine from the title alone whether a document is an RFC, a draft adopted by a WG, an individual draft, or a specification at a particular stage of development from an organization outside of the IETF. On October 8, 2026, the IETF's IESG (Internet Engineering Steering Group) approved the charter for the agentproto (Agent Communication Protocols) WG. However, as of October 9, 2026, the datatracker API showed that this WG had no WG documents associated with it.
\n
\nThis article categorizes documents related to the authorization of AI agents, dividing them into five stages: RFCs, IETF Working Group (WG) documents, individual drafts, specifications outside of the IETF, and new WGs and BOFs. For each document, the article lists the version and date, the status terms used by datatracker and various organizations, and the verification date. It also indicates which hop on the agent path the document addresses. The sources used for verification include datatracker (including APIs), the RFC Editor, the IETF charter and meeting materials and mailing lists, the OpenID Foundation, MCP (Model Context Protocol), A2A (Agent2Agent), AAIF (Agentic AI Foundation), and official W3C pages, as verified on October 9, 2026. This article neither recommends which standards to use nor attempts to predict which documents will be adopted.
\n
\nRelated articles on this site:
\n
\n

\n\n

1. The Scope of This Article and the Date It Was Verified

\n\nThis section defines the scope of this article. Following that, it outlines the criteria for documents to be included in the tables, along with the dates verified and the source materials consulted. It also specifies the terminology used in this article, and clarifies what will not be covered.
\n\n

1.1 The Number of Documents with `agent` in the Title Is a Separate Question from the Stage of Standardization

\n\nThe status terms in datatracker show the stage of an IETF document. Documents adopted by a WG are typically republished as WG documents, usually with names that begin with draft-ietf-. The datatracker describes this naming convention as the typical naming convention (see Section 2.2). WG documents have both a WG state and an IESG state. Once a document becomes an RFC, it is assigned an RFC number, along with a classification such as Proposed Standard or Best Current Practice.
\n
\nOn the other hand, whether a document's title includes the word agent is unrelated to its stage of development. The 48 documents in the opening paragraph contain the string agent in their titles and posted new versions in the window. When counted by stage, all of these are individual drafts. The WG document draft-ietf-wimse-aims-00, which addresses the authentication and authorization of AI agents, does not include agent in its title and therefore is not included in this group of 48. Similarly, there are individual drafts that do not include agent in their titles, and WG documents that address AI agents in an appendix, the introduction, or a body section (see Section 3.3).
\n
\nFurthermore, many of the components used for agent authorization are already RFCs. Documents such as OAuth 2.0 (RFC 6749), Token Exchange (RFC 8693), and Protected Resource Metadata (RFC 9728) were not created specifically for agents. The fact that a large number of individual drafts contain the word agent in their titles does not mean that there are no RFCs available that can be used for agent authorization.
\n\n

1.2 Documents This Article Lists in Its Tables

\n\nThis article lists documents falling into one of two categories. (a) Documents whose title, abstract, introduction, or section or appendix headings mention the authentication, authorization, identification, or delegation of AI agents (including protocols for agents such as MCP or A2A). (b) Documents from the IETF and OpenID Foundation that the three anchor documents reference for authentication and authorization. WGs, BOFs (Birds of a Feather), and community groups are also listed if their charters, BOF requests, or group descriptions mention the topics described in (a). For W3C community groups, only two are listed, as examples (Section 7.1).
\n
\nThe three anchor documents are:
\n
\n

draft-ietf-wimse-aims-00 (hereinafter referred to as AIMS): This is the only IETF WG document, as of October 9, 2026, that includes the string AI agent in its abstract, according to a search of the datatracker API.
The authorization page of MCP specification version 2026-07-28: It defines the authorization process for agents calling tools.
A2A 1.0.0 specification: Chapter 7 of this specification describes the authentication and authorization processes for agents delegating tasks to other agents.

\n
\nDocuments that do not fall into either category (a) or (b) but are closely related to the listed documents are listed separately in peripheral rows, with a note indicating the document that references them. This applies to RFC 9396, RFC 9449, and RFC 9470 (see Section 4.2).
\n
\nSome documents are not included in the tables. The anchor documents also reference documents outside the IETF and OpenID Foundation. AIMS references standards from SPIFFE (a CNCF project), as well as the ACP and AP2 protocols for commerce and payments. These fall outside criterion (b) and are not listed. The OpenID Foundation's OpenID Connect Key Binding 1.0 is also excluded (see Section 1.5).
\n\n

1.3 The Verification Date and the Sources Read

\n\nThis article's content is based on the following materials, verified on October 9, 2026. The datatracker API data was retrieved starting at 11:54 UTC on October 9, 2026. The pages for agentproto, dawn, and audit, as well as the IETF 127 dates, were retrieved again between 20:36 and 20:38 UTC on the same day.
\n
\n

IETF: datatracker document pages, history, API (documents, new version events, status definitions), WG pages, charters, BOF requests, meeting agendas, minutes, and slides, voting records, mailing lists (oauth, wimse, web-bot-auth, ietf-announce), IETF 127 schedule, RFC information from the RFC Editor, draft documents.
OpenID Foundation: Specification documents, specification list, announcements, and the AIIM Community Group page.
MCP: Authorization page for version 2026-07-28, and the versioning page.
A2A: Specification (Latest Released Version 1.0.0; the development version and the v1.0.0 and v1.0.1 pages), GitHub releases, and a blog post from August 27, 2026.
AAIF: Identity & Trust WG page.
W3C: List of Community Groups and individual group pages.

\n
\nThis article is a review of existing documentation and does not involve any hands-on testing or experimentation. From meeting minutes and slides, only agenda items, questions, presenters' statements of scope, and voting results are extracted. The positions of the companies the presenters belong to are not described.
\n\n

1.4 Terminology Used in This Article

\n\nDue to the frequent use of terms with multiple meanings, this article uses the following terminology for clarity:
\n
\n

Internet-Draft and draft: These terms are used exclusively in reference to IETF Internet-Drafts. Draft versions of MCP specifications and Working Group Drafts from the OpenID Foundation are referred to by their respective full names.
WG document: A draft within an IETF stream in datatracker, with a WG state of WG Document or later. Their names typically begin with draft-ietf-. If a Working Group has adopted a draft, but no version under the WG document name has been released yet, the WG state becomes Adopted by a WG (see Section 2.2).
Individual draft: A draft in datatracker where the group is Individual Submissions and there is no associated stream.
Adoption: This refers to the process by which a WG makes an individual draft a WG document. It is distinct from meeting agendas, presentations, inquiries regarding interest, and calls for adoption (the WG chairs asking the Working Group whether to adopt a draft).
Standard: This article avoids using the term \"standard\" as a stage name. Instead, the specific categories used by the RFC process (e.g., Proposed Standard) and the stage terms used by individual organizations are used as is.
WG: When simply written as \"WG,\" this refers to an IETF Working Group. For Working Groups in the OpenID Foundation and AAIF, the organization's name is included. W3C groups are referred to as Community Groups.
Agent: This term refers to AI agents. User-Agents such as web browsers, and the \"Agent\" referenced in the title of draft-ietf-teep-otrp-over-http, are distinct.
Key Binding: The SD-JWT Key Binding JWT defined in RFC 9901 (the abstract of Delegate SD-JWT in Section 6.1 says it allows the Key Binding JWT to also be an SD-JWT) and the OpenID Foundation's OpenID Connect Key Binding 1.0 are separate specifications.

\n\n

1.5 What This Article Does Not Cover

\n\nThis article does not address the following topics, or mentions them only briefly.
\n
\n

DID 1.1, KYA-OS, and the fact that authorization is OPTIONAL in the MCP specification: Covered in Chapter 7 of Identity Lifecycle for AI Agents. Section 7.4 of the same article addresses a draft of Web Bot Auth (an individual draft, draft-meunier-webbotauth-httpsig-protocol-02) as of August 21, 2026, and also records, with its date, the WG's adoption of the draft on September 1, 2026. The datatracker shows that on September 1, 2026, a WG document named draft-ietf-webbotauth-httpsig-protocol-00 was released (Section 5.3). The same article explains the mechanism.
The specifics of MCP authorization, and the handling of CIMD (Client ID Metadata Document), pre-registration, and DCR (Dynamic Client Registration): Covered in Which MCP Clients a Remote MCP Server Lets In.
The history of JOSE and JWT standards (including DPoP, rfc7523bis, and SD-JWT): Covered in JWT and JOSE Standards History and Timeline.
How to use A2A and RFC 8693: Covered in Agent Interoperability Architecture on AWS.
A timeline of function calling, MCP, and A2A: Covered in Tool Use and Agent Protocol History and Timeline.
Agent discovery and registry: Covered in AWS Agent Registry and the Agentic Resource Discovery Specification. For IETF's dawn, this article covers only its proposed charter, in Section 7.3 and Chapter 9.
Implementation of authorization in products: Covered in OWASP Top 10 for Agentic Applications Mapped to AWS Controls, Amazon Bedrock AgentCore Policy Implementation Guide, and Policy Engines Compared.
OpenID Connect Key Binding 1.0 (OpenID Foundation): An announcement dated September 10, 2026, states that the membership approved it as the first Implementer's Draft. However, none of the three anchor documents reference this specification, and the specification itself does not contain the word agent (as of a search of the text on October 9, 2026). Since no source shows a connection to agents, it is not included in the tables.

\n
\nThis article does not compare or rank standards, organizations, or companies, nor does it recommend which documents to use or predict which documents will be adopted. It also does not discuss pricing.
\n\n

2. How to Read the Tables — Hops, Stages, and Three Types of Dates

\n\nThis section defines the terms and columns used in the tables in this article. The method for reading the tables follows the structure outlined in Chapter 2 of What a Translating LLM Gateway Drops. However, while that article defines hops in terms of the path to the model, this article redefines those hops to represent the agent path.
\n\n

2.1 Hops

\n\nThis article defines hops as segments of the agent path, representing the areas covered by a particular document. The Hop column lists the English name for each hop.
\n
\n

User to Agent: This hop is the segment where a user or organization grants permissions to an agent. It includes delegation, consent, and authorization.
Agent to Tool: This hop is the segment where an agent calls a tool or API. The hops in Which MCP Clients a Remote MCP Server Lets In (specifically MCP Client, Authorization Server, MCP Server, and Transport) are a more granular breakdown of this hop.
Agent to Agent: This hop is the segment where an agent delegates tasks to another agent.
Workload to Workload: This hop is the segment where one workload, including an agent, calls another workload. It includes calls within a single trust domain and calls that cross trust domains.
Agent to Website: This hop is the segment where an agent accesses a website.
Not specific to one hop: This category encompasses components that do not fall within a specific hop. Examples include the OAuth 2.0 RFCs and the OpenID Foundation's Shared Signals specifications.

\n
\nThe article What a Translating LLM Gateway Drops deals with the path to models (specifically Client, Gateway, Provider, and Model), but no document in this article's tables covers those hops (as this article classifies it).
\n
\nThe values in the Hop column are this article's classification. A hop is given only when the abstract, introduction, or section or appendix headings mention an agent, workload, tool, website, or acting on behalf of a user; otherwise, the cell says Not specific to one hop. For groups, the hops described in their charters or descriptions are given. When a document or group explicitly names a hop (e.g., the charter for agentproto, which mentions User-to-agent, agent-to-agent, and agent-to-tool interactions), the exact wording is included in the Why It Is Listed column or the main body of the text.
\n
\n

\"Which — Which Hop on the Agent Path Each Document Covers

\n\nThe figure displays five hops arranged horizontally, with documents related to each hop placed beneath them, color-coded by stage. Components not specific to one hop sit in a lower section. The position of this lower section is independent of the hop columns above. The documents are positioned according to the Hop column in the tables for Chapters 5 through 7 (the replaced draft in Section 6.1 is not shown). The RFCs from Chapter 4 also sit in the lower section. Documents that list multiple hops in the Hop column appear in the figure beneath the hop listed first.
\n\n

2.2 Stages and Status Terms

\n\nThis article divides documents into five stages, creating a table for each stage.
\n
\n

RFC: Documents published by the RFC Editor as RFCs. This article gives the RFC number, month and year of publication, and category (Proposed Standard, Best Current Practice).
IETF Working Group (WG) Documents: Documents from IETF Working Groups, as described in Section 1.4. This article gives the WG state and IESG state.
Individual Drafts: Individual drafts from Section 1.4. The datatracker IESG state typically becomes I-D Exists.
Specifications Outside of IETF: Documents and groups from organizations such as MCP, A2A, OpenID Foundation, AAIF, and W3C. This article gives the stage terms each organization uses.
New Working Groups and BOFs: Newly formed IETF Working Groups, and groups in the pre-formation stage. BOF is an abbreviation for Birds of a Feather.

\n
\nStatus terms used in datatracker stay in English. The datatracker status description page defines the main statuses as follows:
\n
\n\n\n\n\n\n\n\n\n\n\n\n

State	Type	What Datatracker Says
`Adopted by a WG`	WG state	`The individual submission document has been adopted by the Working Group (WG), but some administrative matter still needs to be completed (e.g., a WG document replacing this document with the typical naming convention of 'draft-ietf-wgname-topic-nn' has not yet been submitted).`
`WG Document`	WG state	`The document has been identified as a Working Group (WG) document and is under development per Section 7.2 of RFC2418.`
`WG Consensus: Waiting for Write-Up`	WG state	`The Working Group (WG) document has consensus to proceed to publication. However, the document is waiting for a document shepherd write-up per RFC4858.`
`Submitted to IESG for Publication`	WG state	`The Working Group (WG) document has been submitted to the Internet Engineering Steering Group (IESG) for evaluation and publication per Section 7.4 of RFC2418.`
`Dead WG Document`	WG state	`The Working Group (WG) document has been abandoned by the WG. No further development is planned in this WG. A decision to resume work on this document and move it out of this state is possible.`
`I-D Exists`	IESG state	`The IESG has not started processing this draft, or has stopped processing it without publication.`
`RFC Ed Queue`	IESG state	`The document is in the RFC editor Queue (as confirmed by https://www.rfc-editor.org/queue.html).`

\n
\nIn WG documents, the IESG state is I-D Exists until the IESG begins handling it. The RFC Ed Queue indicates the stage where the RFC Editor is processing the document, but the RFC number has not yet been assigned. In addition, the draft itself can have the statuses Active, Expired, or Replaced.
\n
\nTerms used outside of the IETF are written using the terminology of each respective organization.
\n
\n

OpenID Foundation: Final Specification (written Final in the headings of most of these specifications and in the tables in this article) indicates the stage where the announcement states A Final Specification provides intellectual property protections to implementers of the specification and is not subject to further revision. Implementer’s Draft indicates the stage where the announcement states An Implementer’s Draft is a stable version of a specification providing intellectual property protections to implementers of the specification. Working Group Drafts refers to documents approved by the Working Group.
MCP: On the versioning page, Current is defined as the current protocol version, which is ready for use and may continue to receive backwards compatible changes., and Draft is defined as in-progress specifications, not yet ready for consumption. The term Final on the same page refers to previous versions and is distinct from the Final used by the OpenID Foundation.
A2A: The specifications page states, Latest Released Version 1.0.0.
W3C: The list of community groups states Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

\n
\n

\"Where — Where Representative Agent Authorization Documents Stand (Checked October 9, 2026)

\n\nThe figure illustrates five positions in the IETF, arranged from left to right: individual draft, WG document, after WG consensus, handling by the RFC Editor, and RFC. Representative documents are positioned at their stages as of October 9, 2026. The two rows below depict specifications outside of the IETF, as well as new WGs and BOFs. The positions in the lower two rows are not related to the stages shown in the IETF columns above. The figure indicates the status of documents as of the verification date, and does not depict which stage these documents may reach next.
\n\n

2.3 Columns

\n\nEach table listing documents (Chapters 4, 5, and 7, and Section 6.1) is a table that lists the state of documents, not a table that lists results. This article borrows four names from the common columns of What a Translating LLM Gateway Drops: Hop, Decided By, Status and Version, and Where the Source Says So. However, the meaning of these is redefined in this article as follows. The columns used to record results, What Happens and What the Caller Sees, are not used; instead, Document and Why It Is Listed are used. The columns in the table of documents in this article are as follows:
\n
\n

Document: The name of the document (excluding version number) and any common name it may have. Specifications that include a version number in their name, such as MCP specifications, A2A 1.0.0, and Authorization API 1.0, are listed with their respective versions.
Hop: As defined in Section 2.1.
Decided By: The entity that determined the current state of the document. For example, the chair of a WG who changes the WG state, IESG, the RFC Editor, or the voting members of the OpenID Foundation, or a project that publishes a specification. If the source material does not specify the entity, the cell says The source does not say.
Status and Version: The version number, the date of the version, the status description, and the date the status changed.
Why It Is Listed: Which criterion (as defined in Section 1.2) the document meets (which words appear where, or which anchor document references it).
Where the Source Says So: The source material that provides the basis for this entry.

\n
\nColumns that have the same value across all rows of the table are listed only once in the sentence preceding the table and then removed from the table itself. In the tables of RFCs (Chapter 4), Hop is consistently Not specific to one hop, and Decided By consistently refers to IETF procedures (approval by IESG and publication by the RFC Editor). Therefore, these two columns are removed, and the RFC and Title columns replace Document. The tables for meetings, calls for adoption, replacements, source disagreements, and dates (Sections 6.2 through 6.4, Section 8.4, and Chapter 9) each have columns appropriate to their content.
\n\n

2.4 Three Types of Dates and Date Boundaries

\n\nThe document dates written in the Status and Version column and in the body come in three types. The date when the status changes is also recorded in the Status and Version column.
\n
\n

Version Date: This is the date the version was released. In the table, the Document column lists the name of the document (excluding the version number), while the Status and Version column records the version number and the version date, such as -00 (2026-09-15). In the body of this article, it is written as draft-ietf-wimse-aims-00 (September 15, 2026), for example. RFCs are written with the month and year of publication, such as RFC 8693 (January 2020).
Status Change Date: This is the date when a status change occurred, such as adoption, a change in the WG state, IESG approval, or charter approval. It is written as, for example, WG Consensus: Waiting for Write-Up (since 2026-08-21). This is separate from the version date. For example, the predecessor to AIMS, an individual draft, was Adopted by a WG on September 9, 2026, while draft-ietf-wimse-aims-00 was released on September 15, 2026.
Verification Date: This is the date the author reviewed the materials, and is consistently October 9, 2026.

\n
\nIn addition to these, dates for meetings, times of email postings, deadlines, expiration dates, announcement dates, and the date of the specification's content are also recorded. Each is stated together with what kind of date it is.
\n
\nDates shown on the datatracker document pages and history pages, and the times returned by the API (in UTC), may sometimes differ. For draft-ietf-oauth-v2-1-16, the document page shows September 2, 2026, while the API shows 2026-09-03T00:22:00Z, and the date in the draft text is 3 September 2026. For draft-gco-oauth-delegate-sd-jwt-00, the history page shows April 21, 2026, while the API shows 2026-04-22T04:45:15Z. This article records the version date and status change date based on the dates shown on the datatracker pages, and records the counting window (Chapter 3) and the time of email postings in UTC.
\n\n

2.5 When the Source Does Not Say, and When Sources Disagree

\n\nIn the Decided By, Status and Version, and Why It Is Listed columns, only what the source says (or a summary) is written. If the source does not say, the cell says The source does not say. Before writing this, the full text of the source, the pages it links to, and the same organization's other pages (document histories, WG pages, mailing-list threads and message bodies, and announcements) are searched with the document's name and terms such as adopt, adoption, Last Call, approved, charter, replaces, expired, and agent.
\n
\nWhen sources disagree, both descriptions are listed with their respective sources, without favoring either. The disagreements found in this article, and any instances where descriptions could not be found through searching, are summarized in Chapter 8.
\n\n

3. What Counting Shows — 48 Drafts, 70 Submissions, and No `draft-ietf-` Among Them

\n\nThis section describes how the initial numbers were calculated and identifies which documents might be missing based on that counting method.
\n\n

3.1 How the Count Was Made

\n\nThe counting process utilizes two results from the datatracker API. One is the event of submitting a new version (newrevisiondocevent), and the other is a list of Internet-Drafts containing the string agent in their title or name.
\n
\n

https://datatracker.ietf.org/api/v1/doc/newrevisiondocevent/?time__gte=2026-09-24T00:00:00Z&time__lt=2026-10-05T00:00:00Z\nhttps://datatracker.ietf.org/api/v1/doc/document/?type=draft&title__icontains=agent\nhttps://datatracker.ietf.org/api/v1/doc/document/?type=draft&name__icontains=agent

\n
\nThe criteria for counting are as follows:
\n
\n

Window: The date of the event's timestamp (UTC) must fall between September 24, 2026, and October 4, 2026.
Match: The matching process uses partial matching, case-insensitively. This includes matches for strings like Agentic and Agents. Title matches are string matches and do not determine whether a document specifically addresses AI agents.
Submissions and Drafts: Each submission of a new version is counted as one submission. Each draft name is counted as one draft. If a single draft submits multiple versions in the window, the submission count increases by the number of submissions.
Acquisition Time: October 9, 2026, at 11:56 UTC.

\n\n

3.2 Results

\n\n\n\n\n\n\n\n\n

Matching Rule	New-Version Submissions	Drafts
Titles containing `agent`	70	48
Names containing `agent`	30	26
Titles or names containing `agent`	73	51

\n
\nOf the 48 drafts with matching titles, all were in the Individual Submissions group and had no associated stream. There were also zero documents from IRTF with names starting with draft-irtf-. The difference between the 70 submissions and the 48 drafts is due to 10 drafts that have had two or more new versions submitted in the window. The draft with the most submissions, draft-zambo-aer1, had 11 new versions submitted in the window.
\n
\nExamining the 48 titles, 5 contained the string Authoriz (draft-fane-opena2a-aap, draft-gilda-wimse-agent-audit-record, draft-saha-aadp, draft-schrock-ae-challenge, draft-schrock-ep-authorization-evidence-chain), 4 contained Authorit, and 11 contained Identit. There were also individual drafts with names containing wimse (e.g., draft-ni-wimse-ai-agent-identity). However, even if a name includes a group abbreviation, the datatracker does not categorize it as a document for that WG.
\n\n

3.3 Documents Outside the Count

\n\nWhen counting by title, the following documents related to AI agents were not included in the total of 48. None of these documents contain the string agent in either the title or the name.
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n

Document	Stage	Where Agents Appear	Why It Is Outside the Count
`draft-ietf-wimse-aims`	IETF Working Group document	`authentication and authorization of AI agent interactions` in the abstract	Title: `AI Identity Management System`
`draft-ietf-oauth-identity-assertion-authz-grant`	IETF Working Group document	The heading in Appendix A.4: `AI Agent using External Tools`	Title: `Identity Assertion JWT Authorization Grant`
`draft-ietf-oauth-deferred-token-response`	IETF Working Group document	The heading in Appendix A.4: `Autonomous Agent Acting on Behalf of a User`	Title: `Deferred Token Response`. `-00` is dated 2026-09-16, before the window.
`draft-ietf-wimse-arch`	IETF Working Group document	Section 3.4.11 (heading: `AI and ML-Based Intermediaries`), specifically the text discussing `Emerging agentic AI systems`	Title: `Workload Identity in a Multi System Environment (WIMSE) Architecture`
`draft-ietf-webbotauth-httpsig-protocol`	IETF Working Group document	The introduction, specifically mentioning `including AI assistants`	Title: `HTTP Message Signatures for automated traffic`
`draft-hardt-oauth-aauth-protocol`	Individual draft	`agent-to-resource authorization` in the abstract	Title: `AAuth Protocol`. `-11` (2026-09-25) was posted within the window but is not among the 48.
`draft-mcguinness-oauth-mission`	Individual draft	`An AI agent is typically given a mission` in the abstract	Title: `Mission-Bound Authorization for OAuth 2.0`
`draft-gco-oauth-delegate-sd-jwt`	Individual draft	`This has particular applicability to Agentic systems.` in the abstract	Title: `Delegate SD-JWT`

\n
\nThe WG documents outside the counting scope total 5, while the number of WG documents among the 48 is 0. Even when counting documents with agent in the title, no documents adopted by a WG are visible. Conversely, searching the datatracker API for documents whose names begin with draft-ietf- and whose abstracts contain the string AI agent yielded only 1 document, AIMS (as of October 9, 2026). WG documents that only discuss AI agents in their appendices, introductions, or sections of the main body are also not visible when searching the abstract. This article retrieved the main body of current WG documents from the OAuth, WIMSE, and webbotauth WGs, searched them for words about AI agents, and listed the WG documents that meet (a) in Section 1.2.
\n\n

3.4 The Numbers Change Every Day

\n\nExtending the observation window to the verification date, October 9, 2026, means that versions posted up to the retrieval time that day will be included, and values can change even during the same day. This article only uses data from a specific, closed window (from September 24, 2026, to October 4, 2026). Additionally, drafts expire. Separately from the 48 drafts in the window, there are 21 drafts in the entire set of drafts containing the string agent in their titles (901 drafts retrieved on October 9, 2026) whose expiration date (as indicated by the API's expires field) fell in the 14 days before the verification date (from September 25, 2026, to October 8, 2026, in UTC). Of these 21 drafts, 20 were marked as Expired, and 1 was marked as Replaced (see Section 6.4).
\n\n

4. Components That Are Already RFCs

\n\nThis section lists the RFCs that meet the inclusion criteria. For every row in the tables in this chapter, Hop indicates Not specific to one hop, and Decided By refers to the IETF's procedures (approval by the IESG and publication by the RFC Editor). The categories and publication dates were verified using the RFC information available on the RFC Editor's website as of October 9, 2026. None of these RFCs are documents written specifically for agents.
\n\n

4.1 RFCs Cited by AIMS

\n\nAIMS references the following 11 RFCs in its Normative References (Section 18.1), excluding RFC 2119 and RFC 8174, which define keywords.
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

RFC	Title	Status and Version	Why It Is Listed	Where the Source Says So
RFC 6749	The OAuth 2.0 Authorization Framework	`Proposed Standard`, October 2012. Updated by RFC 8252, RFC 8996, and RFC 9700.	Cited by AIMS as `[OAUTH-FRAMEWORK]`.	rfc-editor, AIMS, Section 18.1
RFC 7523	JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants	`Proposed Standard`, May 2015	Cited by AIMS. The Workload Authorization Grant (WAG, Section 6.1) says in its abstract that it uses this RFC's JWT authorization grant.	rfc-editor, AIMS, WAG `-01`
RFC 7591	OAuth 2.0 Dynamic Client Registration Protocol	`Proposed Standard`, July 2015	Cited by AIMS and version 2026-07-28 of the MCP specification. MCP specification version 2026-07-28 marks DCR as `Deprecated`, and support for it remains `MAY`.	rfc-editor, AIMS, MCP authorization page
RFC 7662	OAuth 2.0 Token Introspection	`Proposed Standard`, October 2015	Cited by AIMS.	rfc-editor, AIMS
RFC 8414	OAuth 2.0 Authorization Server Metadata	`Proposed Standard`, June 2018	Cited by AIMS, version 2026-07-28 of the MCP specification, and A2A 1.0.0.	rfc-editor, AIMS, MCP, A2A
RFC 8693	OAuth 2.0 Token Exchange	`Proposed Standard`, January 2020	Cited by AIMS. The Identity Assertion JWT Authorization Grant (ID-JAG, Section 5.1) says in its abstract `using Token Exchange [RFC8693]`.	rfc-editor, AIMS, ID-JAG `-04`
RFC 8705	OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens	`Proposed Standard`, February 2020	Cited by AIMS.	rfc-editor, AIMS
RFC 9068	JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens	`Proposed Standard`, October 2021	Cited by AIMS.	rfc-editor, AIMS
RFC 9421	HTTP Message Signatures	`Proposed Standard`, February 2024	Cited by AIMS. AAuth (Section 6.1) `-11` also cites it in its body.	rfc-editor, AIMS, AAuth `-11`
RFC 9700	Best Current Practice for OAuth 2.0 Security	`Best Current Practice` (BCP 240), January 2025	Cited by AIMS as `[OAUTH-BCP]`.	rfc-editor, AIMS
RFC 9728	OAuth 2.0 Protected Resource Metadata	`Proposed Standard`, April 2025	Cited by AIMS and version 2026-07-28 of the MCP specification.	rfc-editor, AIMS, MCP authorization page

\n
\nAIMS references RFC 6749 as its framework for OAuth, rather than the draft of OAuth 2.1. The MCP specification, version 2026-07-28, references the draft of OAuth 2.1 (Sections 5.1 and 8.1 of this article).
\n\n

4.2 RFCs Cited by MCP or A2A, and Peripheral RFCs

\n\nThe top seven rows in the following table list RFCs that AIMS does not reference but that the authorization page of the MCP specification (version 2026-07-28) or the A2A 1.0.0 specification references as components related to authentication and authorization. While these documents also reference RFCs such as those defining URI syntax (RFC 3986), HTTP semantics (RFC 9110), and JSON canonicalization (RFC 8785), these latter are not directly related to authentication and authorization and are therefore not included in the table. The three rows below are peripheral rows; none of the three anchor documents references them, but drafts listed in this article's tables do.
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

RFC	Title	Status and Version	Why It Is Listed	Where the Source Says So
RFC 6750	The OAuth 2.0 Authorization Framework: Bearer Token Usage	`Proposed Standard`, October 2012. Updated by RFC 8996 and RFC 9700.	Cited by version 2026-07-28 of the MCP specification.	rfc-editor, MCP authorization page
RFC 7235	Hypertext Transfer Protocol (HTTP/1.1): Authentication	`Proposed Standard`, June 2014. Obsoleted by RFC 9110.	Cited by A2A 1.0.0 for describing the names of HTTP authentication schemes.	rfc-editor, A2A specification
RFC 7515	JSON Web Signature (JWS)	`Proposed Standard`, May 2015	Cited by A2A 1.0.0 for describing the format of signatures for Agent Cards.	rfc-editor, A2A specification
RFC 7636	Proof Key for Code Exchange by OAuth Public Clients	`Proposed Standard`, September 2015	Cited by A2A 1.0.0 for describing the configuration of the authorization code flow.	rfc-editor, A2A specification
RFC 8628	OAuth 2.0 Device Authorization Grant	`Proposed Standard`, August 2019	Cited by A2A 1.0.0 for describing the Device Code flow.	rfc-editor, A2A specification
RFC 8707	Resource Indicators for OAuth 2.0	`Proposed Standard`, February 2020	Cited by version 2026-07-28 of the MCP specification.	rfc-editor, MCP authorization page
RFC 9207	OAuth 2.0 Authorization Server Issuer Identification	`Proposed Standard`, March 2022	Cited by version 2026-07-28 of the MCP specification.	rfc-editor, MCP authorization page
RFC 9396	OAuth 2.0 Rich Authorization Requests	`Proposed Standard`, May 2023	Peripheral. Cited by ID-JAG `-04` and Mission-Bound Authorization `-00`.	rfc-editor, each draft document
RFC 9449	OAuth 2.0 Demonstrating Proof of Possession (DPoP)	`Proposed Standard`, September 2023	Peripheral. Cited by ID-JAG `-04`, Deferred Token Response `-00`, Mission-Bound Authorization `-00`, and AAuth `-11`.	rfc-editor, each draft document
RFC 9470	OAuth 2.0 Step Up Authentication Challenge Protocol	`Proposed Standard`, September 2023	Peripheral. Cited by ID-JAG `-04`.	rfc-editor, ID-JAG `-04`

\n
\nRFC 7235, which A2A 1.0.0 references, has been obsoleted by RFC 9110 (as indicated in the RFC Editor's records). RFC 7515 is a JOSE standard, and its history is covered in the JOSE timeline article. RFC 9449 (DPoP) was published in September 2023, the same month as the one given by the timeline in JWT and JOSE Standards History and Timeline. Recording delegation with the claims defined in RFC 8693 is covered in Chapter 4 of Identity Lifecycle for AI Agents. This article does not detail the usage of these RFCs.
\n\n

5. IETF Working Group Documents

\n\nThis section lists IETF WG documents that meet the inclusion criteria, organized by WG. For each entry, version dates and status change dates are the dates shown on the datatracker pages, and the verification date is October 9, 2026.
\n\n

5.1 OAuth WG

\n\nOn datatracker, the formal name of the OAuth WG is Web Authorization Protocol. A search of the full text of the 16 current (Active) WG documents reveals that only ID-JAG contains the string AI agent, while only ID-JAG and Deferred Token Response include agent in their appendix headings. The table includes these two documents, along with five others that the anchor documents reference.
\n
\n\n\n\n\n\n\n\n\n\n\n\n

Document	Hop	Decided By	Status and Version	Why It Is Listed	Where the Source Says So
`draft-ietf-oauth-v2-1` (OAuth 2.1)	`Not specific to one hop`	OAuth WG chairs	`-16` (2026-09-02), `WG Document`, `I-D Exists`. The WG milestone gives `Dec 2026` for submission to the IESG.	Cited by MCP specification version 2026-07-28 (mainly `-13`).	datatracker
`draft-ietf-oauth-client-id-metadata-document` (CIMD)	`Not specific to one hop`	OAuth WG chairs	`-02` (2026-07-06), `WG Document`, `I-D Exists`.	Cited by MCP specification version 2026-07-28 (`-00`) and AIMS (`-02`).	datatracker
`draft-ietf-oauth-identity-assertion-authz-grant` (ID-JAG)	`Agent to Tool`	OAuth WG chairs	`-04` (2026-05-21), `WG Document`, `I-D Exists`.	Appendix A.4 heading `AI Agent using External Tools`. Cited by AIMS.	datatracker, document body
`draft-ietf-oauth-deferred-token-response`	`User to Agent`	OAuth WG chairs	`-00` (2026-09-16), `WG Document` (`WG -00 approved` on 2026-09-16), `I-D Exists`.	Appendix A.4 heading `Autonomous Agent Acting on Behalf of a User`.	datatracker, document body
`draft-ietf-oauth-transaction-tokens` (Transaction Tokens)	`Workload to Workload`	OAuth WG chairs	`-11` (2026-07-30), `WG Consensus: Waiting for Write-Up` (since 2026-08-21), `I-D Exists`. The WG milestone gives `Dec 2026` for submission to the IESG.	Cited by AIMS.	datatracker
`draft-ietf-oauth-identity-chaining` (Identity Chaining)	`Not specific to one hop`	IESG approval and the RFC Editor	`-17` (2026-07-19), IESG state `RFC Ed Queue` (since 2026-06-22), WG state `Submitted to IESG for Publication`. No RFC number yet.	Cited by AIMS.	datatracker
`draft-ietf-oauth-spiffe-client-auth`	`Workload to Workload`	OAuth WG chairs	`-02` (2026-06-15), `WG Document`, `I-D Exists`.	Cited by AIMS.	datatracker

\n
\nWithin this table, only Identity Chaining is currently in the RFC Editor queue (RFC Ed Queue), in this status since June 22, 2026, after the IESG approval announcement. -17 was posted on July 19, 2026. As of October 9, 2026, an RFC number has not yet been assigned. The abstract describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. Because the abstract does not mention anything corresponding to a hop, its Hop is Not specific to one hop. The main body of the document does not contain the term agent, but it was included in the table because AIMS references it. While other documents from the OAuth WG – draft-ietf-oauth-status-list, draft-ietf-oauth-rfc7523bis, and draft-ietf-oauth-rfc8725bis – are also in RFC Ed Queue, they do not mention AI agents and are not referenced by the anchor documents, so they are not included in the table.
\n
\nTransaction Tokens are at a later stage, following WG consensus. The datatracker history shows that an OAuth WG chair initiated the third WG Last Call (3rd WGLC) on August 4, 2026, and on August 21, 2026, changed the WG state from In WG Last Call to WG Consensus: Waiting for Write-Up. The abstract describes tokens that operate within a trusted domain and carry the user's ID, the workload's ID, and the authorization context. The main body does not contain words about AI agents, but it was included in the table because AIMS references it.
\n
\nID-JAG is a mechanism for obtaining access tokens for other applications through the enterprise's identity provider. The abstract states This pattern is informally referred to as Cross-App Access (XAA). Appendix A.4 discusses examples of AI agents using external tools. Deferred Token Response refers to a system where the token endpoint, instead of immediately returning an access token or an error, responds at a later time. On September 16, 2026, -00 was posted under the WG document name, and Appendix A.4 presents examples of autonomous agents that operate on behalf of users.
\n
\nThe method for describing the state of CIMD is the same as that in Section 3.4 of Which MCP Clients a Remote MCP Server Lets In. OAuth 2.1 is a draft that MCP specification version 2026-07-28 references, and as of the verification date, the current version is -16 (Section 8.1). The abstracts for OAuth 2.1, CIMD, and Identity Chaining do not mention anything corresponding to a hop, so their Hop is Not specific to one hop. The document draft-ietf-oauth-spiffe-client-auth is an IETF WG document that uses SPIFFE credentials to authenticate OAuth clients, and its abstract mentions SPIFFE-enabled workloads, and AIMS references it. SPIFFE's own documents are not included in the tables, as indicated in Section 1.2.
\n\n

5.2 WIMSE WG

\n\nOn datatracker, the formal name of the WIMSE WG is Workload Identity in Multi System Environments. AIMS is a WIMSE WG document and cites five other WIMSE WG documents.
\n
\n\n\n\n\n\n\n\n\n\n\n

Document	Hop	Decided By	Status and Version	Why It Is Listed	Where the Source Says So
`draft-ietf-wimse-aims` (AIMS)	`Workload to Workload`, `User to Agent`, `Agent to Tool`, `Agent to Agent`	The WIMSE chair who is the sole responsible chair for this document	`-00` (2026-09-15), `WG Document` (the predecessor `Adopted by a WG` on 2026-09-09, `WG -00 approved` on 2026-09-15), `I-D Exists`, Intended RFC status is `(None)`. Intended status in the text is `Informational`.	Abstract. An anchor document.	datatracker, document body
`draft-ietf-wimse-arch`	`Workload to Workload`	WIMSE chairs	`-08` (2026-07-06), `WG Document`, `I-D Exists`. Intended status in the text is `Informational`.	Section 3.4.11 mentions AI agents. Cited by AIMS.	datatracker, document body
`draft-ietf-wimse-workload-creds`	`Workload to Workload`	WIMSE chairs	`-02` (2026-07-02), `WG Document`, `I-D Exists`	Cited by AIMS.	datatracker
`draft-ietf-wimse-http-signature`	`Workload to Workload`	WIMSE chairs	`-07` (2026-09-20), `WG Document`, `I-D Exists`. Tag `Doc Shepherd Follow-up Underway` (starting 2026-10-05).	Cited by AIMS (version `-06`).	datatracker
`draft-ietf-wimse-identifier`	`Workload to Workload`	WIMSE chairs	`-03` (2026-07-06), `WG Document`, `I-D Exists`	Cited by AIMS.	datatracker
`draft-ietf-wimse-wpt`	`Workload to Workload`	WIMSE chairs	`-02` (2026-08-27), `WG Document`, `I-D Exists`	Cited by AIMS.	datatracker

\n
\nAIMS is given four hops because of the section headings within AIMS (in the figure in Section 2.1, it is placed below Workload to Workload, the first hop listed). Section 4 of AIMS is titled Agents are workloads, and below the section Agent Authorization (Section 10 of AIMS), there are sections titled User Delegates Authorization (Section 10.4.1), Agents Accessed by Systems or Other Agents (Section 10.4.3), and Tool-to-Service Access (Section 10.8). The abstract states that this document describes how existing standards can be applied or extended rather than defining a new protocol.
\n
\n

Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization.

\n
\nThe predecessor to AIMS was the individual draft draft-klrc-aiagent-auth. Following a call for adoption on the WIMSE mailing list, Justin Richer, one of the WIMSE chairs, announced its adoption in a post dated September 9, 2026, at 16:56 UTC. This post also notes that another chair (one of the authors of this document) had recused himself from chairing it.
\n
\n

Note well: for purposes of this document, I am the sole responsible chair, and Pieter has recused himself from all chairing responsibilities for this document.

\n
\nThe datatracker history records that on the same day, this draft's group was changed to WIMSE and its WG state was set to Adopted by a WG. On September 15, 2026, a record indicates WG -00 approved, resulting in the publication of draft-ietf-wimse-aims-00, which replaced the previous draft. The Intended status at the beginning of the document is Informational, and the Intended RFC status in the datatracker is (None).
\n
\nAmong the WIMSE WG documents, draft-ietf-wimse-s2s-protocol has a WG state of Dead WG Document and was split into four documents (Section 6.4). Of these four, draft-ietf-wimse-mutual-tls (-02, 2026-07-06) is not included in the table. This is because it does not appear in the documents referenced by AIMS, and no mention of AI agents is found in the text. The document draft-ietf-wimse-workload-identity-practices (-07, 2026-09-22) is further along in the process, with a WG state of Submitted to IESG for Publication and an IESG state of AD Evaluation::AD Followup. It is also excluded from the table for the same reason.
\n\n

5.3 webbotauth WG

\n\nThe webbotauth WG document addresses the identification of automated traffic, including AI assistants, when it accesses websites. Section 7.4 of Identity Lifecycle for AI Agents describes the mechanism.
\n
\n\n\n\n\n\n

Document	Hop	Decided By	Status and Version	Why It Is Listed	Where the Source Says So
`draft-ietf-webbotauth-httpsig-protocol`	`Agent to Website`	The webbotauth chairs (announced adoption on the mailing list on 2026-09-01)	`-00` (2026-09-01), `WG Document` (`WG -00 approved` on 2026-09-01), `I-D Exists`, Intended RFC status is `(None)`. Intended status in the text is `Standards Track`.	The first sentence of the introduction says `including AI assistants`.	datatracker, document body, web-bot-auth mailing list

\n
\nOn August 18, 2026 (UTC), the webbotauth chairs issued a call for adoption for the individual draft draft-meunier-webbotauth-httpsig-protocol on the mailing list, setting the deadline for responses as Sep 1st. At 12:52 UTC on September 1, 2026, the deadline day, the chairs announced adoption in the same thread.
\n
\n

Based on the feedback on the mailing list, the WG decided to adopt this\ndraft as a WG document.

\n
\nThe datatracker shows a record of WG -00 approved on the same date, September 1, 2026, and the -00 under the WG document name was posted, replacing the individual draft. Section 7.4 of Identity Lifecycle for AI Agents, as of August 21, 2026, mentions the version -02 of the individual draft. This date falls in the call for adoption period, after which the -00 version of the WG document was released.
\n\n

6. Individual Drafts, Meeting Agendas, and Calls for Adoption

\n\nThis section outlines individual draft proposals related to AI agents, focusing on those discussed in WG settings, or referenced by the anchor documents. It also details how these drafts have been handled in WG meetings and on the mailing list, noting when they were included on the meeting agenda, when interest in them was asked about, and when a call for adoption was issued – none of which constitute adoption.
\n\n

6.1 Individual Drafts Taken Up by a WG, and Individual Drafts the Anchor Documents Cite

\n\nChapter 3 gave the 48 drafts as a count with its counting method. This table lists individual drafts outside those 48 that were discussed at WG meetings, or for which a call for adoption was issued, or that the anchor documents cite, and that meet the criteria in Section 1.2. The status reflected is as of October 9, 2026. Each entry is categorized under Individual Submissions and does not have a specific stream. The IESG state for all entries except the last one is I-D Exists. The last entry is a draft that has been replaced; the datatracker page indicates that its IESG state is Replaced by draft-fletcher-oauth-txn-token-chaining-profile.
\n
\n\n\n\n\n\n\n\n\n\n

Document	Hop	Decided By	Status and Version	Why It Is Listed	Where the Source Says So
`draft-hardt-oauth-aauth-protocol` (AAuth)	`Agent to Tool`, `User to Agent`	Authors	`-11` (2026-09-25). Intended status in the text is `Standards Track`, and Intended RFC status is `(None)`.	`agent-to-resource authorization` in the abstract. On the agenda of the OAuth WG interim meeting (2026-10-05).	datatracker, document body, meeting agenda
`draft-carleton-workload-authz-grant` (WAG)	`Workload to Workload`	Authors	`-01` (2026-09-22). Intended status in the text is `Informational`.	`an AI agent is the motivating case` in the abstract. On the agenda of the WIMSE WG interim meeting (2026-10-07).	datatracker, document body, meeting agenda
`draft-mcguinness-oauth-mission` (Mission-Bound Authorization)	`User to Agent`	Authors	`-00` (2026-07-06). Intended status in the text is `Standards Track`.	`An AI agent is typically given a mission` in the abstract. On the agenda of the OAuth WG interim meeting (2026-10-26, scheduled).	datatracker, document body, meeting agenda
`draft-gco-oauth-delegate-sd-jwt` (Delegate SD-JWT)	`User to Agent`	Authors. The OAuth WG chairs issued a call for adoption (2026-09-28, deadline 2026-10-12).	`-00` (2026-04-21). The API expiry is `2026-10-24T04:45:15Z` (the draft header and the datatracker page give Expires `23 October 2026`).	`This has particular applicability to Agentic systems.` in the abstract.	datatracker, mailing list
`draft-fletcher-transaction-token-chaining-profile`	`Not specific to one hop`	Authors	`-02` (2026-07-06), `Replaced` (replaced by `draft-fletcher-oauth-txn-token-chaining-profile-00` on 2026-09-10).	Cited by AIMS.	datatracker, AIMS

\n
\nOf the 48 drafts, 5 have titles containing Authoriz (as detailed in Section 3.2). This article does not evaluate the content of these documents. As of the verification date, all of them were individual drafts in the Individual Submissions group.
\n\n

6.2 A Meeting Agenda Is Not Adoption

\n\nThe OAuth WG and WIMSE WG held interim meetings (meetings with IDs starting with interim- in the datatracker) focusing on agents in September and October 2026. Some meetings were canceled, and others are scheduled after the verification date. The records for these meetings in the datatracker are as follows.
\n
\n\n\n\n\n\n\n\n\n\n\n

Meeting	Date	Agenda Item	What the Record Shows	Where the Source Says So
`interim-2026-oauth-07`	2026-09-28	`Anthropic & OpenAI Agentic Use Cases`	The meeting status was changed to `canceled` on 2026-09-10.	datatracker (meeting status)
`interim-2026-oauth-08`	2026-09-28	`Anthropic & OpenAI Agentic Use Cases`	The meeting minutes state that the presenter indicated that `picking solutions / arriving solutions is out of scope for this presentation.`	Meeting minutes
`interim-2026-oauth-06`	2026-10-05	`AAuth Protocol`	The final slide posed the question, `Where should this work happen?`, presenting `Option A` as `In the OAuth WG` and `Option B` as `In a new WG`.	Slides
`interim-2026-wimse-02`	2026-10-07	`Present and discuss the Workload Authorization Grant draft`	During the meeting vote, a question of interest received 16 votes in favor, 0 against, and 2 no opinion (attendance at the time of closure was 21). The chairs also posted on the mailing list on the same day, stating `This is not a call for adoption`.	Voting record, meeting minutes, mailing list
`interim-2026-oauth-09`	2026-10-19 (scheduled)	`Agent Authorization – Use Cases and Gaps`	As of the verification date, only the agenda item was listed.	datatracker
`interim-2026-oauth-10`	2026-10-26 (scheduled)	`Mission-Bound Authorization`	Added to the schedule on 2026-10-08 (UTC).	datatracker

\n
\nThe question posed in the WIMSE WG meeting poll was as follows:
\n
\n

Are we interested in the problem targeted by this document and this document as a starting point for addressing it?

\n
\nThe WIMSE WG chairs, following the meeting, posted to the mailing list to solicit input from those who were unable to attend. The subject line of the post was Request for Expression of Interest, and the body read as follows:
\n
\n

*This is not a call for adoption* of the draft or of any particular\nsolution. We only want to know whether this is a problem the working group\nshould spend time on.

\n
\nThe slides presented by the OAuth WG chairs at interim-2026-oauth-06 (October 5, 2026) list the interim meetings for September and October 2026. Excluding the dates listed in the table (except October 26, 2026), September 14, 2026, is for HTTP Message Signatures for OAuth, September 21, 2026, for OAuth Protected Authorization, October 12, 2026, is marked as No Meeting, and October 26, 2026, is listed as TBD (the topic for October 26, 2026 was later registered as Mission-Bound Authorization). The records from each meeting reflect the agenda, questions, and expressions of interest, and do not represent decisions to adopt.
\n\n

6.3 Calls for Adoption

\n\nThe WG chairs issue a call for adoption, which asks the WG whether to adopt a submission. The calls for adoption examined in this article were all posted to mailing lists. The datatracker describes Call For Adoption By WG Issued as

A call for adoption of the individual submission document has been issued by the Working Group (WG) chairs. This call is still running but the WG has not yet reached consensus for adoption.

\n
\nThis article analyzed the subject lines and senders of 311 messages from the OAuth WG mailing list, from September 2, 2026, to the retrieval time of October 9, 2026, at 12:11 UTC. Only two threads contained the term adopt in their subject lines.
\n
\n\n\n\n\n\n\n

Draft	Call Posted (UTC)	Deadline in the Call	Agents in the Abstract	Datatracker on 2026-10-09
`draft-richer-oauth-httpsig-03` (OAuth Proof of Possession Tokens with HTTP Message Signatures)	2026-09-21 19:17	`October 5th`	None	`I-D Exists`, no stream
`draft-gco-oauth-delegate-sd-jwt` (Delegate SD-JWT)	2026-09-28 12:21	`October 12`	`This has particular applicability to Agentic systems.`	`I-D Exists`, no stream

\n
\nIn the specified range, no call for adoption was found for a draft with agent in its title. The only call for adoption for a draft whose abstract mentions agents was the one for Delegate SD-JWT. On datatracker, both drafts had a status of I-D Exists, lacked a stream, and did not have a Call For Adoption By WG Issued status. In both threads, the chairs' posts in the range were limited to the initial call, and no posts announcing the outcome of draft-richer-oauth-httpsig, whose deadline had passed, were found.
\n
\nShortly before this range, there was an email that shows the view of the OAuth WG chairs. An author of the individual draft draft-chen-oauth-agent-authz-use-cases-03 requested a call for adoption from the chairs in a message that a chair's reply quotes with the date August 25, 2026. An OAuth WG chair replied to the author in a message dated August 27, 2026, as follows, and another participant quoted this response in an email posted to the mailing list on August 28, 2026, at 01:28 UTC.
\n
\n

Hannes and I discuss this.\nWe think it is premature to call for adoption of any Agents related documents at this time.

\n
\nThe call for adoption for Delegate SD-JWT (September 28, 2026) occurred after this response.
\n
\nSimilarly, in the subject lines of 160 messages on the WIMSE WG mailing list (from September 17, 2026, to the retrieval time of October 9, 2026, at 12:18 UTC), no call for adoption was found. However, there was one thread related to the Request for Expression of Interest mentioned in Section 6.2, and another thread regarding the WG Last Call (WGLC) for draft-ietf-wimse-http-signature. The adoption of AIMS (September 9, 2026) occurred before this range. In the 160 messages on the web-bot-auth WG mailing list (from June 24, 2026, to the retrieval time of October 9, 2026, at 12:18 UTC), one call for adoption and a response from the chairs announcing its adoption were found, as described in Section 5.3. The ranges for WIMSE and web-bot-auth cover four list pages read from the newest side, and the oldest dates only include a portion of the posts from those days.
\n\n

6.4 Replacements, Expirations, and Name Changes

\n\nDrafts can be replaced or expire. The following table lists the predecessor documents to the drafts described in this article, along with records of those replacements.
\n
\n\n\n\n\n\n\n\n\n\n

Before	After	What Datatracker Records	Where the Source Says So
`draft-klrc-aiagent-auth` (`-03`, 2026-07-06)	`draft-ietf-wimse-aims`	On 2026-09-09, the chair announced adoption, and the state became `Adopted by a WG`. On 2026-09-15, `WG -00 approved` and the replacement were recorded.	Datatracker (history), WIMSE mailing list
`draft-meunier-webbotauth-httpsig-protocol` (`-02`, 2026-08-18)	`draft-ietf-webbotauth-httpsig-protocol`	On 2026-09-01, the chairs announced adoption, and `WG -00 approved` and the replacement were recorded on the same day.	Datatracker (history), web-bot-auth mailing list
`draft-gerber-oauth-deferred-token-response`, `draft-parecki-oauth-jwt-grant-interaction-response`	`draft-ietf-oauth-deferred-token-response`	`WG -00 approved` on 2026-09-16. On 2026-09-23, a record shows it replacing the two drafts.	Datatracker (history)
`draft-ietf-wimse-s2s-protocol` (`-07`, 2025-10-16)	`draft-ietf-wimse-workload-creds`, `draft-ietf-wimse-http-signature`, `draft-ietf-wimse-mutual-tls`, `draft-ietf-wimse-wpt`	The WG state is `Dead WG Document`. The draft state is `Replaced`.	Datatracker (document page)
`draft-fletcher-transaction-token-chaining-profile` (`-02`, 2026-07-06)	`draft-fletcher-oauth-txn-token-chaining-profile`	On 2026-09-10, version `-00` was released, replacing the previous draft. The draft state is `Replaced`.	Datatracker (history)

\n
\nMany drafts expire. Separately from the 48 drafts in the window, 21 of the 901 drafts on datatracker that contain the string agent in their titles had an API expiration date (expires) between September 25, 2026, and October 8, 2026 (UTC). Of those 21 drafts, 20 were in the Expired state, and 1 was Replaced (retrieved on October 9, 2026). The count varies between 20 and 21 depending on whether the count includes entries in the Expired state or simply considers the expires date. This article does not list expired drafts in its tables as current proposals.
\n\n

7. Specifications from Outside the IETF, and New Working Groups and BOFs

\n\nThis section lists specifications and groups from organizations outside the IETF, as well as newly formed WGs and BOFs in the IETF. As noted in Section 2.2, stage terms from organizations outside the IETF are given in each organization's own words. All statuses are as of October 9, 2026.
\n\n

7.1 MCP, A2A, AAIF, W3C

\n\n\n\n\n\n\n\n\n\n\n

Document	Hop	Decided By	Status and Version	Why It Is Listed	Where the Source Says So
The authorization page of MCP specification version 2026-07-28	`Agent to Tool`	MCP specification project	`Current`. The versioning page says `The current protocol version is 2026-07-28.`	Anchor document	MCP versioning page, authorization page
A2A 1.0.0 specification	`Agent to Agent`	A2A project (the A2A blog post dated 2026-08-27 states that it was accepted as an AAIF `Growth Stage` project)	`Latest Released Version 1.0.0`. The GitHub release `v1.0.0` is dated 2026-03-12. GitHub also has release `v1.0.1` (2026-05-28, bug fixes), marked Latest.	Anchor document. Chapter 7 covers `Authentication and Authorization`.	A2A specification, A2A blog (2026-08-27), GitHub releases
AAIF Identity & Trust WG	`Agent to Agent`	AAIF	A group, so there is no version. The WG page indicates a status of `Open` and does not list the names of the specifications produced by the WG.	The WG page description mentions `delegation protocols, cross-domain identity, and how permissions flow across agent-to-agent interactions`.	AAIF WG page
W3C AI Agent Protocol Community Group	`Agent to Agent`	W3C community	Community Group, so there is no version.	The group page description states that the group develops protocols for AI agents to `discover, identify, and collaborate`.	W3C group page
W3C Agent Identity Registry Protocol Community Group	`Not specific to one hop`	W3C community	Community Group, so there is no version.	The group page description mentions `verifiable AI agent identity infrastructure`.	W3C group page

\n
\nThe authorization requirements for MCP specification version 2026-07-28 are addressed in Which MCP Clients a Remote MCP Server Lets In and Section 7.5 of Identity Lifecycle for AI Agents. What this article covers is that the MCP specification is a specification from outside the IETF, and that its authorization page references both IETF RFCs and drafts. The referenced drafts are OAuth 2.1 and CIMD, neither of which is currently an RFC (Sections 5.1, 8.1, and 8.2). AIMS references MCP as [MCP] without specifying a particular version.
\n
\nChapter 7 of the A2A 1.0.0 specification describes the concepts of authentication and authorization as follows:
\n
\n

A2A treats agents as standard enterprise applications, relying on established web security practices. Identity information is handled at the protocol layer, not within A2A semantics.

\n
\nSection 7.6 of the A2A specification, concerning In-Task Authorization, defines a mechanism whereby an agent sets the task status to TASK_STATE_AUTH_REQUIRED and requests authorization from the client when authorization is required during the task's execution. The development version of the specification (the pages under a2a-protocol.org/latest/, which the site's version list makes an alias of dev) adds Section 7.6.4, which further limits the scope of this functionality as follows:
\n
\n

The A2A protocol does not define the scope, representation, validity, or revocation semantics of the authorization decision or credential obtained in response to this state.

\n
\nThe specification pages for 1.0.0 and 1.0.1 end Section 7.6 at Section 7.6.3. As of October 9, 2026, this limit is not in a released version.
\n
\nThe A2A specification references several components for authentication, including the metadata for OAuth 2.0 authorization servers (RFC 8414), PKCE (RFC 7636), Device Authorization Grant (RFC 8628), the HTTP authentication framework (RFC 7235), and JWS signatures for Agent Cards (RFC 7515) (see Chapter 4 of this article). An A2A blog post dated August 27, 2026, states that A2A has been accepted as a Growth Stage project in the AAIF.
\n
\nThe AAIF Identity & Trust WG page indicates that the WG's status is Open, but does not list the name of any specifications produced by the WG. As described in Section 2.2, the W3C list says that community groups are proposed and run by the community and do not necessarily represent the views of the W3C Membership or staff. Besides the two W3C community groups in the table, the W3C list of community groups (as of October 9, 2026) has other groups whose descriptions mention the identity or trust of AI agents, such as Agent Trust Protocol (ATP) and Agent Declaration and Assurance. The table lists only two W3C community groups, as examples.
\n\n

7.2 OpenID Foundation

\n\nThis section lists the following documents from the OpenID Foundation: seven documents referenced by AIMS; two OpenID Connect specifications (including Discovery, which is also referenced by AIMS) referenced by the authorization page of MCP specification version 2026-07-28; documents specifically mentioning MCP from the AuthZEN Working Group's Working Group Drafts; and the whitepaper from the AIIM (Artificial Intelligence Identity Management) Community Group. The term Final in the table refers to the heading in the main body of the specification (for SSF, CAEP, and RISC, which have no such heading, it is based on the announcement), and announcements write Final Specification.
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Document	Hop	Decided By	Status and Version	Why It Is Listed	Where the Source Says So
Authorization API 1.0 (AuthZEN)	`Not specific to one hop`	Members of the OpenID Foundation (announced on 2026-01-12)	`Final`; the specification's Published date is 2026-01-11	Cited by AIMS	Specification document, announcement, list of AuthZEN specifications
COAZ-MCP Binding 1.0	`Agent to Tool`	OpenID Foundation AuthZEN Working Group	One of the `Working Group Drafts` in the AuthZEN specification list. The list gives no version date.	The list description says `the COAZ binding for the Model Context Protocol (MCP)`.	List of AuthZEN specifications
OpenID Shared Signals Framework Specification 1.0	`Not specific to one hop`	Members of the OpenID Foundation (announced on 2025-09-02)	`Final`; the specification's Published date is 2025-08-29	Cited by AIMS	Specification document, announcement
OpenID Continuous Access Evaluation Profile 1.0 (CAEP)	`Not specific to one hop`	Members of the OpenID Foundation (announced on 2025-09-02)	`Final`; the specification's Published date is 2025-08-29	Cited by AIMS	Specification document, announcement
OpenID RISC Profile Specification 1.0	`Not specific to one hop`	Members of the OpenID Foundation (announced on 2025-09-02)	`Final`; the specification's Published date is 2025-08-29	Cited by AIMS	Specification document, announcement
OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0 (CIBA)	`Not specific to one hop`	Members of the OpenID Foundation (announced on 2021-09-01)	`Final` (specification heading); the specification text is dated 2021-09-01	Cited by AIMS in Section 10.7 `Human in the Loop`	Specification document, announcement, AIMS
OpenID Connect Discovery 1.0	`Not specific to one hop`	Voting by members of the OpenID Foundation (announcement from the 2014-02-11 vote lists it as a candidate for Final)	`Final` (specification heading); the specification text is dated 2014-02-25	Cited by AIMS and MCP specification version 2026-07-28	Specification document, announcement of the vote, MCP authorization page
OpenID Connect Dynamic Client Registration 1.0	`Not specific to one hop`	Voting by members of the OpenID Foundation (announcement from the 2014-02-11 vote lists it as a candidate for Final)	`Final` (specification heading); the specification text is dated 2014-02-25	Cited by MCP specification version 2026-07-28	Specification document, announcement of the vote, MCP authorization page
FAPI 2.0 Security Profile	`Not specific to one hop`	Members of the OpenID Foundation (announced on 2025-02-19)	`Final`; the specification's Published date is 2025-02-22	Cited by AIMS	Specification document, announcement
Identity Management for Agentic AI (whitepaper from the AIIM Community Group)	`Not specific to one hop`	OpenID Foundation (released); AIIM Community Group (compiled)	A whitepaper, not a specification. Announced on 2025-10-07	Title	Announcement

\n
\nAIMS references documents from the OpenID Foundation, including the authorization decision API (AuthZEN), change notifications (SSF, CAEP, RISC), user approval (CIBA), discovery, and the high assurance profile (FAPI 2.0). The authorization page of the MCP specification, version 2026-07-28, lists OpenID Connect Discovery 1.0 and Dynamic Client Registration 1.0 among the specifications it is based on. None of these are written specifically for agents. Regarding CIBA, AIMS states that an agent, as an OAuth client, can use CIBA so that the user is asked to approve or deny an action.
\n
\n

An Agent, acting as an OAuth client, can use the OpenID Client Initiated Backchannel Authentication (CIBA) protocol ([OpenIDConnect.CIBA]).

\n
\nAn announcement from the OpenID Foundation, dated June 15, 2026, states that the AuthZEN Working Group approved an MCP tool authorization profile and another profile as Working Group Drafts. The announcement and the list of specifications as of the verification date have different document names (Section 8.5). Of the Working Group Drafts listed, COAZ Framework 1.0, AuthZEN Access Request and Approval Profile 1.0, and AuthZEN Profile for Obligations 1.0 are not included in the table because their list descriptions do not mention either AI agents or MCP. The AIIM Community Group's whitepaper is one that, according to an announcement dated October 7, 2025, the OpenID Foundation released as a whitepaper addressing the challenges of authentication and authorization for AI agents. This whitepaper does not have a defined stage among the OpenID Foundation's specifications (e.g., Implementer’s Draft, Final Specification).
\n\n

7.3 New IETF Working Groups and BOFs

\n\nIn the IETF, as of October 9, 2026, there are WGs and BOFs with agents in their names, and these groups are at stages both before and after their official establishment.
\n
\n\n\n\n\n\n\n\n

Document	Hop	Decided By	Status and Version	Why It Is Listed	Where the Source Says So
`agentproto` (Agent Communication Protocols)	`Agent to Agent`, `User to Agent`, `Agent to Tool`	IESG (`IESG has approved the charter`)	Group state `Active`. Charter `charter-ietf-agentproto-01`, `Approved` (2026-10-08). 0 WG documents.	The charter says `User-to-agent, agent-to-agent, and agent-to-tool interactions` and touches on delegated authorization.	Charter, charter history, WG page, datatracker API
`dawn` (Discovery of Agents With Names)	`Not specific to one hop`	IESG (the 2026-10-09 WG Review announcement says `The IESG has not made any determination yet.`)	Group state `Proposed`. Charter `charter-ietf-dawn-00-10` (2026-10-09) in the state `External Review (Message to Community, Selected by Secretariat)` (since 2026-10-09). 0 WG documents.	The proposed charter covers the discovery of AI agents and says it will use existing IETF protocols where possible.	Charter page, charter history, WG page, datatracker API, IETF-Announce announcement
`audit` (Agent Use of Delegation and Interaction Traceability)	`Agent to Agent`, `User to Agent`, `Agent to Tool`	The source does not say. (The BOF request page shows only state changes, and its `Responsible leadership` field is empty.)	Group state `BOF`. Charter `(None)`. The BOF request `bofreq-kuhlewind-audit-agent-use-of-delegation-and-interaction-traceability-00` is `Approved` (2026-10-08). The earlier request `bofreq-kuhlewind-agent-use-of-delegation-and-interaction-traceability-audit-02` (last updated 2026-07-06) is `Declined`.	The BOF request touches on correlating delegation chains and authorization state across domains.	WG page, BOF request pages

\n
\nThe scope defined in the agentproto charter is the management of agent dialogs. The charter describes this scope as follows:
\n
\n

The scope of Agent Communication Protocols (agentproto) Working Group is to define a common baseline agentic dialog management protocol and build a reference architecture to integrate related protocol building blocks, enabling interoperability across platforms and vendors.

\n
\nThe charter lists three deliverables: Agentic Dialog Management Protocol (Standards Track), Reference Architecture (Informational), and Use Cases and Requirements (Informational). Key considerations outlined in the charter include the possibility that agents may need to be authenticated independently of the users who delegated authority to them, and it touches upon delegated authorization across AI agent chains. Conversely, the charter states that the reference architecture is a document describing the identity, authentication, authorization, and encryption components that the dialog management protocol can reuse; it is not intended to define new components.
\n
\n

To ensure interoperability in agent communications, this informational document describes related protocol building blocks that the agentic dialog management protocol can reuse, including identity, authentication, authorization, and encryption, rather than defining new ones.

\n
\nThe charter lists the following WGs for collaboration: Web Authorization Protocol (OAuth), webbotauth, WIMSE - on identity, authorization, and security considerations. The charter's approval is documented in the datatracker history on October 8, 2026. As of October 9, 2026, the datatracker API lists 0 WG documents for this WG.
\n
\nThe proposed dawn charter addresses the discovery of publicly available information regarding AI resources, including agents. Regarding authentication, it states that, where possible, it will use existing IETF protocols.
\n
\n

Where possible, any solutions created by this WG will be built in a modular way using existing IETF protocols that provide support for any needed communication, authentication, and privacy.

\n
\nThe dawn charter transitioned to -00-10 on October 9, 2026, and its state changed from Start Chartering/Rechartering (Internal Steering Group/IAB Review) to External Review (Message to Community, Selected by Secretariat) (as shown in the datatracker history). The IETF-Announce announcement on the same day (WG Review: Discovery of Agents With Names (dawn)) requested that feedback be sent to the IESG by October 19, 2026, and stated, The IESG has not made any determination yet. The datatracker page for the charter indicates that this charter is on the agenda for the IESG telechat on October 22, 2026.
\n
\naudit has a BOF request (bofreq-kuhlewind-audit-agent-use-of-delegation-and-interaction-traceability-00) whose state became Approved on October 8, 2026. The request's description notes that existing mechanisms lack interoperable support for correlating a user's intent, the chain of delegation, the state of authorization, and the resulting actions across domains.
\n
\n

Existing mechanisms, such as system logs, tracing systems, and authorization frameworks, capture individual aspects of system behavior but lack interoperable support for correlating user intent, delegation chains, authorization state, and resulting actions across domains.

\n
\nThe status of the previous request (bofreq-kuhlewind-agent-use-of-delegation-and-interaction-traceability-audit-02, last updated in datatracker on July 6, 2026) is Declined. A request with a different name, ending in -00, became Approved on October 8, 2026. A BOF is not a WG, and the audit group page shows the charter as (None).
\n\n

8. Where the Sources Disagree, and Where No Statement Was Found

\n\nThis section lists instances where discrepancies exist between the sources and instances where a search did not locate a statement. It does not state that any of these instances represents an error in either source.
\n\n

8.1 The OAuth 2.1 Versions the MCP Specification Cites

\n\nThe MCP specification, version 2026-07-28, references the OAuth 2.1 draft, citing it in most places as draft-ietf-oauth-v2-1-13, with a single exception using -14. This discrepancy is addressed in Section 8.1 of Identity Lifecycle for AI Agents. On October 9, 2026, the current version on the datatracker is -16 (2026-09-02), and OAuth 2.1 is not an RFC. In contrast, AIMS references RFC 6749 as the framework for OAuth, and does not reference the OAuth 2.1 draft.
\n\n

8.2 The CIMD Version the MCP Specification Cites

\n\nVersion 2026-07-28 of the MCP specification references CIMD with the identifier -00. AIMS references -02 (2026-07-06), which is the current version as of the verification date. Section 7.1 of Which MCP Clients a Remote MCP Server Lets In addresses the differences in section numbers between identifiers -00 and -02.
\n\n

8.3 The Versions AIMS Cites

\n\nThe AIMS -00 version (September 15, 2026) fixes the versions of the IETF drafts it references. Two of these drafts have discrepancies between the version referenced and the current state as of the verification date.
\n
\n

It references draft-ietf-wimse-http-signature at version -06. Version -07 was released on September 20, 2026, after the AIMS -00 version.
It references draft-fletcher-transaction-token-chaining-profile-02. According to the datatracker history, this draft was replaced with draft-fletcher-oauth-txn-token-chaining-profile-00 on September 10, 2026, five days prior to the AIMS -00 version.

\n
\nFor the remaining IETF drafts referenced by AIMS (CIMD, ID-JAG, Transaction Tokens, Identity Chaining, draft-ietf-oauth-spiffe-client-auth, and four related to WIMSE), AIMS is referencing the same versions as the current versions as of the verification date.
\n\n

8.4 Intended Status in the Text, and Intended RFC Status on Datatracker

\n\nThe Intended status at the top of the draft text and the Intended RFC status on datatracker are separate fields. For nine of the drafts in this article's tables, the two fields read as follows:
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Document	Intended status in the Text	Intended RFC status on Datatracker
`draft-ietf-wimse-aims-00`	`Informational`	`(None)`
`draft-ietf-oauth-v2-1-16`	`Standards Track`	`(None)`
`draft-ietf-oauth-client-id-metadata-document-02`	`Standards Track`	`(None)`
`draft-ietf-oauth-identity-assertion-authz-grant-04`	`Standards Track`	`(None)`
`draft-ietf-oauth-transaction-tokens-11`	`Standards Track`	`(None)`
`draft-ietf-oauth-identity-chaining-17`	`Standards Track`	`Proposed Standard`
`draft-ietf-oauth-deferred-token-response-00`	`Standards Track`	`(None)`
`draft-ietf-webbotauth-httpsig-protocol-00`	`Standards Track`	`(None)`
`draft-hardt-oauth-aauth-protocol-11`	`Standards Track`	`(None)`

\n
\nWithin this table, only the Identity Chaining draft, which has been submitted to the IESG, has a value listed in the datatracker column. Just because a draft is marked as Standards Track in the document does not necessarily mean it has received an RFC classification.
\n\n

8.5 AuthZEN Working Group Draft Names

\n\nThe OpenID Foundation's announcement on June 15, 2026, stated that the AuthZEN Working Group had approved AuthZEN Access Request and Approval Profile (AARP) and AuthZEN Profile for Model Context Protocol Tool Authorization (COAZ) as Working Group Drafts. The list of AuthZEN specifications, as of October 9, 2026, identified the following as Working Group Drafts: COAZ Framework 1.0, COAZ-MCP Binding 1.0, AuthZEN Access Request and Approval Profile 1.0, and AuthZEN Profile for Obligations 1.0. There was no statement found in either the list or the announcement that explicitly detailed the correspondence between the COAZ mentioned in the announcement and the two COAZ documents listed.
\n\n

8.6 Delegate SD-JWT and Delegated SD-JWT

\n\nOn datatracker, the title of draft-gco-oauth-delegate-sd-jwt-00 is Delegate SD-JWT. The OAuth WG chairs' call for adoption was titled Call for adoption - Delegated SD-JWT. Both refer to the same draft (the post links to this draft's page on datatracker).
\n\n

8.7 A2A's Version Banner and the GitHub Release

\n\nThe A2A specification site shows the banner Latest Released Version 1.0.0 on the pages for v1.0.0, v1.0.1, and the development version. The GitHub release list marks v1.0.1 (2026-05-28) as Latest. The v1.0.1 release lists bug fixes (preferring application/a2a+json in the HTTP binding, error changes, and TaskStatus values). This article treats the A2A anchor document as 1.0.0, as the banner says, and treats Section 7.6.4 as text from the development version (Section 7.1). It does not treat either source as wrong.
\n\n

8.8 Where No Statement Was Found

\n\nThe following descriptions were not found in the scope of this article's search, although this does not preclude their existence outside of that scope.
\n
\n

Calls for adoption on the OAuth WG mailing list for drafts containing agent in the title: The subject lines of 311 messages (from September 2, 2026, to October 9, 2026, at 12:11 UTC) (Section 6.3).
Call for adoption announcements for AAuth: The subject lines of the same 311 messages. AAuth was an item on the OAuth WG's interim agenda on October 5, 2026, and its slides asked where the work should happen (Section 6.2).
A post announcing the outcome of the call for adoption of draft-richer-oauth-httpsig: The subject lines and senders of the same 311 messages. In the thread, the chairs' posts were limited to the initial call only (Section 6.3).
Call for adoption announcements from the WIMSE WG mailing list: The subject lines of 160 messages (from September 17, 2026, to October 9, 2026, at 12:18 UTC) (Section 6.3).
Instances of the term agent in the body of OpenID Connect Key Binding 1.0: The body was searched on October 9, 2026 (Section 1.5).
Verbatim announcements regarding the approval of OpenID Connect Discovery 1.0 and Dynamic Client Registration 1.0 as Final: Announcements from the OpenID Foundation in February 2014 (the table in Section 7.2 is based on the vote announcement dated February 11, 2014).
Specifications released by the Identity & Trust WG of AAIF: The WG's page (Section 7.1).
WG documents for agentproto: 0 documents found via the datatracker API (as of October 9, 2026).
Status of Call For Adoption By WG Issued for Delegate SD-JWT and draft-richer-oauth-httpsig within datatracker: Neither document's page nor history contains this status (Section 6.3).

\n\n

9. Dates on Which These Statuses Can Change Next

\n\nThe status information presented in this article was verified as of October 9, 2026. This section lists, as described in the sources, the dates following the verification date that are relevant to the rows in the tables. The expiry rows are drafts in the tables whose expiry falls within 2026. This section does not detail how the status will change on each of these dates.
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Date	What Is Scheduled	Rows It Touches	Where the Source Says So
2026-10-12	Reply deadline of the call for adoption for Delegate SD-JWT (`October 12`)	Sections 6.1 and 6.3	OAuth WG mailing list
2026-10-19	OAuth WG interim `interim-2026-oauth-09` (`Agent Authorization – Use Cases and Gaps`)	Section 6.2	datatracker
2026-10-19	Deadline for feedback on the external review of the `dawn` charter (`by 2026-10-19`)	Section 7.3	IETF-Announce announcement
2026-10-22	IESG telechat with the `dawn` charter on the agenda (`On agenda of 2026-10-22 IESG telechat`)	Section 7.3	datatracker
2026-10-24 (UTC)	Expiry of Delegate SD-JWT `-00` (the API's `expires` is `2026-10-24T04:45:15Z`; the draft header and the datatracker page give `23 October 2026`)	Section 6.1	datatracker API, draft document
2026-10-26	OAuth WG interim `interim-2026-oauth-10` (`Mission-Bound Authorization`)	Sections 6.1 and 6.2	datatracker
2026-11-02	Internet-Draft submission cut-off for IETF 127 (`by UTC 23:59`)	Drafts in Chapters 5 and 6	IETF 127 schedule
2026-11-14	Start of IETF 127 meeting (San Francisco, 7 days)	IETF documents and groups in Chapters 5 and 6 and Section 7.3	datatracker
2026-11-22 (UTC)	Expiry of ID-JAG `-04` (the API's `expires` is `2026-11-22T22:18:28Z`)	Section 5.1	datatracker API
2026-12	WG milestone for OAuth 2.1 and Transaction Tokens (submission to the IESG, `Dec 2026`)	Section 5.1	datatracker
2026-12-17 (UTC)	Expiry of `draft-ietf-oauth-spiffe-client-auth-02` (the API's `expires` is `2026-12-17T08:11:11Z`)	Section 5.1	datatracker API

\n
\nThe dates mentioned are all deadlines and scheduled times. If you are reading this article after October 9, 2026, check the version number and status terms again on the datatracker document page.
\n\n

10. Frequently Asked Questions about the Status of AI Agent Authorization Standards

\n\nThis article addresses common questions that arise during design reviews concerning the status of documents related to AI agent authorization. All answers reflect the status as of October 9, 2026.
\n\n

Q1. Is there an RFC (Request for Comments) regarding the authorization of AI agents?

\n\nThe 21 RFCs listed in this article (Chapter 4) were not written specifically for AI agents. They include components such as OAuth 2.0 (RFC 6749), Token Exchange (RFC 8693), and Protected Resource Metadata (RFC 9728), and 18 of them are cited by AIMS, MCP specification version 2026-07-28, or A2A 1.0.0 as components related to authentication and authorization. In a datatracker API search on October 9, 2026, only one IETF Working Group document, AIMS, mentions the string AI agent in its abstract, and its WG state is WG Document (Section 3.3).
\n\n

Q2. Is AIMS a standard?

\n\nAIMS is the WIMSE WG document draft-ietf-wimse-aims-00 (September 15, 2026); the WG state is WG Document and the IESG state is I-D Exists. It is not an RFC. The top of the document's text indicates an Intended status of Informational, and the Intended RFC status in the datatracker is (None). The abstract describes the document as one that does not define a new protocol, but rather explains how existing standards can be applied or extended for agent authentication and authorization.
\n\n

Q3. Does the number of drafts with `agent` in the title indicate progress in standardization?

\n\nNo, it does not. Between September 24 and October 4, 2026 (UTC), 48 drafts containing the string agent in their titles posted new versions (70 submissions in total). All of these drafts were individual drafts. The counts are of new-version submissions and drafts, and do not represent WG (Working Group) adoption or IESG (Internet Engineering Steering Group) decisions. Of the WG documents that meet (a) in Section 1.2, the 5 documents in Section 3.3 do not include agent in their titles and therefore fall outside this count.
\n\n

Q4. Was AAuth adopted by the OAuth Working Group?

\n\nAs of the verification date, AAuth (draft-hardt-oauth-aauth-protocol-11, September 25, 2026) was an individual draft, with the datatracker group listed as Individual Submissions and no designated stream. AAuth was on the agenda for an interim meeting of the OAuth WG on October 5, 2026. The final slide of the AAuth presentation presented two options for where the work should happen: Option A indicated In the OAuth WG, while Option B indicated In a new WG. A search of the subject lines on the OAuth WG mailing list from September 2, 2026, to 12:11 UTC on October 9, 2026 (a total of 311 messages) did not find any call for adoption of AAuth (Section 8.8). In a preceding email dated August 27, 2026, an OAuth WG chair wrote that a call for adoption regarding documents related to agents was premature at that time (Section 6.3). The call for adoption for Delegate SD-JWT (September 28, 2026) occurred after this email.
\n\n

Q5. Is the `agentproto` working group focused on standardizing agent authorization?

\n\nThe scope defined in the agentproto charter includes a protocol for managing agent dialogs, a reference architecture, and a document outlining use cases and requirements. The charter does mention delegated authorization. However, it says the reference architecture is a document that outlines the authentication and authorization components the dialog management protocol can reuse, rather than defining new ones. The charter was approved on October 8, 2026, and as of the verification date, the WG had 0 WG documents.
\n\n

Q6. Is MCP authorization an IETF standard?

\n\nThe MCP specification is a specification from outside the IETF, and the versioning page indicates that version 2026-07-28 is marked as Current. The authorization page references IETF RFCs (such as RFC 8414 and RFC 9728) and drafts (OAuth 2.1, primarily version -13, with one instance at -14, and CIMD, version -00). The referenced OAuth 2.1 and CIMD are not RFCs but rather WG documents of the OAuth WG (WG Document, I-D Exists).
\n\n

11. Summary

\n\nThe following information reflects the status as of October 9, 2026.
\n
\nThe number of documents containing the string agent in their title, and the standardization stages, are distinct. Between September 24, 2026, and October 4, 2026 (UTC), 48 Internet-Drafts containing the string agent in their titles posted new versions. They made 70 submissions, and all 48 were individual drafts. The WG document focusing on AI agent authentication and authorization (AIMS, draft-ietf-wimse-aims-00, September 15, 2026) does not include agent in its title and is therefore not counted in this figure. Similarly, WG documents that address agents in appendices, introductions, or sections of the main body (ID-JAG, Deferred Token Response, WIMSE Architecture, and the WG document on Web Bot Auth) are not identified through title matching.
\n
\nMany of the components used for agent authorization are already RFCs. Of the 18 RFCs listed in this article that the anchor documents reference as components for authentication and authorization, none were specifically written for agents. Among the WG documents in the Chapter 5 tables, Identity Chaining is in RFC Ed Queue (no RFC number yet), Transaction Tokens is in WG Consensus: Waiting for Write-Up, and AIMS, ID-JAG, CIMD, and OAuth 2.1 are in WG Document. Individual drafts dealing with agent delegation and authorization (AAuth, Mission-Bound Authorization, Delegate SD-JWT, and others) are at the individual draft stage, as detailed in Chapter 6.
\n
\nThe agenda items, expressions of interest, and calls for adoption are not adoption. The OAuth WG's interim meeting on October 5, 2026, included AAuth on the agenda, and the AAuth slides inquired about the location of the work. The agenda items for the meetings scheduled on October 19 and October 26, 2026, concerned use cases and gaps in agent authorization, as well as Mission-Bound Authorization. The WIMSE WG chairs wrote This is not a call for adoption to gauge interest in WAG. In the subject lines of the 311 messages on the OAuth WG's mailing list from September 2, 2026, onward, only one call for adoption was for a draft whose abstract mentions agents—Delegate SD-JWT—with a deadline of October 12, 2026.
\n
\nBeyond the IETF, there are other terms to describe stages of development. MCP specification version 2026-07-28 is marked as Current. A2A is Latest Released Version 1.0.0 on its specification pages (GitHub marks release v1.0.1 as Latest; Section 8.7). The OpenID Foundation's AuthZEN Authorization API 1.0 is Final. And AuthZEN's COAZ-MCP Binding 1.0 is one of the Working Group Drafts. agentproto, which received charter approval in the IETF on October 8, 2026, covers dialog management, and its charter states that the reference architecture describes authentication and authorization components that the dialog management protocol can reuse. The group state of dawn is Proposed, and that of audit is BOF.
\n
\nFinally, here are five things to verify during design reviews when asked whether a document is a standard:
\n
\n

The document's name, version number, and version date. Check the WG state and IESG state in datatracker; if it's an RFC, check the number and category.
Rather than the document's title, verify what the abstract, introduction, and appendix headings cover.
Confirm which versions of which documents the specification you rely on (MCP, A2A, AIMS, etc.) references, and whether those versions are current.
Ensure that agenda items and calls for adoption are not mistakenly considered adoption. Has the status in datatracker changed?
If a date in Chapter 9 has passed, double-check the status on the datatracker page.

\n\n

12. References

\n\n

\n
\n\n\n\n\n
\nReferences:
\nTech Blog with curated related content
\n\n\n

Written by Hidekazu Konishi