From 537bd62de78dccc5057c4ff99d64fe6b304ee31d Mon Sep 17 00:00:00 2001 From: Jeff Lombardo Date: Thu, 25 Jun 2026 19:16:33 +0000 Subject: [PATCH 1/5] changed for MAJOR-3, issue 123 --- draft-klrc-aiagent-auth.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/draft-klrc-aiagent-auth.md b/draft-klrc-aiagent-auth.md index 66e2ba0..8cc23d5 100644 --- a/draft-klrc-aiagent-auth.md +++ b/draft-klrc-aiagent-auth.md @@ -1,7 +1,7 @@ --- title: "AI Agent Authentication and Authorization" abbrev: "AI-Auth" -category: info +category: bcp docname: draft-klrc-aiagent-auth-latest submissiontype: IETF # also: "independent", "editorial", "IAB", or "IRTF" @@ -130,6 +130,10 @@ By doing so, this document serves two complementary goals: 2. **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. +# 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. + # Conventions and Definitions {::boilerplate bcp14-tagged} @@ -297,7 +301,8 @@ A resource server in receipt of tokens opaque to it are able to obtain authoriza OAuth 2.0 defines a number authorization grant flows in support of different authorization scenarios. The appropriate flow depends on the specific authorization scenario and the nature of User involvement. The following subsections describe the most relevant flows for Agent authorization. ### User Delegates Authorization {#user_delegates_authorization} -When a User delegates authorization to an Agent, the Agent SHOULD obtain an access token using the Authorization Code Grant as described in {{Section 4.1 of OAUTH-FRAMEWORK}}. This redirection-based flow involves an interactive authorization process, typically in a web browser, in which the user authenticates to the authorization server and explicitly approves the requested access. Users SHOULD be authenticated using phishing-resistant authentication mechanisms such as a passkey. Once the user has approved the request, the authorization server returns an authorization code to the Agent via the redirect. + +When a User delegates authorization to an Agent, the Authorization Code Grant as described in Section 4.1 of {{OAUTH-FRAMEWORK}} is the appropriate mechanism. This redirection-based flow involves an interactive authorization process, typically in a web browser, in which the user authenticates to the authorization server and explicitly approves the requested access. Users SHOULD be authenticated using phishing-resistant authentication mechanisms such as a passkey. Once the user has approved the request, the authorization server returns an authorization code to the Agent via the redirect. The Agent, acting as an OAuth client, then makes a token request to the authorization server to redeem the authorization code for an access token. When making this token request, the Agent authenticates itself directly to the authorization server using the credentials described in {{agent_credentials}} with a compatible OAuth client authentication mechanism, and not with the use of static, long-lived client secrets. Compatible OAuth client authentication mechanisms are defined in {{!OAUTH-CLIENTAUTH-JWT=RFC7523}}, {{!OAUTH-CLIENTAUTH-MTLS=RFC8705}} and {{!OAUTH-SPIFFE=I-D.ietf-oauth-spiffe-client-auth}}. The OAuth client authentication step is distinct from, and occurs after, the user authentication and approval described above. The resulting access token reflects the authorization delegated to the Agent by the User and can be used by the Agent to access resources on behalf of the user. The use of OAuth negates the need for the Agent to have access to a User's credentials when accessing a resource on the User's behalf. @@ -318,9 +323,8 @@ To avoid passing access tokens between microservices, the Agent, LLM or Tools ca A transaction token MAY be used to obtain an access token to call another service (e.g. another Agent, Tool or LLM) by using OAuth 2.0 Token Exchange as defined in {{OAUTH-TOKEN-EXCHANGE}}. ## Cross Domain Access -Agents often require access to resources that are protected by different OAuth 2.0 authorization servers. When the components in {{fig-ai-agent-workload}} are protected by different logical authorization servers, an Agent SHOULD use OAuth Identity and Authorization Chaining Across Domains as defined in ({{!OAUTH-ID-CHAIN=I-D.ietf-oauth-identity-chaining}}), or a derived specification such as the Identity Assertion JWT Authorization Grant {{!OAUTH-JWT-ASSERTION=I-D.ietf-oauth-identity-assertion-authz-grant}}, to obtain an access token from the relevant authorization servers. -When using OAuth Identity and Authorization Chaining Across Domains ({{OAUTH-ID-CHAIN}}), an Agent SHOULD use the access token or transaction token it received to obtain a JWT authorization grant as described in {{Section 2.3 of OAUTH-ID-CHAIN}} and then use the JWT authorization grant it receives to obtain an access token for the resource it is trying to access as defined in {{Section 2.4 of OAUTH-ID-CHAIN}}. +Agents often require access to resources that are protected by different OAuth 2.0 authorization servers. When the components in Figure 1 are protected by different logical authorization servers, an Agent SHOULD use OAuth Identity and Authorization Chaining Across Domains as defined in {{!OAUTH-ID-CHAIN=I-D.ietf-oauth-identity-chaining}}, or a derived specification such as the Identity Assertion JWT Authorization Grant {{!OAUTH-JWT-ASSERTION=I-D.ietf-oauth-identity-assertion-authz-grant}}, to obtain an access token from the relevant authorization servers. The agent first exchanges its current access token or transaction token for a JWT authorization grant (Section 2.3 of {{OAUTH-ID-CHAIN}}) and then presents that grant to obtain an access token for the target resource (Section 2.4 of {{OAUTH-ID-CHAIN}}). When using the Identity Assertion JWT Authorization Grant {{OAUTH-JWT-ASSERTION}}, the identity assertion (e.g. the OpenID Connect ID Token or SAML assertion) for the target end-user is used to obtain a JWT assertion as described in {{Section 4.3 of OAUTH-JWT-ASSERTION}}, which is then used to obtain an access token as described in {{Section 4.4 of OAUTH-JWT-ASSERTION}}. @@ -345,7 +349,7 @@ Access from the Tools to the resources and services MAY be controlled through a ## Privacy Considerations {#privacy} Authorization tokens may contain user identifiers, agent identifiers, audience restrictions, transaction details, and contextual attributes. Deployments SHOULD minimize disclosure of personally identifiable or sensitive information in tokens and prefer audience-restricted and short-lived tokens. Where possible, opaque tokens with introspection SHOULD be preferred when claim minimization is required. -Agents SHOULD request only the minimum scopes and authorization details necessary to complete a task. Resource servers SHOULD avoid logging full tokens and instead log token identifiers or hashes. When authorization context is propagated across services, derived or down-scoped tokens (such as transaction tokens) SHOULD be used to reduce correlation and replay risk. +Agents SHOULD request only the minimum scopes and authorization details necessary to complete a task. As recommended in {{OAUTH-BCP}}, resource servers avoid logging full tokens and instead log token identifiers or hashes. When authorization context is propagated across services, derived or down-scoped tokens (such as transaction tokens) SHOULD be used to reduce correlation and replay risk. Implementations MUST ensure that user identity information delegated to agents is not exposed to unrelated services and that cross-domain authorization exchanges only disclose information required for the target authorization decision. From 69c66df059cbeb078fd82db85386e4c579b9bb34 Mon Sep 17 00:00:00 2001 From: Jeff Lombardo Date: Fri, 26 Jun 2026 17:57:52 -0400 Subject: [PATCH 2/5] Change category from 'bcp' to 'info' --- draft-klrc-aiagent-auth.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-klrc-aiagent-auth.md b/draft-klrc-aiagent-auth.md index 8cc23d5..69a4d7e 100644 --- a/draft-klrc-aiagent-auth.md +++ b/draft-klrc-aiagent-auth.md @@ -1,7 +1,7 @@ --- title: "AI Agent Authentication and Authorization" abbrev: "AI-Auth" -category: bcp +category: info docname: draft-klrc-aiagent-auth-latest submissiontype: IETF # also: "independent", "editorial", "IAB", or "IRTF" From 9bfc1dcdb1a448d0203096e0a26da174c3545b71 Mon Sep 17 00:00:00 2001 From: Jeff Lombardo Date: Fri, 26 Jun 2026 18:02:10 -0400 Subject: [PATCH 3/5] Update draft-klrc-aiagent-auth.md Co-authored-by: PieterKas <90690777+PieterKas@users.noreply.github.com> --- draft-klrc-aiagent-auth.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-klrc-aiagent-auth.md b/draft-klrc-aiagent-auth.md index 69a4d7e..a479a84 100644 --- a/draft-klrc-aiagent-auth.md +++ b/draft-klrc-aiagent-auth.md @@ -324,7 +324,7 @@ A transaction token MAY be used to obtain an access token to call another servic ## Cross Domain Access -Agents often require access to resources that are protected by different OAuth 2.0 authorization servers. When the components in Figure 1 are protected by different logical authorization servers, an Agent SHOULD use OAuth Identity and Authorization Chaining Across Domains as defined in {{!OAUTH-ID-CHAIN=I-D.ietf-oauth-identity-chaining}}, or a derived specification such as the Identity Assertion JWT Authorization Grant {{!OAUTH-JWT-ASSERTION=I-D.ietf-oauth-identity-assertion-authz-grant}}, to obtain an access token from the relevant authorization servers. The agent first exchanges its current access token or transaction token for a JWT authorization grant (Section 2.3 of {{OAUTH-ID-CHAIN}}) and then presents that grant to obtain an access token for the target resource (Section 2.4 of {{OAUTH-ID-CHAIN}}). +Agents often require access to resources that are protected by different OAuth 2.0 authorization servers. When the components in Figure 1 are protected by different logical authorization servers, an Agent SHOULD use OAuth Identity and Authorization Chaining Across Domains as defined in {{!OAUTH-ID-CHAIN=I-D.ietf-oauth-identity-chaining}}, or a derived specification such as the Identity Assertion JWT Authorization Grant {{!OAUTH-JWT-ASSERTION=I-D.ietf-oauth-identity-assertion-authz-grant}} or , Transaction Token Authorization Grant Profile for OAuth Identity and Authorization Chaining {{!OAUTH-TXN-ASSERTION=I-D.fletcher-transaction-token-chaining-profile}}, to obtain an access token from the relevant authorization servers. The agent first exchanges its current access token or transaction token for a JWT authorization grant (Section 2.3 of {{OAUTH-ID-CHAIN}}) and then presents that grant to obtain an access token for the target resource (Section 2.4 of {{OAUTH-ID-CHAIN}}). When using the Identity Assertion JWT Authorization Grant {{OAUTH-JWT-ASSERTION}}, the identity assertion (e.g. the OpenID Connect ID Token or SAML assertion) for the target end-user is used to obtain a JWT assertion as described in {{Section 4.3 of OAUTH-JWT-ASSERTION}}, which is then used to obtain an access token as described in {{Section 4.4 of OAUTH-JWT-ASSERTION}}. From 6007d75f16ef04725df195e1a7f96927204695cf Mon Sep 17 00:00:00 2001 From: PieterKas <90690777+PieterKas@users.noreply.github.com> Date: Mon, 29 Jun 2026 12:27:18 +0100 Subject: [PATCH 4/5] Apply suggestion from @PieterKas --- draft-klrc-aiagent-auth.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/draft-klrc-aiagent-auth.md b/draft-klrc-aiagent-auth.md index a479a84..54e71b5 100644 --- a/draft-klrc-aiagent-auth.md +++ b/draft-klrc-aiagent-auth.md @@ -426,7 +426,9 @@ The authors would like to thank: # Document History \[\[ To be removed from the final specification ]] + -03 + * Update us of normative language (https://github.com/PieterKas/agent2agent-auth-framework/issues/123) -02 * Add Aaron Parecki from Okta as co-author. From d84af30cc17759586fcc78ea67e013f481be5468 Mon Sep 17 00:00:00 2001 From: PieterKas <90690777+PieterKas@users.noreply.github.com> Date: Tue, 30 Jun 2026 11:45:30 +0100 Subject: [PATCH 5/5] Apply suggestion from @PieterKas --- draft-klrc-aiagent-auth.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-klrc-aiagent-auth.md b/draft-klrc-aiagent-auth.md index 4c32c74..b059960 100644 --- a/draft-klrc-aiagent-auth.md +++ b/draft-klrc-aiagent-auth.md @@ -443,7 +443,7 @@ The authors would like to thank: * Editorial updates * Clarify relationship between WIMSE and SPIFFE credentials (https://github.com/PieterKas/agent2agent-auth-framework/issues/136) * Clarify that LLMs should not have access to Agent credentials: https://github.com/PieterKas/agent2agent-auth-framework/issues/127 - * Update us of normative language (https://github.com/PieterKas/agent2agent-auth-framework/issues/123) + * Update use of normative language (https://github.com/PieterKas/agent2agent-auth-framework/issues/123) -02