From 1981ad07b8be4cca785893352eb4a8056b5ab365 Mon Sep 17 00:00:00 2001 From: PieterKas <90690777+PieterKas@users.noreply.github.com> Date: Fri, 5 Jun 2026 18:18:38 +0100 Subject: [PATCH 1/4] Add reference to CIBA protocol in user confirmation section Clarify the use of CIBA protocol for user confirmation in OAuth authorization. --- 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 66e2ba0..bc53406 100644 --- a/draft-klrc-aiagent-auth.md +++ b/draft-klrc-aiagent-auth.md @@ -327,7 +327,7 @@ When using the Identity Assertion JWT Authorization Grant {{OAUTH-JWT-ASSERTION} OAuth Identity and Authorization Chaining Across Domains ({{OAUTH-ID-CHAIN}}) provides a general mechanism for obtaining cross-domain access that can be used whether an identity assertion like a SAML or OpenID Connect token is available or not. The Identity Assertion JWT Authorization Grant {{OAUTH-JWT-ASSERTION}} is optimized for cases where an identity assertion like a SAML or OpenID Connect token is available from an identity provider that is trusted by all the OAuth authorization servers as it removes the need for the user to re-authenticate. This is typically used within enterprise deployments to simplify authorization delegation for multiple software-as-a-service offerings. ## Human in the Loop -An OAuth authorization server MAY conclude that the level of access requested by an Agent requires explicit user confirmation. In such cases the authorization server SHOULD either decline the request or obtain additional authorization from the User. An Agent, acting as an OAuth client, may use the OpenID Client Initiated Backchannel Authentication (CIBA) protocol. This triggers an out-of-band interaction allowing the user to approve or deny the requested operation without exposing credentials to the agent (for example a push notification requesting the user to approve a request through an authenticator application on their mobile device). +An OAuth authorization server MAY conclude that the level of access requested by an Agent requires explicit user confirmation. In such cases the authorization server SHOULD either decline the request or obtain additional authorization from the User. An Agent, acting as an OAuth client, may use the OpenID Client Initiated Backchannel Authentication (CIBA) protocol ({{OpenIDConnect.CIBA}}). This triggers an out-of-band interaction allowing the user to approve or deny the requested operation without exposing credentials to the agent (for example a push notification requesting the user to approve a request through an authenticator application on their mobile device). Interactive agent frameworks may also solicit user confirmation directly during task execution (for example tool invocation approval or parameter confirmation). Such interactions do not by themselves constitute authorization and MUST be bound to a verifiable authorization grant issued by the authorization server. The agent SHOULD therefore translate user confirmation into an OAuth authorization event (e.g., step-up authorization via CIBA) before accessing protected resources. From 2d25a64ebf9543a8d9625ceb599e62cbcd0bc9dc Mon Sep 17 00:00:00 2001 From: PieterKas <90690777+PieterKas@users.noreply.github.com> Date: Fri, 5 Jun 2026 18:20:28 +0100 Subject: [PATCH 2/4] Add reference to CIBA and update co-author Included reference to CIBA and updated co-author information. --- draft-klrc-aiagent-auth.md | 1 + 1 file changed, 1 insertion(+) diff --git a/draft-klrc-aiagent-auth.md b/draft-klrc-aiagent-auth.md index bc53406..8d57505 100644 --- a/draft-klrc-aiagent-auth.md +++ b/draft-klrc-aiagent-auth.md @@ -431,6 +431,7 @@ The authors would like to thank: * Clarify Oauth authentication mechanisms when an Agent acts as and OAuth client. * Update Security Considerations section * Add section on Agent Mission (see issue https://github.com/PieterKas/agent2agent-auth-framework/issues/107) + * Include reference to CIBA (see https://github.com/PieterKas/agent2agent-auth-framework/issues/131) -01 From 9976abc6f030586663cb0884e2f474d827b9e68b Mon Sep 17 00:00:00 2001 From: PieterKas <90690777+PieterKas@users.noreply.github.com> Date: Fri, 5 Jun 2026 18:44:07 +0100 Subject: [PATCH 3/4] Update document history with new reference to CIBA --- draft-klrc-aiagent-auth.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/draft-klrc-aiagent-auth.md b/draft-klrc-aiagent-auth.md index 8d57505..908768c 100644 --- a/draft-klrc-aiagent-auth.md +++ b/draft-klrc-aiagent-auth.md @@ -423,6 +423,10 @@ The authors would like to thank: # Document History \[\[ To be removed from the final specification ]] + -03 + + * Include reference to CIBA (see https://github.com/PieterKas/agent2agent-auth-framework/issues/131) + -02 * Add Aaron Parecki from Okta as co-author. @@ -431,7 +435,6 @@ The authors would like to thank: * Clarify Oauth authentication mechanisms when an Agent acts as and OAuth client. * Update Security Considerations section * Add section on Agent Mission (see issue https://github.com/PieterKas/agent2agent-auth-framework/issues/107) - * Include reference to CIBA (see https://github.com/PieterKas/agent2agent-auth-framework/issues/131) -01 From 96b6d6dcd745099256a8b7b1c94be41d42f9f57d Mon Sep 17 00:00:00 2001 From: PieterKas <90690777+PieterKas@users.noreply.github.com> Date: Tue, 30 Jun 2026 11:22:06 +0100 Subject: [PATCH 4/4] 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 908768c..373bfab 100644 --- a/draft-klrc-aiagent-auth.md +++ b/draft-klrc-aiagent-auth.md @@ -327,7 +327,7 @@ When using the Identity Assertion JWT Authorization Grant {{OAUTH-JWT-ASSERTION} OAuth Identity and Authorization Chaining Across Domains ({{OAUTH-ID-CHAIN}}) provides a general mechanism for obtaining cross-domain access that can be used whether an identity assertion like a SAML or OpenID Connect token is available or not. The Identity Assertion JWT Authorization Grant {{OAUTH-JWT-ASSERTION}} is optimized for cases where an identity assertion like a SAML or OpenID Connect token is available from an identity provider that is trusted by all the OAuth authorization servers as it removes the need for the user to re-authenticate. This is typically used within enterprise deployments to simplify authorization delegation for multiple software-as-a-service offerings. ## Human in the Loop -An OAuth authorization server MAY conclude that the level of access requested by an Agent requires explicit user confirmation. In such cases the authorization server SHOULD either decline the request or obtain additional authorization from the User. An Agent, acting as an OAuth client, may use the OpenID Client Initiated Backchannel Authentication (CIBA) protocol ({{OpenIDConnect.CIBA}}). This triggers an out-of-band interaction allowing the user to approve or deny the requested operation without exposing credentials to the agent (for example a push notification requesting the user to approve a request through an authenticator application on their mobile device). +An OAuth authorization server MAY conclude that the level of access requested by an Agent requires explicit user confirmation. In such cases the authorization server SHOULD either decline the request or obtain additional authorization from the User. An Agent, acting as an OAuth client, can use the OpenID Client Initiated Backchannel Authentication (CIBA) protocol ({{OpenIDConnect.CIBA}}). This triggers an out-of-band interaction allowing the user to approve or deny the requested operation without exposing credentials to the agent (for example a push notification requesting the user to approve a request through an authenticator application on their mobile device). Interactive agent frameworks may also solicit user confirmation directly during task execution (for example tool invocation approval or parameter confirmation). Such interactions do not by themselves constitute authorization and MUST be bound to a verifiable authorization grant issued by the authorization server. The agent SHOULD therefore translate user confirmation into an OAuth authorization event (e.g., step-up authorization via CIBA) before accessing protected resources.