AI Agent Authentication and Authorization (IETF Internet-Draft)

The Internet Engineering Task Force (IETF) has published an Internet-Draft titled 'AI Agent Authentication and Authorization' (draft-klrc-aiagent-auth-03), proposing best practices for authenticating and authorizing AI agent interactions by leveraging existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0. The draft, authored by Kasselman et al., expires on 7 January 2027, and aims to provide a framework to identify gaps and guide future standardization efforts.

| Internet-Draft | AI-Auth | July 2026 | | Kasselman, et al. | Expires 7 January 2027 | Page | - Workgroup: - Network Working Group - Internet-Draft: - draft-klrc-aiagent-auth-03 - Published: - Intended Status: - Informational - Expires: AI Agent Authentication and Authorization Abstract abstract This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments WIMSE architecture and OAuth 2.0 family of specifications. 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. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. ¶ section-abstract-1 About This Document name-about-this-document This note is to be removed before publishing as an RFC. ¶ section-note.1-1 The latest revision of this draft can be found at https://PieterKas.github.io/agent2agent-auth-framework/draft-klrc-aiagent-auth.html https://PieterKas.github.io/agent2agent-auth-framework/draft-klrc-aiagent-auth.html . Status information for this document may be found at https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/ https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/ . ¶ section-note.1-2 Source for this draft and an issue tracker can be found at https://github.com/PieterKas/agent2agent-auth-framework https://github.com/PieterKas/agent2agent-auth-framework . ¶ section-note.1-3 Status of This Memo name-status-of-this-memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. ¶ section-boilerplate.1-1 Internet-Drafts are working documents of the Internet Engineering Task Force IETF . Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/ https://datatracker.ietf.org/drafts/current/ . ¶ section-boilerplate.1-2 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." ¶ section-boilerplate.1-3 This Internet-Draft will expire on 7 January 2027. ¶ section-boilerplate.1-4 Copyright Notice name-copyright-notice Copyright c 2026 IETF Trust and the persons identified as the document authors. All rights reserved. ¶ section-boilerplate.2-1 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents https://trustee.ietf.org/license-info https://trustee.ietf.org/license-info in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. ¶ section-boilerplate.2-2 1. section-1 Introduction name-introduction The rapid emergence of AI agents as autonomous workloads has sparked considerable innovation in authentication and authorization approaches. However, many of these efforts develop solutions in isolation, often reinventing existing mechanisms unaware of applicable prior art. This fragmentation risks creating incompatible implementations, duplicated development effort, and missed opportunities to leverage decades of established identity and authorization standards. ¶ section-1-1 This document aims to help close that gap by providing a comprehensive model demonstrating how existing, well-established standards and some emergent specifications can be composed and applied to solve agent authentication and authorization challenges. Rather than proposing new protocols, this work focuses on integrating proven standards into a coherent framework tailored to the specific requirements of AI agent workloads. ¶ section-1-2 By doing so, this document serves two complementary goals: ¶ section-1-3 - Consolidation of prior art : It establishes a baseline by showing how existing standards address the core identity, authentication, authorization, monitoring and observability needs of agent-based systems. Implementers and standards developers can reference this framework to avoid redundant work and ensure interoperability. ¶ section-1-4.1.1 - Foundation for future work : As the agent ecosystem matures, having such a framework aids in identifying gaps and clarifies where extensions or profiles of existing standards are needed. This provides a foundation for more focused standardization efforts in areas needing novel work rather than variations of existing approaches. ¶ section-1-4.2.1 2. section-2 Document Status name-document-status This document profiles existing standards and emerging specifications from the IETF, CNCF, and OpenID Foundation, as well as third-party protocols and mechanisms, for the AI agent use case. It defines best current practices for combining these and identifies new requirements specific to agent authentication and authorization. ¶ section-2-1 3. section-3 Conventions and Definitions name-conventions-and-definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC2119 RFC8174 RFC8174 when, and only when, they appear in all capitals, as shown here. ¶ section-3-1 4. section-4 Agents are workloads name-agents-are-workloads An Agent is a workload that iteratively interacts with a Large Language Model LLM and a set of Tools, Services and Resources. An agent performs its operations until a terminating condition, determined either by the LLM or by the agent's internal logic, is reached. It may receive input from a user, or act autonomously. Figure 1 fig-ai-agent-workload shows a conceptual model of the AI Agent as a workload and illustrates the high-level interaction model between the User or System, the AI Agent, the Large Language Model LLM , Tools, Services, and Resources. ¶ section-4-1 In this document, Tools, Services, and Resources are treated as a single category of external endpoints that an agent invokes or interacts with to complete a task. Communication within or between Tools, Services, and Resources is out of scope. ¶ section-4-2 - Optional: The User or System e.g. a batch job or another Agent provides an initial request or instruction to the AI Agent. ¶ section-4-4.1.1 - The AI Agent provides the available context to the LLM. Context is implementation, and deployment, specific and may include User or System input, system prompts, Tool descriptions, prior Tool, Service and Resource outputs, and other relevant state. ¶ section-4-4.2.1 - The LLM returns output to the AI Agent facilitating selection of Tools, Services or Resources to invoke. ¶ section-4-4.3.1 - The AI Agent invokes one or more external endpoints of selected Tools, Services or Resources. A Tool endpoint may itself be implemented by another AI agent. ¶ section-4-4.4.1 - The external endpoint of the Tools, Services or Resources returns a result of the operation to the AI Agent, which may send the information as additional context to the Large Language Model, repeating steps 2-5 until the exit condition is reached and the task is completed. ¶ section-4-4.5.1 - Optional: Once the exit condition is reached in step 5, the AI Agent may return a response to the User or System. The AI Agent may also return intermediate results or request additional input. ¶ section-4-4.6.1 As shown in Figure 1 fig-ai-agent-workload , the AI agent is a workload that needs an identifier and credentials so it can be authenticated by the Tools, Services, Resources, Large Language Model, System and the User via the underlying operating system or platform, similar to existing applications and services . Once authenticated, these parties determine if the AI Agent is authorized to access the requested Large Language Model, Tools, Services or Resources. If the AI Agent is acting on behalf of a User or System, the User or System needs to delegate authority to the AI Agent, and the User or System context is preserved and used as input to authorization decisions and recorded in audit trails. ¶ section-4-5 This document describes how AI Agents should leverage existing standards defined by SPIFFE SPIFFE SPIFFE , WIMSE, OAuth and OpenID SSF SSF SSF . ¶ section-4-6 5. section-5 Agent Identity Management System name-agent-identity-management-s This document defines the term Agent Identity Management System AIMS as a conceptual model describing the set of functions required to establish, maintain, and evaluate the identity and permissions of an agent workload. AIMS does not refer to a single product, protocol, or deployment architecture. AIMS may be implemented by one component or distributed across multiple systems such as identity providers, provisioning services, authorization servers, policy engines, and runtime enforcement points . ¶ section-5-1 An Agent Identity Management System ensures that the right Agent has access to the right resources and tools at the right time for the right reason. An Agent identity management system depends on the following components to achieve its goals: ¶ section-5-2 - Agent Identifiers: Unique identifier assigned to every Agent. ¶ section-5-3.1.1 - Agent Credentials: Cryptographic binding between the Agent Identifier and attributes of the Agent. ¶ section-5-3.2.1 - Agent Credential Provisioning: The mechanism for provisioning credentials to the agent at runtime. ¶ section-5-3.3.1 - Agent Authentication: Protocols and mechanisms used by the Agent to authenticate itself to Large Language Models or Tools resource or server in the system. ¶ section-5-3.4.1 - Agent Authorization: Protocols and systems used to determine if an Agent is allowed to access a Large Language Model or Tool resource or server . ¶ section-5-3.5.1 - Agent Observability and Remediation: Protocols and mechanisms to dynamically modify the authorization decisions based on observed behavior and system state. ¶ section-5-3.6.1 - Agent Authentication and Authorization Policy: The configuration and rules for each of the Agent Identity Management System. ¶ section-5-3.7.1 - Agent Compliance: Measurement of the state and functioning of the system against the stated policies. ¶ section-5-3.8.1 The components form a logical stack in which higher layers depend on guarantees provided by lower layers, as illustrated in Figure 2 fig-agent-identity-management-system . ¶ section-5-4 6. section-6 Agent Identifier name-agent-identifier Agents MUST be uniquely identified in order to support authentication, authorization, auditing, and delegation. ¶ section-6-1 The Workload Identity in Multi-System Environments WIMSE identifier as defined by WIMSE-ID WIMSE-ID is the primary identifier for agents in this framework. ¶ section-6-2 A WIMSE identifier is a URI that uniquely identifies a workload within a trust domain. Authorization decisions, delegation semantics, and audit records rely on this identifier remaining stable for the lifetime of the workload identity. ¶ section-6-3 The Secure Production Identity Framework for Everyone SPIFFE SPIFFE identifier is a widely deployed and operationally mature instance of the WIMSE identifier model WIMSE-ID WIMSE-ID . A SPIFFE identifier SPIFFE-ID SPIFFE-ID is a URI in the form of spiffe://<trust-domain /<path that uniquely identifies a workload within a trust domain. ¶ section-6-4 An agent participating in this framework MUST be assigned exactly one WIMSE identifier, which MAY be a SPIFFE ID. ¶ section-6-5 7. section-7 Agent Credentials name-agent-credentials Agents MUST possess credentials that provide a cryptographic binding to the agent identifier. These credentials are considered primary credentials that are provisioned at runtime. An identifier alone is insufficient unless it can be verified to be controlled by the communicating agent through a cryptographic binding. ¶ section-7-1 WIMSE defines two credential formats in WIMSE-CRED WIMSE-CRED : the Workload Identity Token WIT and the transport-layer X.509 Workload Identity Certificate WIC , both of which bind a cryptographic key to a workload identifier for use in authentication. SPIFFE defines three credential formats: the X.509-SVID SPIFFE-X509-SVID SPIFFE-X509-SVID , WIT-SVID SPIFFE-WIT-SVID SPIFFE-WIT-SVID , and JWT-SVID SPIFFE-JWT-SVID SPIFFE-JWT-SVID . X.509-SVID is compatible with WIC, while WIT-SVID profiles WIT. JWT-SVIDs are short-lived bearer credentials used for JWT-based authentication. The choice of credential format depends on the deployment’s trust model and integration requirements. ¶ section-7-2 Agent credentials SHOULD be short-lived to minimize the risk of credential theft, MUST include an explicit expiration time after which it is no longer accepted, and MAY carry additional attributes relevant to the agent for example trust domain, attestation evidence, or workload metadata . ¶ section-7-3 Deployments can improve the assurance of agent identity by protecting private keys using hardware-backed or isolated cryptographic storage such as TPMs, secure enclaves, or platform security modules when such capabilities are available. These mechanisms reduce key exfiltration risk but are not required for interoperability. ¶ section-7-4 In some cases, agents MAY need secondary credentials to access a proprietary or legacy environment that is not compatible with the X.509, JWT or WIT it is provisioned with. In these cases an agent MAY exchange their primary credentials through a credential exchange mechanisms e.g., OAuth 2.0 Token Exchange OAUTH-TOKEN-EXCHANGE OAUTH-TOKEN-EXCHANGE , Transaction Tokens OAUTH-TXN-TOKENS OAUTH-TXN-TOKENS or Workload Identity Federation . This allows an agent to obtain a credential targeted to a specific environment by leveraging the primary credential in its possession. ¶ section-7-5 Note : Static API keys are an antipattern for agent identity. They are bearer artifacts that are not cryptographically bound, do not convey identity, are typically long-lived and are operationally difficult to rotate, making them unsuitable for secure agent authentication or authorization. ¶ section-7-6 8. section-8 Agent Credential Provisioning name-agent-credential-provisioni Agent credential provisioning refers to the runtime issuance, renewal, lifecycle state and rotation of the credentials an agent uses to authenticate and authorize itself to other agents. Agents may be provisioned with one or more credential types as described in Section 7 agent credentials . Unlike static secrets, agent credentials are provisioned dynamically and are intentionally short-lived, eliminating the operational burden of manual expiration management and reducing the impact of credential compromise. ¶ section-8-1 Credential provisioning is also the assessment point to confirm that the Agent and its runtime environment satisfy the posture requirements. In this document, posture assessment refers to the evaluation of signals about the Agent, its software, deployment context, runtime environment, and operational state. These signals can influence whether a credential is issued, which identifier is bound to the credential, what type of credential is issued, what attributes are included in the credential, and how long the credential remains valid. ¶ section-8-2 Posture assessment mechanisms are deployment and risk specific. They may include hardware-backed evidence, trusted execution environment TEE evidence, software integrity measurements, supply-chain provenance, platform or orchestration-layer metadata, workload placement information, configuration state, operator assertions, or other environment-specific signals. Depending on the risk involved, a single signal may be sufficient, while higher-risk deployments may require multiple independent signals before credentials are issued or renewed. ¶ section-8-3 Deployed workload identity systems commonly perform some form of posture assessment as part of credential provisioning. For example, SPIFFE implementations can evaluate platform and environment-specific information about a workload before binding it to a SPIFFE identifier and issuing an SVID. At a high level, a provisioning component gathers workload and execution context signals, verifies them according to local policy, and, if verification succeeds, issues short-lived credentials for subsequent authentication and authorization. ¶ section-8-4 An Agent Identity Management System may incorporate multiple posture assessment mechanisms and implementations. The selection of mechanisms depends on deployment constraints, such as the underlying platform, available identity signals, and desired level of trust assurance. This document does not require any particular posture assessment mechanism, evidence format, or verifier architecture. ¶ section-8-5 Agent credential provisioning must operate autonomously, scale to high-churn environments, and integrate closely with the posture assessment mechanisms used to establish trust in the Agent at each issuance or rotation event. ¶ section-8-6 Agent credential provisioning typically includes two phases: ¶ section-8-7 - Initial Provisioning : The process by which an agent first acquires a credential bound to its identity. This often occurs immediately after deployment or instantiation and is based on verified properties of the agent e.g., deployment context, posture assessment results, or orchestration metadata . ¶ section-8-8.1.1 - Rotation/Renewal : The automatic refresh of short-lived credentials before expiration. Continuous rotation ensures that credentials remain valid only for the minimum necessary time and that authorization state reflects current operational conditions. ¶ section-8-8.2.1 The use of short-lived credentials provides a significant improvement in the risk profile and risk of credential exposure. It provides an alternative to explicit revocation mechanisms and simplifies lifecycle management in large, automated environments while removing the risks of downtime as a result of credential expiry. ¶ section-8-9 Deployed frameworks such as SPIFFE SPIFFE provide proven mechanisms for automated, short-lived credential provisioning at runtime. In addition to issuing short-lived credentials, SPIFFE SPIFFE also provisions ephemeral cryptographic key material bound to each credential, further reducing the risks associated with compromising long-lived keys. ¶ section-8-10 The Large Language Model MUST NOT have access to an agent's credentials or to credentials that may be needed to access tools and services. This prevents the Large Language Model from using, exposing, or being manipulated via prompt injection into disclosing the credentials. ¶ section-8-11 9. section-9 Agent Authentication name-agent-authentication Agents may authenticate using a variety of mechanisms, depending on the credentials they possess, the protocols supported in the deployment environment, and the risk profile of the application. As described in the WIMSE Architecture WIMSE-ARCH WIMSE-ARCH , authentication can occur at either the transport layer or the application layer, and many deployments rely on a combination of both. ¶ section-9-1 9.1. section-9.1 Transport Layer Authentication name-transport-layer-authenticat Transport-layer authentication establishes trust during the establishment of a secure transport channel. The most common mechanism used by agents is mutually-authenticated TLS mTLS , in which both endpoints present X.509-based credentials and perform a bidirectional certificate exchange as part of the TLS negotiation. When paired with short-lived workload identities, such as those issued by SPIFFE or WIMSE, mTLS provides strong channel binding and cryptographic proof of control over the agent’s private key. ¶ section-9.1-1 mTLS is particularly well-suited for environments where transport-level protection, peer authentication, and ephemeral workload identity are jointly required. It also simplifies authorization decisions by enabling agents to associate application-layer requests with an authenticated transport identity. One example of this is the use of mTLS in service mesh architectures such as Istio or LinkerD. ¶ section-9.1-2 9.1.1. section-9.1.1 Limitations name-limitations There are scenarios where transport-layer authentication is not desirable or cannot be relied upon. In architectures involving intermediaries, such as proxies, API gateways, service meshes, load balancers, or protocol translators, TLS sessions are often terminated and re-established, breaking the end-to-end continuity of transport-layer identity. Similarly, some deployment models such as serverless platforms, multi-tenant edge environments, or cross-domain topologies may obscure or abstract identity presented at the transport layer, making it difficult to bind application-layer actions to a credential presented at the transport layer. In these cases, application-layer authentication provides a more robust and portable mechanism for expressing agent identity and conveying attestation or policy-relevant attributes. ¶ section-9.1.1-1 9.2. section-9.2 Application Layer Authentication name-application-layer-authentic Application-layer authentication allows agents to authenticate independently of the underlying transport. This enables end-to-end identity preservation even when requests traverse proxies, load balancers, or protocol translation layers. ¶ section-9.2-1 The WIMSE working group defines WIMSE Proof Tokens and HTTP Message Signatures as authentication mechanisms that may be used by agents. ¶ section-9.2-2 9.2.1. section-9.2.1 WIMSE Proof Tokens WPTs name-wimse-proof-tokens-wpts WIMSE Workload Proof Tokens WPTs, WIMSE-WPT WIMSE-WPT are a protocol-independent, application-layer mechanism for proving possession of the private key associated with a Workload Identity Token WIT . WPTs are generated by the agent, using the private key matching the public key in the WIT. A WPT is defined as a signed JSON Web Token JWT that binds an agent’s authentication to a specific message context, for example, an HTTP request, thereby providing proof of possession rather than relying on bearer semantics. ¶ section-9.2.1-1 WPTs are designed to work alongside WITs WIMSE-CRED WIMSE-CRED and are typically short-lived to reduce the window for replay attacks. They carry claims such as audience aud , expiration exp , a unique token identifier jti , and a hash of the associated WIT wth . A WPT may also include hashes of other related tokens e.g., a Transaction Token to bind the authentication contexts to specific transaction or authorizations details. ¶ section-9.2.1-2 Although the draft currently defines a protocol binding for HTTP via a Workload-Proof-Token header , the core format is protocol-agnostic, making it applicable to other protocols. Its JWT structure and claims model allow WPTs to be bound to different protocols and transports, including asynchronous or non-HTTP messaging systems such as Kafka and gRPC, or other future protocol bindings. This design enables receiving systems to verify identity, key possession, and message binding at the application layer even in environments where transport-layer identity e.g., mutual TLS is insufficient or unavailable. ¶ section-9.2.1-3 9.2.2. section-9.2.2 HTTP Message Signatures name-http-message-signatures The WIMSE Workload-to-Workload Authentication with HTTP Signatures specification WIMSE-HTTPSIG WIMSE-HTTPSIG defines an application-layer authentication profile built on the HTTP Message Signatures standard HTTP-SIG HTTP-SIG . It is one of the mechanisms WIMSE defines for authenticating workloads in HTTP-based interactions where transport-layer protections may be insufficient or unavailable. The protocol combines a workload's Workload Identity Token WIT which binds the agent's identity to a public key with HTTP Message Signatures using the corresponding private key , thereby providing proof of possession and message integrity for individual HTTP requests and responses. This approach ensures end-to-end authentication and integrity even when traffic traverses intermediaries such as TLS proxies or load balancers that break transport-layer identity continuity. The profile mandates signing of some request components e.g., method, request-target, content digest, and the WIT itself and supports optional response signing. Note that @request-target covers only the request-target string typically path + query and not the method, scheme, or authority; those are only protected if separately covered e.g., @method, @scheme, @authority . ¶ section-9.2.2-1 9.2.3. section-9.2.3 Limitations name-limitations-2 Unlike transport-layer authentication, application-layer authentication does not inherently provide channel binding to the underlying secure transport. As a result, implementations MUST consider the risk of message relay or replay if tokens or signed messages are accepted outside their intended context. Deployments typically mitigate these risks through short token lifetimes, audience restrictions, nonce or unique identifier checks, and binding authentication to specific requests or transaction parameters. ¶ section-9.2.3-1 11. section-11 Agent Monitoring, Observability and Remediation name-agent-monitoring-observabil Because agents may perform sensitive actions autonomously or on behalf of users, deployments MUST maintain sufficient monitoring and observability to reconstruct agent behavior and authorization context after execution. Observability is therefore a security control, not solely an operational feature. ¶ section-11-1 Any participant in the system, including the Agent, Tool, System, LLM or other resources and service MAY subscribe to change notifications using eventing mechanisms such as the OpenID Shared Signals Framework SSF SSF with either the Continuous Access Evaluation Profile CAEP CAEP or Risk Incident Sharing and Coordination RISC RISC to receive security and authorization-relevant signals. Upon receipt of a relevant signal e.g., session revoked, risk level change, subject disabled, token replay suspected, risk elevated , the recipient SHOULD remediate by attenuating access, such as terminating local sessions, discarding cached tokens, re-acquiring tokens with updated constraints, reducing privileges, or re-running policy evaluation before continuing to allow access. Recipients of such signals MUST ensure that revoked or downgraded authorization is enforced without undue delay. Cached authorization decisions and tokens that are no longer valid MUST NOT continue to be used after a revocation or risk notification is received. ¶ section-11-2 To support detection, investigation, and accountability, deployments MUST produce durable audit logs covering authorization decisions and subsequent remediations. Audit records MUST be tamper-evident and retained according to the security policy of the deployment. ¶ section-11-3 At a minimum, audit events MUST record: ¶ section-11-4 - authenticated agent identifier ¶ section-11-5.1.1 - delegated subject user or system , when present ¶ section-11-5.2.1 - resource or tool being accessed ¶ section-11-5.3.1 - action requested and authorization decision ¶ section-11-5.4.1 - timestamp and transaction or request correlation identifier ¶ section-11-5.5.1 - posture assessment or risk state influencing the decision ¶ section-11-5.6.1 - remediation or revocation events and their cause ¶ section-11-5.7.1 Monitoring / Observability systems SHOULD correlate events across Agents, Tools, Services, Resources and LLMs to detect misuse patterns such as replay, confused deputy behavior, privilege escalation, or unexpected action sequences. ¶ section-11-6 End-to-end audit is enabled when Agents, Users, Systems, LLMs, Tools, services and resources have stable, verifiable identifiers that allow auditors to trace "which entity did what, using which authorization context, and why access changed over time." ¶ section-11-7 Implementations SHOULD provide operators the ability to reconstruct a complete execution chain of an agent task, including delegated authority, intermediate calls, and resulting actions across service boundaries. ¶ section-11-8 13. section-13 Agent Compliance name-agent-compliance Compliance for Agent-based systems SHOULD be assessed by auditing observed behavior and recorded evidence logs, signals, and authorization decisions against the deployment’s Agent Authentication and Authorization Policy Section 12 agent auhtentication and authorization policy . Since compliance criteria are specific to individual deployments, organizations, industries and jurisdictions, they are out of scope for this framework though implementers SHOULD ensure strong observability and accountable governance, subject to their specific business needs. ¶ section-13-1 14. section-14 Security Considerations name-security-considerations This document composes existing specifications to enable authentication and authorization between AI agents. The security considerations of each referenced specification apply in full. ¶ section-14-1 In addition to the guidance included in existing specifications, additional security best practices and profiles have been developed for the Oauth protocol famility. The OAuth 2.0 Security Best Current Practice OAUTH-BCP OAUTH-BCP which captures current guidance on threats and mitigations that have emerged since the original OAuth 2.0 specifications were published. The FAPI 2.0 Security Profile OpenIDConnect.FAPI OpenIDConnect.FAPI defines a high-assurance profile of OAuth 2.0 suitable for high security applications. ¶ section-14-2 15. section-15 Privacy Considerations name-privacy-considerations-2 This document composes existing specifications to enable authentication and authorization between AI agents. ¶ section-15-1 In addition to the the privacy considerations in Section 10.9 privacy , the privacy considerations in each referenced specification apply in full. ¶ section-15-2 16. section-16 IANA Considerations name-iana-considerations This document has no IANA actions. ¶ section-16-1 17. section-17 Acknowledgments name-acknowledgments The authors would like to thank: ¶ section-17-1 - Sean O'Dell for providing valuable input and feedback on this work. ¶ section-17-2.1.1 - Karl McGuinness for his blog posts on mission shaping as a pre-cursor to authorization MissionShaping MissionShaping ¶ section-17-2.2.1 18. section-18 References name-references 18.1. section-18.1 Normative References name-normative-references - A2A - "Agent2Agent A2A Protocol", n.d., < https://github.com/a2aproject/A2A https://github.com/a2aproject/A2A . - ACP - "Agentic Commerce Protocol", n.d., < https://www.agenticcommerce.dev/docs https://www.agenticcommerce.dev/docs . - AP2 - "Agent Payments Protocol AP2 ", n.d., < https://github.com/google-agentic-commerce/AP2 https://github.com/google-agentic-commerce/AP2 . - CAEP - "OpenID Continuous Access Evaluation Profile 1.0", n.d., < https://openid.net/specs/openid-caep-1 0-final.html https://openid.net/specs/openid-caep-1 0-final.html . - HTTP-SIG - Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, , < https://www.rfc-editor.org/rfc/rfc9421 https://www.rfc-editor.org/rfc/rfc9421 . - MCP - "Model Context Protocol", n.d., < https://modelcontextprotocol.io/specification https://modelcontextprotocol.io/specification . - OAUTH-ACCESSTOKEN-JWT - Bertocci, V., "JSON Web Token JWT Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, , < https://www.rfc-editor.org/rfc/rfc9068 https://www.rfc-editor.org/rfc/rfc9068 . - OAUTH-BCP - Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, , < https://www.rfc-editor.org/rfc/rfc9700 https://www.rfc-editor.org/rfc/rfc9700 . - OAUTH-CLIENT-METADATA - Parecki, A. and E. Smith, "OAuth Client ID Metadata Document", Work in Progress, Internet-Draft, draft-ietf-oauth-client-id-metadata-document-01, , < https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-01 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-01 . - OAUTH-CLIENTAUTH-JWT - Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, , < https://www.rfc-editor.org/rfc/rfc7523 https://www.rfc-editor.org/rfc/rfc7523 . - OAUTH-CLIENTAUTH-MTLS - Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, , < https://www.rfc-editor.org/rfc/rfc8705 https://www.rfc-editor.org/rfc/rfc8705 . - OAUTH-FRAMEWORK - Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , < https://www.rfc-editor.org/rfc/rfc6749 https://www.rfc-editor.org/rfc/rfc6749 . - OAUTH-ID-CHAIN - Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-16, , < https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-chaining-16 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-chaining-16 . - OAUTH-JWT-ASSERTION - Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz-grant-04, , < https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant-04 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant-04 . - OAUTH-REGISTRATION - Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, , < https://www.rfc-editor.org/rfc/rfc7591 https://www.rfc-editor.org/rfc/rfc7591 . - OAUTH-RESOURCE-METADATA - Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, , < https://www.rfc-editor.org/rfc/rfc9728 https://www.rfc-editor.org/rfc/rfc9728 . - OAUTH-SERVER-METADATA - Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, , < https://www.rfc-editor.org/rfc/rfc8414 https://www.rfc-editor.org/rfc/rfc8414 . - OAUTH-SPIFFE - Schwenkschuster, A., Kasselman, P., Rose, S., Thorgersen, S., and N. Cam-Winget, "OAuth SPIFFE Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-spiffe-client-auth-02, , < https://datatracker.ietf.org/doc/html/draft-ietf-oauth-spiffe-client-auth-02 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-spiffe-client-auth-02 . - OAUTH-TOKEN-EXCHANGE - Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, , < https://www.rfc-editor.org/rfc/rfc8693 https://www.rfc-editor.org/rfc/rfc8693 . - OAUTH-TOKEN-INTROSPECTION - Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, , < https://www.rfc-editor.org/rfc/rfc7662 https://www.rfc-editor.org/rfc/rfc7662 . - OAUTH-TXN-ASSERTION - Fletcher, G., Kasselman, P., and S. O'Dell, "Transaction Token Authorization Grant Profile for OAuth Identity and Authorization Chaining", Work in Progress, Internet-Draft, draft-fletcher-transaction-token-chaining-profile-01, , < https://datatracker.ietf.org/doc/html/draft-fletcher-transaction-token-chaining-profile-01 https://datatracker.ietf.org/doc/html/draft-fletcher-transaction-token-chaining-profile-01 . - OAUTH-TXN-TOKENS - Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-09, , < https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-09 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-09 . - OpenIDConnect.AuthZEN - Gazitt, O., Ed., Brossard, D., Ed., and A. Tulshibagwale, Ed., "Authorization API 1.0", , < https://openid.net/specs/authorization-api-1 0.html https://openid.net/specs/authorization-api-1 0.html . - OpenIDConnect.CIBA - "OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0", n.d., < https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1 0.html https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1 0.html . - OpenIDConnect.Discovery - "OpenID Connect Discovery 1.0", n.d., < https://openid.net/specs/openid-connect-discovery-1 0-final.html https://openid.net/specs/openid-connect-discovery-1 0-final.html . - OpenIDConnect.FAPI - "FAPI 2.0 Security Profile", n.d., < https://openid.net/specs/fapi-security-profile-2 0-final.html https://openid.net/specs/fapi-security-profile-2 0-final.html . - RFC2119 - Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , < https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119 . - RFC8174 - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , < https://www.rfc-editor.org/rfc/rfc8174 https://www.rfc-editor.org/rfc/rfc8174 . - RISC - "OpenID Risk Incident Sharing and Coordination Profile 1.0", n.d., < https://openid.net/specs/openid-risc-1 0-final.html https://openid.net/specs/openid-risc-1 0-final.html . - SPIFFE - "Secure Production Identity Framework for Everyone", n.d., < https://spiffe.io/docs/latest/spiffe-about/overview/ https://spiffe.io/docs/latest/spiffe-about/overview/ . - SPIFFE-ID - "SPIFFE-ID", n.d., < https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md . - SPIFFE-JWT-SVID - "The JWT SPIFFE Verifiable Identity Document", n.d., < https://github.com/spiffe/spiffe/blob/main/standards/JWT-SVID.md https://github.com/spiffe/spiffe/blob/main/standards/JWT-SVID.md . - SPIFFE-WIT-SVID - "The WIT SPIFFE Verifiable Identity Document", n.d., < https://github.com/spiffe/spiffe/blob/draft-wit-svid/standards/WIT-SVID.md https://github.com/spiffe/spiffe/blob/draft-wit-svid/standards/WIT-SVID.md . - SPIFFE-X509-SVID - "The X.509 SPIFFE Verifiable Identity Document", n.d., < https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md . - SSF - "OpenID Shared Signals Framework Specification 1.0", n.d., < https://openid.net/specs/openid-sharedsignals-framework-1 0-final.html https://openid.net/specs/openid-sharedsignals-framework-1 0-final.html . - WIMSE-ARCH - Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment WIMSE Architecture", Work in Progress, Internet-Draft, draft-ietf-wimse-arch-07, , < https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-07 https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-07 . - WIMSE-CRED - Campbell, B., Salowey, J. A., Schwenkschuster, A., Sheffer, Y., and Y. Rosomakho, "WIMSE Workload Credentials", Work in Progress, Internet-Draft, draft-ietf-wimse-workload-creds-02, , < https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-02 https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-02 . - WIMSE-HTTPSIG - Salowey, J. A. and Y. Sheffer, "WIMSE Workload-to-Workload Authentication with HTTP Signatures", Work in Progress, Internet-Draft, draft-ietf-wimse-http-signature-04, , < https://datatracker.ietf.org/doc/html/draft-ietf-wimse-http-signature-04 https://datatracker.ietf.org/doc/html/draft-ietf-wimse-http-signature-04 . - WIMSE-ID - Rosomakho, Y. and J. A. Salowey, "Workload Identifier", Work in Progress, Internet-Draft, draft-ietf-wimse-identifier-03, , < https://datatracker.ietf.org/doc/html/draft-ietf-wimse-identifier-03 https://datatracker.ietf.org/doc/html/draft-ietf-wimse-identifier-03 . - WIMSE-WPT - Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof Token", Work in Progress, Internet-Draft, draft-ietf-wimse-wpt-01, , < https://datatracker.ietf.org/doc/html/draft-ietf-wimse-wpt-01 https://datatracker.ietf.org/doc/html/draft-ietf-wimse-wpt-01 . 18.2. section-18.2 Informative References name-informative-references - MissionShaping - McGuinness, K., "The Mission Shaping Problem", , < https://notes.karlmcguinness.com/notes/the-mission-shaping-problem/ https://notes.karlmcguinness.com/notes/the-mission-shaping-problem/ . Appendix A. appendix-A Document History name-document-history To be removed from the final specification -03 ¶ appendix-A-1 - Editorial updates ¶ appendix-A-2.1.1 - Clarify relationship between WIMSE and SPIFFE credentials https://github.com/PieterKas/agent2agent-auth-framework/issues/136 ¶ appendix-A-2.2.1 - Clarify that LLMs should not have access to Agent credentials: https://github.com/PieterKas/agent2agent-auth-framework/issues/127 ¶ appendix-A-2.3.1 - Update use of normative language https://github.com/PieterKas/agent2agent-auth-framework/issues/123 ¶ appendix-A-2.4.1 -03 ¶ appendix-A-3 - Include reference to CIBA see https://github.com/PieterKas/agent2agent-auth-framework/issues/131 ¶ appendix-A-4.1.1 -02 ¶ appendix-A-5 - Add Aaron Parecki from Okta as co-author. ¶ appendix-A-6.1.1 - Add reference to phishing resistent credentials e.g. FIDO passkeys/authenticators - see https://github.com/PieterKas/agent2agent-auth-framework/issues/106 ¶ appendix-A-6.2.1 - Fold attestation section into provosioning section. Change terminology to posture management. ¶ appendix-A-6.3.1 - Clarify Oauth authentication mechanisms when an Agent acts as and OAuth client. ¶ appendix-A-6.4.1 - Update Security Considerations section ¶ appendix-A-6.5.1 - Add section on Agent Mission see issue https://github.com/PieterKas/agent2agent-auth-framework/issues/107 ¶ appendix-A-6.6.1 -01 ¶ appendix-A-7 - Add Nick Steele from OpenAI as co-author. ¶ appendix-A-8.1.1 -00 ¶ appendix-A-9