{"slug": "ai-identity-management-system", "title": "AI Identity Management System", "summary": "The IETF's WIMSE working group published draft-ietf-wimse-aims-00 on 15 September 2026, a document proposing best practices for authenticating and authorizing AI agent interactions by applying existing WIMSE architecture and OAuth 2.0 specifications rather than defining new protocols. The draft, authored by Pieter Kasselman of Defakto Security, Jeff Lombardo of AWS, Yaroslav Rosomakho of Zscaler, Brian Campbell of Ping Identity, Nick Steele of OpenAI and Aaron Parecki of Okta, replaces draft-klrc-aiagent-auth and aims to identify gaps and guide future standardization for agent authentication and authorization. The document is an active Internet-Draft with no intended RFC status yet and expires on 19 March 2027.", "body_md": "# \n AI Identity Management System\n \n\ndraft-ietf-wimse-aims-00\n\n| Document | Type | | Active Internet-Draft ( [wimse WG](https://datatracker.ietf.org/wg/wimse/about/) ) | \n|---|---|---|---|\n| | Authors | | [Pieter Kasselman](https://datatracker.ietf.org/person/prkasselman@gmail.com) ,[Jeff Lombardo](https://datatracker.ietf.org/person/jeffsec@amazon.com) ,[Yaroslav Rosomakho](https://datatracker.ietf.org/person/yrosomakho@zscaler.com) ,[Brian Campbell](https://datatracker.ietf.org/person/bcampbell@pingidentity.com) ,[Nick Steele](https://datatracker.ietf.org/person/steele@openai.com) ,[Aaron Parecki](https://datatracker.ietf.org/person/aaron@parecki.com) | \n| | Last updated | | 2026-09-15 | \n| | Replaces | | [draft-klrc-aiagent-auth](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) | \n| | RFC stream | | Internet Engineering Task Force (IETF) | \n| | Intended RFC status | | (None) | \n| | Formats | | | \n| | Additional resources | | [Mailing list discussion](https://mailarchive.ietf.org/arch/browse/wimse/?q=draft-ietf-wimse-aims) | \n| Stream | [WG state](https://datatracker.ietf.org/doc/help/state/draft-stream-ietf/) | | WG Document | \n| | Document shepherd | | (None) | \n| IESG | [IESG state](https://datatracker.ietf.org/doc/help/state/draft-iesg/) | | I-D Exists | \n| | Consensus boilerplate | | Unknown | \n| | Telechat date | | (None) | \n| | Responsible AD | | (None) | \n| | Send notices to | | (None) | \n\n \n draft-ietf-wimse-aims-00\n \n \n\n```\nWIMSE P. Kasselman\nInternet-Draft Defakto Security\nIntended status: Informational J. Lombardo\nExpires: 19 March 2027 AWS\n Y. Rosomakho\n Zscaler\n B. Campbell\n Ping Identity\n N. Steele\n OpenAI\n A. Parecki\n Okta\n 15 September 2026\n\n AI Identity Management System\n draft-ietf-wimse-aims-00\n\nAbstract\n\n This document proposes best practices for authentication and\n authorization of AI agent interactions. It leverages existing\n standards such as the Workload Identity in Multi-System Environments\n (WIMSE) architecture and OAuth 2.0 family of specifications. Rather\n than defining new protocols, this document describes how existing and\n widely deployed standards can be applied or extended to establish\n agent authentication and authorization. By doing so, it aims to\n provide a framework within which to use existing standards, identify\n gaps and guide future standardization efforts for agent\n authentication and authorization.\n\nAbout This Document\n\n This note is to be removed before publishing as an RFC.\n\n The latest revision of this draft can be found at https://ietf-wg-\n wimse.github.io/draft-ietf-wimse-aims/draft-ietf-wimse-aims.html.\n Status information for this document may be found at\n https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/.\n\n Discussion of this document takes place on the WIMSE Working Group\n mailing list (mailto:wimse@ietf.org), which is archived at\n https://mailarchive.ietf.org/arch/browse/wimse/. Subscribe at\n https://www.ietf.org/mailman/listinfo/wimse/.\n\n Source for this draft and an issue tracker can be found at\n https://github.com/ietf-wg-wimse/draft-ietf-wimse-aims.\n\nKasselman, et al. Expires 19 March 2027 [Page 1]\nInternet-Draft AIMS September 2026\n\nStatus of This Memo\n\n This Internet-Draft is submitted in full conformance with the\n provisions of BCP 78 and BCP 79.\n\n Internet-Drafts are working documents of the Internet Engineering\n Task Force (IETF). Note that other groups may also distribute\n working documents as Internet-Drafts. The list of current Internet-\n Drafts is at https://datatracker.ietf.org/drafts/current/.\n\n Internet-Drafts are draft documents valid for a maximum of six months\n and may be updated, replaced, or obsoleted by other documents at any\n time. It is inappropriate to use Internet-Drafts as reference\n material or to cite them other than as \"work in progress.\"\n\n This Internet-Draft will expire on 19 March 2027.\n\nCopyright Notice\n\n Copyright (c) 2026 IETF Trust and the persons identified as the\n document authors. All rights reserved.\n\n This document is subject to BCP 78 and the IETF Trust's Legal\n Provisions Relating to IETF Documents (https://trustee.ietf.org/\n license-info) in effect on the date of publication of this document.\n Please review these documents carefully, as they describe your rights\n and restrictions with respect to this document. Code Components\n extracted from this document must include Revised BSD License text as\n described in Section 4.e of the Trust Legal Provisions and are\n provided without warranty as described in the Revised BSD License.\n\nTable of Contents\n\n 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3\n 2. Document Status . . . . . . . . . . . . . . . . . . . . . . . 4\n 3. Conventions and Definitions . . . . . . . . . . . . . . . . . 4\n 4. Agents are workloads . . . . . . . . . . . . . . . . . . . . 4\n 5. Agent Identity Management System . . . . . . . . . . . . . . 6\n 6. Agent Identifier . . . . . . . . . . . . . . . . . . . . . . 7\n 7. Agent Credentials . . . . . . . . . . . . . . . . . . . . . . 8\n 8. Agent Credential Provisioning . . . . . . . . . . . . . . . . 9\n 9. Agent Authentication . . . . . . . . . . . . . . . . . . . . 11\n 9.1. Transport Layer Authentication . . . . . . . . . . . . . 11\n 9.1.1. Limitations . . . . . . . . . . . . . . . . . . . . . 11\n 9.2. Application Layer Authentication . . . . . . . . . . . . 12\n 9.2.1. WIMSE Proof Tokens (WPTs) . . . . . . . . . . . . . . 12\n 9.2.2. HTTP Message Signatures . . . . . . . . . . . . . . . 12\n 9.2.3. Limitations . . . . . . . . . . . . . . . . . . . . . 13\n\nKasselman, et al. Expires 19 March 2027 [Page 2]\nInternet-Draft AIMS September 2026\n\n 10. Agent Authorization . . . . . . . . . . . . . . . . . . . . . 13\n 10.1. Agent Mission . . . . . . . . . . . . . . . . . . . . . 13\n 10.2. Leverage OAuth 2.0 as a Delegation Authorization\n Framework . . . . . . . . . . . . . . . . . . . . . . . 14\n 10.3. Use of OAuth 2.0 Access Tokens . . . . . . . . . . . . . 14\n 10.4. Obtaining an OAuth 2.0 Access Token . . . . . . . . . . 15\n 10.4.1. User Delegates Authorization . . . . . . . . . . . . 15\n 10.4.2. Agent Obtains Own Authorization . . . . . . . . . . 16\n 10.4.3. Agents Accessed by Systems or Other Agents . . . . . 16\n 10.4.4. OAuth 2.0 Security Best Practices . . . . . . . . . 16\n 10.5. Risk Reduction with Transaction Tokens . . . . . . . . . 16\n 10.6. Cross Domain Access . . . . . . . . . . . . . . . . . . 17\n 10.7. Human in the Loop . . . . . . . . . . . . . . . . . . . 18\n 10.8. Tool-to-Service Access . . . . . . . . . . . . . . . . . 18\n 10.9. Privacy Considerations . . . . . . . . . . . . . . . . . 19\n 10.10. OAuth 2.0 Discovery in Dynamic Environments . . . . . . 19\n 10.10.1. Authorization Server Capability Discovery . . . . . 20\n 10.10.2. Protected Resource Capability Discovery . . . . . . 20\n 10.10.3. Client Capability Discovery . . . . . . . . . . . . 20\n 11. Agent Monitoring, Observability and Remediation . . . . . . . 20\n 12. Agent Authentication and Authorization Policy . . . . . . . . 22\n 13. Agent Compliance . . . . . . . . . . . . . . . . . . . . . . 22\n 14. Security Considerations . . . . . . . . . . . . . . . . . . . 22\n 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23\n 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23\n 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23\n 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 23\n 18.1. Normative References . . . . . . . . . . . . . . . . . . 23\n 18.2. Informative References . . . . . . . . . . . . . . . . . 28\n Appendix A. Document History . . . . . . . . . . . . . . . . . . 28\n Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29\n\n1. Introduction\n\n The rapid emergence of AI agents as autonomous workloads has sparked\n considerable innovation in authentication and authorization\n approaches. However, many of these efforts develop solutions in\n isolation, often reinventing existing mechanisms unaware of\n applicable prior art. This fragmentation risks creating incompatible\n implementations, duplicated development effort, and missed\n opportunities to leverage decades of established identity and\n authorization standards.\n\nKasselman, et al. Expires 19 March 2027 [Page 3]\nInternet-Draft AIMS September 2026\n\n This document aims to help close that gap by providing a\n comprehensive model demonstrating how existing, well-established\n standards and some emergent specifications can be composed and\n applied to solve agent authentication and authorization challenges.\n Rather than proposing new protocols, this work focuses on integrating\n proven standards into a coherent framework tailored to the specific\n requirements of AI agent workloads.\n\n By doing so, this document serves two complementary goals:\n\n 1. *Consolidation of prior art*: It establishes a baseline by\n showing how existing standards address the core identity,\n authentication, authorization, monitoring and observability needs\n of agent-based systems. Implementers and standards developers\n can reference this framework to avoid redundant work and ensure\n interoperability.\n\n 2. *Foundation for future work*: As the agent ecosystem matures,\n having such a framework aids in identifying gaps and clarifies\n where extensions or profiles of existing standards are needed.\n This provides a foundation for more focused standardization\n efforts in areas needing novel work rather than variations of\n existing approaches.\n\n2. Document Status\n\n This document profiles existing standards and emerging specifications\n from the IETF, CNCF, and OpenID Foundation, as well as third-party\n protocols and mechanisms, for the AI agent use case. It defines best\n current practices for combining these and identifies new requirements\n specific to agent authentication and authorization.\n\n3. Conventions and Definitions\n\n The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\",\n \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"NOT RECOMMENDED\", \"MAY\", and\n \"OPTIONAL\" in this document are to be interpreted as described in\n BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all\n capitals, as shown here.\n\n4. Agents are workloads\n\n An Agent is a workload that iteratively interacts with a Large\n Language Model (LLM) and a set of Tools, Services and Resources. An\n agent performs its operations until a terminating condition,\n determined either by the LLM or by the agent's internal logic, is\n reached. It may receive input from a user, or act autonomously.\n Figure 1 shows a conceptual model of the AI Agent as a workload and\n\nKasselman, et al. Expires 19 March 2027 [Page 4]\nInternet-Draft AIMS September 2026\n\n illustrates the high-level interaction model between the User or\n System, the AI Agent, the Large Language Model (LLM), Tools,\n Services, and Resources.\n\n In this document, Tools, Services, and Resources are treated as a\n single category of external endpoints that an agent invokes or\n interacts with to complete a task. Communication within or between\n Tools, Services, and Resources is out of scope.\n\n +----------------+\n | Large Language |\n | Model (LLM) |\n +----------------+\n ^ |\n | |\n (2) (3)\n | |\n | v\n +--------+ +------------+ +-----------+\n | User |--(1)->| AI Agent |--(4)->| Tools |\n | or | | (workload) | | Services |\n | System |<-(6)--| |<-(5)--| Resources |\n +--------+ +------------+ +-----------+\n\n Figure 1: AI Agent as a Workload\n\n 1. Optional: The User or System (e.g. a batch job or another Agent)\n provides an initial request or instruction to the AI Agent.\n\n 2. The AI Agent provides the available context to the LLM. Context\n is implementation, and deployment, specific and may include User\n or System input, system prompts, Tool descriptions, prior Tool,\n Service and Resource outputs, and other relevant state.\n\n 3. The LLM returns output to the AI Agent facilitating selection of\n Tools, Services or Resources to invoke.\n\n 4. The AI Agent invokes one or more external endpoints of selected\n Tools, Services or Resources. A Tool endpoint may itself be\n implemented by another AI agent.\n\n 5. The external endpoint of the Tools, Services or Resources returns\n a result of the operation to the AI Agent, which may send the\n information as additional context to the Large Language Model,\n repeating steps 2-5 until the exit condition is reached and the\n task is completed.\n\nKasselman, et al. Expires 19 March 2027 [Page 5]\nInternet-Draft AIMS September 2026\n\n 6. Optional: Once the exit condition is reached in step 5, the AI\n Agent may return a response to the User or System. The AI Agent\n may also return intermediate results or request additional input.\n\n As shown in Figure 1, the AI agent is a workload that needs an\n identifier and credentials so it can be authenticated by the Tools,\n Services, Resources, Large Language Model, System and the User (via\n the underlying operating system or platform, similar to existing\n applications and services). Once authenticated, these parties\n determine if the AI Agent is authorized to access the requested Large\n Language Model, Tools, Services or Resources. If the AI Agent is\n acting on behalf of a User or System, the User or System needs to\n delegate authority to the AI Agent, and the User or System context is\n preserved and used as input to authorization decisions and recorded\n in audit trails.\n\n This document describes how AI Agents should leverage existing\n standards defined by SPIFFE [SPIFFE], WIMSE, OAuth and OpenID SSF\n [SSF].\n\n5. Agent Identity Management System\n\n This document defines the term Agent Identity Management System\n (AIMS) as a conceptual model describing the set of functions required\n to establish, maintain, and evaluate the identity and permissions of\n an agent workload. AIMS does not refer to a single product,\n protocol, or deployment architecture. AIMS may be implemented by one\n component or distributed across multiple systems (such as identity\n providers, provisioning services, authorization servers, policy\n engines, and runtime enforcement points).\n\n An Agent Identity Management System ensures that the right Agent has\n access to the right resources and tools at the right time for the\n right reason. An Agent identity management system depends on the\n following components to achieve its goals:\n\n * *Agent Identifiers:* Unique identifier assigned to every Agent.\n\n * *Agent Credentials:* Cryptographic binding between the Agent\n Identifier and attributes of the Agent.\n\n * *Agent Credential Provisioning:* The mechanism for provisioning\n credentials to the agent at runtime.\n\n * *Agent Authentication:* Protocols and mechanisms used by the Agent\n to authenticate itself to Large Language Models or Tools (resource\n or server) in the system.\n\nKasselman, et al. Expires 19 March 2027 [Page 6]\nInternet-Draft AIMS September 2026\n\n * *Agent Authorization:* Protocols and systems used to determine if\n an Agent is allowed to access a Large Language Model or Tool\n (resource or server).\n\n * *Agent Observability and Remediation:* Protocols and mechanisms to\n dynamically modify the authorization decisions based on observed\n behavior and system state.\n\n * *Agent Authentication and Authorization Policy:* The configuration\n and rules for each of the Agent Identity Management System.\n\n * *Agent Compliance:* Measurement of the state and functioning of\n the system against the stated policies.\n\n The components form a logical stack in which higher layers depend on\n guarantees provided by lower layers, as illustrated in Figure 2.\n\n +--------------+----------------------------------+-----------------+\n | Policy | Monitoring, Observability | Compliance |\n | | & Remediation | |\n | +----------------------------------+ |\n | | Authorization | |\n | +----------------------------------+ |\n | | Authentication | |\n | +----------------------------------+ |\n | | Provisioning | |\n | +----------------------------------+ |\n | | Credentials | |\n | +----------------------------------+ |\n | | Identifier | |\n +--------------+----------------------------------+-----------------+\n\n Figure 2: Agent Identity Management System\n\n6. Agent Identifier\n\n Agents MUST be uniquely identified in order to support\n authentication, authorization, auditing, and delegation.\n\n The Workload Identity in Multi-System Environments (WIMSE) identifier\n as defined by [WIMSE-ID] is the primary identifier for agents in this\n framework.\n\n A WIMSE identifier is a URI that uniquely identifies a workload\n within a trust domain. Authorization decisions, delegation\n semantics, and audit records rely on this identifier remaining stable\n for the lifetime of the workload identity.\n\nKasselman, et al. Expires 19 March 2027 [Page 7]\nInternet-Draft AIMS September 2026\n\n The Secure Production Identity Framework for Everyone ([SPIFFE])\n identifier is a widely deployed and operationally mature instance of\n the WIMSE identifier model [WIMSE-ID]. A SPIFFE identifier\n ([SPIFFE-ID]) is a URI in the form of spiffe:///\n that uniquely identifies a workload within a trust domain.\n\n An agent participating in this framework MUST be assigned exactly one\n WIMSE identifier, which MAY be a SPIFFE ID.\n\n7. Agent Credentials\n\n Agents MUST possess credentials that provide a cryptographic binding\n to the agent identifier. These credentials are considered primary\n credentials that are provisioned at runtime. An identifier alone is\n insufficient unless it can be verified to be controlled by the\n communicating agent through a cryptographic binding.\n\n WIMSE defines two credential formats in [WIMSE-CRED]: the Workload\n Identity Token (WIT) and the transport-layer X.509 Workload Identity\n Certificate (WIC), both of which bind a cryptographic key to a\n workload identifier for use in authentication. SPIFFE defines three\n credential formats: the X.509-SVID [SPIFFE-X509-SVID], WIT-SVID\n [SPIFFE-WIT-SVID], and JWT-SVID [SPIFFE-JWT-SVID]. X.509-SVID is\n compatible with WIC, while WIT-SVID profiles WIT. JWT-SVIDs are\n short-lived bearer credentials used for JWT-based authentication.\n The choice of credential format depends on the deployment’s trust\n model and integration requirements.\n\n Agent credentials SHOULD be short-lived to minimize the risk of\n credential theft, MUST include an explicit expiration time after\n which it is no longer accepted, and MAY carry additional attributes\n relevant to the agent (for example trust domain, attestation\n evidence, or workload metadata).\n\n Deployments can improve the assurance of agent identity by protecting\n private keys using hardware-backed or isolated cryptographic storage\n such as TPMs, secure enclaves, or platform security modules when such\n capabilities are available. These mechanisms reduce key exfiltration\n risk but are not required for interoperability.\n\nKasselman, et al. Expires 19 March 2027 [Page 8]\nInternet-Draft AIMS September 2026\n\n In some cases, agents MAY need secondary credentials to access a\n proprietary or legacy environment that is not compatible with the\n X.509, JWT or WIT it is provisioned with. In these cases an agent\n MAY exchange their primary credentials through a credential exchange\n mechanisms (e.g., OAuth 2.0 Token Exchange [OAUTH-TOKEN-EXCHANGE],\n Transaction Tokens [OAUTH-TXN-TOKENS] or Workload Identity\n Federation). This allows an agent to obtain a credential targeted to\n a specific environment by leveraging the primary credential in its\n possession.\n\n *Note*: Static API keys are an antipattern for agent identity. They\n are bearer artifacts that are not cryptographically bound, do not\n convey identity, are typically long-lived and are operationally\n difficult to rotate, making them unsuitable for secure agent\n authentication or authorization.\n\n8. Agent Credential Provisioning\n\n Agent credential provisioning refers to the runtime issuance,\n renewal, lifecycle state and rotation of the credentials an agent\n uses to authenticate and authorize itself to other agents. Agents\n may be provisioned with one or more credential types as described in\n Section 7. Unlike static secrets, agent credentials are provisioned\n dynamically and are intentionally short-lived, eliminating the\n operational burden of manual expiration management and reducing the\n impact of credential compromise.\n\n Credential provisioning is also the assessment point to confirm that\n the Agent and its runtime environment satisfy the posture\n requirements. In this document, posture assessment refers to the\n evaluation of signals about the Agent, its software, deployment\n context, runtime environment, and operational state. These signals\n can influence whether a credential is issued, which identifier is\n bound to the credential, what type of credential is issued, what\n attributes are included in the credential, and how long the\n credential remains valid.\n\n Posture assessment mechanisms are deployment and risk specific. They\n may include hardware-backed evidence, trusted execution environment\n (TEE) evidence, software integrity measurements, supply-chain\n provenance, platform or orchestration-layer metadata, workload\n placement information, configuration state, operator assertions, or\n other environment-specific signals. Depending on the risk involved,\n a single signal may be sufficient, while higher-risk deployments may\n require multiple independent signals before credentials are issued or\n renewed.\n\nKasselman, et al. Expires 19 March 2027 [Page 9]\nInternet-Draft AIMS September 2026\n\n Deployed workload identity systems commonly perform some form of\n posture assessment as part of credential provisioning. For example,\n SPIFFE implementations can evaluate platform and environment-specific\n information about a workload before binding it to a SPIFFE identifier\n and issuing an SVID. At a high level, a provisioning component\n gathers workload and execution context signals, verifies them\n according to local policy, and, if verification succeeds, issues\n short-lived credentials for subsequent authentication and\n authorization.\n\n An Agent Identity Management System may incorporate multiple posture\n assessment mechanisms and implementations. The selection of\n mechanisms depends on deployment constraints, such as the underlying\n platform, available identity signals, and desired level of trust\n assurance. This document does not require any particular posture\n assessment mechanism, evidence format, or verifier architecture.\n\n Agent credential provisioning must operate autonomously, scale to\n high-churn environments, and integrate closely with the posture\n assessment mechanisms used to establish trust in the Agent at each\n issuance or rotation event.\n\n Agent credential provisioning typically includes two phases:\n\n 1. *Initial Provisioning*: The process by which an agent first\n acquires a credential bound to its identity. This often occurs\n immediately after deployment or instantiation and is based on\n verified properties of the agent (e.g., deployment context,\n posture assessment results, or orchestration metadata).\n\n 2. *Rotation/Renewal*: The automatic refresh of short-lived\n credentials before expiration. Continuous rotation ensures that\n credentials remain valid only for the minimum necessary time and\n that authorization state reflects current operational conditions.\n\n The use of short-lived credentials provides a significant improvement\n in the risk profile and risk of credential exposure. It provides an\n alternative to explicit revocation mechanisms and simplifies\n lifecycle management in large, automated environments while removing\n the risks of downtime as a result of credential expiry.\n\n Deployed frameworks such as [SPIFFE] provide proven mechanisms for\n automated, short-lived credential provisioning at runtime. In\n addition to issuing short-lived credentials, [SPIFFE] also provisions\n ephemeral cryptographic key material bound to each credential,\n further reducing the risks associated with compromising long-lived\n keys.\n\nKasselman, et al. Expires 19 March 2027 [Page 10]\nInternet-Draft AIMS September 2026\n\n The Large Language Model MUST NOT have access to an agent's\n credentials or to credentials that may be needed to access tools and\n services. This prevents the Large Language Model from using,\n exposing, or being manipulated via prompt injection into disclosing\n the credentials.\n\n9. Agent Authentication\n\n Agents may authenticate using a variety of mechanisms, depending on\n the credentials they possess, the protocols supported in the\n deployment environment, and the risk profile of the application. As\n described in the WIMSE Architecture [WIMSE-ARCH], authentication can\n occur at either the transport layer or the application layer, and\n many deployments rely on a combination of both.\n\n9.1. Transport Layer Authentication\n\n Transport-layer authentication establishes trust during the\n establishment of a secure transport channel. The most common\n mechanism used by agents is mutually-authenticated TLS (mTLS), in\n which both endpoints present X.509-based credentials and perform a\n bidirectional certificate exchange as part of the TLS negotiation.\n When paired with short-lived workload identities, such as those\n issued by SPIFFE or WIMSE, mTLS provides strong channel binding and\n cryptographic proof of control over the agent’s private key.\n\n mTLS is particularly well-suited for environments where transport-\n level protection, peer authentication, and ephemeral workload\n identity are jointly required. It also simplifies authorization\n decisions by enabling agents to associate application-layer requests\n with an authenticated transport identity. One example of this is the\n use of mTLS in service mesh architectures such as Istio or LinkerD.\n\n9.1.1. Limitations\n\n There are scenarios where transport-layer authentication is not\n desirable or cannot be relied upon. In architectures involving\n intermediaries, such as proxies, API gateways, service meshes, load\n balancers, or protocol translators, TLS sessions are often terminated\n and re-established, breaking the end-to-end continuity of transport-\n layer identity. Similarly, some deployment models (such as\n serverless platforms, multi-tenant edge environments, or cross-domain\n topologies) may obscure or abstract identity presented at the\n transport layer, making it difficult to bind application-layer\n actions to a credential presented at the transport layer. In these\n cases, application-layer authentication provides a more robust and\n portable mechanism for expressing agent identity and conveying\n attestation or policy-relevant attributes.\n\nKasselman, et al. Expires 19 March 2027 [Page 11]\nInternet-Draft AIMS September 2026\n\n9.2. Application Layer Authentication\n\n Application-layer authentication allows agents to authenticate\n independently of the underlying transport. This enables end-to-end\n identity preservation even when requests traverse proxies, load\n balancers, or protocol translation layers.\n\n The WIMSE working group defines WIMSE Proof Tokens and HTTP Message\n Signatures as authentication mechanisms that may be used by agents.\n\n9.2.1. WIMSE Proof Tokens (WPTs)\n\n WIMSE Workload Proof Tokens (WPTs, [WIMSE-WPT]) are a protocol-\n independent, application-layer mechanism for proving possession of\n the private key associated with a Workload Identity Token (WIT).\n WPTs are generated by the agent, using the private key matching the\n public key in the WIT. A WPT is defined as a signed JSON Web Token\n (JWT) that binds an agent’s authentication to a specific message\n context, for example, an HTTP request, thereby providing proof of\n possession rather than relying on bearer semantics.\n\n WPTs are designed to work alongside WITs [WIMSE-CRED] and are\n typically short-lived to reduce the window for replay attacks. They\n carry claims such as audience (aud), expiration (exp), a unique token\n identifier (jti), and a hash of the associated WIT (wth). A WPT may\n also include hashes of other related tokens (e.g., a Transaction\n Token) to bind the authentication contexts to specific transaction or\n authorizations details.\n\n Although the draft currently defines a protocol binding for HTTP (via\n a Workload-Proof-Token header), the core format is protocol-agnostic,\n making it applicable to other protocols. Its JWT structure and\n claims model allow WPTs to be bound to different protocols and\n transports, including asynchronous or non-HTTP messaging systems such\n as Kafka and gRPC, or other future protocol bindings. This design\n enables receiving systems to verify identity, key possession, and\n message binding at the application layer even in environments where\n transport-layer identity (e.g., mutual TLS) is insufficient or\n unavailable.\n\n9.2.2. HTTP Message Signatures\n\n The WIMSE Workload-to-Workload Authentication with HTTP Signatures\n specification [WIMSE-HTTPSIG] defines an application-layer\n authentication profile built on the HTTP Message Signatures standard\n [HTTP-SIG]. It is one of the mechanisms WIMSE defines for\n authenticating workloads in HTTP-based interactions where transport-\n layer protections may be insufficient or unavailable. The protocol\n\nKasselman, et al. Expires 19 March 2027 [Page 12]\nInternet-Draft AIMS September 2026\n\n combines a workload's Workload Identity Token (WIT) (which binds the\n agent's identity to a public key) with HTTP Message Signatures (using\n the corresponding private key), thereby providing proof of possession\n and message integrity for individual HTTP requests and responses.\n This approach ensures end-to-end authentication and integrity even\n when traffic traverses intermediaries such as TLS proxies or load\n balancers that break transport-layer identity continuity. The\n profile mandates signing of some request components (e.g., method,\n request-target, content digest, and the WIT itself) and supports\n optional response signing. Note that @request-target covers only the\n request-target string (typically path + query) and not the method,\n scheme, or authority; those are only protected if separately covered\n (e.g., @method, @scheme, @authority).\n\n9.2.3. Limitations\n\n Unlike transport-layer authentication, application-layer\n authentication does not inherently provide channel binding to the\n underlying secure transport. As a result, implementations MUST\n consider the risk of message relay or replay if tokens or signed\n messages are accepted outside their intended context. Deployments\n typically mitigate these risks through short token lifetimes,\n audience restrictions, nonce or unique identifier checks, and binding\n authentication to specific requests or transaction parameters.\n\n10. Agent Authorization\n\n Agents act on behalf of a user, a system, or on their own behalf as\n shown in Figure 1 and need to obtain authorization when interacting\n with protected resources.\n\n10.1. Agent Mission\n\n An Agent receives a Mission from a User, a System, or another Agent.\n The Mission is the task or objective the Agent will pursue. It is\n typically expressed in natural language and may require decomposition\n as it is mapped from a broad objective into specific resource\n requirements and corresponding access requests. The translation of a\n mission into authorization requirements is expected to occur as a\n planning step before the Agent requests authorization. The process\n through which the mission is translated into authorization\n requriements is out of scope of this specification. Once the\n required resources and their associated authorization requirements\n are determined, the Agent SHOULD use the mechanisms described in this\n section to obtain access.\n\nKasselman, et al. Expires 19 March 2027 [Page 13]\nInternet-Draft AIMS September 2026\n\n10.2. Leverage OAuth 2.0 as a Delegation Authorization Framework\n\n The widely deployed OAuth 2.0 Authorization Framework\n [OAUTH-FRAMEWORK] is a mechanism for delegated authorization that\n enables an Agent to obtain limited access to a protected resource\n (e.g., a service or API), intermediated by an Authorization Server,\n often with the explicit approval of the authenticated User. An Agent\n uses OAuth 2.0-based mechanisms to obtain authorization from a User,\n a System, or on its own behalf. OAuth 2.0 defines a wide range of\n authorization grant flows that supports these scenarios. In these\n Oauth 2.0 flows, an Agent acts as an OAuth 2.0 Client to an OAuth 2.0\n Authorization Server, which receives the request, evaluate the\n authorization policy and returns an access token, which the Agent\n presents to the Resource Server (i.e. the protected resources such as\n the LLM or Tools in Figure 1, which can evaluate its authorization\n policy and complete the request.\n\n10.3. Use of OAuth 2.0 Access Tokens\n\n An OAuth access token represents the authorization granted to the\n Agent. In many deployments, access tokens are structured as JSON Web\n Tokens (JWTs) [OAUTH-ACCESSTOKEN-JWT], which include claims such as\n 'client_id', 'sub', 'aud', 'scope', and other attributes relevant to\n authorization. The access token includes the Agent identity as the\n 'client_id' claim as defined in Section 2.2 of\n [OAUTH-ACCESSTOKEN-JWT].\n\n When the Agent is acting on-behalf of another User or System, the\n User or System identifier is conveyed in the 'sub' claim as defined\n in Section 2.2 of [OAUTH-ACCESSTOKEN-JWT]. These identifiers MUST be\n used by resource servers protected by the OAuth 2.0 authorization\n service, along with other claims in the access token, to determine if\n access to a resource should be allowed. The access token typically\n includes additional claims to convey contextual, attestation-derived,\n or policy-related information that enables fine-grained access\n control. The resource server uses the access token and the\n information it contains along with other authorization systems (e.g.\n policy based, attribute based or role based authorization systems)\n when enforcing access control. JWT access tokens can be validated\n directly by resource servers while other formats that are opaque to\n the resource server can be validated through a mechanism that calls\n back to the authorization server (the mechanism is called\n introspection despite the word having nearly the opposite meaning).\n This framework supports both models and does not require a specific\n token format, provided that equivalent authorization semantics are\n maintained.\n\nKasselman, et al. Expires 19 March 2027 [Page 14]\nInternet-Draft AIMS September 2026\n\n A resource server in receipt of tokens opaque to it are able to\n obtain authorization and other information from the token through\n OAuth 2.0 Token Introspection [OAUTH-TOKEN-INTROSPECTION]. The\n introspection response provides the active state of the token and\n associated authorization attributes equivalent to those conveyed in\n structured tokens.\n\n10.4. Obtaining an OAuth 2.0 Access Token\n\n OAuth 2.0 defines a number authorization grant flows in support of\n different authorization scenarios. The appropriate flow depends on\n the specific authorization scenario and the nature of User\n involvement. The following subsections describe the most relevant\n flows for Agent authorization.\n\n10.4.1. User Delegates Authorization\n\n When a User delegates authorization to an Agent, the Authorization\n Code Grant as described in Section 4.1 of [OAUTH-FRAMEWORK] is the\n appropriate mechanism. This redirection-based flow involves an\n interactive authorization process, typically in a web browser, in\n which the user authenticates to the authorization server and\n explicitly approves the requested access. Users SHOULD be\n authenticated using phishing-resistant authentication mechanisms such\n as a passkey. Once the user has approved the request, the\n authorization server returns an authorization code to the Agent via\n the redirect.\n\n The Agent, acting as an OAuth client, then makes a token request to\n the authorization server to redeem the authorization code for an\n access token. When making this token request, the Agent\n authenticates itself directly to the authorization server using the\n credentials described in Section 7 with a compatible OAuth client\n authentication mechanism, and not with the use of static, long-lived\n client secrets. Compatible OAuth client authentication mechanisms\n are defined in [OAUTH-CLIENTAUTH-JWT], [OAUTH-CLIENTAUTH-MTLS] and\n [OAUTH-SPIFFE]. The OAuth client authentication step is distinct\n from, and occurs after, the user authentication and approval\n described above. The resulting access token reflects the\n authorization delegated to the Agent by the User and can be used by\n the Agent to access resources on behalf of the user. The use of\n OAuth negates the need for the Agent to have access to a User's\n credentials when accessing a resource on the User's behalf.\n\nKasselman, et al. Expires 19 March 2027 [Page 15]\nInternet-Draft AIMS September 2026\n\n10.4.2. Agent Obtains Own Authorization\n\n Agents obtaining access tokens on their own behalf can use the Client\n Credentials Grant as described in Section 4.4 of [OAUTH-FRAMEWORK] or\n the JWT Authorization Grant as described in Section 2.1 of\n [OAUTH-CLIENTAUTH-JWT]. When using the Client Credentials Grant, the\n Agent authenticates itself using the credentials described in\n Section 7 with a compatible OAuth client authentication mechanism\n listed in previous section, and not with the use of static, long-\n lived client secrets. When using the JWT Authorization Grant, the\n Agent will be identified in the subject of the JWT assertion.\n\n10.4.3. Agents Accessed by Systems or Other Agents\n\n Agents themselves can act in the role of an OAuth protected resource\n and be invoked by a System (e.g. a batch job or another Agent). The\n System obtains an access token using an appropriate mechanism and\n then invokes the Agent presenting the access token.\n\n10.4.4. OAuth 2.0 Security Best Practices\n\n The Best Current Practice for OAuth 2.0 Security as described in\n [OAUTH-BCP] are applicable when requesting and using access tokens.\n\n10.5. Risk Reduction with Transaction Tokens\n\n Resources servers, whether they are LLMs, Tools or Agents (in the\n Agent-to-Agent case) may be composed of multiple microservices that\n are invoked to complete a request. The access tokens presented to\n the Agent, LLM or Tools can typically be used with multiple\n transactions and consequently have broader scope than needed to\n complete any specific transaction. Passing the access token from one\n microservice to another within an invoked Agent, LLM or the Tools\n increases the risk of token theft and replay attacks. For example,\n an attacker may discover and access token passed between\n microservices in a log file or crash dump, exfiltrate it, and use it\n to invoke a new transaction with different parameters (e.g. increase\n the transaction amount, or invoke an unrelated call as part of\n executing a lateral move).\n\n To avoid passing access tokens between microservices, the Agent, LLM\n or Tools can exchange the received access token for a transaction\n token, as defined in the Transaction Token specification\n [OAUTH-TXN-TOKENS]. The transaction token allows for identity and\n authorization information to be passed along the internal call chain\n of microservices. The transaction token issuer enriches the\n transaction token with context of the caller that presented the\n access token (e.g. IP address, etc.), transaction context\n\nKasselman, et al. Expires 19 March 2027 [Page 16]\nInternet-Draft AIMS September 2026\n\n (transaction amount), identity information and a unique transaction\n identifier. This results in a downscoped token that is bound to a\n specific transaction and cannot be used as an access token, with\n another transaction, or within the same transaction with modified\n transaction details (e.g. change in transaction amount). Transaction\n tokens are typically short-lived, further limiting the risk in case\n they are obtained by an attacker by limiting the time window during\n which these tokens will be accepted.\n\n A transaction token MAY be used to obtain an access token to call\n another service (e.g. another Agent, Tool or LLM) by using OAuth 2.0\n Token Exchange as defined in [OAUTH-TOKEN-EXCHANGE].\n\n10.6. Cross Domain Access\n\n Agents often require access to resources that are protected by\n different OAuth 2.0 authorization servers. When the components in\n Figure 1 are protected by different logical authorization servers, an\n Agent SHOULD use OAuth Identity and Authorization Chaining Across\n Domains as defined in [OAUTH-ID-CHAIN], or a derived specification\n such as the Identity Assertion JWT Authorization Grant\n [OAUTH-JWT-ASSERTION] or , Transaction Token Authorization Grant\n Profile for OAuth Identity and Authorization Chaining\n [OAUTH-TXN-ASSERTION], to obtain an access token from the relevant\n authorization servers. The agent first exchanges its current access\n token or transaction token for a JWT authorization grant (Section 2.3\n of [OAUTH-ID-CHAIN]) and then presents that grant to obtain an access\n token for the target resource (Section 2.4 of [OAUTH-ID-CHAIN]).\n\n When using the Identity Assertion JWT Authorization Grant\n [OAUTH-JWT-ASSERTION], the identity assertion (e.g. the OpenID\n Connect ID Token or SAML assertion) for the target end-user is used\n to obtain a JWT assertion as described in Section 4.3 of\n [OAUTH-JWT-ASSERTION], which is then used to obtain an access token\n as described in Section 4.4 of [OAUTH-JWT-ASSERTION].\n\n OAuth Identity and Authorization Chaining Across Domains\n ([OAUTH-ID-CHAIN]) provides a general mechanism for obtaining cross-\n domain access that can be used whether an identity assertion like a\n SAML or OpenID Connect token is available or not. The Identity\n Assertion JWT Authorization Grant [OAUTH-JWT-ASSERTION] is optimized\n for cases where an identity assertion like a SAML or OpenID Connect\n token is available from an identity provider that is trusted by all\n the OAuth authorization servers as it removes the need for the user\n to re-authenticate. This is typically used within enterprise\n deployments to simplify authorization delegation for multiple\n software-as-a-service offerings.\n\nKasselman, et al. Expires 19 March 2027 [Page 17]\nInternet-Draft AIMS September 2026\n\n10.7. Human in the Loop\n\n An OAuth authorization server MAY conclude that the level of access\n requested by an Agent requires explicit user confirmation. In such\n cases the authorization server SHOULD either decline the request or\n obtain additional authorization from the User. An Agent, acting as\n an OAuth client, can use the OpenID Client Initiated Backchannel\n Authentication (CIBA) protocol ([OpenIDConnect.CIBA]). This triggers\n an out-of-band interaction allowing the user to approve or deny the\n requested operation without exposing credentials to the agent (for\n example a push notification requesting the user to approve a request\n through an authenticator application on their mobile device).\n\n Interactive agent frameworks may also solicit user confirmation\n directly during task execution (for example tool invocation approval\n or parameter confirmation). Such interactions do not by themselves\n constitute authorization and MUST be bound to a verifiable\n authorization grant issued by the authorization server. The agent\n SHOULD therefore translate user confirmation into an OAuth\n authorization event (e.g., step-up authorization via CIBA) before\n accessing protected resources.\n\n This model aligns with user-solicitation patterns such as those\n described by the Model Context Protocol ([MCP]), where an agent\n pauses execution and requests user confirmation before performing\n sensitive actions. The final authorization decision remains with the\n authorization server, and the agent MUST NOT treat local UI\n confirmation alone as sufficient authorization.\n\n *Note:* Additional specification or design work may be needed to\n define how out-of-band interactions with the User occur at different\n stages of execution. CIBA itself only accounts for client\n initiation, which doesn't map well to cases that envision the need\n for User confirmation to occur mid-execution.\n\n10.8. Tool-to-Service Access\n\n Tools expose interfaces to underlying services and resources. Access\n to the Tools can be controlled by OAuth and augmented by policy,\n attribute or role based authorization systems (amongst others). If\n the Tools are implemented as one or more microservices, it should use\n transaction tokens to reduce risk as described in Section 10.5 to\n avoid passing access tokens around within the Tool implementation.\n\n Access from the Tools to the resources and services MAY be controlled\n through a variety of authorization mechanisms, including OAuth. If\n access is controlled through OAuth, the Tools can use OAuth 2.0 Token\n Exchange as defined in [OAUTH-TOKEN-EXCHANGE] to exchange the access\n\nKasselman, et al. Expires 19 March 2027 [Page 18]\nInternet-Draft AIMS September 2026\n\n token it received for a new access token to access the resource or\n service in question. When the Tool needs access to a resource\n protected by an authorization server other than the Tool's own\n authorization server, the OAuth Identity and Authorization Chaining\n Across Domains ([OAUTH-ID-CHAIN]) can be used to obtain an access\n token from the authorization server protecting that resource.\n\n *Note:* It is an anti-pattern for Tools to forward access tokens it\n received from the Agent to Services or Resources. It increases the\n risk of credential theft and lateral attacks.\n\n10.9. Privacy Considerations\n\n Authorization tokens may contain user identifiers, agent identifiers,\n audience restrictions, transaction details, and contextual\n attributes. Deployments SHOULD minimize disclosure of personally\n identifiable or sensitive information in tokens and prefer audience-\n restricted and short-lived tokens. Where possible, opaque tokens\n with introspection SHOULD be preferred when claim minimization is\n required.\n\n Agents SHOULD request only the minimum scopes and authorization\n details necessary to complete a task. As recommended in [OAUTH-BCP],\n resource servers avoid logging full tokens and instead log token\n identifiers or hashes. When authorization context is propagated\n across services, derived or down-scoped tokens (such as transaction\n tokens) SHOULD be used to reduce correlation and replay risk.\n\n Implementations MUST ensure that user identity information delegated\n to agents is not exposed to unrelated services and that cross-domain\n authorization exchanges only disclose information required for the\n target authorization decision.\n\n10.10. OAuth 2.0 Discovery in Dynamic Environments\n\n In dynamic Agent deployments (e.g., ephemeral workloads, multi-tenant\n services, and frequently changing endpoint topology), Agents and\n other participants MAY use OAuth discovery mechanisms to reduce\n static configuration and to bind runtime decisions to verifiable\n metadata.\n\nKasselman, et al. Expires 19 March 2027 [Page 19]\nInternet-Draft AIMS September 2026\n\n10.10.1. Authorization Server Capability Discovery\n\n An Agent that needs to obtain tokens can discover authorization\n server endpoints and capabilities using OAuth 2.0 Authorization\n Server Metadata [OAUTH-SERVER-METADATA] and/or OpenID Connect\n Discovery [OpenIDConnect.Discovery]. This allows the Agent to learn\n the authorization server issuer identifier, authorization and token\n endpoints, supported grant types, client authentication methods,\n signing keys (via jwks_uri), and other relevant capabilities without\n preconfiguring them.\n\n10.10.2. Protected Resource Capability Discovery\n\n When an Agent is invoking a Tool, the Agent MAY use OAuth 2.0\n Protected Resource Metadata [OAUTH-RESOURCE-METADATA] to discover how\n the resource is protected, including the resource identifier and the\n applicable Authorization Server(s) that protects Tool access. This\n enables an Agent to select the correct issuer/audience and token\n acquisition flow at runtime, even when resources are deployed or\n moved dynamically.\n\n A Tool that attempts to access and OAuth protected resource MAY use\n OAuth 2.0 Protected Resource Metadata [OAUTH-RESOURCE-METADATA] in a\n similar way as an Agent. Similarly, a System may use\n [OAUTH-RESOURCE-METADATA] when accessing an Agent.\n\n10.10.3. Client Capability Discovery\n\n Other actors (e.g., Authorization Servers, registrars, or policy\n systems) may need to learn about any entities (System, Agent, Tool)\n that acts as OAuth clients. Where supported, they MAY use Client ID\n Metadata Documents [OAUTH-CLIENT-METADATA], which allow a client to\n host its metadata at a URL-valued client_id so that the relying party\n can retrieve client properties (e.g., redirect URIs, display\n information, and other registered client metadata) without prior\n bilateral registration.\n\n As an alternative, entities acting as OAuth clients MAY register\n their capabilities with authorization servers as defined in the OAuth\n 2.0 Dynamic Client Registration Protocol [OAUTH-REGISTRATION].\n\n11. Agent Monitoring, Observability and Remediation\n\n Because agents may perform sensitive actions autonomously or on\n behalf of users, deployments MUST maintain sufficient monitoring and\n observability to reconstruct agent behavior and authorization context\n after execution. Observability is therefore a security control, not\n solely an operational feature.\n\nKasselman, et al. Expires 19 March 2027 [Page 20]\nInternet-Draft AIMS September 2026\n\n Any participant in the system, including the Agent, Tool, System, LLM\n or other resources and service MAY subscribe to change notifications\n using eventing mechanisms such as the OpenID Shared Signals Framework\n [SSF] with either the Continuous Access Evaluation Profile [CAEP] or\n Risk Incident Sharing and Coordination [RISC] to receive security and\n authorization-relevant signals. Upon receipt of a relevant signal\n (e.g., session revoked, risk level change, subject disabled, token\n replay suspected, risk elevated), the recipient SHOULD remediate by\n attenuating access, such as terminating local sessions, discarding\n cached tokens, re-acquiring tokens with updated constraints, reducing\n privileges, or re-running policy evaluation before continuing to\n allow access. Recipients of such signals MUST ensure that revoked or\n downgraded authorization is enforced without undue delay. Cached\n authorization decisions and tokens that are no longer valid MUST NOT\n continue to be used after a revocation or risk notification is\n received.\n\n To support detection, investigation, and accountability, deployments\n MUST produce durable audit logs covering authorization decisions and\n subsequent remediations. Audit records MUST be tamper-evident and\n retained according to the security policy of the deployment.\n\n At a minimum, audit events MUST record:\n\n * authenticated agent identifier\n\n * delegated subject (user or system), when present\n\n * resource or tool being accessed\n\n * action requested and authorization decision\n\n * timestamp and transaction or request correlation identifier\n\n * posture assessment or risk state influencing the decision\n\n * remediation or revocation events and their cause\n\n Monitoring / Observability systems SHOULD correlate events across\n Agents, Tools, Services, Resources and LLMs to detect misuse patterns\n such as replay, confused deputy behavior, privilege escalation, or\n unexpected action sequences.\n\n End-to-end audit is enabled when Agents, Users, Systems, LLMs, Tools,\n services and resources have stable, verifiable identifiers that allow\n auditors to trace \"which entity did what, using which authorization\n context, and why access changed over time.\"\n\nKasselman, et al. Expires 19 March 2027 [Page 21]\nInternet-Draft AIMS September 2026\n\n Implementations SHOULD provide operators the ability to reconstruct a\n complete execution chain of an agent task, including delegated\n authority, intermediate calls, and resulting actions across service\n boundaries.\n\n12. Agent Authentication and Authorization Policy\n\n The configuration and runtime parameters for Agent Identifiers\n Section 6, Agent Credentials Section 7, Agent Credential Provisioning\n Section 8, Agent Authentication Section 9, Agent Authorization\n Section 10 and Agent Monitoring, Observability and Remediation\n Section 11 collectively constitute the authentication and\n authorization policy within which the Agent operates.\n\n Because these parameters are highly deployment and risk-model-\n specific (and often reflect local governance, regulatory, and\n operational constraints), the policy model and document format are\n out of scope for this framework and are not recommended as a target\n for standardization within this specification. Implementations MAY\n represent policy in any suitable “policy-as-code” or configuration\n format (e.g., JSON/YAML), provided it is versioned, reviewable, and\n supports consistent evaluation across the components participating in\n the end-to-end flow.\n\n13. Agent Compliance\n\n Compliance for Agent-based systems SHOULD be assessed by auditing\n observed behavior and recorded evidence (logs, signals, and\n authorization decisions) against the deployment’s Agent\n Authentication and Authorization Policy Section 12. Since compliance\n criteria are specific to individual deployments, organizations,\n industries and jurisdictions, they are out of scope for this\n framework though implementers SHOULD ensure strong observability and\n accountable governance, subject to their specific business needs.\n\n14. Security Considerations\n\n This document composes existing specifications to enable\n authentication and authorization between AI agents. The security\n considerations of each referenced specification apply in full.\n\nKasselman, et al. Expires 19 March 2027 [Page 22]\nInternet-Draft AIMS September 2026\n\n In addition to the guidance included in existing specifications,\n additional security best practices and profiles have been developed\n for the Oauth protocol famility. The OAuth 2.0 Security Best Current\n Practice [OAUTH-BCP] which captures current guidance on threats and\n mitigations that have emerged since the original OAuth 2.0\n specifications were published. The FAPI 2.0 Security Profile\n [OpenIDConnect.FAPI] defines a high-assurance profile of OAuth 2.0\n suitable for high security applications.\n\n15. Privacy Considerations\n\n This document composes existing specifications to enable\n authentication and authorization between AI agents.\n\n In addition to the the privacy considerations in Section 10.9, the\n privacy considerations in each referenced specification apply in\n full.\n\n16. IANA Considerations\n\n This document has no IANA actions.\n\n17. Acknowledgments\n\n The authors would like to thank:\n\n * Sean O'Dell for providing valuable input and feedback on this\n work.\n\n * Karl McGuinness for his blog posts on mission shaping as a pre-\n cursor to authorization [MissionShaping]\n\n18. References\n\n18.1. Normative References\n\n [A2A] \"Agent2Agent (A2A) Protocol\", n.d.,\n .\n\n [ACP] \"Agentic Commerce Protocol\", n.d.,\n .\n\n [AP2] \"Agent Payments Protocol (AP2)\", n.d.,\n .\n\n [CAEP] \"OpenID Continuous Access Evaluation Profile 1.0\", n.d.,\n .\n\nKasselman, et al. Expires 19 March 2027 [Page 23]\nInternet-Draft AIMS September 2026\n\n [HTTP-SIG] Backman, A., Ed., Richer, J., Ed., and M. Sporny, \"HTTP\n Message Signatures\", RFC 9421, DOI 10.17487/RFC9421,\n February 2024, .\n\n [MCP] \"Model Context Protocol\", n.d.,\n .\n\n [OAUTH-ACCESSTOKEN-JWT]\n Bertocci, V., \"JSON Web Token (JWT) Profile for OAuth 2.0\n Access Tokens\", RFC 9068, DOI 10.17487/RFC9068, October\n 2021, .\n\n [OAUTH-BCP]\n Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,\n \"Best Current Practice for OAuth 2.0 Security\", BCP 240,\n RFC 9700, DOI 10.17487/RFC9700, January 2025,\n .\n\n [OAUTH-CLIENT-METADATA]\n Parecki, A. and E. Smith, \"OAuth Client ID Metadata\n Document\", Work in Progress, Internet-Draft, draft-ietf-\n oauth-client-id-metadata-document-02, 6 July 2026,\n .\n\n [OAUTH-CLIENTAUTH-JWT]\n Jones, M., Campbell, B., and C. Mortimore, \"JSON Web Token\n (JWT) Profile for OAuth 2.0 Client Authentication and\n Authorization Grants\", RFC 7523, DOI 10.17487/RFC7523, May\n 2015, .\n\n [OAUTH-CLIENTAUTH-MTLS]\n Campbell, B., Bradley, J., Sakimura, N., and T.\n Lodderstedt, \"OAuth 2.0 Mutual-TLS Client Authentication\n and Certificate-Bound Access Tokens\", RFC 8705,\n DOI 10.17487/RFC8705, February 2020,\n .\n\n [OAUTH-FRAMEWORK]\n Hardt, D., Ed., \"The OAuth 2.0 Authorization Framework\",\n RFC 6749, DOI 10.17487/RFC6749, October 2012,\n .\n\nKasselman, et al. Expires 19 March 2027 [Page 24]\nInternet-Draft AIMS September 2026\n\n [OAUTH-ID-CHAIN]\n Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins,\n M. J., Campbell, B., and A. Parecki, \"OAuth Identity and\n Authorization Chaining Across Domains\", Work in Progress,\n Internet-Draft, draft-ietf-oauth-identity-chaining-17, 19\n July 2026, .\n\n [OAUTH-JWT-ASSERTION]\n Parecki, A., McGuinness, K., and B. Campbell, \"Identity\n Assertion JWT Authorization Grant\", Work in Progress,\n Internet-Draft, draft-ietf-oauth-identity-assertion-authz-\n grant-04, 21 May 2026,\n .\n\n [OAUTH-REGISTRATION]\n Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and\n P. Hunt, \"OAuth 2.0 Dynamic Client Registration Protocol\",\n RFC 7591, DOI 10.17487/RFC7591, July 2015,\n .\n\n [OAUTH-RESOURCE-METADATA]\n Jones, M.B., Hunt, P., and A. Parecki, \"OAuth 2.0\n Protected Resource Metadata\", RFC 9728,\n DOI 10.17487/RFC9728, April 2025,\n .\n\n [OAUTH-SERVER-METADATA]\n Jones, M., Sakimura, N., and J. Bradley, \"OAuth 2.0\n Authorization Server Metadata\", RFC 8414,\n DOI 10.17487/RFC8414, June 2018,\n .\n\n [OAUTH-SPIFFE]\n Schwenkschuster, A., Kasselman, P., Rose, S., Thorgersen,\n S., and N. Cam-Winget, \"OAuth SPIFFE Client\n Authentication\", Work in Progress, Internet-Draft, draft-\n ietf-oauth-spiffe-client-auth-02, 15 June 2026,\n .\n\n [OAUTH-TOKEN-EXCHANGE]\n Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,\n and C. Mortimore, \"OAuth 2.0 Token Exchange\", RFC 8693,\n DOI 10.17487/RFC8693, January 2020,\n .\n\nKasselman, et al. Expires 19 March 2027 [Page 25]\nInternet-Draft AIMS September 2026\n\n [OAUTH-TOKEN-INTROSPECTION]\n Richer, J., Ed., \"OAuth 2.0 Token Introspection\",\n RFC 7662, DOI 10.17487/RFC7662, October 2015,\n .\n\n [OAUTH-TXN-ASSERTION]\n Fletcher, G., Kasselman, P., and S. O'Dell, \"Transaction\n Token Authorization Grant Profile for OAuth Identity and\n Authorization Chaining\", Work in Progress, Internet-Draft,\n draft-fletcher-transaction-token-chaining-profile-02, 6\n July 2026, .\n\n [OAUTH-TXN-TOKENS]\n Tulshibagwale, A., Fletcher, G., and P. Kasselman,\n \"Transaction Tokens\", Work in Progress, Internet-Draft,\n draft-ietf-oauth-transaction-tokens-11, 30 July 2026,\n .\n\n [OpenIDConnect.AuthZEN]\n Gazitt, O., Ed., Brossard, D., Ed., and A. Tulshibagwale,\n Ed., \"Authorization API 1.0\", 2026,\n .\n\n [OpenIDConnect.CIBA]\n \"OpenID Connect Client-Initiated Backchannel\n Authentication Flow - Core 1.0\", n.d.,\n .\n\n [OpenIDConnect.Discovery]\n \"OpenID Connect Discovery 1.0\", n.d.,\n .\n\n [OpenIDConnect.FAPI]\n \"FAPI 2.0 Security Profile\", n.d.,\n .\n\n [RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate\n Requirement Levels\", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n .\n\nKasselman, et al. Expires 19 March 2027 [Page 26]\nInternet-Draft AIMS September 2026\n\n [RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, .\n\n [RISC] \"OpenID Risk Incident Sharing and Coordination Profile\n 1.0\", n.d.,\n .\n\n [SPIFFE] \"Secure Production Identity Framework for Everyone\", n.d.,\n .\n\n [SPIFFE-ID]\n \"SPIFFE-ID\", n.d.,\n .\n\n [SPIFFE-JWT-SVID]\n \"The JWT SPIFFE Verifiable Identity Document\", n.d.,\n .\n\n [SPIFFE-WIT-SVID]\n \"The WIT SPIFFE Verifiable Identity Document\", n.d.,\n .\n\n [SPIFFE-X509-SVID]\n \"The X.509 SPIFFE Verifiable Identity Document\", n.d.,\n .\n\n [SSF] \"OpenID Shared Signals Framework Specification 1.0\", n.d.,\n .\n\n [WIMSE-ARCH]\n Salowey, J. A., Rosomakho, Y., and H. Tschofenig,\n \"Workload Identity in a Multi System Environment (WIMSE)\n Architecture\", Work in Progress, Internet-Draft, draft-\n ietf-wimse-arch-08, 6 July 2026,\n .\n\nKasselman, et al. Expires 19 March 2027 [Page 27]\nInternet-Draft AIMS September 2026\n\n [WIMSE-CRED]\n Campbell, B., Salowey, J. A., Schwenkschuster, A.,\n Sheffer, Y., and Y. Rosomakho, \"WIMSE Workload\n Credentials\", Work in Progress, Internet-Draft, draft-\n ietf-wimse-workload-creds-02, 2 July 2026,\n .\n\n [WIMSE-HTTPSIG]\n Salowey, J. A. and Y. Sheffer, \"WIMSE Workload-to-Workload\n Authentication with HTTP Signatures\", Work in Progress,\n Internet-Draft, draft-ietf-wimse-http-signature-06, 4\n August 2026, .\n\n [WIMSE-ID] Rosomakho, Y. and J. A. Salowey, \"Workload Identifier\",\n Work in Progress, Internet-Draft, draft-ietf-wimse-\n identifier-03, 6 July 2026,\n .\n\n [WIMSE-WPT]\n Campbell, B. and A. Schwenkschuster, \"WIMSE Workload Proof\n Token\", Work in Progress, Internet-Draft, draft-ietf-\n wimse-wpt-02, 27 August 2026,\n .\n\n18.2. Informative References\n\n [MissionShaping]\n McGuinness, K., \"The Mission Shaping Problem\", 2026,\n .\n\nAppendix A. Document History\n\n [[ To be removed from the final specification ]] -03\n\n * Editorial updates\n\n * Clarify relationship between WIMSE and SPIFFE credentials\n (https://github.com/PieterKas/agent2agent-auth-framework/\n issues/136)\n\n * Clarify that LLMs should not have access to Agent credentials:\n https://github.com/PieterKas/agent2agent-auth-framework/issues/127\n\nKasselman, et al. Expires 19 March 2027 [Page 28]\nInternet-Draft AIMS September 2026\n\n * Update use of normative language (https://github.com/PieterKas/\n agent2agent-auth-framework/issues/123)\n\n -03\n\n * Include reference to CIBA (see https://github.com/PieterKas/\n agent2agent-auth-framework/issues/131)\n\n -02\n\n * Add Aaron Parecki from Okta as co-author.\n\n * Add reference to phishing resistent credentials (e.g. FIDO\n passkeys/authenticators) - see https://github.com/PieterKas/\n agent2agent-auth-framework/issues/106\n\n * Fold attestation section into provosioning section. Change\n terminology to posture management.\n\n * Clarify Oauth authentication mechanisms when an Agent acts as and\n OAuth client.\n\n * Update Security Considerations section\n\n * Add section on Agent Mission (see issue\n https://github.com/PieterKas/agent2agent-auth-framework/\n issues/107)\n\n -01\n\n * Add Nick Steele from OpenAI as co-author.\n\n -00\n\nAuthors' Addresses\n\n Pieter Kasselman\n Defakto Security\n Email: pieter@defakto.security\n\n Jean-François Lombardo\n AWS\n Email: jeffsec@amazon.com\n\n Yaroslav Rosomakho\n Zscaler\n\nKasselman, et al. Expires 19 March 2027 [Page 29]\nInternet-Draft AIMS September 2026\n\n Email: yrosomakho@zscaler.com\n\n Brian Campbell\n Ping Identity\n Email: bcampbell@pingidentity.com\n\n Nick Steele\n OpenAI\n Email: steele@openai.com\n\n Aaron Parecki\n Okta\n Email: aaron@parecki.com\n\nKasselman, et al. Expires 19 March 2027 [Page 30]\n```\n\n", "url": "https://wpnews.pro/news/ai-identity-management-system", "canonical_source": "https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/00/", "published_at": "2026-10-23 12:28:11+00:00", "updated_at": "2026-10-23 12:42:21.294514+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-policy", "artificial-intelligence"], "entities": ["IETF", "WIMSE Working Group", "Pieter Kasselman", "Defakto Security", "AWS", "Zscaler", "Ping Identity", "OpenAI"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/ai-identity-management-system", "markdown": "https://wpnews.pro/news/ai-identity-management-system.md", "text": "https://wpnews.pro/news/ai-identity-management-system.txt", "jsonld": "https://wpnews.pro/news/ai-identity-management-system.jsonld"}}