# drafts

name: draft-zhang-aiproto-svcb-mapping-for-agents
rev: 01
title: Service Binding Mapping for Agents
time: 2026-01-05T07:14:39Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-09T07:14:39Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:03.420511+00:00
abstract:
With the continuous introduction of intelligent agent communication
   and interaction protocols, the current DNS cannot adequately meet the
   requirements for agent service resolution.  This document defines a
   new DNS resource record type, AGENT, which is a SVCB-compatible RR
   type, and specifies the mapping specifications.

full_text:
Network Working Group                                           M. Zhang
Internet-Draft                                                  Z.W. Yan
Intended status: Informational                                 K.J. Dong
Expires: 6 July 2026                                             H.T. Li
                                                                   CNNIC
                                                          2 January 2026


                   Service Binding Mapping for Agents
             draft-zhang-aiproto-svcb-mapping-for-agents-01

Abstract

   With the continuous introduction of intelligent agent communication
   and interaction protocols, the current DNS cannot adequately meet the
   requirements for agent service resolution.  This document defines a
   new DNS resource record type, AGENT, which is a SVCB-compatible RR
   type, and specifies the mapping specifications.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/.

   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."

   This Internet-Draft will expire on 6 July 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Zhang, et al.              Expires 6 July 2026                  [Page 1]

Internet-Draft     Service Binding Mapping for Agents       January 2026


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (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.

Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Basic requirements  . . . . . . . . . . . . . . . . . . . . .   3
   4.  SvcParamKeys defined by SVCB  . . . . . . . . . . . . . . . .   3
     4.1.  "alpn"  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.2.  "port"  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.3.  "ipv4hint" and "ipv6hint" . . . . . . . . . . . . . . . .   4
   5.  Definition of the New SvcParamKeys  . . . . . . . . . . . . .   4
     5.1.  "apn" . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.2.  "agentpath" . . . . . . . . . . . . . . . . . . . . . . .   4
     5.3.  "descpath"  . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Requirements notation

   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] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Introduction

   Building on the existing DNS, SVCB records provide additional
   convenience for clients to select different services and obtain the
   parameters required for connections.








Zhang, et al.              Expires 6 July 2026                  [Page 2]

Internet-Draft     Service Binding Mapping for Agents       January 2026


   With the rapid development of artificial intelligence, various
   communication and interaction protocols related to agents are
   currently being developed.  Agents have put forward new technical
   requirements in terms of session, communication, service invocation,
   and collaboration, and existing DNS cannot adequately meet the needs
   of agent service resolution.

   This document defines a new DNS resource record type, AGENT, which is
   a SVCB-compatible RR type, and specifies the mapping specifications
   required by SVCB.

3.  Basic requirements

   To provide special handling for agent service use cases, the AGENT RR
   type is defined as a SVCB-compatible RR type, specific to the "agent"
   scheme.

   The presentation format of the record is: Name TTL IN AGENT
   SvcPriority TargetName SvcParams

4.  SvcParamKeys defined by SVCB

   The SVCB record [RFC9460] defines a set of initial SvcParamKeys,
   which are applicable to the AGENT scheme.

4.1.  "alpn"

   This key indicates the set of protocols supported by the endpoint.

   When a specific protocol is designated, corresponding configurations
   shall be implemented via other parameters in accordance with the
   usage requirements and specifications of that protocol, so as to
   provide a complete protocol suite supporting it.

   Otherwise, setting only this value without specifying other necessary
   parameters for the protocol shall be considered an error.

4.2.  "port"

   The "port" SvcParamKey defines the port number to be used for
   connecting to this alternative endpoint.

   If this key is not present, the client shall use the default port
   number of the transport protocol.







Zhang, et al.              Expires 6 July 2026                  [Page 3]

Internet-Draft     Service Binding Mapping for Agents       January 2026


4.3.  "ipv4hint" and "ipv6hint"

   The "ipv4hint" and "ipv6hint" keys convey the IP addresses that the
   client may use to access the agent service.

5.  Definition of the New SvcParamKeys

   In addition to the aforementioned SvcParamKeys defined by SVCB, this
   document specifies new SvcParamKeys for agent service usage.

5.1.  "apn"

   The "apn" SvcParamKey is used to indicate the protocol employed for
   agent communication and interaction, where "apn" refers to Agent
   Protocol Negotiation.

   When a specific protocol is designated, other parameters must be
   configured in accordance with the usage requirements and
   specifications of that protocol to provide a complete protocol suite
   supporting it.

   Otherwise, setting only this value without specifying other necessary
   parameters for the protocol shall be considered an error.

   The "apn" key shall be used in conjunction with the "alpn" key.

   Since some agent-related protocols are currently in the stage of
   discussion and revision, the usage and supporting requirements of
   this parameter will be updated accordingly based on the release of
   future protocols.

5.2.  "agentpath"

   The value of the "agentpath" SvcParamKey is the URI template of the
   agent.

5.3.  "descpath"

   Agent description information includes attribute details such as
   agent identity, authentication, capabilities, and collaboration
   mechanisms.  Currently, its specific form varies across different
   protocols.

   The "descpath" SvcParamKey is used to identify the access address
   (e.g., the URL) of the agent's detailed information.






Zhang, et al.              Expires 6 July 2026                  [Page 4]

Internet-Draft     Service Binding Mapping for Agents       January 2026


6.  Security Considerations

   The use of DNSSEC is optional for AGENT records.

   The downgrade attacks relevant to the SVCB record are also applicable
   to this document.

7.  IANA Considerations

   To be determined.

8.  Acknowledgments

   To be determined.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/info/rfc9460>.

Authors' Addresses

   Man Zhang
   CNNIC
   Email: zmjy_9@163.com


   Zhiwei Yan
   CNNIC
   Email: yan@cnnic.cn






Zhang, et al.              Expires 6 July 2026                  [Page 5]

Internet-Draft     Service Binding Mapping for Agents       January 2026


   Kejun Dong
   CNNIC
   Email: dongkejun@cnnic.cn


   Hongtao Li
   CNNIC
   Email: lihongtao@cnnic.cn











































Zhang, et al.              Expires 6 July 2026                  [Page 6]


name: draft-chen-ai-agent-auth-new-requirements
rev: 00
title: New requirements for Authentication and Authorization in the AI Agents era
time: 2026-01-06T02:22:59Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-10T02:22:59Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment"]
tags: []
fetched_at: 2026-02-27T22:56:03.420513+00:00
abstract:
AI Agents are rapidly evolving from academic concepts into the core
   engines driving next-generation applications.  However, their
   autonomy, dynamic nature, and complex delegation relationships pose a
   fundamental challenge to our existing authentication and
   authorization frameworks, which were designed for human users and
   traditional software.  This document dissects the novel
   characteristics of AI Agents and outlines the new requirements for
   authentication and authorization which can manage dynamic behavior
   rather than verifying static identity.

full_text:
Internet Engineering Task Force                                  M. Chen
Internet-Draft                                                     L. Su
Intended status: Standards Track                            China Mobile
Expires: 10 July 2026                                     6 January 2026


 New requirements for Authentication and Authorization in the AI Agents
                                  era
              draft-chen-ai-agent-auth-new-requirements-00

Abstract

   AI Agents are rapidly evolving from academic concepts into the core
   engines driving next-generation applications.  However, their
   autonomy, dynamic nature, and complex delegation relationships pose a
   fundamental challenge to our existing authentication and
   authorization frameworks, which were designed for human users and
   traditional software.  This document dissects the novel
   characteristics of AI Agents and outlines the new requirements for
   authentication and authorization which can manage dynamic behavior
   rather than verifying static identity.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/.

   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."

   This Internet-Draft will expire on 10 July 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (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



Chen & Su                 Expires 10 July 2026                  [Page 1]

Internet-Draft  AI Agent Authentication and Authorizatio    January 2026


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  New Authentication Requirements:From "Who Are You?" to "Are You
           Still Trustworthy?" . . . . . . . . . . . . . . . . . . .   3
     3.1.  New Requirement 1: Traceable Identity and Provenance  . .   3
     3.2.  New Requirement 2: Continuous Behavioral Attestation  . .   4
     3.3.  New Requirement 3: Ultra-Low-Overhead Identity
           Management  . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  New Authorization Requirements: From "What Permissions Do You
           Have?" to "What Are You Allowed to Do, Right Here, Right
           Now?" . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  New Requirement 1: Intent-Driven, Just-in-Time (JIT)
           Permissions . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  New Requirement 2: Rich Context and Risk-Awareness  . . .   4
     4.3.  New Requirement 3: Explainable and Auditable
           Authorization . . . . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Traditional security models are built on a core assumption: the
   behavior of a protected entity, be it a human or a service, is
   relatively predictable.  We authenticate an "identity" and then grant
   it a set of fixed "permissions."  AI Agents shatter this foundation.

   An AI Agent is not a simple instruction executor; it is a goal
   achiever.  We provide it with a high-level objective (e.g., "optimize
   supply chain costs"), and it autonomously deconstructs the task,
   learns from its environment, invokes tools, and may discover
   innovative operational paths we never anticipated.  This shift
   introduces four disruptive characteristics:

   High Autonomy and Emergent Behavior: An Agent's actions are not pre-
   coded but are dynamically generated to achieve a goal.  Static
   permission rules can neither foresee nor cover all its possible
   operations.






Chen & Su                 Expires 10 July 2026                  [Page 2]

Internet-Draft  AI Agent Authentication and Authorizatio    January 2026


   Dynamic, Ephemeral, and Replicable Nature: For efficiency, a primary
   Agent may spawn thousands of ephemeral sub-agents in an instant to
   handle parallel tasks.  Their identities are transient, massive in
   scale, and may exist for only milliseconds.

   Complex Delegation and Chains of Responsibility: Agents can form
   deep, networked call chains.  A travel Agent might call a flight
   Agent, which in turn calls a payment Agent.  When an unauthorized
   action occurs, attributing responsibility and tracing the flow of
   permissions becomes incredibly complex.

   Continuous Learning and Adaptation: An Agent's decision-making model
   evolves over time.  This means an Agent's "normal behavior" today may
   differ from yesterday's, making it vulnerable to model drift or
   malicious manipulation that traditional static credentials cannot
   detect.

2.  Terminology

   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] [RFC8174].

3.  New Authentication Requirements:From "Who Are You?" to "Are You
    Still Trustworthy?"

   In the face of these characteristics, one-time authentication becomes
   woefully inadequate.  We need a new authentication framework capable
   of continuously assessing an Agent's trustworthiness.

3.1.  New Requirement 1: Traceable Identity and Provenance

   Authentication protocols must support a new identity format that is
   more than just an ID; it's a cryptographic "provenance record."  This
   certificate must contain:

   Genesis Information: The root user or task that initiated the Agent's
   creation.  Delegation Chain: A cryptographically signed, non-
   forgeable call path that clearly records every delegation from the
   genesis to the current instance.










Chen & Su                 Expires 10 July 2026                  [Page 3]

Internet-Draft  AI Agent Authentication and Authorizatio    January 2026


3.2.  New Requirement 2: Continuous Behavioral Attestation

   Authentication cannot be a single event.  Protocols must support a
   lightweight "behavioral heartbeat" mechanism, allowing an Agent to
   periodically submit a cryptographic digest of its recent actions to a
   monitoring system.  By comparing this digest against an expected
   behavioral baseline, the system can continuously verify that the
   Agent is "acting normally," thus detecting hijacking or unexpected
   drift even if its identity credential remains valid.

3.3.  New Requirement 3: Ultra-Low-Overhead Identity Management

   To support massive-scale, ephemeral Agents, protocols must enable
   near-zero overhead for identity creation and verification.  Expensive
   public-key operations and complex handshakes should be replaced with
   efficient symmetric-key mechanisms to meet the demands of high-
   frequency creation, destruction, and continuous attestation.

4.  New Authorization Requirements: From "What Permissions Do You Have?"
    to "What Are You Allowed to Do, Right Here, Right Now?"

   Static, Role-Based Access Control (RBAC) is obsolete in the face of
   autonomous Agents.  Authorization decisions must become dynamic,
   precise, and risk-aware.

4.1.  New Requirement 1: Intent-Driven, Just-in-Time (JIT) Permissions

   Authorization is no longer about pre-assigning a broad role.
   Instead, it must be about granting the principle of least privilege
   required to complete a specific task, at the moment of execution.
   For example, the system should grant an Agent permission to "execute
   a payment of amount <= $100 for the purpose of booking a flight"
   rather than a generic "payment" permission.  This permission must
   expire immediately upon task completion.

4.2.  New Requirement 2: Rich Context and Risk-Awareness

   Authorization decisions must be based on a rich set of contextual
   factors, including but not limited to:

   *  The Agent's intent and objective.

   *  A risk assessment of the requested operation.

   *  Whether its current behavioral patterns are normal.

   *  The sensitivity and provenance of the data being accessed.




Chen & Su                 Expires 10 July 2026                  [Page 4]

Internet-Draft  AI Agent Authentication and Authorizatio    January 2026


   Protocols must be able to efficiently carry this structured context
   to the policy engine for real-time evaluation.

4.3.  New Requirement 3: Explainable and Auditable Authorization

   Given the autonomy of Agents, when something goes wrong, we must be
   able to answer, "Why was the system authorized to do that?"
   Therefore, the response from an authorization protocol must be
   explainable.  It should return not just an "Allow" or "Deny" verdict
   but also the rationale behind the decision, such as the policy IDs
   that were matched and a snapshot of the critical context evaluated.
   This is essential for post-mortem audits, accountability, and the
   iterative refinement of security guardrails.

5.  IANA Considerations

6.  Security Considerations

Authors' Addresses

   Meiling Chen
   China Mobile
   BeiJing
   China
   Email: chenmeiling@chinamobile.com


   Li Su
   China Mobile
   BeiJing
   China
   Email: suli@chinamobile.com



















Chen & Su                 Expires 10 July 2026                  [Page 5]


name: draft-chen-oauth-rar-agent-extensions
rev: 00
title: Policy and Lifecycle Extensions for OAuth Rich Authorization Requests
time: 2026-02-04T02:18:23Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-08T02:18:23Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "A2A protocols", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:03.420515+00:00
abstract:
OAuth 2.0 Rich Authorization Requests (RAR), as defined in RFC 9396,
   provides a mechanism for clients to request fine-grained, structured
   authorization details.  However, in emerging ecosystems of
   collaborating AI agents and long-running automated tasks, two
   critical authorization dimensions remain implicit: the required
   security assurance level of the authorization policy and the strict
   binding of authorization lifetime to a task's lifecycle.

   This document extends the "authorization_details" object of RAR by
   introducing two new members: "policy_context" and
   "lifecycle_binding".  The "policy_context" member allows a client to
   explicitly request that the authorization be evaluated and granted
   under a specific policy assurance level, mitigating policy downgrade
   attacks and enhancing user consent.  The "lifecycle_binding" member
   enables the validity of an authorization grant to be tied directly to
   the state of an external entity, such as an automated task, ensuring
   permissions are automatically and immediately revoked upon task
   completion.  These extensions provide a standardized way to achieve
   more secure, transparent, and context-aware authorization in complex,
   automated environments.

full_text:
oauth                                                            M. Chen
Internet-Draft                                                     L. Su
Intended status: Standards Track                            China Mobile
Expires: 8 August 2026                                   4 February 2026


 Policy and Lifecycle Extensions for OAuth Rich Authorization Requests
                draft-chen-oauth-rar-agent-extensions-00

Abstract

   OAuth 2.0 Rich Authorization Requests (RAR), as defined in RFC 9396,
   provides a mechanism for clients to request fine-grained, structured
   authorization details.  However, in emerging ecosystems of
   collaborating AI agents and long-running automated tasks, two
   critical authorization dimensions remain implicit: the required
   security assurance level of the authorization policy and the strict
   binding of authorization lifetime to a task's lifecycle.

   This document extends the "authorization_details" object of RAR by
   introducing two new members: "policy_context" and
   "lifecycle_binding".  The "policy_context" member allows a client to
   explicitly request that the authorization be evaluated and granted
   under a specific policy assurance level, mitigating policy downgrade
   attacks and enhancing user consent.  The "lifecycle_binding" member
   enables the validity of an authorization grant to be tied directly to
   the state of an external entity, such as an automated task, ensuring
   permissions are automatically and immediately revoked upon task
   completion.  These extensions provide a standardized way to achieve
   more secure, transparent, and context-aware authorization in complex,
   automated environments.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/.

   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."

   This Internet-Draft will expire on 8 August 2026.



Chen & Su                 Expires 8 August 2026                 [Page 1]

Internet-Draft             extensions for RAR              February 2026


Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  The Need for Advanced Authorization in AI Agent
           Ecosystems  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  The "policy_context" Member . . . . . . . . . . . . . . . . .   4
     2.1.  Structure of the "policy_context" Object  . . . . . . . .   4
     2.2.  Pre-defined Policy Context Parameters . . . . . . . . . .   4
       2.2.1.  The "assurance_level" Parameter . . . . . . . . . . .   4
       2.2.2.  The "compliance_frameworks" Parameter . . . . . . . .   4
     2.3.  Authorization Server Processing . . . . . . . . . . . . .   5
     2.4.  Issuance in Access Tokens . . . . . . . . . . . . . . . .   5
   3.  The "lifecycle_binding" Member  . . . . . . . . . . . . . . .   5
     3.1.  Structure of the "lifecycle_binding" Object . . . . . . .   5
     3.2.  Lifecycle Binding Types . . . . . . . . . . . . . . . . .   5
       3.2.1.  The "task_status_webhook" Type  . . . . . . . . . . .   6
     3.3.  Authorization Server Processing . . . . . . . . . . . . .   6
     3.4.  Resource Server Responsibilities  . . . . . . . . . . . .   6
   4.  Example Authorization Request . . . . . . . . . . . . . . . .   6
   5.  Authorization Server Metadata . . . . . . . . . . . . . . . .   7
   6.  Error Response  . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  OAuth Authorization Server Metadata . . . . . . . . . . .   8
     8.2.  OAuth Extensions Error Registry . . . . . . . . . . . . .   8
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     10.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9






Chen & Su                 Expires 8 August 2026                 [Page 2]

Internet-Draft             extensions for RAR              February 2026


1.  Introduction

   OAuth 2.0 Rich Authorization Requests [RFC9396] significantly
   enhances the expressive power of authorization requests beyond simple
   string- based scopes.  This enables clients, such as sophisticated AI
   agents, to articulate their needs with greater precision.

1.1.  The Need for Advanced Authorization in AI Agent Ecosystems

   Modern distributed systems are increasingly composed of autonomous or
   semi-autonomous AI agents that collaborate to fulfill complex user
   intents.  For example, a user's request to "plan a business trip to
   Paris" might involve a primary "coordinator" agent that delegates
   sub-tasks to specialized agents for flight booking, hotel
   reservation, and expense reporting.

   In such scenarios, traditional authorization models face two major
   challenges:

   *Permission Abuse and Policy Downgrade: An agent might request a
   high-privilege action (e.g., booking a flight) but the authorization
   server (AS) might grant it under a default, low- assurance security
   policy.  A malicious or compromised client could exploit this
   ambiguity to bypass stricter security controls like multi-factor
   authentication or fraud detection that should be associated with
   high-risk operations.  The authorization request lacks a standard
   mechanism for the client to explicitly request and for the user to
   consent to a specific, appropriate level of policy assurance.

   *Excessive Permission Lifetime: An agent is granted permission to
   manage a long-running task (e.g., a data processing job).
   Traditional access tokens rely on a fixed expiration time ("exp"
   claim).  If the task completes or fails prematurely, the token
   remains valid for the remainder of its lifetime, creating a
   significant window of opportunity for misuse if the token is
   compromised.  The principle of least privilege dictates that the
   permission's lifetime should be strictly bound to the task's active
   lifecycle.

   This specification addresses these gaps by extending the RAR
   framework to include explicit policy context and lifecycle binding
   information within the authorization request itself.









Chen & Su                 Expires 8 August 2026                 [Page 3]

Internet-Draft             extensions for RAR              February 2026


1.2.  Terminology

   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 [RFC8174].

   This document uses the terms "Authorization Server" (AS), "Client",
   "Resource Server" (RS), and "Access Token" as defined in The OAuth
   2.0 Authorization Framework [RFC6749].  The term
   "authorization_details" is used as defined in Rich Authorization
   Requests [RFC9396].

2.  The "policy_context" Member

   This specification defines a new JSON object member,
   "policy_context", for the "authorization_details" object.  This
   member allows a client to request that the authorization decision be
   subject to a specific set of policy constraints and assurance levels.

2.1.  Structure of the "policy_context" Object

   The "policy_context" member, if present, MUST be a JSON object.  Its
   members provide context for the policy decision.

   { "assurance_level": "financial_grade_v1", "compliance_frameworks":
   ["pci-dss", "gdpr","iso27001"] }

2.2.  Pre-defined Policy Context Parameters

2.2.1.  The "assurance_level" Parameter

   A string that identifies the desired policy assurance level.  This
   identifier MUST be from a list of values pre-defined and published by
   the authorization server.  It serves as the primary input for the AS
   to select the appropriate set of evaluation rules (e.g., requiring
   MFA, performing risk analysis).This identifier MUST be one of the
   values advertised by the Authorization Server in its
   "policy_assurance_levels_supported" metadata entry (see Section 5).

2.2.2.  The "compliance_frameworks" Parameter

   An optional array of strings identifying specific compliance
   frameworks that the requested operation must adhere to.  These string
   identifiers MUST be values from the "OAuth Policy Compliance
   Frameworks" registry established by this specification (see
   Section 10.3.2).




Chen & Su                 Expires 8 August 2026                 [Page 4]

Internet-Draft             extensions for RAR              February 2026


2.3.  Authorization Server Processing

   When an AS receives an "authorization_details" object containing a
   "policy_context" member, it MUST:

   1.  Validate that the value of "assurance_level" is known and
       supported.

   2.  Use the "policy_context" to select and execute the corresponding
       authorization policies.

   3.  Perform a cross-validation to ensure the requested policy context
       is appropriate for the requested "type" and "actions".  For
       instance, an AS policy may require that a "payment_transaction"
       type MUST request a "financial_grade_v1" or higher assurance
       level.

   4.  Clearly communicate the semantic meaning of the requested
       "policy_context" to the end-user during the consent process.

2.4.  Issuance in Access Tokens

   If the request is approved, the AS SHOULD include the validated
   "policy_context" object within the "authorization_details" claim of
   the issued JWT access token.  This enables the resource server to
   perform its own local policy enforcement based on this context.

3.  The "lifecycle_binding" Member

   This specification defines another new JSON object member,
   "lifecycle_binding", for the "authorization_details" object.  This
   member ties the authorization's validity to the lifecycle of an
   external entity.

3.1.  Structure of the "lifecycle_binding" Object

   The "lifecycle_binding" member, if present, MUST be a JSON object.

   { "type": "task_status_webhook", "task_id": "job-d4a3b2-8c7e-4f5a-
   9b1c-2d3e4f5a6b7c", "termination_states": ["COMPLETED", "FAILED",
   "CANCELLED"] }

3.2.  Lifecycle Binding Types

   The "type" member indicates the mechanism by which the AS can monitor
   the external entity's state.





Chen & Su                 Expires 8 August 2026                 [Page 5]

Internet-Draft             extensions for RAR              February 2026


3.2.1.  The "task_status_webhook" Type

   Indicates that the external task provider will notify the AS of
   terminal state changes via a pre-configured webhook.  The object MUST
   also contain:

   o "task_id" (string): A unique identifier for the task.  o
   "termination_states" (array of strings): A list of states that, once
   the task enters, will trigger the immediate revocation of the
   associated authorization.

3.3.  Authorization Server Processing

   When an AS processes a request with a "lifecycle_binding" member, it
   MUST:

   1.  Verify its capability to monitor the specified task.

   2.  Create an internal record linking the "task_id" to the access
       token to be issued (e.g., via its "jti").

   3.  Upon receiving notification that the task has entered a terminal
       state, the AS MUST immediately revoke the associated token and
       propagate this revocation information.

3.4.  Resource Server Responsibilities

   Resource servers receiving tokens that contain a "lifecycle_binding"
   claim SHOULD NOT rely solely on the "exp" claim for validation.  They
   MUST employ a mechanism to check for real-time revocation, such as
   subscribing to a revocation feed from the AS or using token
   introspection [RFC7662].

4.  Example Authorization Request

   The following is a non-normative example of an
   "authorization_details" object utilizing both new members for a
   request to execute a sensitive data processing task.

   [ { "type": "patient_data_analysis_job", "actions": ["execute",
   "monitor_progress"], "locations": ["https://api.compute.com/jobs"],
   "policy_context": { "assurance_level": "hipaa_phi_access",
   "compliance_frameworks": ["hipaa", "gdpr"] }, "lifecycle_binding": {
   "type": "task_status_webhook", "task_id": "analysis-job-1138",
   "termination_states": ["COMPLETED", "FAILED_VALIDATION"] } } ]






Chen & Su                 Expires 8 August 2026                 [Page 6]

Internet-Draft             extensions for RAR              February 2026


5.  Authorization Server Metadata

   This specification adds the following parameters to the OAuth
   Authorization Server Metadata [RFC8414].

   policy_assurance_levels_supported: OPTIONAL.  A JSON array of
   objects, where each object represents a supported assurance level.
   Each object has the following members:

   "level" (string): A structured identifier for the assurance level
   (e.g., "nist_ial2").  REQUIRED. "description" (string): A human-
   readable description.  OPTIONAL. "uri" (string): A URI pointing to
   the detailed definition of the level.  OPTIONAL.

   policy_compliance_frameworks_supported: OPTIONAL.  A JSON array of
   strings containing the compliance framework identifiers supported by
   the AS.

6.  Error Response

   When a request is denied due to a failure in validating the
   "policy_context", the AS returns an error response with the following
   error code:

   Error Code: policy_requirement_not_met Description: The requested
   "policy_context" is not supported or cannot be satisfied.  The AS
   SHOULD include an "error_description" parameter to provide developers
   with more details about the failure.

7.  Security Considerations

   Preventing Policy Downgrade Attacks: The "policy_context" member
   allows the AS to enforce that high-risk actions are always requested
   with a corresponding high-assurance policy context.  The AS MUST
   reject requests where this mapping is violated, thus preventing a
   client from obtaining a privileged token under weak security
   pretenses.

   Ensuring Timely Revocation: The "lifecycle_binding" member
   significantly reduces the risk window of compromised tokens for long-
   running tasks.  The effectiveness of this mechanism is entirely
   dependent on the reliability of the state notification and revocation
   propagation systems.  Implementations MUST include robust error
   handling and fallbacks.  The token's "exp" claim serves as an
   essential fallback mechanism.






Chen & Su                 Expires 8 August 2026                 [Page 7]

Internet-Draft             extensions for RAR              February 2026


   User Consent and Transparency: The structured nature of these new
   members allows the AS to present a far more intelligible and accurate
   consent screen to the user, leading to more meaningful and informed
   authorization decisions.

   Reliability of External State Monitoring: The AS must trust the
   source of the lifecycle events (e.g., the task provider's webhook).
   Mechanisms such as mutual TLS authentication and request signing
   SHOULD be used to secure the communication channel for state updates.

   The "policy_context" and "lifecycle_binding" members may contain
   information about the user's intended actions and associated tasks.
   This information must be handled with care by the AS and RS, subject
   to the system's overall privacy policy.

8.  IANA Considerations

8.1.  OAuth Authorization Server Metadata

   This specification requests the registration of the following values
   in the "OAuth Authorization Server Metadata" registry:

   *policy_assurance_levels_supported
   *policy_compliance_frameworks_supported

8.2.  OAuth Extensions Error Registry

   This specification requests the registration of the following value
   in the "OAuth Extensions Error Registry":

   *Error Code: policy_requirement_not_met

9.  Acknowledgements

   This document based on RFC9396

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6749>.



Chen & Su                 Expires 8 August 2026                 [Page 8]

Internet-Draft             extensions for RAR              February 2026


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9396]  Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
              Rich Authorization Requests", RFC 9396,
              DOI 10.17487/RFC9396, May 2023,
              <https://www.rfc-editor.org/rfc/rfc9396>.

   [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
              Authorization Server Metadata", RFC 8414,
              DOI 10.17487/RFC8414, June 2018,
              <https://www.rfc-editor.org/rfc/rfc8414>.

10.2.  Informative References

   [RFC7662]  Richer, J., Ed., "OAuth 2.0 Token Introspection",
              RFC 7662, DOI 10.17487/RFC7662, October 2015,
              <https://www.rfc-editor.org/rfc/rfc7662>.

Authors' Addresses

   Meiling Chen
   China Mobile
   BeiJing
   China
   Email: chenmeiling@chinamobile.com


   Li Su
   China Mobile
   BeiJing
   China
   Email: suli@chinamobile.com

















Chen & Su                 Expires 8 August 2026                 [Page 9]


name: draft-han-ai-agent-impact-infra
rev: 00
title: The Impact of AI Agent to Network Infrastructure
time: 2026-01-09T07:09:43Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-08T09:04:53Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "ML traffic mgmt"]
tags: []
fetched_at: 2026-02-27T22:56:03.420517+00:00
abstract:
This document disucss and analyses the impact of AI Agent on network
   infrastructure aiming to facilitate the discussion and
   standardization about AI Agent communication within IETF.

full_text:
Network Working Group                                        M. Han, Ed.
Internet-Draft                                             N. Zhang, Ed.
Intended status: Informative                              X. Gu, Ed.
Expires: 8 January 2026                                     China Unicom
                                                             7 July 2025


            The Impact of AI Agent to Network Infrastructure
                   draft-han-ai-agent-impact-infra-00

Abstract

   This document disucss and analyses the impact of AI Agent on network
   infrastructure aiming to facilitate the discussion and
   standardization about AI Agent communication within IETF.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/.

   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."

   This Internet-Draft will expire on 8 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (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.





Han, et al.              Expires 8 January 2026                 [Page 1]

Internet-Draft   The Impact of AI Agent to Network Infra       July 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Network for Agent Communication . . . . . . . . . . . . . . .   3
     3.1.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.1.  Agent Communication in LAN  . . . . . . . . . . . . .   3
       3.1.2.  Agent Communication across WAN  . . . . . . . . . . .   4
       3.1.3.  Agent Communication in Fields . . . . . . . . . . . .   4
     3.2.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  Agent ID management among heterougenous networks  . .   5
       3.2.2.  Mobility Management (esp. for Non-3GPP networks)  . .   5
       3.2.3.  Pervassive Point-to-Point Secure Channel  . . . . . .   5
     3.3.  Potential new works . . . . . . . . . . . . . . . . . . .   6
       3.3.1.  Pervasive Mobility Managment in fixed networks  . . .   6
       3.3.2.  On-demand Point-to-Point Private Line service . . . .   6
   4.  Agent-based Network O&M . . . . . . . . . . . . . . . . . . .   6
     4.1.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.1.  Autonomic O&M through AI Agent built into Devices . .   6
       4.1.2.  Agent interactions between Devices and Controllers  .   6
     4.2.  Potential new works . . . . . . . . . . . . . . . . . . .   7
       4.2.1.  Extension of Anima Framework & Protocols  . . . . . .   7
       4.2.2.  South-bound Interface Extension for Agentic O&M . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The rapid advancement of AI agents has introduced transformative
   changes across various domains, particularly in network
   infrastructure.  AI agents, the autonomous, intelligent entities
   capable of perception, reasoning, and decision-making, are
   increasingly being deployed in diverse scenarios.  On the one hand,
   the network needs to provide communication support for AI agent
   collaboration, such as industrial, office, smart home and other
   scenarios.  On the other hand, AI agents can be deployed in the
   network to achieve automatic network O&M.

   Traditional network infrastructures were primarily designed for
   human-driven communication (e.g., web browsing, video streaming).
   However, the rise of multi-agent systems, where AI agents collaborate
   or compete in real-time, demands ultra-low-delay communication,
   dynamic resource allocation, and enhanced security protocols.




Han, et al.              Expires 8 January 2026                 [Page 2]

Internet-Draft   The Impact of AI Agent to Network Infra       July 2025


   Besides, AI agents are revolutionizing network O&M.  AI agents,
   powered by reinforcement learning and large language models, enable
   autonomous fault detection, predictive maintenance, and intent-driven
   networking.

   This draft explores the impact of AI Agents on network
   infrastructure, with a focus on Network for Agent Communication and
   Agent-based Network O&M.

2.  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] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.  Abbreviations and definitions used in this
   document:

3.  Network for Agent Communication

3.1.  Scenarios

3.1.1.  Agent Communication in LAN

   a.  Office networks In the office network scenario, agents rely on a
   stable LAN environment to build an efficient collaboration system.
   Typical office agents, such as personal AI assistant, can
   automatically analyze users' work requirements, such as writing
   emails, organizing reports, and quickly generating drafts.  In the
   situation of team collaboration, multiple agents share data in real-
   time, automatically arrange task priorities, which can reduce manual
   communication costs and significantly improve work efficiency.  There
   is a requirement for office network to provide security guarantees
   for data interaction among agents to prevent the leakage of sensitive
   information.

   b.  Industrial networks In the industrial scenario, the LAN
   establishes a low-delay and highly reliable communication environment
   for agents, enabling efficient interconnection among production
   equipment, logistics robots, and management systems.  For example, in
   the warehousing and logistics process, the agents carried by AGV
   communicate with the central dispatching agent through the network,
   dynamically planning transportation routes based on real-time traffic
   conditions to improve the efficiency of material distribution.







Han, et al.              Expires 8 January 2026                 [Page 3]

Internet-Draft   The Impact of AI Agent to Network Infra       July 2025


3.1.2.  Agent Communication across WAN

   a.  Agents directly access to public networks When agents directly
   access public network, they can achieve efficient coordination over a
   wide range and across regions.  For example, in smart city, traffic
   management agents, environment monitoring agents, and public service
   agents collaborate efficiently through public networks.  However, the
   openness of public networks also brings challenges in data security
   and privacy protection, which require the use of technologies such as
   encryption and authentication to ensure the security of agent
   communication.

   b.  Agents in Campus/DC to communicate across the WAN AI agents
   within different DCs can achieve resource sharing and remote
   collaboration through WAN.  For example, when a data center
   experiences a shortage of computing resources, the resource
   scheduling agent in this DC negotiates with resource scheduling
   agents of other DCs through the WAN to divert some tasks to DCs with
   idle resources.  This requires the WAN to ensure low delay.

3.1.3.  Agent Communication in Fields

   a.  Interaction through 3GPP radio networks In the office network
   scenario, agents rely on a stable LAN environment to build an
   efficient collaboration system.  Typical office agents, such as
   personal AI assistant, can automatically analyze users' work
   requirements, such as writing emails, organizing reports, and quickly
   generating drafts.  In the situation of team collaboration, multiple
   agents share data in real-time, automatically arrange task
   priorities, which can reduce manual communication costs and
   significantly improve work efficiency.  There is a requirement for
   office network to provide security guarantees for data interaction
   among agents to prevent the leakage of sensitive information.

   b.  Interaction through WiFi In the industrial scenario, the LAN
   establishes a low-delay and highly reliable communication environment
   for agents, enabling efficient interconnection among production
   equipment, logistics robots, and management systems.  For example, in
   the warehousing and logistics process, the agents carried by AGV
   communicate with the central dispatching agent through the network,
   dynamically planning transportation routes based on real-time traffic
   conditions to improve the efficiency of material distribution.

   c.  Interaction through satellite networks In the industrial
   scenario, the LAN establishes a low-delay and highly reliable
   communication environment for agents, enabling efficient
   interconnection among production equipment, logistics robots, and
   management systems.  For example, in the warehousing and logistics



Han, et al.              Expires 8 January 2026                 [Page 4]

Internet-Draft   The Impact of AI Agent to Network Infra       July 2025


   process, the agents carried by AGV communicate with the central
   dispatching agent through the network, dynamically planning
   transportation routes based on real-time traffic conditions to
   improve the efficiency of material distribution.

3.2.  Gap Analysis

3.2.1.  Agent ID management among heterougenous networks

   Agent ID management in heterogeneous networks refers to the processes
   and systems for uniquely identifying, authenticating, and managing
   agents (software entities, devices, or services) across networks with
   different architectures, protocols, and technologies.  Key challenges
   include interoperability, scalability, security, dynamicity, and
   privacy protection.

3.2.2.  Mobility Management (esp. for Non-3GPP networks)

   The AI agent era exacerbates existing gaps in mobility management,
   particularly in interoperability, security, and context awareness.
   Addressing these requires,

   AI-native mobility frameworks that prioritize agent intent over
   device-centric logic.  Dynamic, secure abstraction layers for cross-
   protocol interoperability.  Standardized interfaces for agents to
   share mobility intent with networks.  Energy-efficient, role-based
   QoS models tailored to autonomous AI agents.

3.2.3.  Pervassive Point-to-Point Secure Channel

   Pervasive P2P secure channels in the AI agent era require a paradigm
   shift from device-centric, static security to agent-aware, dynamic,
   and scalable frameworks.  Addressing these requires,

   Developing lightweight, context-aware trust models for ephemeral
   agent interactions.  Implementing distributed key management and low-
   latency protocols for massive agent swarms.  Creating adaptive
   security abstractions that work across heterogeneous networks.
   Integrating privacy-preserving techniques, such as metadata
   obfuscation and fine-grained access control, into core channel
   design.  Establishing AI-specific standards that align security with
   agent roles and autonomy.









Han, et al.              Expires 8 January 2026                 [Page 5]

Internet-Draft   The Impact of AI Agent to Network Infra       July 2025


3.3.  Potential new works

3.3.1.  Pervasive Mobility Managment in fixed networks

   TBD

3.3.2.  On-demand Point-to-Point Private Line service

   TBD

4.  Agent-based Network O&M

4.1.  Scenarios

4.1.1.  Autonomic O&M through AI Agent built into Devices

   In traditional congestion control method, there is a lack of cross-
   device historical data sharing and AI model collaboration between
   devices.  It is unable to adaptively optimize based on real-time
   traffic patterns.  When AI agents are introduced into network
   devices, intelligent collaboration can be achieved.  Devices
   synchronize real-time link bandwidth and TOP-N traffic
   characteristics through BGP extension.  The AI agent dynamically
   define congestion thresholds based on traffic data, replacing manual
   threshold configuration.  Upon detecting congestion, devices
   negotiate AI-generated policies (e.g., dynamic adjustment of Multi-
   Exit Discriminator (MED) values) and route traffic precisely to
   lightly loaded links.  Reinforcement learning is applied to
   dynamically optimize policy parameters during this process.

4.1.2.  Agent interactions between Devices and Controllers

   In the current IPv6 end-to-end traffic monitoring scenario, traffic
   data collection and analysis rely on manual intervention, while the
   large volume of live network traffic data results in high resource
   requirements.  When AI agents are deployed in network controllers and
   devices, intelligent collaboration can be achieved between
   controllers and edge devices.  The controller agent collects and
   monitors IPv6/IP traffic data in real time, and performs preliminary
   analysis including flow pattern recognition and IPv6/IPv4 traffic
   ratio trending.  The device agent collects customer traffic data,
   decomposes traffic distribution characteristics to identify high-
   value business scenarios, and synchronizes these insights to the
   controller agwnt.  The controller agent integrates global traffic
   ingress/egress data to construct regional traffic matrices, obtaining
   analysis results such as traffic distribution and link utilization.





Han, et al.              Expires 8 January 2026                 [Page 6]

Internet-Draft   The Impact of AI Agent to Network Infra       July 2025


4.2.  Potential new works

4.2.1.  Extension of Anima Framework & Protocols

   Considering the Anima Framework & Protocols [RFC7575] with AI Agent,
   which provides more intelligent operation and management of network
   devices to achieve the Intention-driven network and Auto-driven
   network.

4.2.2.  South-bound Interface Extension for Agentic O&M

   The relatted agent communication protocols such as MCP, A2A etc.,
   need to be extended to support the collabration between network
   devices and controller.

5.  Security Considerations

   TBD

6.  IANA Considerations

   TBD

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2.  Informative References

   [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
              Networking: Definitions and Design Goals", RFC 7575,
              DOI 10.17487/RFC7575, June 2015,
              <https://www.rfc-editor.org/info/rfc7575>.

Authors' Addresses






Han, et al.              Expires 8 January 2026                 [Page 7]

Internet-Draft   The Impact of AI Agent to Network Infra       July 2025


   Mengyao Han (editor)
   China Unicom
   Beijing
   China
   Email: hanmy12@chinaunicom.cn


   Naihan Zhang (editor)
   China Unicom
   Beijing
   China
   Email: zhangnh12@chinaunicom.cn


   Xinrui Gu (editor)
   China Unicom
   Beijing
   China
   Email: guxr12@chinaunicom.cn
































Han, et al.              Expires 8 January 2026                 [Page 8]


name: draft-yu-dmsc-ai-agent-use-cases-in-6g
rev: 01
title: AI Agent Use Cases and Requirements in 6G Network
time: 2026-01-12T03:16:03Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-16T03:16:03Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "ML traffic mgmt", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:03.420520+00:00
abstract:
This draft introduces use cases related to AI Agents in 6G networks,
   primarily referencing the technical report of 3GPP SA1 R20 Study on
   6G Use Cases and Service Requirements (TR 22.870).  It also
   elaborates on some of the requirements for introducing AI Agents into
   6G networks from the perspective of operators.

full_text:
Network Working Group                                              M. Yu
Internet-Draft                                                   A. Wang
Intended status: Informational                                     J. Li
Expires: 16 July 2026                                              Z. Li
                                                           China Telecom
                                                         12 January 2026


           AI Agent Use Cases and Requirements in 6G Network
               draft-yu-dmsc-ai-agent-use-cases-in-6g-01

Abstract

   This draft introduces use cases related to AI Agents in 6G networks,
   primarily referencing the technical report of 3GPP SA1 R20 Study on
   6G Use Cases and Service Requirements (TR 22.870).  It also
   elaborates on some of the requirements for introducing AI Agents into
   6G networks from the perspective of operators.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/.

   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."

   This Internet-Draft will expire on 16 July 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Yu, et al.                Expires 16 July 2026                  [Page 1]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Intent-based 6G Services Enabled by Network AI Agents . .   4
     2.2.  Device-Network Collaboration  . . . . . . . . . . . . . .   5
     2.3.  Multiple Devices Collaboration  . . . . . . . . . . . . .   5
     2.4.  Network-Application Collaboration . . . . . . . . . . . .   6
   3.  Potential Requirements for 6G Network . . . . . . . . . . . .   7
     3.1.  The Identity of AI Agents . . . . . . . . . . . . . . . .   7
     3.2.  Efficient Collaboration . . . . . . . . . . . . . . . . .   7
     3.3.  Cross-Domain Collaboration  . . . . . . . . . . . . . . .   7
     3.4.  Registration and Discovery  . . . . . . . . . . . . . . .   8
     3.5.  Service and Data Exposure . . . . . . . . . . . . . . . .   8
     3.6.  Reliability Assurance . . . . . . . . . . . . . . . . . .   8
     3.7.  High-performance Communication  . . . . . . . . . . . . .   8
     3.8.  Security  . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.9.  Energy Efficiency . . . . . . . . . . . . . . . . . . . .   8
   4.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Currently, with breakthroughs in large language models and multi-
   modal technologies, AI Agent has emerged as a major research focus in
   the industry.  Equipped with capabilities such as intent
   understanding, action planning, decision-making, task execution, and
   self-awareness, AI Agents can integrate environmental perception,
   memory, tool invocation, and multi-agent collaboration to accomplish
   complex tasks.  They have already demonstrated significant value in
   key fields like autonomous driving, intelligent customer service, and
   smart home systems.  In the 6G era, the introduction of AI Agent
   technology will enable operators to fully leverage the potential of
   mobile communication networks, significantly improving network
   operational efficiency and user experience.  As a result, AI Agents
   are expected to become a key research focus in future 6G networks,
   leading to deep integration between 6G and AI Agent technologies.




Yu, et al.                Expires 16 July 2026                  [Page 2]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


   In the 3GPP R20 standardization research for 6G, AI Agent has been
   one of the most discussed and debated topics, whether in SA1's study
   on 6G scenarios and requirements or SA2's research on network
   architecture.  In the SA1#109 meeting, 19 contributions related to AI
   Agents were submitted, which include 16 new use cases, with 4 use
   cases ultimately agreed.  And a preliminary definition of AI Agent
   from a capability perspective was adopted: "an automated intelligent
   entity capable of e.g interacting with its environment, acquiring
   contextual information, reasoning, self-learning, decision-making,
   executing tasks (autonomously or in collaboration with other Al
   Agents) to achieve a specific goal."  In the SA1#110 meeting, more
   than 30 contributions related to AI Agents were submitted, which
   include 22 new use cases, with 7 ultimately agreed.  In the SA2#172
   meeting, how to achieve deep integration of 6G network with AI
   technology (e.g. AI agent) has been explicitly included in the scope
   of 6G architecture study.

   This draft summarizes and categorizes the AI Agent-related use cases
   in 6G networks, with a brief introduction provided in Section 2.  In
   Section 3, from an operator's perspective, we elaborate on the
   potential requirements for introducing AI Agents into 6G networks,
   which should be considered when designing the agent communication
   related protocol in mobile communication network.  In Section 4, we
   conclude this draft.

2.  Use Cases

   AI Agents can be deployed at various locations within the 6G system.
   Depending on their deployment positions, AI Agents in 6G can be
   classified into On-device AI Agents, application AI Agents, network
   AI Agents, operation management AI Agents, etc.  For instance, on-
   device AI Agents refer to those implemented on end-user devices,
   while network AI Agents are those embedded within the 6G network.

   This section summarizes and categorizes AI Agent-related use cases in
   6G networks.  Unlike AI Agents in the Internet domain, use cases
   involving AI Agents in mobile communication networks place greater
   emphasis on how network AI Agents can deliver 6G services to users,
   as well as how different AI Agents within the 6G system coordinate
   with each other.











Yu, et al.                Expires 16 July 2026                  [Page 3]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


2.1.  Intent-based 6G Services Enabled by Network AI Agents

   By deploying AI Agents within 6G network, the 6G network can provide
   users with intent-based services.  These intelligent services may
   represent combinations of multiple network capabilities, such as
   communication, sensing, AI/ML, computing, data and more.  Users only
   need to express their intent to the 6G network, without requiring
   specialized technical knowledge to decompose the intent into
   technical requirements.  In this context, 3GPP SA1 has formally
   defined network intent as: Expectations including requirements, goals
   and constraints without specifying how to achieve them.

   Use Case A: Network-Wide Intent Fulfilment

   The 6G system interprets high-level service intents and translate
   such intent into concrete actions, including resource selection,
   configuration, and coordination across communication, sensing,
   computing, AI, and data capabilities utilizing network AI Agents.

   Use Case B: Dynamic Service Customization and Optimization

   The 6G network AI Agents dynamically adapt and optimize service
   behavior based on real-time context information, user requirements,
   and operational conditions in order to maintain desired service
   objectives.

                                   +-------------+
                                   | User Intent |
                                   +------+------+
                                          |
                                 +--------v----------+
                                 | Network AI Agents |
                                 +--------+----------+
                                          |
                           +--------------v----------------+
                           |    Service Orchestration &    |
                           |      Resource Optimization    |
                           +-------------------------------+

                        Figure 2.1 Intent-Based Network Control











Yu, et al.                Expires 16 July 2026                  [Page 4]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


2.2.  Device-Network Collaboration

   With the rapid advancement of technologies like smart phones and
   lightweight large-scale AI models, capabilities of user devices have
   significantly expanded, enabling autonomous execution of certain AI
   tasks and independent decision-making.  However, due to inherent
   device limitations - including constrained computational resources
   and battery capacity - deploying complex AI agents or performing
   sophisticated AI tasks locally on devices remains challenging.
   Consequently, investigating optimal collaboration mechanisms between
   UE-based AI agents and network-based AI agents to accomplish complex
   tasks represents a critical research direction for 6G networks.

   Use Case A: Enhanced UE Intelligence via Network Support

   The 6G system enables collaboration between on-device AI Agents and
   Network AI Agents such that devices can leverage network-provided
   context, analytics, and capabilities to improve local decision-making
   and task execution.

   Use Case B: Joint Device and Network Coordination Services

   On-device AI Agents and Network AI Agents jointly support
   coordination services in which adaptation decisions are distributed
   across device-side and network-side components.

        +-------------------+                  +-----------------------+
        | On-Device AI      | <--------------> | 6G Network AI Agents  |
        | Agent (UE)        |                  | and Network Support   |
        +-------------------+                  +-----------------------+
                  |                                        |
                  |                                        |
        +---------v---------+                  +-----------v----------+
        | Local Decisions   |                  | Network Capabilities |
        +-------------------+                  +----------------------+

                Figure 2.2 Device-Network AI Collaboration

2.3.  Multiple Devices Collaboration

   Under the powerful communication capabilities of 6G network, multiple
   on-device AI Agents can collaborate with each other to accomplish
   complex AI tasks.  These AI Agents may from either the same
   application or different applications.

   Use Case A: Cross-Device Intelligent Coordination





Yu, et al.                Expires 16 July 2026                  [Page 5]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


   The 6G system securely exchanges information among multiple on-device
   AI Agents to enable coordinated task execution across devices.

   Use Case B: Group AI Agent Collaboration Domains

   The 6G system dynamically establishes the collaboration domains that
   allow authorized AI Agents to participate in group-based task
   execution under defined security and policy constraints.

 +-------------------+    +-------------------+    +-------------------+
 |   On-Device AI    |    |   On-Device AI    |    |   On-Device AI    |
 | Agent (Device 1)  |<-->| Agent (Device 2)  |<-->| Agent (Device N)  |
 +-------------------+    +-------------------+    +-------------------+
             \                    |                     /
              \                   |                    /
        +--------------------------------------------------------+
        | Dynamic Multi-Agent Secured Collaboration(DMSC) Domain |
        +--------------------------------------------------------+

              Figure 2.3 Multiple On-device AI Agents Collaboration

2.4.  Network-Application Collaboration

   The 6G network AI Agents and application AI Agents can fully
   collaborate to accomplish network tasks.  On one hand, AI agents
   within the 6G network can invoke appropriate application AI Agents
   based on service characteristics.  On the other hand, the network AI
   Agents can share network data and domain expertise with application
   AI Agents, providing crucial data support for application AI Agents.

   Use Case A: Integrated Service Orchestration

   The 6G system enables cooperation between Network AI Agents and
   application-layer AI Agents to support end-to-end service
   orchestration through context sharing and coordinated control
   actions.

   Use Case B: Knowledge-Driven AI Enhancements

   The 6G system provides mechanisms for exposing network-generated
   knowledge, such as sensing data and telemetry, to authorized AI
   Agents in support of advanced reasoning and service optimization.









Yu, et al.                Expires 16 July 2026                  [Page 6]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


    +---------------------+                +-----------------------+
    |    Application      |                | 6G Network AI Agents  |
    |     AI Agents       |<-------------->|                       |
    +----------+----------+                +----------+------------+
               |                                      |
   +-----------v---------+                +-----------v------------------+
   | External Services   |                | Network Knowledge            |
   |  and Applications   |                | (Sensing, AI, Computing,etc) |
   +---------------------+                +------------------------------+

          Figure 2.4 Network-Application AI Collaboration

3.  Potential Requirements for 6G Network

   In this section, we present potential requirements to 6G network that
   may arise from the introduction of AI Agents in 6G mobile
   communication network from an operator's perspective.  Some of these
   potential requirements have already been agreed by 3GPP, while others
   have not yet been adopted by 3GPP.

3.1.  The Identity of AI Agents

   The 6G network shall support secure authentication, authorization,
   and management mechanisms for AI Agents' digital identities.  These
   AI Agents include on-device AI Agents, 3rd party AI Agents, Network
   AI Agents, etc.  A robust identity management mechanism is the
   prerequisite for interactions between users and AI Agents, as well as
   between different AI Agents.

3.2.  Efficient Collaboration

   The 6G network shall support efficient collaboration between
   different AI Agents and between AI Agents and the tools.  This
   include: developing agent communication protocols better suited for
   6G network characteristics, supporting multi-modal data (such as
   text, audio, video, etc.) interactions, enabling rapid transmission
   of massive data volumes, etc.

3.3.  Cross-Domain Collaboration

   Future AI agents will be ubiquitous, forming a device-network-
   industry end-to-end ecosystem. 6G network shall support the cross-
   domain collaboration of AI agents, including the device domain, RAN
   domain, core network domain, operation and management domain,
   application domain, etc.






Yu, et al.                Expires 16 July 2026                  [Page 7]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


3.4.  Registration and Discovery

   The 6G network shall support mechanisms for on-device AI Agents, 3rd
   party AI Agent, Network AI Agents and tools to register their
   attributes to 6G network, which enables efficient, cross-platforms
   and cross-domain AI Agents and tools discovery.  This may different
   from the discovery mechanism in existing agent communication related
   protocol (e.g. NRF discovery mechanism).

3.5.  Service and Data Exposure

   The 6G network shall support secure mechanisms to expose the 6G
   services (e.g. sensing service, computing service, AI/ML service,
   etc.) and network data (e.g. sensing data, positioning data, etc.) to
   3rd party AI Agents.

3.6.  Reliability Assurance

   The 6G network shall be able to provide mechanisms (e.g. network
   digital twin) to ensure the reliability and the validity of the
   decisions made by the AI Agents.  The decisions made by the AI Agents
   in 6G network may directly change the network status, parameters,
   configurations.  Only decisions that have been verified for
   reliability can be executed to change the network environment.

3.7.  High-performance Communication

   The 6G network shall enable high-performance communication, which may
   include low latency, high band-width, ultra-high data rate, etc.
   This is crucial for numerous scenarios such as device-network
   collaboration, network-application collaboration.

3.8.  Security

   The security of AI Agents communication in 6G includes the data
   protection and user consent.  Data privacy means the 6G network shall
   support end-to-end encryption for the interactions between AI Agents
   to ensure robust data protection and privacy security for sensitive
   information.  Besides, 6G network shall be able to provide mechanisms
   to collect the user consent for the local data collection.

3.9.  Energy Efficiency

   The 6G network shall be able to provide mechanisms to optimize the
   communication between AI Agents (especially for the on-device AI
   Agents) to reduce energy consumption.





Yu, et al.                Expires 16 July 2026                  [Page 8]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


4.  Conclusion

   AI Agents are expected to represent a critical innovation vector for
   6G.  This draft explores the transformative potential of AI Agents in
   6G network, outlining key use cases and operational requirements from
   an operator's perspective.  When designing agent communication
   related protocols for 6G network, the aforementioned requirements
   should be thoroughly considered and incorporated into the protocol
   architecture.

5.  Informative References

   [TR_22.870]
              "3GPP TR 22.870, "Study on 6G Use Cases and Service
              Requirements", 2025.".

Authors' Addresses

   Menghan Yu
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: yumh1@chinatelecom.cn


   Aijun Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: wangaj3@chinatelecom.cn


   Jinyan Li
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: lijinyan@chinatelecom.cn


   Zhen Li
   China Telecom
   Beiqijia Town, Changping District



Yu, et al.                Expires 16 July 2026                  [Page 9]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


   Beijing
   Beijing, 102209
   China
   Email: liz779@chinatelecom.cn















































Yu, et al.                Expires 16 July 2026                 [Page 10]


name: draft-chang-agent-token-efficient
rev: 02
title: A Token-efficient Data Layer for Agentic Communication
time: 2026-01-12T09:56:08Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-16T09:56:08Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Data formats/interop", "Model serving/inference"]
tags: []
fetched_at: 2026-02-27T22:56:03.420522+00:00
abstract:
Agentic communication fundamentally differs from traditional machine
   communication in that its outputs are recursively consumed and
   interpreted by Large Language Models (LLMs).  This unique
   characteristic makes efficient use of the model's limited context a
   critical requirement.  However, current agent communication protocols
   - such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) -
   often suffer from token or context bloat, caused by redundant schema
   definitions, verbose message structures, and inefficient capability
   exchanges.  As a result, a substantial number of tokens are
   unnecessarily consumed within the model’s context window.

   To address these issues, this draft defines the Agentic Data
   Optimization Layer (ADOL), a general and foundational data-layer for
   agent communication.  ADOL introduces a set of backward-compatible
   optimizations, including schema deduplication through JSON
   references, adaptive inclusion of optional fields, controllable
   response verbosity, and retrieval-based selection mechanisms.
   Collectively, these mechanisms reduce token consumption, enhance
   context efficiency, and provide a scalable foundation for future
   agent communication frameworks.

full_text:
Network Working Group                                           Z. Chang
Internet-Draft                                                     J. Li
Intended status: Informational                                    Z. Cao
Expires: 16 July 2026                                             Huawei
                                                         12 January 2026


         A Token-efficient Data Layer for Agentic Communication
                  draft-chang-agent-token-efficient-02

Abstract

   Agentic communication fundamentally differs from traditional machine
   communication in that its outputs are recursively consumed and
   interpreted by Large Language Models (LLMs).  This unique
   characteristic makes efficient use of the model's limited context a
   critical requirement.  However, current agent communication protocols
   - such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) -
   often suffer from token or context bloat, caused by redundant schema
   definitions, verbose message structures, and inefficient capability
   exchanges.  As a result, a substantial number of tokens are
   unnecessarily consumed within the model’s context window.

   To address these issues, this draft defines the Agentic Data
   Optimization Layer (ADOL), a general and foundational data-layer for
   agent communication.  ADOL introduces a set of backward-compatible
   optimizations, including schema deduplication through JSON
   references, adaptive inclusion of optional fields, controllable
   response verbosity, and retrieval-based selection mechanisms.
   Collectively, these mechanisms reduce token consumption, enhance
   context efficiency, and provide a scalable foundation for future
   agent communication frameworks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/.

   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."




Chang, et al.             Expires 16 July 2026                  [Page 1]

Internet-Draft              Abbreviated Title               January 2026


   This Internet-Draft will expire on 16 July 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Token Bloat Problem in A2A (Agent-Agent Communication)  .   3
     1.2.  Token Bloat Problem in MCP (Agent-Tool Communication) . .   3
     1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Repetitive Schema Across Tools  . . . . . . . . . . . . .   4
     2.2.  Excessive Optional Content  . . . . . . . . . . . . . . .   5
     2.3.  Overly Long Server Responses  . . . . . . . . . . . . . .   5
     2.4.  Inefficient Tool Selection  . . . . . . . . . . . . . . .   6
   3.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Schema Deduplication Using JSON References  . . . . . . .   7
     3.2.  Adaptive Optional Field Inclusion . . . . . . . . . . . .   8
     3.3.  Controllable Response Verbosity . . . . . . . . . . . . .   8
     3.4.  Tool Selection Mechanism  . . . . . . . . . . . . . . . .   9
   4.  Specification . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction









Chang, et al.             Expires 16 July 2026                  [Page 2]

Internet-Draft              Abbreviated Title               January 2026


1.1.  Token Bloat Problem in A2A (Agent-Agent Communication)

   The Agent-to-Agent (A2A) protocol defines structured message
   exchanges among multiple AI agents to support coordination,
   collaboration, and task delegation.  It provides a semantic framework
   through which agents can advertise their capabilities, exchange
   intermediate reasoning results, and invoke each other's functions in
   a standardized manner.

   A2A communication typically uses JSON-based message structures to
   ensure interoperability across heterogeneous agents.  However, as the
   number and complexity of agents increase, message size and redundancy
   also grow.  Agents often repeatedly exchange static or overlapping
   information (such as capability descriptions, metadata, or schema
   definitions) across multiple rounds of interaction.  This repetition
   leads to a phenomenon known as token bloat, where verbose or
   redundant message components consume excessive tokens in the LLM's
   context window.

   Token bloat degrades reasoning efficiency, increases latency, and
   elevates operational cost, particularly in large-scale or multi-agent
   deployments.  These challenges highlight the need for a unified and
   optimized data layer that reduces redundancy while preserving
   interoperability and semantic integrity.

1.2.  Token Bloat Problem in MCP (Agent-Tool Communication)

   The Model Context Protocol (MCP) defines a standardized interface for
   communication between Large Language Models (LLMs) and external tools
   or data sources.  It allows agents to describe, list, and invoke
   tools in a structured and interoperable manner.  MCP follows a
   client-server architecture consisting of a client (which connects to
   the MCP server), a server (which hosts tool definitions and logic),
   and a host (which coordinates the overall interaction).
   Conceptually, MCP consists of two layers:

   1. the data layer, which defines JSON-RPC-based primitives such as
   tools, resources, prompts, and notifications; and

   2. the transport layer, which handles connection establishment,
   message framing, and authorization.










Chang, et al.             Expires 16 July 2026                  [Page 3]

Internet-Draft              Abbreviated Title               January 2026


   As the number of MCP servers/tools increases, token bloat problem
   also emerges.  Each tool's detailed schema, including optional fields
   and human-readable descriptions, is transmitted to the model during
   reasoning.  Overlapping schemas, unfiltered tool lists, and verbose
   outputs also contribute to redundant token usage.  Though protocol
   correctness is unaffected, efficiency, latency, and cost are
   negatively impacted.  These limitations motivate the design of a more
   efficient data layer.

1.3.  Requirements Language

   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] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Problem Statement

   Agentic communication introduces unique efficiency challenges because
   all exchanged messages are recursively processed by Large Language
   Models (LLMs).  Every transmitted token consumes part of the model's
   limited context window, making redundancy and verbosity directly
   detrimental to reasoning efficiency and operational cost.

   Across current agent protocols - such as the [MCP] and [A2A] - four
   common inefficiencies are observed in the data-layer design:
   repetitive schemas, excessive optional content, verbose responses,
   and inefficient capability selection.  Together, these issues cause
   token and context bloat, limiting scalability and responsiveness in
   multi-agent systems.

2.1.  Repetitive Schema Across Tools

   When the LLM requests a list of tools from the server, the server
   returns a list of tools that includes the tool schema for all tools.
   However, tools hosted on the same MCP server often share similar or
   identical schema components, such as parameters or output schemas.
   These recurring elements not only introduce unnecessary repetition
   but also waste tokens when provided to LLM.  We have conducted an
   experiment to analyze the duplicate content in the schemas of 60
   tools within the official GitHub MCP server.  According to our
   results, the repetition rate of some contents within the 60 tool
   schemas, such as







Chang, et al.             Expires 16 July 2026                  [Page 4]

Internet-Draft              Abbreviated Title               January 2026


   {
     "repo": {
           "description": "Repository name",
           "type": "string"
         }
   }

                    Figure 1: Repetitive Schema Example

   reached 9.84%, indicating that it is necessary to improve the tool
   schemas to reduce such repetitive fields.

2.2.  Excessive Optional Content

   The MCP tool schema currently includes a variety of optional fields,
   such as output schemas and metadata.  In many cases, these fields are
   not essential for successful tool invocation.  For instance, the
   output schema is primarily intended to help the LLM interpret and
   structure the server’s response.  However, when the server’s output
   is already concise and semantically clear, the value of providing an
   additional output schema becomes marginal.  From the server’s
   standpoint, these fields are optional; yet, once transmitted, they
   are fully processed and tokenized by the LLM, contributing directly
   to prompt length and token overhead.  At present, the client has no
   mechanism to indicate whether such optional content should be
   included, resulting in unnecessary data exchange and reduced token
   efficiency.

2.3.  Overly Long Server Responses

   Under the current MCP architecture, the server is responsible for
   generating outputs that conform to its declared output schema.
   However, in many scenarios, this design results in overly verbose
   responses that exceed the LLM’s actual informational needs.  For
   example, when a weather-reporting tool provides detailed structured
   data—including temperature, humidity, wind speed, and visibility—an
   LLM may only require a subset of this information, such as
   temperature and humidity.  Since the server lacks awareness of the
   LLM’s contextual requirements, it always returns the complete output
   defined by the schema.  Consequently, the LLM must parse and tokenize
   all fields, even those irrelevant to the current prompt.  This
   behavior introduces unnecessary token consumption and increases
   computational cost, particularly in use cases where concise responses
   are sufficient.







Chang, et al.             Expires 16 July 2026                  [Page 5]

Internet-Draft              Abbreviated Title               January 2026


2.4.  Inefficient Tool Selection

   In practice, a service provider typically exposes a single MCP server
   that aggregates multiple tools under one endpoint.  These tools may
   span heterogeneous functional domains (e.g., translation, data
   retrieval, summarization), all of which are simultaneously
   discoverable by the MCP client.  While this design simplifies server-
   side deployment and management, it introduces inefficiency on the
   client side.  As the number of available tools grows, agents must
   evaluate and compare an increasingly large set of tool descriptions
   to determine the most relevant one.  This process not only increases
   computational overhead but also leads to selection ambiguity,
   especially when multiple tools exhibit overlapping functionalities or
   verbose metadata.  Empirical observations indicate that excessively
   detailed tool descriptions, while intended to enhance
   interpretability, can paradoxically increase token consumption during
   parsing and prompt formation.  Moreover, the expanded search space
   degrades the accuracy and efficiency of tool selection, particularly
   in real-time or resource-constrained scenarios.

3.  Solution Overview

       +--------------------------------------------------------+
       |         Agentic Data Optimization Layer (ADOL)         |
       +--------------------------------------------------------+

  +--------+               +---------------+               +-----------+
  |        |               |               |               |           |
  |  LLM   |               |    Client     | B&D.Tool/list |  Server   |
  |        |               |               +-------------->+           |
  |        |               |               | --short --tag |           |
  |        |               |               |               |           |
  |        | Curated List  |               |A.Curated List |           |
  |        <---------------+               <---------------+           |
  |        |               |               |               |           |
  |        |   Tool Call   |               |   Tool Call   |           |
  |        +-------------->+               +-------------->+           |
  |        |C.requireOutput|               |               |           |
  |        |               |               |               |           |
  |        |    Response   |               |    Response   |           |
  |        <---------------+ requireOutput <---------------+           |
  |        |   (Filtered)  |               |               |           |
  +--------+               +---------------+               +-----------+

                    Figure 2: Typical workflow of ADOL






Chang, et al.             Expires 16 July 2026                  [Page 6]

Internet-Draft              Abbreviated Title               January 2026


   To systematically address the inefficiencies identified above, this
   draft introduces the Agentic Data Optimization Layer (ADOL) -- a
   unified and backward-compatible enhancement to existing agentic data
   layers.  Rather than focusing on a single protocol, ADOL provides a
   generalized framework that improves the efficiency of data exchange
   across diverse agent communication settings, including both Model
   Context Protocol (MCP) and Agent-to-Agent (A2A) workflows.

   ADOL defines a set of lightweight mechanisms that preserve
   interoperability while significantly reducing redundant token usage
   in LLM-driven interactions.  It optimizes data compactness and
   adaptiveness without altering existing transport or semantic layers.
   As displayed in Figure 2, ADOL enhances the agentic data layer along
   four complementary dimensions:

   A.  Schema Deduplication: eliminate repetitive definitions through
       JSON references;

   B.  Adaptive Optional Inclusion: allow clients to request concise or
       full schemas;

   C.  Controllable Response Verbosity: enable models to specify the
       required output scope;

   D.  Context-Aware Tool Selection: limit tool exposure to those
       relevant to the current task.

   Together, these mechanisms establish a more efficient and extensible
   foundation for agentic communication, reducing token and context
   bloat while maintaining full compatibility with existing agent
   frameworks.

3.1.  Schema Deduplication Using JSON References

   To eliminate redundant schema definitions, MCP tool schemas may
   enable the JSON `$ref` mechanism, which was not supported in the
   original MCP architecture and thus leads to a significant amount of
   duplicate content.  This JSON `$ref` mechanism supports both internal
   and external references, as can be seen in [JSON].

   {
     "definitions": {
       "user": { "type": "object" }
     },
     "properties": {
       "data": { "$ref": "#/definitions/user" }
     }
   }



Chang, et al.             Expires 16 July 2026                  [Page 7]

Internet-Draft              Abbreviated Title               January 2026


                   Figure 3: Example: Internal Reference

   The internal reference case enables schema reuse within the same
   file, which applies to situations where there is multiple duplicate
   content within the same Json schema.

   {
     "$ref": "schema/common/user.json"
   }

                   Figure 4: Example: External Reference

   The external reference allows a tool schema to reference a shared
   template stored either locally or remotely.  The MCP host or client
   may cache these schemas to avoid repeated token consumption.  This
   mechanism is more suitable for situations where there is overlapping
   content among multiple tool schemas.  We have conducted extensive
   experiments where the tool schema in the server are modified by using
   $ref references.  The results show that the LLM can still accurately
   recognize and invoke these tools, introducing no backward
   incompatibility.

3.2.  Adaptive Optional Field Inclusion

   When responding to `tool/list` requests, servers SHOULD determine
   whether to include optional schema content based on the client
   request.  Specifically, an additional field `optional` is introduced
   in the server's tool configuration file, which contains schema
   content that is not mandatory.  If the client requests a “short” list
   (for example, via `tool/list --short`), the server SHOULD omit
   unnecessary optional contents included in the `optional` field and
   return a concise tool schema.  This conditional inclusion mechanism
   prevents unnecessary token usage.

3.3.  Controllable Response Verbosity

   Client SHOULD be capable of adjusting response verbosity based on the
   LLM’s request.  To address this, ADOL introduces a new
   `requireOutput` field in the tool schema.












Chang, et al.             Expires 16 July 2026                  [Page 8]

Internet-Draft              Abbreviated Title               January 2026


   {
     "requireOutput": {
       "description": "A list of output field names that the LLM expects to be returned from the tool's complete output.",
       "type": "array",
       "items": {
         "type": "string",
         "enum": ["toolOutcome_1", "toolOutcome_2", "toolOutcome_n"]
       },
       "uniqueItems": true
     }
   }

                       Figure 5: RequireOutput Schema

   When invoking a tool, the LLM first retrieves the tool list and
   corresponding schemas through the client.  Each tool schema may
   include a `requireOutput` field, which defines an optional list of
   output fields that can be selectively requested.  This field enables
   the LLM to specify which parts of a tool’s output are relevant to the
   current context.  Based on this field, the LLM infers which elements
   of the tool’s defined enumerated outcome are needed and passes the
   generated `requireOutput` schema to the MCP client.  Upon receiving
   the tool’s execution result, the MCP client filters the output
   according to `requireOutput` and returns the trimmed result to the
   LLM.  For example, in a weather-related tool, the output schema may
   contain multiple fields such as current conditions, temperature,
   humidity, and visibility.  The `requireOutput` allows the client to
   specify which subset of these results should be included (e.g.,
   `"requireOutput": ["temperature", "humidity"]`).  After receiving the
   server’s response, the client extracts and forwards only these fields
   to the LLM, filtering out unnecessary content while preserving
   semantic completeness.  This design ensures that the LLM only
   receives the necessary data for the current context, thereby reducing
   redundant information and minimizing token consumption.

3.4.  Tool Selection Mechanism

   To alleviate the token overhead caused by large tool lists, an
   retrieval-based mechanism is introduced.  Generally, The MCP client
   may include additional informative field in the `tool/list` request
   to indicate its requirements for tool.  The server then filters and
   returns only the tools that meet the need.  We propose two typical
   implementation approaches:








Chang, et al.             Expires 16 July 2026                  [Page 9]

Internet-Draft              Abbreviated Title               January 2026


   1.  Semantic-based retrieval: The client provides a natural language
       description of its requirement.  The server computes an embedding
       for the requirement and compares it with precomputed embeddings
       of all available tools.  Then, the server ranks the tools based
       on similarity and returns either the top-K most relevant tools or
       those whose similarity score exceeds a predefined threshold.

   2.  Tag-based retrieval: The client provides one or more predefined
       tool tags.  Each tool is assigned at least one tag.  The server
       returns the tools whose tags match the ones requested by the
       client.

   These two approaches can accommodate servers with different
   capabilities.  Approach 1 requires a more sophisticated server
   implementation, but it is expected to provide better retrieval
   performance and higher flexibility.  In contrast, Approach 2 is
   simpler to implement, though it introduces some usage limitations.

   By tool selection mechanism, the range of tools selected by the LLM
   is narrowed down, thereby reducing the token overhead of the LLM and
   improving the accuracy of tool selection.

4.  Specification

   The proposed extensions can be summarized as follows:

     +===================+============================+=============+
     | Mechanism         | Description                | Impact      |
     +===================+============================+=============+
     | JSON $ref support | Deduplicate schema content | Reduce      |
     |                   |                            | token usage |
     +-------------------+----------------------------+-------------+
     | Optional field    | Client-specified schema    | Reduce      |
     | control           | inclusion                  | token usage |
     +-------------------+----------------------------+-------------+
     | Response          | Adaptive detail level in   | Reduce      |
     | Verbosity control | output                     | token usage |
     +-------------------+----------------------------+-------------+
     | Retrieval-based   | Vectorized tool selection  | Improve     |
     | tool selection    |                            | accuracy    |
     +-------------------+----------------------------+-------------+

                        Table 1: Mechanism Summary

   Backward compatibility is maintained, as none of the proposed changes
   modify existing MCP schema semantics.





Chang, et al.             Expires 16 July 2026                 [Page 10]

Internet-Draft              Abbreviated Title               January 2026


5.  IANA Considerations

   This memo includes no request to IANA.

6.  Security Considerations

   Embedding-based retrieval introduces potential information exposure
   risks if tool embeddings or client embeddings are transmitted in
   plaintext.  Implementations SHOULD ensure encryption and access
   control when exchanging embedding vectors.  Schema caching and
   external references should only reference trusted sources to avoid
   code injection or schema poisoning.

   In addition to this, ADOL does not introduce new security
   vulnerabilities beyond those already present in existing agent
   communication protocols such as MCP or A2A.  However, implementers
   should ensure that any schema references or external resources
   retrieved via $ref are obtained from trusted sources to prevent
   schema injection or data tampering.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2.  Informative References

   [A2A]      Google, "Agent2Agent(A2A) Protocol", 2025,
              <https://a2a-protocol.org/latest>.

   [MCP]      Anthropic, "Model Context Protocol (MCP)", 2025,
              <https://modelcontextprotocol.io/docs/getting-started/
              intro>.

   [JSON]     Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON
              Schema: A Media Type for Describing JSON Documents", 2022.







Chang, et al.             Expires 16 July 2026                 [Page 11]

Internet-Draft              Abbreviated Title               January 2026


Acknowledgements

   The author thanks the MCP and A2A open-source community for the
   ongoing discussion and the SEP authors for foundational design
   insights.  The SEP link we proposed in the official MCP GitHub
   community is:
   https://github.com/modelcontextprotocol/modelcontextprotocol/
   issues/1576.

Authors' Addresses

   Zeze Chang
   Huawei
   No. 3, Shangdi Information Road, Haidian District
   Beijing
   100085
   China
   Email: changzeze@huawei.com


   Jinyang Li
   Huawei
   No. 3, Shangdi Information Road, Haidian District
   Beijing
   100085
   China
   Email: lijinyang9@huawei.com


   Zhen Cao
   Huawei
   No. 3, Shangdi Information Road, Haidian District
   Beijing
   100085
   China
   Email: zhen.cao@huawei.com















Chang, et al.             Expires 16 July 2026                 [Page 12]


name: draft-fu-nmop-agent-communication-framework
rev: 00
title: Agent Communication Framework for Network AIOps
time: 2026-01-25T05:44:04Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-29T05:44:04Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Autonomous netops", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:03.420524+00:00
abstract:
As the development of large model and agent technology, it is a trend
   for multi-agent collaboration to solve complex problems.  This
   document proposes an Agent Communication Framework, a multi-agent
   communication and collaboration framework that facilitates the
   coordination of heterogeneous multi-agents and supports intelligent
   network operations and maintenance (AIOps).  Its architecture
   includes an AI gateway and an Agent Name Service, along with
   capabilities such as monitoring and tracking, as well as security
   protection.  Agent Communication Framework provides a comprehensive
   solution for multi-agent communication and collaboration, laying the
   foundation for future interactive, scalable, secure, and controllable
   multi-agent network intelligent operations and maintenance.

full_text:
nmop                                                               Y. Fu
Internet-Draft                                                    Q. Sun
Intended status: Standards Track                                 X. Song
Expires: 29 July 2026                                             C. Xie
                                                           China Telecom
                                                         25 January 2026


            Agent Communication Framework for Network AIOps
             draft-fu-nmop-agent-communication-framework-00

Abstract

   As the development of large model and agent technology, it is a trend
   for multi-agent collaboration to solve complex problems.  This
   document proposes an Agent Communication Framework, a multi-agent
   communication and collaboration framework that facilitates the
   coordination of heterogeneous multi-agents and supports intelligent
   network operations and maintenance (AIOps).  Its architecture
   includes an AI gateway and an Agent Name Service, along with
   capabilities such as monitoring and tracking, as well as security
   protection.  Agent Communication Framework provides a comprehensive
   solution for multi-agent communication and collaboration, laying the
   foundation for future interactive, scalable, secure, and controllable
   multi-agent network intelligent operations and maintenance.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/.

   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."

   This Internet-Draft will expire on 29 July 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Fu, et al.                Expires 29 July 2026                  [Page 1]

Internet-Draft        Agent Communication Framework         January 2026


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Definition and Terminology  . . . . . . . . . . . . . . .   3
   2.  Agent Communication Framework and Components  . . . . . . . .   3
     2.1.  AI Gateway  . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Agent Name Service  . . . . . . . . . . . . . . . . . . .   7
       2.2.1.  Agent Accessing . . . . . . . . . . . . . . . . . . .   7
       2.2.2.  Agent Addressing  . . . . . . . . . . . . . . . . . .   8
       2.2.3.  Security Protection . . . . . . . . . . . . . . . . .   9
       2.2.4.  Capabilities Monitoring and Management  . . . . . . .   9
       2.2.5.  Cross-domain synchronization  . . . . . . . . . . . .   9
   3.  Use Case  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   As the rapid development of AI technology, network operations and
   maintenance have evolved from efficiency improvement to automation,
   through the Data-Driven Digital age with the rise of AIOps
   (intelligent network operations and maintenance), now striding
   towards the Agentic AI stage.  In this new phase, the collaborative
   capabilities of intelligent agents will drive operations and
   maintenance toward a higher level of autonomy.  However, current
   multi-agent collaboration still lacks reliable mechanisms for agent
   addressing, communication, and orchestration scheduling.  It
   introduces several requirements as below:

   • Agent registering and discovering：With the rapid developments of
   multi-agent collaborative scenarios, traditional service discovery
   mechanisms face several challenges.  They are unable to adapt to the
   multi-heterogeneous and dynamically changing capability of agents.
   There is a lack of a unified capability of registration and discovery
   framework for the cross-domain and spans different subject agents,



Fu, et al.                Expires 29 July 2026                  [Page 2]

Internet-Draft        Agent Communication Framework         January 2026


   result in low efficiency of task-driven precise collaboration.  There
   is an urgent need to build a global agent capability registration
   mechanism, dynamically maintain the real-time capability database of
   agents across the network, and generate optimal matching strategies
   based on task requirements.

   • Cross-domain interconnection: In some task-oriented collaboration
   scenarios, it may encounter interoperability challenges—both within
   intra-domain and inter-domain use cases.  In inter-domain scenario,
   agents belonging to different domains must discover, access, and
   securely interact with one another to enable effective collaboration.

   • Security Operations: To support large-scale deployment of
   intelligent agents, a comprehensive operation-level security
   framework is required that integrates management, access control,
   traceability, and authentication tailored for agent-centric
   environments., with security mechanisms and capabilities such as zero
   trust, communication encryption and decryption, and supervision
   embedded in the protocol.

1.1.  Requirements Language

   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] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Definition and Terminology

   • ACF：Agent Communication Framework

   • ANS：Agent Name Service

   • AI Gateway：AI GW

2.  Agent Communication Framework and Components

   To address the requirements described above, we propose an Agent
   Communication Framework for intra-domain and inter-domain agent
   communications.  It consists of two components: AI Gateway and Agent
   Name Service (ANS).  It is the “Connection and control Hub” for agent
   communication.  The overview of the agent communication framework is
   shown in Figure 1.







Fu, et al.                Expires 29 July 2026                  [Page 3]

Internet-Draft        Agent Communication Framework         January 2026


    +---------------------------+     +----------------------------+
    |                           |     |                            |
    |      Domain1:   ACF       |     |      Domain2:   ACF        |
    |                           |     |                            |
    |                           |     |                            |
    |  +--------------------+   |     |  +---------------------+   |
    |  |                    |   |     |  |                     |   |
    |  | Agent Name Service <---+-----+--> Agent Name Service  |   |
    |  |                    |   |     |  |                     |   |
    |  +---------^----------+   |     |  +--------^------------+   |
    |            |              |     |           |                |
    |            |              |     |           |                |
    |      +-----v-----+--<-----+-----+--->--+----v------+         |
    |      |           |        |     |      |           |         |
    |      |           |        |     |      |           |         |
    |  +---v---+   +---v---+    |     |  +---v---+   +---v-- +     |
    |  |       |   |       |    |     |  |       |   |       |     |
    |  | AI GW |   | AI GW |    |     |  | AI GW |   | AI GW |     |
    |  |       |   |       |    |     |  |       |   |       |     |
    |  +---^---+   +---^---+    |     |  +---^---+   +---^---+     |
    |      |           |        |     |      |           |         |
    |      |           |        |     |      |           |         |
    +------+-----------+--------+     +------+-----------+---------+
           |           |                     |           |
           |           |                     |           |
       +---v---+   +---v---+             +---v---+   +---v---+
       |       |   |       |             |       |   |       |
       | Agent |   | Agent |             | Agent |   | Agent |
       |       |   |       |             |       |   |       |
       +-------+   +-------+             +-------+   +-------+

   As described in Section 1, efficient interconnection among agents
   relies on clear identity information and capability-based discovery.
   Therefore, a unified identity identification and agent information
   management mechanism forms the foundation for the secure agent
   interconnection.  Agent Communication Framework issue unique identity
   IDs for each agent and establish an authentication framework to
   ensure the security of mutual visits.  They are capable of managing
   information for a massive number of agents, able to obtain agent
   information through multiple methods to ensure information
   comprehensiveness.  In Agent Communication Framework, a semantics-
   based dynamic agent addressing scheme is proposed to enhance the
   accuracy and flexibility of agent interconnection and collaboration,
   enabling interoperability across different domains.  In Intra-domain
   scenarios, the agent communication framework enables the discovery
   and management within the domain and presents a unified proxy
   externally.  Independent AI gateways realize the unified access and
   mutual discovery of agents within domains such as edge homes and the



Fu, et al.                Expires 29 July 2026                  [Page 4]

Internet-Draft        Agent Communication Framework         January 2026


   Internet of Things.  In inter-domain scenarios, information
   synchronization mechanism needs to be done by designing as an agent
   information repository in Agent Name Service (ANS) between different
   domains, combining with the existing DNS mechanisms for cross-domain
   addressing and discovery of agents.

2.1.  AI Gateway

   An AI Gateway is a reliable, efficient, and secure interconnection
   hub for agents.  The main functions of AI Gateway include:

   *  Service Proxy: Service Proxy function acts as an intelligent
      network address translation (NAT) layer that seamlessly translates
      between internal and external network addresses, enabling secure
      communication between private services and external clients.  By
      masking the identities and IP addresses of internal agents or
      services, it effectively hides the internal network topology from
      external access, thereby enhancing security, reducing exposure to
      potential threats, and simplifying service exposure management.

   *  Traffic forwarding and optimization: The AI Gateway provides
      intelligent traffic forwarding and optimization capabilities,
      including Quality of Service (QoS) guarantees to prioritize
      critical workloads, dynamic multi-channel selection for optimal
      path routing based on real-time network conditions, and packet
      compression to reduce bandwidth consumption and latency.
      Additionally, it leverages AI-driven analytics to adaptively
      manage traffic flows, ensure reliable delivery, and enhance
      overall network efficiency and user experience.

   *  Security protection: It provides comprehensive security protection
      by implementing end-to-end channel encryption to ensure data
      confidentiality and integrity during transmission, coupled with
      advanced traffic security detection and real-time threat
      mitigation mechanisms—such as anomaly detection, intrusion
      prevention, and malicious payload filtering—to safeguard against
      cyberattacks and unauthorized access.

   *  Monitoring and auditing: It provides comprehensive monitoring and
      auditing capabilities by continuously observing and logging all
      interaction behaviors between agents, including request sources,
      destinations, timestamps, data payloads (where permitted), and
      access patterns.

   In addition to the capabilities described above, the AI Gateway also
   supports the requirements of high concurrency, high reliability, as
   well as scalability.




Fu, et al.                Expires 29 July 2026                  [Page 5]

Internet-Draft        Agent Communication Framework         January 2026


   *  The AI Gateway supports persistent, always online sessions for
      heterogeneous agents, enabling seamless dynamic
      participation—where agents can join or leave a session at any time
      without disrupting the workflow.  It ensures session continuity
      through intelligent checkpointing and resumption mechanisms,
      allowing tasks to resume exactly from the point of interruption in
      the event of network disconnections or agent failures, without
      requiring the entire task to be restarted.  This capability
      maintains task integrity, improves resource efficiency, and
      enhances reliability in complex, multi-agent collaborative
      scenarios.

   *  The AI Gateway is designed to deliver highly concurrent, secure,
      and ultra-low-latency asynchronous communication for multi-agent
      systems, supporting scalable workloads with millions of
      simultaneous connections.  It ensures robust security through end-
      to-end encryption and fine-grained access control, while
      optimizing message routing and processing to minimize
      latency—enabling efficient, real-time coordination among large-
      scale heterogeneous agents

   *  The AI Gateway is designed for high scalability, supporting both
      horizontal and vertical expansion to accommodate growing multi-
      agent workloads.  Horizontally, it enables elastic scaling of
      gateways to handle increased traffic and agent density by
      dynamically adding or removing nodes based on demand.  Vertically,
      it implements recursive addressing across hierarchical gateway
      layers, allowing seamless inter-layer communication and efficient
      routing in large-scale, nested, or federated agent architectures.
      Together, these capabilities ensure the system can scale flexibly
      and efficiently—both outward across distributed deployments and
      upward through logical abstraction layers—while maintaining
      performance, consistency, and manageability.

   *  The AI Gateway supports high-reliability requirements for fully
      autonomous, human-intervention-free interactions among agents.  It
      ensures continuously stable and fault-resilient network
      connectivity through redundant pathways, automatic failover
      mechanism—thereby preventing communication disruptions that could
      otherwise trigger cascading failures across the agent ecosystem.
      This reliability is critical to maintaining uninterrupted task
      execution and system-wide stability in mission-critical multi-
      agent environments.








Fu, et al.                Expires 29 July 2026                  [Page 6]

Internet-Draft        Agent Communication Framework         January 2026


2.2.  Agent Name Service

   Agent Name Service provides access and semantic addressing function
   for multi-agents, and combines with the AI Gateway to provide
   security protection and monitoring capabilities.

2.2.1.  Agent Accessing

   *  Registration: The Agent Name Service (ANS) provides a secure and
      structured access mechanism for intelligent agents through an
      integrated registration and identity management mechanism.  It
      begins with the Registration Module, which receives registration
      requests from agents, validates their legitimacy (e.g., through
      credentials, tokens, or domain policies), and initiates the
      enrollment process.  The Security Module then handles
      cryptographic identity provisioning by accepting the agent’s
      Certificate Signing Request (CSR), verifying its authenticity, and
      issuing a signed certificate to establish trusted identity.
      Finally, the Registry securely stores each agent’s
      metadata—including its unique identifier, certificate,
      capabilities—enabling reliable discovery, authentication, and
      secure communication across the multi-agents.  This end-to-end
      workflow ensures that only authorized agents are admitted into the
      system, with verifiable identities and consistent governance.



























Fu, et al.                Expires 29 July 2026                  [Page 7]

Internet-Draft        Agent Communication Framework         January 2026


   *  Update, Renewal and Revocation: The Agent Name Service (ANS)
      supports comprehensive lifecycle management for registered agents
      through secure and auditable update, renewal, and revocation
      operations.  For updates, agents may submit requests to modify
      their metadata—such as capabilities, protocols, or agent Card
      information.  The ANS server performs signature verification to
      authenticate the request and ensures backward compatibility; if
      the changes introduce incompatibilities, the agent must update its
      version number and do re-registration.  Upon successful
      validation, the ANS updates the corresponding versioned record in
      its registry.  For certificate renewal, agents initiate a renewal
      request before their current certificate expires.  The ANS
      validates the agent’s identity via cryptographic signature
      verification.  After confirmation, it issues a new signed
      certificate while updating the associated agent entry—ensuring
      uninterrupted, trusted operation without service disruption.  For
      revocation, agents or administrators can request certificate
      invalidation in cases of key expiration.  After verifying the
      authenticity of the revocation request through signature checks,
      the ANS permanently removes the agent’s certificate and associated
      metadata from the registry, immediately terminating its ability to
      access.  All operations are executed under strict cryptographic
      validation and audit logging, ensuring integrity, traceability,
      and continuous security across the agent lifecycle.

2.2.2.  Agent Addressing

   The Agent Name Service (ANS) provides a millisecond-level Semantic
   Addressing Query capability that enables agent discovery—allowing
   users or systems to express intent in plain language (e.g., “Poor
   mobile signal and unstable broadband at home”) and automatically
   resolving it to the most relevant agents (e.g., Home Broadband Agent
   and Wireless Network Optimization Agent).  Semantic-based addressing
   and discovery of agents requires the Agent Name Service (ANS) to
   possess comprehensive, detailed descriptive information for all
   agents.  This functionality is implemented through three coordinated
   components:

   • The Resolution Module receives semantic resolution requests from
   agents and leverages RAG techniques to interpret the query and match
   it to appropriate agent. • The Registry then retrieves the
   corresponding agent’s metadata—including its capabilities, protocol
   details, and certificate—based on the resolved semantic intent. •
   Finally, the Security Module cryptographically signs the retrieved
   agent information and certificate using the private key, ensuring
   authenticity and integrity before returning the signed response to
   the requester.




Fu, et al.                Expires 29 July 2026                  [Page 8]

Internet-Draft        Agent Communication Framework         January 2026


2.2.3.  Security Protection

   The Agent Name Service (ANS) incorporates robust security and
   governance mechanisms to ensure safe and controlled agent
   interactions.  It enforces fine-grained permission control at the
   agent level through a structured workflow that includes registration
   requests, administrative approval, and explicit
   authorization—ensuring that only vetted agents gain access to
   specific capabilities or resources.

   To counter adversarial inputs, ANS integrates prompt injection
   prevention by inspecting all incoming instructions or queries for
   malicious patterns, obfuscated commands, or attempts to hijack agent
   behavior, thereby safeguarding the integrity of agent operations.

   Additionally, it implements tiered content security protection to
   prevent sensitive information leakage, applying data classification
   policies, context-aware filtering, and output sanitization based on
   sensitivity levels.

2.2.4.  Capabilities Monitoring and Management

   The Agent Name Service (ANS) enables real-time monitoring of agent
   reference, dynamically constructs a graph of agent relationships to
   visualize interaction patterns and dependencies across the domain,
   and supports proactive intervention in anomalous or unauthorized
   behaviors.

   The Agent Name Service (ANS) provides intelligent agent capability
   management by systematically evaluating and verifying the functional
   competencies, performance characteristics, and operational boundaries
   of registered agents.  This includes assessing declared capabilities,
   validating actual behavior through runtime evidence or sandboxed
   testing, and maintaining a trusted, up-to-date profile of each
   agent’s verified skills.  By ensuring that advertised capabilities
   accurately reflect real-world functionality, ANS enables reliable
   agent discovery, safe composition, and context-aware orchestration
   within dynamic multi-agent domains.

2.2.5.  Cross-domain synchronization

   The Agent Name Service (ANS) enables cross-domain collaboration among
   intelligent agents by securely synchronizing agent information.  In
   inter-domain scenarios, information synchronization mechanism needs
   to be done by designing as an agent information repository in ANS
   between different domains, and combining with the existing DNS
   mechanisms for cross-domain addressing and discovery of agents.




Fu, et al.                Expires 29 July 2026                  [Page 9]

Internet-Draft        Agent Communication Framework         January 2026


3.  Use Case

   *  Case 1: Home Broadband Service Installation

   In the scenario of handling home broadband service installation, we
   employ a collaborative system comprising 13 agents, including the
   Intent Recognition Agent, Domain-Specific Configuration Agent, Master
   Control Agent, Service Validation Agent etc.

   Phase 1: Service intent recognition

   Agent Used: Intent Recognition Agent; Master Control Agent of service
   installation

   Action: 1.Identify users' service installation requirements by the
   Intention Recognition Agent.  2.Automatically send the structured
   service intent to the Master Control Agent.

   Phase 2: Service Orchestration and Resource Allocation

   Agent Used: Master Control Agent of service installation; Service
   Orchestration and Resource Allocation Agent

   Action: 1.The Master Control Agent sends the service installation
   request to the Service Orchestration and Resource Allocation Agent,
   completes the planning of the service path and the evaluation and
   allocation of resources.  2.The Service Orchestration and Resource
   Allocation Agent feedback the service path and resource allocation
   plan back to the Master Control Agent.

   Phase 3: Data Preparation and Distribution

   Agent Used: Master Control Agent of service installation; Domain-
   Specific Configuration Agent

   Action: 1.The Service installation Master Control Agent initiates
   data preparation and configuration requests based on the plan.  2.The
   Domain-Specific Configuration Agent generates the systems
   corresponding configuration data and completes the automatic
   configuration of network elements (NEs) / network management systems.
   3.As the completion of the configuration, the results are
   automatically back to the Master Control Agent.

   Phase 4: Service Validation

   Agent Used: Master Control Agent of service installation; Domain-
   Specific Configuration Agent; Service Validation Agent




Fu, et al.                Expires 29 July 2026                 [Page 10]

Internet-Draft        Agent Communication Framework         January 2026


   Action: 1.The Master Control Agent triggers the automated service
   validation process.  2.The Service Validation Agent collaborates with
   the Domain-Specific Configuration Agent to query the data of
   configuration and status, and subsequently performs installation
   verification and validation.  3.The validation results are back to
   the Master Control Agent, forming a closed-loop validation cycle.

   Phase 5: Quality monitoring

   Agent Used: Installation and Maintenance Scheduling Agent

   Action: 1.The Installation and Maintenance Scheduling Agent performs
   continuous monitoring of customer services to ensure the quality of
   new installations.

   Phase 6: Customer feedback survey

   Agent Used: Personal Intelligent Assistant Agent

   Action: 1.The Personal Intelligent Assistant Agent schedules the
   installation/maintenance engineers for service follow-up and review.

   *  Case 2: Home Broadband Network Fault Diagnosis

   In the scenario of handling home broadband network fault diagnosis,
   we employ a collaborative system comprising 13 agents, including the
   Intent Recognition Agent, Preprocessing Agent, Single-Domain Root
   Cause Analysis Agent, Knowledge Q&A Agent, Fault Handling Agent etc.

   Phase 1: User Complaint Intent Recognition and Data Sensing

   Agent Used: Intent Recognition Agent; Preprocessing Agent

   Action: 1.Identify the type of user complaint by the Intention
   Recognition Agent.  2.Automatically trigger the data preprocessing
   function of the Preprocessing Agent based on the complaint type to
   collect key information such as user devices, alarms, and networks
   information.  3.Complete unified perception and aggregation of user-
   side data.

   Phase 2: Home Broadband Fault Complaint Handling

   Agent Used: MSingle-Domain Root Cause Analysis Agent; Perception Data
   Collection Agent; Knowledge Q&A Agent; Data Collection Agent

   Action: 1.The Single-Domain Root Cause Analysis Agent performs
   initial root cause analysis based on existing data.
   2.If information is insufficient, it triggers the data recollection



Fu, et al.                Expires 29 July 2026                 [Page 11]

Internet-Draft        Agent Communication Framework         January 2026


   mechanism of the Perception Data Collection Agent.  The Knowledge Q&A
   Agent guides the user to supplement key information.  The Data
   Collection Agent complements the missing data.  3. After multiple
   iterations, it outputs a most likely root cause, impact scope, and
   recommendations.

   Phase 3: Trouble Shooting

   Agent Used: Fault Handling Agent; Installation and Maintenance
   Scheduling Agent

   Action: 1.The Fault Handling Agent supports automatic fault recovery.
   2.If automatic repair fails, it triggers the Installation and
   Maintenance Scheduling Agent to generate the optimal dispatch plan
   based on the location and skills of the installation and maintenance
   engineers, as well as the urgency of the fault.

   Phase 4: Service Validation

   Agent Used: End-to-End Testing Agent

   Action: 1.The End-to-End Testing Agent initiates tests to ensure
   service consistency.

   Phase 5: Quality monitoring

   Agent Used: Installation and Maintenance Scheduling Agent

   Action: 1.The Installation and Maintenance Scheduling Agent performs
   continuous monitoring of customer services to to prevent recurring
   faults.

   Phase 6: Customer feedback survey

   Agent Used: Personal Intelligent Assistant Agent

   Action: 1.The Personal Intelligent Assistant Agent schedules the
   installation/maintenance engineers for service follow-up and review.

4.  Security Considerations

   TBD

5.  IANA Considerations

   This document has no IANA actions.

6.  Normative References



Fu, et al.                Expires 29 July 2026                 [Page 12]

Internet-Draft        Agent Communication Framework         January 2026


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Acknowledgements

   TBD

Authors' Addresses

   Yu Fu
   China Telecom
   Beijing
   China
   Email: fuy44@chinatelecom.cn


   Qing Sun
   China Telecom
   Beijing
   China
   Email: sunqiong@chinatelecom.cn


   Xin Song
   China Telecom
   Beijing
   China
   Email: songx18@chinatelecom.cn


   Chongfeng Xie
   China Telecom
   Beijing
   China
   Email: xiechf@chinatelecom.cn










Fu, et al.                Expires 29 July 2026                 [Page 13]


name: draft-pioli-agent-discovery
rev: 01
title: Agent Registration and Discovery Protocol (ARDP)
time: 2026-02-24T08:14:02Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-28T08:14:02Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Agent identity/auth", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:03.420526+00:00
abstract:
This document specifies the Agent Registration and Discovery Protocol
   (ARDP), a lightweight protocol for registering, discovering, and
   reaching autonomous software agents in distributed and federated
   environments.  ARDP provides stable agent identities, dynamic
   endpoint resolution, capability advertisement (including protocol
   selection among MCP, A2A, HTTP, and gRPC), minimal presence
   signaling, and a security-first discovery control plane.  ARDP is
   transport-agnostic and complementary to existing agent interaction
   protocols.

full_text:
Network Working Group                                           R. Pioli
Internet-Draft                                               Independent
Intended status: Informational                             February 2026
Expires: 28 August 2026


            Agent Registration and Discovery Protocol (ARDP)
                     draft-pioli-agent-discovery-01

Abstract

   This document specifies the Agent Registration and Discovery Protocol
   (ARDP), a lightweight protocol for registering, discovering, and
   reaching autonomous software agents in distributed and federated
   environments.  ARDP provides stable agent identities, dynamic
   endpoint resolution, capability advertisement (including protocol
   selection among MCP, A2A, HTTP, and gRPC), minimal presence
   signaling, and a security-first discovery control plane.  ARDP is
   transport-agnostic and complementary to existing agent interaction
   protocols.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/.

   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."

   This Internet-Draft will expire on 5 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (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



Pioli                    Expires 28 August 2026                 [Page 1]

Internet-Draft  Agent Registration and Discovery Protoco   February 2026


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Design Goals  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
   6.  Layering and Composition  . . . . . . . . . . . . . . . . . .   4
   7.  Agent Identity  . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  AID Syntax  . . . . . . . . . . . . . . . . . . . . . . .   5
     7.2.  Canonical Form  . . . . . . . . . . . . . . . . . . . . .   5
   8.  Registration Model  . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  REGISTER  . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.2.  DEREGISTER  . . . . . . . . . . . . . . . . . . . . . . .   6
     8.3.  Registration Semantics  . . . . . . . . . . . . . . . . .   6
     8.4.  TTL and Refresh . . . . . . . . . . . . . . . . . . . . .   6
     8.5.  Meta Resource . . . . . . . . . . . . . . . . . . . . . .   6
   9.  Discovery and Resolution  . . . . . . . . . . . . . . . . . .   7
     9.1.  RESOLVE . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.2.  QUERY . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.3.  Privacy Defaults and Redaction  . . . . . . . . . . . . .   7
   10. Capabilities  . . . . . . . . . . . . . . . . . . . . . . . .   7
     10.1.  Capability Bindings  . . . . . . . . . . . . . . . . . .   8
   11. Presence and Health . . . . . . . . . . . . . . . . . . . . .   8
   12. Security Considerations . . . . . . . . . . . . . . . . . . .   8
     12.1.  Proof of Control . . . . . . . . . . . . . . . . . . . .   8
       12.1.1.  Signed Payload . . . . . . . . . . . . . . . . . . .   8
       12.1.2.  Deterministic JSON Serialization . . . . . . . . . .   8
       12.1.3.  Nonce Acquisition  . . . . . . . . . . . . . . . . .   9
       12.1.4.  Verification . . . . . . . . . . . . . . . . . . . .   9
       12.1.5.  Algorithm Support  . . . . . . . . . . . . . . . . .   9
     12.2.  Authorization Scopes . . . . . . . . . . . . . . . . . .   9
   13. Federation  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     13.1.  Federation Profile (Minimum) . . . . . . . . . . . . . .  10
   14. Relationship to Existing Protocols  . . . . . . . . . . . . .  10
   15. Wire Format Sketch (Non-Normative)  . . . . . . . . . . . . .  10
     15.1.  Minimal HTTPS Binding  . . . . . . . . . . . . . . . . .  10
     15.2.  Error Model  . . . . . . . . . . . . . . . . . . . . . .  11
   16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     16.1.  Well-Known URI . . . . . . . . . . . . . . . . . . . . .  11
     16.2.  Agent Identifier Namespace . . . . . . . . . . . . . . .  11
   17. Capability Schema v0  . . . . . . . . . . . . . . . . . . . .  11
   18. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . .  12
   19. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12



Pioli                    Expires 28 August 2026                 [Page 2]

Internet-Draft  Agent Registration and Discovery Protoco   February 2026


   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Autonomous and semi-autonomous software agents introduce challenges
   in discoverability, reachability, and interoperability.  Agents may
   be ephemeral, mobile across execution environments, and implemented
   by heterogeneous vendors.

   ARDP addresses stable addressing of agents whose runtime location
   changes, authorized discovery by identity and declared capabilities,
   capability-driven selection among interaction protocols (e.g., MCP,
   A2A, HTTP, gRPC), and minimal, privacy-aware presence signaling.

2.  Design Goals

   Stable Identity; Dynamic Reachability; Minimalism (control plane
   only); Security by Default; Federation-Friendly; Extensibility.

3.  Non-Goals

   ARDP is intentionally narrow in scope.  The following are explicitly
   out of scope for this specification:

   1.  Agent-to-agent interaction, session management, task execution,
       and tool invocation protocols.  These are addressed by
       interaction protocols such as MCP and A2A.

   2.  Identity governance frameworks, IAM policy languages, and
       organizational trust models.  ARDP accepts identity attestations
       as inputs but does not define how they are issued or governed.

   3.  Runtime authorization token formats and enforcement proxies.
       ARDP provides discovery-time authorization scopes; runtime
       enforcement is delegated to interaction layers.

   4.  Post-execution evidence, audit trails, compliance logging
       formats, and non-repudiation mechanisms.

   5.  Billing, accounting, reputation, benchmarking, and other business
       frameworks.

   6.  Naming and bootstrap mechanisms beyond locating an ARDP
       authority.  DNS-based discovery, well-known URIs, or other
       bootstrap mechanisms may be used alongside ARDP.






Pioli                    Expires 28 August 2026                 [Page 3]

Internet-Draft  Agent Registration and Discovery Protoco   February 2026


   7.  Centralization requirements.  ARDP supports domain-scoped
       authorities and explicit federation without mandating a single
       global registry.

4.  Terminology

   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be
   interpreted as described in RFC 2119 and RFC 8174.

   *  Agent: Autonomous software entity capable of initiating and
      receiving interactions.

   *  Agent Identifier (AID): Stable, namespaced identifier of the form
      agent:<local-id>@<authority>.

   *  Registrar: Service that accepts agent registrations and maintains
      bindings.

   *  Resolver: Service that resolves an AID to active endpoints.

   *  Endpoint: Network location and protocol tuple through which an
      agent can be reached.

   *  Capability: Declarative description of supported protocols and
      interaction modes.

5.  Architecture Overview

   ARDP defines a logical control plane composed of registrars and
   resolvers.  Agents register their presence and capabilities with a
   registrar.  Authorized clients query resolvers to obtain endpoint and
   capability information.

6.  Layering and Composition

   ARDP operates as a control-plane protocol for registration and
   discovery.  It is designed to compose with other layers of the agent
   ecosystem:

   *  Transport Security: ARDP endpoints are typically secured using
      TLS, mTLS, or QUIC.  Transport security is orthogonal to ARDP
      semantics.








Pioli                    Expires 28 August 2026                 [Page 4]

Internet-Draft  Agent Registration and Discovery Protoco   February 2026


   *  Identity Governance and Attestation: ARDP uses identity
      attestations as inputs for proof-of-control during registration
      and for authorization decisions.  The issuance, revocation, and
      governance of these attestations are handled by external identity
      frameworks.

   *  Bootstrap Mechanisms: Clients may use DNS-based discovery, well-
      known URIs, or other mechanisms to locate ARDP registrars and
      resolvers.  ARDP does not prescribe a specific bootstrap method.

   *  Interaction Protocols: Once an agent's endpoint and capabilities
      are discovered via ARDP, clients select an appropriate interaction
      protocol (MCP, A2A, HTTP, gRPC) based on the advertised
      capabilities.  ARDP does not define interaction semantics.

   ARDP does not specify runtime enforcement mechanisms, session
   semantics, or evidence/audit systems.  These concerns are delegated
   to the appropriate layers.

7.  Agent Identity

   Each agent SHALL have a unique AID.  The authority component denotes
   the administrative authority responsible for the identity.

   Agents MUST prove control of an AID during registration using
   cryptographic credentials bound to that identity.

7.1.  AID Syntax

   An ARDP Agent Identifier (AID) MUST follow this grammar (ABNF per RFC
   5234):

aid              = "agent:" local-id "@" authority
local-id         = 1*( ALPHA / DIGIT / "_" / "-" / "." / "/" )
authority        = dns-name / internal-name / opaque-authority
dns-name         = 1*( ALPHA / DIGIT / "-" / "." )  ; see IDNA2008 notes
internal-name    = 1*( ALPHA / DIGIT / "-" / "." )
opaque-authority = "tenant-" 1*( ALPHA / DIGIT / "-" )

   Note: When internationalized domain names are used, implementers
   should follow the IDNA2008 RFC series.

7.2.  Canonical Form

   The canonical AID string is:

   1.  The literal prefix agent: in lowercase.




Pioli                    Expires 28 August 2026                 [Page 5]

Internet-Draft  Agent Registration and Discovery Protoco   February 2026


   2.  The authority normalized to lowercase (including IDNA2008
       normalization where applicable); internal-name is lowercased as-
       is.

   3.  local-id is case-sensitive and MUST be preserved as sent.

   4.  AIDs MUST be compared using the canonical form.

8.  Registration Model

8.1.  REGISTER

   A REGISTER request includes: AID; one or more endpoints; capability
   document (versioned); TTL; and cryptographic proof.

   Registrations are soft-state and MUST be refreshed before expiration.
   Refresh is performed by sending a new REGISTER request with the same
   (aid, binding_id) pair.

8.2.  DEREGISTER

   An agent MAY explicitly remove its registration.

8.3.  Registration Semantics

   Registration is idempotent on (aid, binding_id).  If a client sends
   the same (aid, binding_id), the server MUST treat it as a refresh.

   If a client sends the same aid with a different binding_id, the
   server MUST return a conflict error unless the client has
   registry:override scope.

8.4.  TTL and Refresh

   The server MUST be authoritative for expires_at and SHOULD return it
   in responses.

   Clients SHOULD refresh at <= 0.5 * ttl with random jitter.

   The server MUST define and enforce TTL bounds and advertise them in a
   metadata resource (recommended: /.well-known/ardp/meta).

8.5.  Meta Resource

   This section defines a metadata resource for deployments using HTTPS
   bindings.

   Path: GET /.well-known/ardp/meta



Pioli                    Expires 28 August 2026                 [Page 6]

Internet-Draft  Agent Registration and Discovery Protoco   February 2026


   The response advertises server capabilities, TTL bounds, supported
   protocols, and proof-of-control requirements:

   {
     "version": "1.0",
     "registrar_id": "ardp.example.com",
     "min_ttl": 30,
     "max_ttl": 3600,
     "default_ttl": 300,
     "supported_protocols": ["MCP", "A2A", "HTTP", "gRPC"],
     "supported_auth_methods": ["jws-proof-of-control"],
     "jws_required": true,
     "nonce_endpoint": "/.well-known/ardp/nonce",
     "supported_schema_versions": ["v0"],
     "compliance_mode": "standard"
   }

   When jws_required is true, the nonce_endpoint field indicates where
   clients acquire nonces for proof-of-control.

9.  Discovery and Resolution

9.1.  RESOLVE

   RESOLVE maps an AID to active endpoints and capabilities.  Access
   MUST be authorized via the registry:resolve scope.

9.2.  QUERY

   QUERY allows authorized discovery by capability or namespace.
   Results SHOULD be minimized to prevent metadata leakage.

   Access MUST be authorized via the registry:query scope.

9.3.  Privacy Defaults and Redaction

   By default, QUERY returns only aid and status.  Clients MAY request
   full details via a detail=full parameter.

   If redaction applies, the server MUST omit restricted fields and
   include "redacted": true in the response.

10.  Capabilities

   Capability documents MAY include supported protocols (MCP, A2A, HTTP,
   gRPC), transport bindings, authentication mechanisms, modalities,
   rate or cost hints, and protocol-specific metadata.  Capabilities are
   declarative and do not imply authorization.



Pioli                    Expires 28 August 2026                 [Page 7]

Internet-Draft  Agent Registration and Discovery Protoco   February 2026


10.1.  Capability Bindings

   Capabilities MUST include protocol-specific bindings when a protocol
   is declared.

11.  Presence and Health

   Presence is limited to: online, offline, degraded.

12.  Security Considerations

   Threats include identity spoofing, registration poisoning,
   unauthorized discovery, replay and downgrade attacks, and registrar
   compromise.

   Mitigations include cryptographic identity proof, signed
   registrations, strict authorization, rate limiting, and audit
   logging.

12.1.  Proof of Control

   Proof-of-control is REQUIRED for REGISTER and refresh operations.
   RESOLVE and QUERY do not use proof-of-control; they are authorized
   via scopes (see Authorization Scopes below).

12.1.1.  Signed Payload

   Clients MUST present a JWS-signed proof when registering or
   refreshing.  The signed payload consists of:

   *  The registration body, serialized as deterministic JSON

   *  A server-provided nonce

   *  An issued_at timestamp in RFC 3339 format

12.1.2.  Deterministic JSON Serialization

   The registration body MUST be serialized using deterministic JSON
   with the following rules:

   *  Object keys are sorted lexicographically (Unicode code point
      order)

   *  No insignificant whitespace between tokens

   *  Array element order is preserved




Pioli                    Expires 28 August 2026                 [Page 8]

Internet-Draft  Agent Registration and Discovery Protoco   February 2026


   *  Strings are encoded as UTF-8

   *  Numbers use minimal representation without trailing zeros

12.1.3.  Nonce Acquisition

   Clients acquire nonces via:

   GET /.well-known/ardp/nonce

   The response is a JSON object:

   {
     "nonce": "abc123...",
     "expires_in": 300
   }

   Nonces are single-use or have a narrow replay window.  The
   recommended TTL is 300 seconds.  The nonce endpoint is advertised in
   the /meta response when JWS proof-of-control is required.

12.1.4.  Verification

   Servers MUST verify the JWS using a JWKS key set (RFC 7517) or a
   configured trust store.

   Servers MUST enforce replay windows and clock skew tolerances.

12.1.5.  Algorithm Support

   Implementations MUST support ES256 (ECDSA using P-256 and SHA-256).

   Implementations MAY additionally support: RS256, RS384, RS512, PS256,
   PS384, PS512, ES384, ES512.

   EdDSA is not currently supported.

12.2.  Authorization Scopes

   Proof-of-control is used for REGISTER and refresh operations.
   Authorization scopes apply to all operations and are the primary
   access control mechanism for RESOLVE and QUERY.

   Operations require the following scopes:

   *  registry:register - required for REGISTER





Pioli                    Expires 28 August 2026                 [Page 9]

Internet-Draft  Agent Registration and Discovery Protoco   February 2026


   *  registry:refresh - required for refresh (re-REGISTER with same
      binding_id)

   *  registry:resolve - required for RESOLVE

   *  registry:query - required for QUERY

   *  registry:deregister - required for DEREGISTER

   *  registry:override - allows registering with a different binding_id
      for an existing AID

13.  Federation

   Registrars MAY federate across domains via explicit trust
   relationships and policy agreements.

13.1.  Federation Profile (Minimum)

   Federation is allowed only between explicit trust anchors.

   Responses from remote registrars MUST include provenance fields:
   origin_authority, origin_registrar_id, origin_signature.

   Caches MUST honor remote TTL and mark records as federated.

14.  Relationship to Existing Protocols

   ARDP complements, and does not replace, agent interaction protocols
   such as MCP and A2A.

15.  Wire Format Sketch (Non-Normative)

   JSON over HTTPS is shown as an example binding.  Alternative
   encodings (e.g., CBOR, gRPC) are possible.

15.1.  Minimal HTTPS Binding

   This section describes a minimal HTTPS binding for ARDP operations.
   All endpoints are under the /.well-known/ardp/ path prefix.

   *  GET /.well-known/ardp/meta - Returns server metadata including TTL
      bounds, supported protocols, and proof-of-control requirements.

   *  GET /.well-known/ardp/nonce - Returns a JSON object with nonce and
      expires_in fields for use in proof-of-control.





Pioli                    Expires 28 August 2026                [Page 10]

Internet-Draft  Agent Registration and Discovery Protoco   February 2026


   *  POST /.well-known/ardp/register - Registers or refreshes an agent.
      Refresh is performed by re-registering with the same (aid,
      binding_id).

   *  POST /.well-known/ardp/deregister - Removes an agent registration.

   *  GET /.well-known/ardp/resolve?aid={aid} - Resolves an AID to
      endpoints and capabilities.

   *  GET /.well-known/ardp/query - Queries for agents by capability or
      namespace.  Supports parameters: protocol, schema, limit, offset,
      detail.  Default returns minimal data; use detail=full to request
      complete records.

15.2.  Error Model

   Servers MUST return errors with: code (stable error code), message
   (human-readable), and correlation_id (for tracing).

   Required codes: invalid_aid, unauthorized, forbidden, conflict,
   not_found, expired.

16.  IANA Considerations

16.1.  Well-Known URI

   IANA is requested to register the following URI suffix per RFC 8615
   in the "Well-Known URIs" registry:

   URI suffix: ardp

   Change controller: IETF

   Specification document(s): This document

16.2.  Agent Identifier Namespace

   The agent: prefix is used as an internal identifier namespace and is
   not registered as a URI scheme in this version.

17.  Capability Schema v0

   A minimal JSON schema for capability documents is provided as a
   companion artifact in the GitHub mirror.







Pioli                    Expires 28 August 2026                [Page 11]

Internet-Draft  Agent Registration and Discovery Protoco   February 2026


18.  Open Issues

   *  Capability schema evolution

   *  Privacy-preserving discovery

   *  Federation bootstrapping

   *  Consider adopting RFC 8785 (JSON Canonicalization Scheme) for
      deterministic JSON serialization in a future revision

19.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, 2017,
              <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, 2002,
              <https://www.rfc-editor.org/rfc/rfc3339>.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, 2008,
              <https://www.rfc-editor.org/rfc/rfc5234>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, 2010, <https://www.rfc-editor.org/rfc/rfc5890>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, 2015,
              <https://www.rfc-editor.org/rfc/rfc7515>.

   [RFC7517]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Key
              (JWK)", RFC 7517, 2015,
              <https://www.rfc-editor.org/rfc/rfc7517>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, 2019,
              <https://www.rfc-editor.org/rfc/rfc8615>.

Author's Address





Pioli                    Expires 28 August 2026                [Page 12]

Internet-Draft  Agent Registration and Discovery Protoco   February 2026


   Roberto Pioli
   Independent
   Email: roberto.pioli@gmail.com
















































Pioli                    Expires 28 August 2026                [Page 13]


name: draft-yue-anima-agent-recovery-networks
rev: 00
title: Task-Oriented Multi-Agent Recovery Framework for High-Reliability in Converged Mobile Networks
time: 2026-02-06T07:09:03Z
group_uri: /api/v1/group/group/1027/
expires: 2026-02-06T04:11:23Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "A2A protocols", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:03.420529+00:00
abstract:
This document defines a task-oriented, agent-based method for fault
   recovery in converged public-private mobile networks.  The proposed
   method introduces a multi-agent collaboration framework that enables
   autonomous failure detection, scoped diagnosis, inter-domain
   coordination, and intent-driven policy reconfiguration.  It is
   particularly applicable in complex 5G/6G network deployments, such as
   Multi-Operator Core Networks (MOCN) and Standalone Non-Public
   Networks (SNPN), where traditional centralized management is
   insufficient for ensuring high service reliability and dynamic
   recovery.  The document also specifies protocol requirements for
   inter-agent communication, state consistency, and secure
   coordination, aiming to support interoperability and resilience
   across heterogeneous network domains.

full_text:
anima                                                        Y. Yue, Ed.
Internet-Draft                                             X. Zhang, Ed.
Intended status: Standards Track                            China Unicom
Expires: 5 February 2026                                   4 August 2025


  Task-Oriented Multi-Agent Recovery Framework for High-Reliability in
                       Converged Mobile Networks
               draft-yue-anima-agent-recovery-networks-00

Abstract

   This document defines a task-oriented, agent-based method for fault
   recovery in converged public-private mobile networks.  The proposed
   method introduces a multi-agent collaboration framework that enables
   autonomous failure detection, scoped diagnosis, inter-domain
   coordination, and intent-driven policy reconfiguration.  It is
   particularly applicable in complex 5G/6G network deployments, such as
   Multi-Operator Core Networks (MOCN) and Standalone Non-Public
   Networks (SNPN), where traditional centralized management is
   insufficient for ensuring high service reliability and dynamic
   recovery.  The document also specifies protocol requirements for
   inter-agent communication, state consistency, and secure
   coordination, aiming to support interoperability and resilience
   across heterogeneous network domains.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/.

   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."

   This Internet-Draft will expire on 5 February 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Yue & Zhang              Expires 5 February 2026                [Page 1]

Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Dynamic Fault Recovery in Shared 5G MOCN
           Infrastructure  . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Autonomous Recovery in Enterprise SNPN  . . . . . . . . .   4
     3.3.  Cross-Domain Policy Conflict Resolution . . . . . . . . .   4
     3.4.  SLA-Aware Remediation in AI-Driven RAN  . . . . . . . . .   5
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Protocol Requirements . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Agent Communications Interface  . . . . . . . . . . . . .   6
     5.2.  Message Semantics and Encoding  . . . . . . . . . . . . .   6
     5.3.  Reliability, Ordering, and Timeout Handling . . . . . . .   7
     5.4.  Security and Trust Requirements . . . . . . . . . . . . .   7
     5.5.  Behavior and State Consistency  . . . . . . . . . . . . .   7
     5.6.  Interoperability Considerations . . . . . . . . . . . . .   7
   6.  Task-Oriented Agent-Based Recovery Method for High-Reliability
           Assurance . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Objectives  . . . . . . . . . . . . . . . . . . . . . . .   8
     6.2.  Agent Roles and Responsibilities  . . . . . . . . . . . .   8
     6.3.  Recovery Workflow . . . . . . . . . . . . . . . . . . . .   9
       6.3.1.  Scoped Fault Correlation  . . . . . . . . . . . . . .   9
       6.3.2.  Intent-Driven Recovery Evaluation . . . . . . . . . .   9
       6.3.3.  Inter-Domain Coordination . . . . . . . . . . . . . .   9
       6.3.4.  Execution and Safety Enforcement  . . . . . . . . . .  10
       6.3.5.  Feedback Loop and Adaptive Monitoring . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10










Yue & Zhang              Expires 5 February 2026                [Page 2]

Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


1.  Introduction

   As mobile networks evolve toward 5G and 6G architectures, new
   deployment paradigms such as Multi-Operator Core Networks (MOCN),
   Shared RAN, and Standalone Non-Public Networks (SNPN) have emerged to
   support both public and enterprise services.  These converged
   deployments introduce unprecedented complexity in terms of topology,
   administrative boundaries, resource sharing, and dynamic service
   intent management.

   Ensuring high reliability in such networks is increasingly difficult
   using traditional centralized network management systems, which often
   suffer from limited scalability, slow responsiveness, and single
   points of failure.  These limitations are particularly critical in
   enterprise and industrial environments, where service-level
   agreements (SLAs) mandate deterministic latency, availability, and
   adaptability.

   This document introduces a task-oriented, agent-based recovery method
   that enables distributed fault detection, context-aware correlation,
   inter-agent negotiation, and closed-loop policy execution.  Agents
   operate at various roles — including telemetry monitoring, domain
   coordination, policy interpretation, and action enforcement — and
   communicate through a structured Agent Communication Interface (ACI).
   The method is designed to autonomously localize faults, assess
   recovery strategies based on service intents, and coordinate recovery
   actions across administrative domains, with minimal human
   intervention.

   In addition to describing the recovery workflow and agent roles, this
   document outlines the associated protocol requirements to ensure
   secure, consistent, and interoperable interactions among agents.
   These requirements cover communication semantics, message formats,
   transport assumptions, and behavioral guarantees.  The goal is to
   enable standards-compliant, intent-aware, and autonomous fault
   management in future mobile network infrastructures.

2.  Conventions and Terminology

   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 [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Abbreviations and definitions used in this document: *ACI: Agent
   Communication Interface. *DCA: Domain Coordination Agent. *EA:
   Execution Agent. *FDA: Fault Detection Agent. *FSM: Finite State



Yue & Zhang              Expires 5 February 2026                [Page 3]

Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


   Machine. *LLM: Large Language Model. *MOCN: Multi-Operator Core
   Network. *MTTR: Mean Time to Recovery. *PIA: Policy Interpretation
   Agent. *SLA: Service-Level Agreement. *SNPN: Standalone Non-Public
   Network. *URI: Uniform Resource Identifier.

3.  Use Cases

   The method defined in this document applies to several real-world use
   cases in future mobile network environments:

3.1.  Dynamic Fault Recovery in Shared 5G MOCN Infrastructure

   In Multi-Operator Core Network (MOCN) deployments, multiple mobile
   network operators (MNOs) share the same RAN and transport
   infrastructure.  A node failure or link degradation in the shared
   segment can affect multiple tenant slices simultaneously.  With
   agent-based coordination, local agents at affected nodes can detect
   the fault, and domain-level agents from each operator can negotiate
   temporary recovery strategies (e.g., re-routing or resource
   reallocation) without requiring centralized orchestration or full-
   stack configuration reloading.

3.2.  Autonomous Recovery in Enterprise SNPN

   Standalone Non-Public Networks (SNPN) are often deployed by
   enterprises to support on-site applications such as industrial
   automation, AGV coordination, or safety monitoring.  In these
   environments, recovery must be both low-latency and intent-aware.
   For example, if a compute node hosting a real-time controller fails,
   the agent system can trigger service migration to a backup node based
   on the intent to maintain <10ms latency for URLLC traffic, without
   requiring manual administrator intervention.

3.3.  Cross-Domain Policy Conflict Resolution

   In hybrid deployments where a public network operator provides
   managed service slices to enterprises, misaligned policies across
   administrative domains may cause service disruptions (e.g., route
   loops, priority mismatches).  With inter-domain agent negotiation,
   agents can exchange scoped views of current state and intent,
   evaluate compatibility, and agree on a temporary policy contract to
   preserve service continuity until a global policy reconciliation
   occurs.








Yue & Zhang              Expires 5 February 2026                [Page 4]

Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


3.4.  SLA-Aware Remediation in AI-Driven RAN

   With the rise of AI-native RAN optimization, agents embedded within
   distributed units (DU/CU) or edge compute nodes may detect
   performance anomalies (e.g., increased jitter, burst loss).  Rather
   than waiting for offline model retraining, the system can dynamically
   adapt configuration (e.g., buffer allocation, scheduler adjustment)
   using the agent-based recovery workflow to preserve SLA requirements
   in real time.

4.  Problem Statement

   In converged public-private mobile networks, ensuring service
   continuity and network reliability in the event of failures is a
   fundamental requirement, particularly for enterprise and critical
   infrastructure scenarios.  Traditional centralized network management
   systems often suffer from single points of failure and delayed
   recovery, which are unacceptable in contexts where deterministic
   availability and ultra-low downtime are essential.  Multi-agent
   systems enable fault-tolerant operation through distributed
   intelligence and redundancy.  When a failure occurs—such as link
   disconnection, node crash, or policy conflict—a well-coordinated
   group of agents can dynamically detect, localize, and mitigate the
   issue through real-time communication and cooperative decision-
   making.  This distributed resilience mechanism reduces mean time to
   recovery (MTTR) and minimizes the impact radius of failures.
   Moreover, in cross-domain environments (e.g., MOCN with multiple
   operators or SNPN with enterprise-hosted infrastructure), fault
   management becomes more complex due to administrative isolation and
   heterogeneous control planes.  Intelligent agents deployed at domain
   boundaries can negotiate fallback strategies, synchronize state
   across domains, and maintain policy consistency during partial
   outages.  For example, upon detecting performance degradation in a
   tenant slice, the agents can proactively rebalance traffic, reassign
   resources, or trigger intent re-interpretation without waiting for
   centralized orchestration.  Without agent-based failure
   collaboration, the system risks becoming fragmented, with isolated
   components unable to respond effectively to cascading failures.
   Therefore, enabling resilient, autonomous coordination among agents
   in failure scenarios is essential to support high-availability SLAs,
   enhance robustness against dynamic network threats, and reduce
   operational overhead in complex network environments.









Yue & Zhang              Expires 5 February 2026                [Page 5]

Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


5.  Protocol Requirements

   To support the efficient and intelligent transmission of sensing data
   in 6G environments, enhancements to the MoQ protocol are proposed.
   These enhancements aim to enrich MoQ metadata or header extensions to
   include key information required for intelligent routing, data
   classification, service mapping, and QoS-aware scheduling in sensing-
   centric applications.

5.1.  Agent Communications Interface

   This section specifies the protocol-level requirements to support the
   agent-based recovery method defined in Section 5.  These requirements
   cover message formats, communication interfaces, timing constraints,
   behavioral consistency, and inter-domain negotiation semantics.  The
   goal is to ensure interoperability, reliability, and intent-aware
   execution of fault recovery workflows across diverse network domains
   and agent implementations.  REQ-1: The system SHOULD define a
   structured Agent Communication Interface (ACI) to support
   asynchronous and event-driven communication among agents.  REQ-2: ACI
   SHOULD support the following core message types: FAULT_EVENT: Sent
   from FDA to DCA; conveys detected fault condition.
   SCOPE_CORRELATION_QUERY/REPLY: Between DCAs; used for inter-domain
   fault localization.  INTENT_REQUEST/RESPONSE: Between DCA and PIA;
   conveys service-level intent and policy goals.  RECOVERY_PROPOSAL:
   Sent from initiating DCA to peer DCA(s); contains proposed joint
   recovery actions.  RECOVERY_CONTRACT: Formalizes agreement among
   domains on resource reallocation and rollback.

   EXECUTION_COMMAND: Sent from DCA to EA to enact recovery actions.
   EXECUTION_STATUS: Sent from EA to DCA to report outcome and
   validation results.  REQ-3: All ACI messages SHOULD include: Agent
   identity and role Timestamp Message type and version Unique
   transaction/session ID Integrity protection (e.g., signature or HMAC)
   REQ-4: The ACI protocol SHOULD support both push and pull modes for
   event dissemination and agent querying.

5.2.  Message Semantics and Encoding

   REQ-5: Protocol messages SHOULD be encoded using a format that is
   both human-readable and machine-processable.  JSON and CBOR are
   RECOMMENDED; protocol buffers MAY be used in constrained
   environments.  REQ-6: Each message type SHOULD conform to a pre-
   defined schema, including required and optional fields.  REQ-7:
   Message payloads involving intent retrieval or policy proposals
   SHOULD include a service identifier that maps to a known SLA or
   intent profile.




Yue & Zhang              Expires 5 February 2026                [Page 6]

Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


5.3.  Reliability, Ordering, and Timeout Handling

   REQ-8: Protocol exchanges involving recovery workflows MUST support
   acknowledgment and retry mechanisms.  REQ-9: Agents participating in
   a recovery transaction MUST support: Timers for detecting negotiation
   or execution timeout Fallback strategies upon failure to reach
   consensus or apply action REQ-10: ACI message transport MUST
   guarantee in-order delivery of messages within a session context,
   particularly for multi-step negotiation sequences.

5.4.  Security and Trust Requirements

   REQ-11: All ACI communications MUST be secured using mutually
   authenticated channels.  REQ-12: Agents MUST maintain a local trust
   registry of peer agents and their associated roles, identities, and
   access policies.  REQ-13: Inter-domain messages MUST be
   cryptographically signed and include domain-level identifiers to
   prevent spoofing or replay.  REQ-14: Sensitive data in intent
   evaluation MUST be protected during transit and only exposed to
   authorized agents.

5.5.  Behavior and State Consistency

   REQ-15: Agents MUST implement finite state machines (FSMs) to ensure
   correct handling of message sequences and recovery states.  REQ-16:
   In case of multi-agent execution, agents MUST agree on task status
   codes to track workflow progress consistently.  REQ-17: Feedback and
   learning data SHOULD be stored in a common, queryable knowledge base
   accessible to policy training agents.

5.6.  Interoperability Considerations

   REQ-18: Implementations MUST support version negotiation for ACI
   messages to ensure forward compatibility.  REQ-19: Domain-specific
   extensions (e.g., for 5G MOCN, SNPN) MUST be encapsulated using an
   optional extension field, and MUST NOT interfere with baseline schema
   validation.  REQ-20: Recovery workflows MUST be idempotent where
   possible, allowing repeated execution without unintended side effects
   in failure or retry scenarios.












Yue & Zhang              Expires 5 February 2026                [Page 7]

Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


6.  Task-Oriented Agent-Based Recovery Method for High-Reliability
    Assurance

   This part defines a distributed, agent-based recovery method that
   supports high-reliability service assurance in converged public-
   private mobile networks.  The method enables autonomous failure
   detection, scoped diagnosis, and intent-driven policy adaptation
   through coordination among multiple intelligent agents.  It is
   designed to address both intra-domain and inter-domain failure
   scenarios while maintaining SLA compliance.

6.1.  Objectives

   The method is designed to fulfill the following objectives: (1)
   Resilience through distribution: Eliminate single points of failure
   by decentralizing failure detection and recovery logic across agents.
   (2) Scoped collaboration: Allow agents to reason over localized
   context while supporting inter-agent negotiation for broader fault
   scenarios. (3) Intent consistency: Ensure that all recovery decisions
   align with user or service-level intents registered in the system.
   (4) Closed-loop adaptability: Continuously monitor recovery outcomes
   and feed them into learning or policy refinement processes. (5) The
   method is applicable in deployment environments such as 5G MOCN,
   SNPN, or 6G hybrid infrastructures involving multiple tenants and
   administrative domains.

6.2.  Agent Roles and Responsibilities

   The method introduces four distinct roles for intelligent agents,
   each fulfilling a key functional responsibility in the recovery
   workflow: (1) Fault Detection Agent (FDA): Resides at network or
   compute nodes; performs real-time telemetry monitoring.  Upon
   threshold violation, constructs a structured fault event including
   metadata such as event ID, node ID, timestamp, metric type, and
   severity. (2) Domain Coordination Agent (DCA): Aggregates events from
   multiple FDAs to determine failure scope and severity.  Responsible
   for intra-domain coordination and inter-domain negotiation when
   needed. (3) Policy Interpretation Agent (PIA): Retrieves and parses
   registered service intents.  Evaluates recovery options and generates
   adaptive policy updates based on current state and available
   resources. (4) Execution Agent (EA): Applies the reconfiguration
   actions (e.g., rerouting, resource migration, parameter adjustment)
   and performs post-configuration checks to ensure compliance and
   stability.  All agents communicate over an Agent Communication
   Interface (ACI), which provides structured messaging primitives for
   event reporting, status querying, negotiation, and command dispatch.





Yue & Zhang              Expires 5 February 2026                [Page 8]

Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


6.3.  Recovery Workflow

   The recovery method consists of the following task-oriented workflow:
   ### Fault Detection and Event Generation FDA continuously monitors
   key performance metrics (e.g., latency, packet loss, CPU
   utilization).  On violation, FDA emits a structured fault event:
   +-------------------+-----------------------------+ | Field | Value |
   +-------------------+-----------------------------+ | event_id |
   e12345 | | node_id | node-A | | timestamp | 2025-07-21T08:00:00Z | |
   metric | link_loss | | value | 15.2 | | threshold | 10.0 | |
   severity | major |
   +-------------------+-----------------------------+ This event is
   transmitted to the local DCA via ACI.

6.3.1.  Scoped Fault Correlation

   DCA aggregates fault reports from FDAs and analyzes temporal-spatial
   correlations.  If patterns emerge indicating a localized or
   distributed failure domain, DCA maps the affected logical services
   (e.g., slices, functions, access nodes).  If the impact likely
   crosses domain boundaries (e.g., MOCN core or shared RAN), the DCA
   initiates inter-domain state queries.

6.3.2.  Intent-Driven Recovery Evaluation

   DCA invokes PIA with a fault-context descriptor.  PIA queries the
   intent registry and retrieves the affected service's constraints and
   goals, such as:
   +---------------------+----------------------------+ | Field |
   Value | +---------------------+----------------------------+ |
   intent_id | tenant-001-intent | | sla.latency | < 20ms | |
   sla.availability | 99.99% | | fallback_policy | [reroute,
   degrade_qos] | | priority | critical |
   +---------------------+----------------------------+ PIA evaluates
   multiple recovery strategies (e.g., traffic shift, resource
   migration, service downgrade) and scores them against SLA compliance
   and resource availability.

6.3.3.  Inter-Domain Coordination

   When faults span across domains, the DCA of the initiating domain
   sends a Recovery Proposal Message to peer DCAs.  Each DCA evaluates
   local resource availability and responds with either: Acceptance of
   shared recovery effort (with constraints), or Negotiation of a
   fallback agreement (with time limits and rollback conditions).  Upon
   consensus, a Recovery Execution Contract is established, which
   includes scope, roles, time windows, and validation checkpoints.




Yue & Zhang              Expires 5 February 2026                [Page 9]

Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


6.3.4.  Execution and Safety Enforcement

   DCA dispatches a recovery command to EA, which applies configurations
   (e.g., policy updates, slice rerouting, traffic prioritization).  EA
   performs pre- and post-checks to verify: Policy consistency
   Compliance with intent System stability post-update

6.3.5.  Feedback Loop and Adaptive Monitoring

   After execution, FDA switches to enhanced monitoring mode in affected
   areas (e.g., higher-frequency sampling, link probing).  DCA collects
   performance data and sends summary logs to a shared knowledge base
   for: Post-mortem analysis Learning model refinement (e.g.,
   reinforcement learning agent tuning) If instability persists, PIA may
   auto-trigger policy reevaluation or escalate to supervisory agent
   layer.

7.  Security Considerations

   TBD

8.  IANA Considerations

   TBD

9.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Yi Yue (editor)
   China Unicom
   Beijing
   China
   Email: yuey80@chinaunicom.cn








Yue & Zhang              Expires 5 February 2026               [Page 10]

Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 2025


   Xuebei Zhang (editor)
   China Unicom
   Beijing
   China
   Email: zhangxb170@chinaunicom.cn














































Yue & Zhang              Expires 5 February 2026               [Page 11]


name: draft-diaconu-agents-authz-info-sharing
rev: 00
title: Cross-Domain AuthZ Information sharing for Agents
time: 2026-02-06T14:58:24Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-10T14:58:24Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance", "AI safety/alignment"]
tags: []
fetched_at: 2026-02-27T22:56:03.420532+00:00
abstract:
Distributed Multi-Agent Systems consist of Agents and MCP Servers
   operating across multiple administrative domains, each with its own
   Identity Providers (IdPs) and Authorization Servers (AS).

   This document discusses the challenges and solution approaches for
   sharing authorization information securely and flexibly across
   domains, including the use of dynamic identity, interoperable claims,
   and verifiable credentials.

full_text:
Internet Engineering Task Force                               J. Diaconu
Internet-Draft                                               M. Yannuzzi
Intended status: Standards Track                                H. Muyal
Expires: 10 August 2026                                     F. Brockners
                                                                 N. Kale
                                                                   Cisco
                                                              A. Agarwal
                                                                 Skyfire
                                                              J. Hickman
                                                                Ory Corp
                                                                  A. Lal
                                                                     AWS
                                                         6 February 2026


           Cross-Domain AuthZ Information sharing for Agents
               draft-diaconu-agents-authz-info-sharing-00

Abstract

   Distributed Multi-Agent Systems consist of Agents and MCP Servers
   operating across multiple administrative domains, each with its own
   Identity Providers (IdPs) and Authorization Servers (AS).

   This document discusses the challenges and solution approaches for
   sharing authorization information securely and flexibly across
   domains, including the use of dynamic identity, interoperable claims,
   and verifiable credentials.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/.

   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."

   This Internet-Draft will expire on 10 August 2026.






Diaconu, et al.          Expires 10 August 2026                 [Page 1]

Internet-Draft          AuthZ Sharing for Agents           February 2026


Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
   3.  Abbreviations / Definitions . . . . . . . . . . . . . . . . .   4
   4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Cross-Domain Tool Invocation  . . . . . . . . . . . . . .   5
     4.2.  Enterprise Partnership Integration  . . . . . . . . . . .   5
     4.3.  Multi-Vendor Workflow Orchestration . . . . . . . . . . .   5
     4.4.  Supply Chain Data Exchange  . . . . . . . . . . . . . . .   6
     4.5.  Regulatory Compliance Across Jurisdictions  . . . . . . .   6
   5.  Requirements Summary  . . . . . . . . . . . . . . . . . . . .   7
   6.  Solution Approaches . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Solution Approach 1: Dynamic Client Registration (RFC
           7591) . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  Solution Approach 2: SCIM extensions  . . . . . . . . . .   8
     6.3.  Solution Approach 3: Client-ID Metadata . . . . . . . . .   9
     6.4.  Solution Approach 4: Client-ID Metadata + W3C Verifiable
           Credentials Extension . . . . . . . . . . . . . . . . . .  11
       6.4.1.  Delegation Semantics for Cross-Domain Multi-Agent
               Workflows . . . . . . . . . . . . . . . . . . . . . .  13
       6.4.2.  Agent Authorization Verifiable Credential Profile . .  18
   7.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
     7.1.  Client-ID Metadata Example  . . . . . . . . . . . . . . .  21
     7.2.  Verifiable Credential Example . . . . . . . . . . . . . .  21
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
     8.1.  Security Considerations . . . . . . . . . . . . . . . . .  23
       8.1.1.  Threat Model for Cross-Domain Authorization
               Sharing . . . . . . . . . . . . . . . . . . . . . . .  23
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
     10.1.  Informative References . . . . . . . . . . . . . . . . .  28
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29




Diaconu, et al.          Expires 10 August 2026                 [Page 2]

Internet-Draft          AuthZ Sharing for Agents           February 2026


1.  Introduction

   Distributed Multi-Agent Systems, consisting of Agents and Model
   Context Protocol (MCP) Servers, are increasingly deployed across
   multiple administrative domains.  Each domain typically operates its
   own Identity Providers (IdPs) and Authorization Servers (AS),
   creating a fundamental challenge: how can an agent from Organization
   A securely prove its identity and authorization to resources in
   Organization B?

   While OAuth 2.0 and related specifications provide robust
   authorization frameworks for human users and pre-registered clients,
   the emergence of autonomous agent systems operating across
   organizational boundaries presents new challenges that existing
   mechanisms do not fully address.

   This challenge is distinct from traditional cross-domain identity
   federation for human users.  Humans rarely delegate authority through
   multiple organizational boundaries.  Agents routinely do so--an
   orchestrator agent in Domain X may invoke a tool agent in Domain Y,
   which accesses an MCP server in Domain Z.  Existing authorization
   mechanisms such as OAuth 2.0 Dynamic Client Registration [RFC7591]
   and Token Exchange [RFC8693] assume single-domain operation or pre-
   established relationships, and do not address the dynamic, multi-hop
   delegation patterns that characterize modern agentic systems.

   This document analyzes the cross-domain agent authorization problem
   and evaluates solution approaches.  The proposed solution extends
   OAuth 2.0 Client-ID Metadata
   [I-D.ietf-oauth-client-id-metadata-document] with W3C Verifiable
   Credentials [W3C.VCDM2.0] to enable dynamic identity establishment
   without pre-registration across domains, cryptographically verifiable
   authorization claims that travel with the agent, multi-hop delegation
   with monotonic scope narrowing and accountability chains, and
   selective disclosure of sensitive authorization attributes.

   The document is structured as follows: Section 3 defines key
   terminology.  Section 4 presents use cases demonstrating cross-domain
   scenarios.  Section 8.1.1 identifies threats specific to cross-domain
   authorization sharing.  Section 5 establishes requirements and
   evaluates solution approaches.  Section 8.1 covers security
   considerations.









Diaconu, et al.          Expires 10 August 2026                 [Page 3]

Internet-Draft          AuthZ Sharing for Agents           February 2026


2.  Conventions Used in This Document

   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
   [RFC2119] and [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Abbreviations / Definitions

   Agent  An autonomous entity that performs tasks on behalf of a user
      or another program within a multi-agent system.

   MCP Server  A program that exposes specific capabilities, like data
      access or tools, to AI models through the Model Context Protocol
      (MCP).

   AS (Authorization Server)  A server that issues authorization tokens
      to clients after successfully authenticating them.

   IdP (Identity Provider)  A service that creates, manages, and
      verifies digital identities for users and service users, often for
      accessing multiple applications and services.

   Subject  The principal (user or service).

   Claim  Essentially a piece of information asserted about a subject.

   Domain  Scope over which a specific, uniform set of security policies
      and user management rules are enforced.

   VCDM 2.0  Verifiable Credentials Data Model 2.0, a W3C standard for
      expressing verifiable credentials on the web.

   VC  Verifiable Credential, a digital credential that is
      cryptographically secure and can be verified independently.

   SD-JWT  Selective Disclosure JSON Web Token, a JWT that allows the
      holder to disclose only specific parts of the token.

   DID  Decentralized Identifier, a new type of identifier that enables
      verifiable, self-sovereign digital identities.

4.  Use Cases

   The following use cases demonstrate scenarios where cross-domain
   agent authorization presents challenges not addressed by existing
   single-domain mechanisms.



Diaconu, et al.          Expires 10 August 2026                 [Page 4]

Internet-Draft          AuthZ Sharing for Agents           February 2026


4.1.  Cross-Domain Tool Invocation

   A coding assistant agent operated by Developer Tools Inc. needs to
   invoke a code review tool provided by Code Analysis Corp.  The tool
   is exposed as an MCP Server protected by Code Analysis Corp's
   Authorization Server.

   Cross-Domain Challenge  Developer Tools Inc.'s agent must present
      credentials that Code Analysis Corp's AS can verify, despite
      having no pre-existing trust relationship.  The AS must determine
      what operations the agent may perform based on claims issued by a
      foreign domain.

   Requirements  Verifiable agent and MCP server identity across domain
      boundaries, authorization claims that are interpretable by the
      receiving domain.

4.2.  Enterprise Partnership Integration

   Company A partners with Company B to provide integrated customer
   support services.  Company A deploys a support agent that needs to
   access Company B's customer ticketing system and knowledge base to
   resolve customer issues.

   Cross-Domain Challenge  Company A's agent authenticates using Company
      A's IdP and holds a Verifiable Credential issued by Company A.
      Company B's Authorization Server has no trust relationship with
      Company A's IdP--it cannot verify Company A's tokens.  Company B
      needs a mechanism to verify the agent's identity and authorization
      claims without requiring bilateral federation setup for every
      partner.

   Requirements  Dynamic identity verification across domains,
      verifiable compliance attestations, and scope restrictions that
      Company B's AS can enforce based on Company A's authorization
      grants.

4.3.  Multi-Vendor Workflow Orchestration

   A security operations workflow involves agents from multiple vendors:
   an orchestrator agent from Security Vendor X coordinates a threat
   intelligence agent from Vendor Y and a remediation agent from Vendor
   Z.  The orchestrator must delegate appropriate permissions to each
   specialized agent.

   Cross-Domain Challenge  The orchestrator in Domain X must delegate





Diaconu, et al.          Expires 10 August 2026                 [Page 5]

Internet-Draft          AuthZ Sharing for Agents           February 2026


      authority to agents in Domains Y and Z.  Each receiving domain
      must verify the delegation chain, ensure the delegated scope does
      not exceed what the originating principal authorized, and maintain
      an auditable record of the delegation chain.  Receiving domains
      must ensure that the authorization decisions do not rely on
      revoked, suspended, or superseded delegations by performing
      runtime delegation chain verification according to the local
      policy.

   Requirements  Multi-hop delegation with scope narrowing, cross-domain
      accountability chains, privacy-preserving identity claims, and
      domain-specific policy enforcement at each trust boundary
      crossing.

4.4.  Supply Chain Data Exchange

   A manufacturer's inventory management agent needs to query suppliers'
   availability systems.  Multiple suppliers operate their own
   authorization infrastructure.  The agent must access each supplier's
   MCP servers with appropriate credentials.

   Cross-Domain Challenge  Each supplier's AS must verify the
      manufacturer's agent without requiring manual pre-registration.
      Dynamic Client Registration [RFC7591] would require the agent to
      register separately with each supplier's AS, creating operational
      overhead and not providing cryptographic verification of the
      agent's authorization claims from its home domain.  The agent may
      need different permission levels at different suppliers based on
      partnership agreements.  Suppliers must be able to audit which
      manufacturer agents accessed their data.

   Requirements  Dynamic agent provisioning across multiple foreign
      domains, verifiable identity without pre-registration, and domain-
      specific scope mappings.

4.5.  Regulatory Compliance Across Jurisdictions

   A financial services agent operating in the EU needs to access data
   from a partner institution in the US.  Both jurisdictions have
   different regulatory requirements.

   Cross-Domain Challenge  The receiving domain's AS must verify that
      the requesting agent's compliance attestations meet local policy
      requirements.  The VC issued by the originating domain asserts
      compliance with GDPR; the receiving domain must determine whether
      this satisfies its own data handling requirements without assuming
      equivalence of compliance frameworks.




Diaconu, et al.          Expires 10 August 2026                 [Page 6]

Internet-Draft          AuthZ Sharing for Agents           February 2026


   Requirements  Verifiable compliance attestations that receiving
      domains can evaluate against local policies, and data sensitivity
      clearance, verification across regulatory boundaries.

5.  Requirements Summary

   A system for cross-domain sharing of authorization information of
   agents needs to meet the following set of requirements:

   *  *Dynamic Identity for Agents and MCP Servers:* The Agents and MCP
      Servers can onboard dynamically and get an assigned identity in
      the IdP.

   *  *Interoperability Across Domains:* The system must enable seamless
      interaction between Agents across different domains.

   *  *Flexible Definition of Claims:* Claims should be adaptable as
      they may vary from organization to organization.  They may include
      information related to authorization, compliance requirements,
      chains of delegation, and other domain-specific concerns.

   *  *Dynamic Management of Authorization Information:* The system must
      allow creation, removal, updating, and deletion of authorization
      information for agents, as agents can be highly dynamic.

   *  *Security and Privacy:* Ensuring secure and private sharing of
      authorization information across domains.

   *  *Compliance and Auditability:* Support for compliance with
      regulatory standards and auditability of authorization exchanges.

6.  Solution Approaches

6.1.  Solution Approach 1: Dynamic Client Registration (RFC 7591)

   *Description:* Dynamic Client Registration as outlined in [RFC7591]
   allows clients to register with an AS dynamically, facilitating the
   management of client credentials and metadata.

   *Discussion:*











Diaconu, et al.          Expires 10 August 2026                 [Page 7]

Internet-Draft          AuthZ Sharing for Agents           February 2026


   +==================+===============================+================+
   | Requirement      | Met or Partially Met          | Not Met        |
   +==================+===============================+================+
   | Dynamic Identity | Met                           |                |
   | for Agents and   |                               |                |
   | MCP Servers      |                               |                |
   +------------------+-------------------------------+----------------+
   | Interoperability | Partially Met (Granted by     |                |
   | Across Domains   | the Dynamic Registration,     |                |
   |                  | however no common ground      |                |
   |                  | between AS)                   |                |
   +------------------+-------------------------------+----------------+
   | Flexible         |                               | Not Met        |
   | Definition of    |                               | (OAuth2 claims |
   | Claims           |                               | only)          |
   +------------------+-------------------------------+----------------+
   | Dynamic          |                               | Not Met        |
   | Management of    |                               | (Delete or     |
   | Authorization    |                               | Update not     |
   | Information      |                               | supported)     |
   +------------------+-------------------------------+----------------+
   | Security and     |                               | Not Met        |
   | Privacy          |                               | (Claims are    |
   |                  |                               | shared but no  |
   |                  |                               | common schema) |
   +------------------+-------------------------------+----------------+
   | Compliance and   | Partially Met (Claims are     |                |
   | Auditability     | shared, APIs are auditable,   |                |
   |                  | but no regulatory standards   |                |
   |                  | are defined for the schema)   |                |
   +------------------+-------------------------------+----------------+

                                  Table 1

6.2.  Solution Approach 2: SCIM extensions

   [I-D.abbey-scim-agent-extension] proposes extending the SCIM (System
   for Cross-Domain Identity Management) protocol to standardize the
   provisioning, management, and governance of AI agents and other
   digital workers.

   [I-D.wahl-scim-agent-schema] is a companion document to the draft-
   abbey-scim-agent-extension.  Its purpose is to define the specific
   SCIM schema and attributes required to represent AI agents (digital
   workers) and agentic applications within the SCIM framework.

   *Description:* Provision Agents / MCP Servers through a SCIM
   extension.



Diaconu, et al.          Expires 10 August 2026                 [Page 8]

Internet-Draft          AuthZ Sharing for Agents           February 2026


   *Discussion:*

     +==================+======================================+=====+
     | Requirement      | Met or Partially Met                 | Not |
     |                  |                                      | Met |
     +==================+======================================+=====+
     | Dynamic Identity | Partially Met (SCIM support is       |     |
     | for Agents and   | limited and with constraints,        |     |
     | MCP Servers      | example for Azure: “Subsequent syncs |     |
     |                  | are triggered every 20-40 minutes”.) |     |
     +------------------+--------------------------------------+-----+
     | Interoperability | Partially Met (SCIM is supported and |     |
     | Across Domains   | schema is well defined)              |     |
     +------------------+--------------------------------------+-----+
     | Flexible         | Met (Defined by the schema)          |     |
     | Definition of    |                                      |     |
     | Claims           |                                      |     |
     +------------------+--------------------------------------+-----+
     | Dynamic          | Partially Met (SCIM support is       |     |
     | Management of    | limited and with constraints,        |     |
     | Authorization    | example for Azure: “Subsequent syncs |     |
     | Information      | are triggered every 20-40 minutes”.) |     |
     +------------------+--------------------------------------+-----+
     | Security and     | Partially Met (A schema is defined   |     |
     | Privacy          | but Selective Disclosure not         |     |
     |                  | supported)                           |     |
     +------------------+--------------------------------------+-----+
     | Compliance and   | Partially Met (Claims are shared,    |     |
     | Auditability     | APIs are auditable, but no           |     |
     |                  | regulatory standards are defined for |     |
     |                  | the schema)                          |     |
     +------------------+--------------------------------------+-----+

                                  Table 2

6.3.  Solution Approach 3: Client-ID Metadata

   *Description:* Client ID Metadata
   [I-D.ietf-oauth-client-id-metadata-document] is a method for OAuth
   clients to identify themselves using a URL, which points to a JSON
   file containing their OAuth metadata.  Instead of requiring pre-
   registration, an authorization server can fetch this JSON document at
   the client's provided URL to provision the identity.

   *Discussion:*






Diaconu, et al.          Expires 10 August 2026                 [Page 9]

Internet-Draft          AuthZ Sharing for Agents           February 2026


   +==================+==========================+=====================+
   | Requirement      | Met or Partially Met     | Not Met             |
   +==================+==========================+=====================+
   | Dynamic Identity | Met                      |                     |
   | for Agents and   |                          |                     |
   | MCP Servers      |                          |                     |
   +------------------+--------------------------+---------------------+
   | Interoperability | Met                      |                     |
   | Across Domains   |                          |                     |
   +------------------+--------------------------+---------------------+
   | Flexible         |                          | Not Met*            |
   | Definition of    |                          | (client_id is       |
   | Claims           |                          | common, all the     |
   |                  |                          | rest is limited     |
   |                  |                          | to OAuth2 claims)   |
   +------------------+--------------------------+---------------------+
   | Dynamic          | Met                      |                     |
   | Management of    |                          |                     |
   | Authorization    |                          |                     |
   | Information      |                          |                     |
   +------------------+--------------------------+---------------------+
   | Security and     | Partially Met** (A       |                     |
   | Privacy          | schema is defined but    |                     |
   |                  | Selective Disclosure not |                     |
   |                  | supported)               |                     |
   +------------------+--------------------------+---------------------+
   | Compliance and   | Partially Met** (Claims  |                     |
   | Auditability     | are shared, APIs are     |                     |
   |                  | auditable, but no        |                     |
   |                  | regulatory standards are |                     |
   |                  | defined for the schema)  |                     |
   +------------------+--------------------------+---------------------+

                                  Table 3

   **Flexible Definition of Claims:* The OAuth claims in the draft
   follow the claims exposed and defined by IANA OAuth Parameters.
   Hence, the metadata fields are limited to a fixed set of claims.
   This makes it difficult to convey richer features about the client,
   including provenance details, compliance attestations, or contextual
   trust scores without introducing vendor-specific extensions, thereby
   reducing portability and interoperability.









Diaconu, et al.          Expires 10 August 2026                [Page 10]

Internet-Draft          AuthZ Sharing for Agents           February 2026


   ***Security and Privacy, Compliance and Auditability:* All metadata
   is published to a publicly accessible endpoint.  There is no native
   ability to keep certain attributes private, apply selective
   disclosure, or restrict visibility based on trust relationships.
   Sensitive operational data or compliance-related data must be handled
   outside the metadata framework, leading to fragmented trust models.
   There is no mechanism for revocation and expiration.

6.4.  Solution Approach 4: Client-ID Metadata + W3C Verifiable
      Credentials Extension

  Agent (Client)             AuthZ Server (AS)         Metadata Endpoint
        |                            |                      |
        | 1. Authorization Request   |                      |
        |    (client_id = URL)       |                      |
        |--------------------------->|                      |
        |                            |                      |
        |                            | 2. HTTP GET (URL)    |
        |                            |--------------------->|
        |                            |                      |
        |                            | 3. Returns Metadata  |
        |                            |    (JWKS + "vc+jwt") |
        |                            |<---------------------|
        |                            |                      |
        |                            | 4. Validate Metadata |
        |                            |    & Verify VC Signature (JWKS)
        |                            |                      |

          Figure 1: Client-ID Metadata with VC Verification Flow

   *Description:* The proposed solution is based on Solution 3, but
   enhances the supported claims with a new claim, "vc+jwt", based on
   the Verifiable Credentials Data Model 2.0 from W3C.

   vc+jwt  A standard method used in decentralized identity to package
      and secure a digital credential.  The Verifiable Credential
      (VC)—the actual data proving a fact (e.g., identity or degree)—is
      encapsulated within a JSON Web Token (JWT), which provides a
      cryptographic signature from the issuer.  This signature allows
      any third party (the Verifier) to instantly confirm the
      credential's authenticity and integrity.  Modern formats like SD-
      JWT VC further enhance this by enabling the holder to share only
      specific parts of the credential (Selective Disclosure) to protect
      privacy.

   *Discussion:*





Diaconu, et al.          Expires 10 August 2026                [Page 11]

Internet-Draft          AuthZ Sharing for Agents           February 2026


      +===========================+======================+=========+
      | Requirement               | Met or Partially Met | Not Met |
      +===========================+======================+=========+
      | Dynamic Identity for      | Met                  |         |
      | Agents and MCP Servers    |                      |         |
      +---------------------------+----------------------+---------+
      | Interoperability Across   | Met (1)              |         |
      | Domains                   |                      |         |
      +---------------------------+----------------------+---------+
      | Flexible Definition of    | Met (2)              |         |
      | Claims                    |                      |         |
      +---------------------------+----------------------+---------+
      | Dynamic Management of     | Met                  |         |
      | Authorization Information |                      |         |
      +---------------------------+----------------------+---------+
      | Security and Privacy      | Met (3)              |         |
      +---------------------------+----------------------+---------+
      | Compliance and            | Met (4)              |         |
      | Auditability              |                      |         |
      +---------------------------+----------------------+---------+

                                 Table 4

   *Detailed explanations:*

   The W3C Verifiable Credentials Data Model 2.0 addresses the
   shortcomings of the previous Solution 3, by introducing a
   cryptographically verifiable and standards-based way to assert
   identities, capabilities, and compliance attestations.  It supports
   selective disclosure to protect sensitive information, enables time-
   bound and revocable authorizations, and ensures provenance tracking
   for audit and regulatory compliance.  They are part of a broader
   decentralized identity (DID) specification.

   Using the W3C Verifiable Credentials Data Model 2.0 for Agents, MCP
   Clients, and MCP Servers provides a standardized, cryptographically
   secure way to establish trust, delegate authority, and ensure
   interoperability across different systems.

   It enables Agents, MCP Clients, and MCP Servers to prove, among other
   things, their identities, identity issuers and provenance, supported
   skills and permitted actions through verifiable proofs, including
   support for fine-grained and time-bound access control, while
   maintaining transparency enabling audit trails for compliance.

   Additionally, it enhances privacy through selective disclosure and
   privacy-preserving proofs (e.g., allowing Agents to prove skills and
   authorized actions without exposing unnecessary details).



Diaconu, et al.          Expires 10 August 2026                [Page 12]

Internet-Draft          AuthZ Sharing for Agents           February 2026


   The Verifiable Credentials Data Model 2.0 is a W3C standard that fits
   the needs expressed above:

   *(1) Enhanced Interoperability:* VCDM 2.0 provides a standardized,
   extensible way to express identities, capabilities, and compliance
   data across different systems.  Its use of DIDs and schema-governed
   claims ensures that Agents, MCP Clients, and MCP Servers can verify
   and exchange trust information, enabling consistent interoperability
   across domains and platforms.

   *(2) Flexible Definition of Claims:* VCDM 2.0 allows arbitrary,
   schema-governed claims that can represent complex concepts such as
   provenance, software supply-chain attestations (e.g., SLSA), security
   posture, audit certifications (SOC2, ISO-27001), or dynamic trust
   signals.  These claims can be extended without breaking
   interoperability, thanks to widely adopted JSON-LD and schema
   registries.

   *(3) Security and Privacy:* Credentials are signed using verifiable
   cryptographic proofs (e.g., JSON Web Signatures, Data Integrity
   proofs).  This ensures that Agents, MCP clients, and MCP servers can
   verify the authenticity of claims without relying solely on HTTPS
   endpoints or centralized registries.  Through techniques like BBS+
   signatures, holders can disclose only the subset of claims required
   for a given authorization flow.  This is essential for scenarios
   where Agents must prove capabilities (e.g., "I'm allowed to execute
   this skill") without revealing unnecessary or sensitive identity
   attributes.

   *(4) Compliance and Auditability:* VCDM 2.0 enables cryptographically
   verifiable audit trails by binding each credential to an issuer,
   timestamp, and revocation status.  Compliance attestations can be
   embedded directly in credentials, and real-time revocation checks
   ensure they remain valid.  This provides trustworthy provenance,
   regulatory-grade accountability, and reliable lifecycle tracking
   across distributed systems.

6.4.1.  Delegation Semantics for Cross-Domain Multi-Agent Workflows

   Multi-agent systems frequently involve chains of delegation where
   Agent A invokes Agent B, which may invoke Agent C—potentially
   spanning multiple administrative domains.  This section defines
   authorization semantics for such delegation chains, addressing the
   novel challenges of cross-domain delegation.







Diaconu, et al.          Expires 10 August 2026                [Page 13]

Internet-Draft          AuthZ Sharing for Agents           February 2026


   Humans rarely delegate authority through multiple levels across
   organizational boundaries.  Agents routinely do so.  Existing
   delegation mechanisms ([RFC8693] Token Exchange 'act' claims) assume
   single-domain operation and do not address cross-domain VC-based
   delegation with verifiable accountability chains.

6.4.1.1.  Delegation Models

   This specification supports two delegation models:

   Direct Invocation  Agent A directly invokes MCP Server M using A's
      own credentials.  No delegation occurs; authorization is based
      solely on A's VC.

   Delegated Invocation (Cross-Domain)  Agent A in Domain X invokes
      Agent B in Domain Y to perform a task.  B acts on A's behalf (and
      transitively, on behalf of A's originating principal) when
      accessing resources.  The authorization decision considers both
      A's delegation grant and B's own credentials, applying Domain Y's
      policies.

   Domain X                          |  Domain Y
                                     |
   +-----------+   +---------+       |  +---------+   +--------------+
   | Principal |   | Agent A |       |  | Agent B |   | MCP Server M |
   |     P     |   |         |       |  |         |   |              |
   +-----------+   +---------+       |  +---------+   +--------------+
         |              |            |       |               |
         | 1. Task      |            |       |               |
         |------------->|            |       |               |
         |              |            |       |               |
         |              | 2. Delegate + VC(A)|               |
         |              |------------|------>|               |
         |              |            |       |               |
         |              |            |       | 3. Request    |
         |              |            |       |    + VC(B)    |
         |              |            |       |    + Deleg(A) |
         |              |            |       |-------------->|
         |              |            |       |               |
         |              |            |       |  4. Verify chain
         |              |            |       |  5. Apply local policy
         |              |            |       |  6. Authorize

                   Figure 2: Cross-Domain Delegation Flow







Diaconu, et al.          Expires 10 August 2026                [Page 14]

Internet-Draft          AuthZ Sharing for Agents           February 2026


6.4.1.2.  Scope Derivation Rules

   When Agent A delegates to Agent B (potentially across domains), B's
   effective scope MUST be computed as the intersection of:

   1.  A's delegatable scope: The subset of A's permissions that A is
       authorized to delegate

   2.  B's intrinsic scope: The permissions B holds in its own VC

   3.  Explicit delegation grant: What A actually delegated to B for
       this invocation

   4.  Receiving domain policy: The maximum scope the receiving domain
       permits for this cross-domain delegation

   Effective_Scope(B) = A.delegatable_scope
                        INTERSECT B.intrinsic_scope
                        INTERSECT Delegation.granted_scope
                        INTERSECT Receiving_Domain_Policy

                     Figure 3: Scope Derivation Formula

   This ensures:

   *  B cannot exceed A's authority (no privilege amplification)

   *  B cannot exceed its own authority (intrinsic limits apply)

   *  A can further restrict B for specific tasks (explicit grant)

   *  The receiving domain retains sovereignty over its resources (local
      policy)

   Implementations MUST enforce monotonic scope narrowing: at each
   delegation step, effective scope can only decrease or remain the
   same, never increase.

   This intersection semantics aligns with capability-based security
   principles (see: Mark Miller's Principle of Least Authority, Google
   Macaroons, Biscuit authorization tokens) and extends [RFC8693] Token
   Exchange delegation semantics to cross-domain VC-based scenarios.









Diaconu, et al.          Expires 10 August 2026                [Page 15]

Internet-Draft          AuthZ Sharing for Agents           February 2026


6.4.1.3.  Accountability Chain Construction

   Each delegation step MUST produce a verifiable record enabling cross-
   domain forensic reconstruction.To support revocation and scope-change
   handling, delegation records SHOULD enable downstream verifiers to
   identify and validate upstream delegation elements so that
   authorization decisions do not depend on revoked or superseded
   delegation claims.  The delegation record MUST include:

    +==================+=================+===========================+
    | Field            | Description     | Cross-Domain Relevance    |
    +==================+=================+===========================+
    | delegator_id     | Agent A's id    | Enables tracing to        |
    |                  | from its VC     | originating domain        |
    +------------------+-----------------+---------------------------+
    | delegator_domain | Domain that     | Identifies trust          |
    |                  | issued A's VC   | relationship to verify    |
    +------------------+-----------------+---------------------------+
    | delegatee_id     | Agent B's id    | Identifies receiving      |
    |                  | from its VC     | agent                     |
    +------------------+-----------------+---------------------------+
    | delegatee_domain | Domain that     | Identifies receiving      |
    |                  | issued B's VC   | domain                    |
    +------------------+-----------------+---------------------------+
    | timestamp        | Time of         | Temporal ordering for     |
    |                  | delegation      | forensics                 |
    +------------------+-----------------+---------------------------+
    | granted_scope    | Scopes          | Audit of intended         |
    |                  | delegated       | authorization             |
    +------------------+-----------------+---------------------------+
    | expiration       | Delegation      | MUST NOT exceed           |
    |                  | validity period | delegator's VC expiration |
    +------------------+-----------------+---------------------------+
    | chain_hash       | Cryptographic   | Ensures chain integrity   |
    |                  | binding to      | across domains            |
    |                  | prior chain     |                           |
    +------------------+-----------------+---------------------------+

                    Table 5: Delegation Record Fields

   The complete accountability chain enables:

   1.  Cross-domain attribution: Determining which principal originated
       a request that traversed multiple domains

   2.  Forensic reconstruction: Rebuilding the sequence of delegations
       across domain boundaries




Diaconu, et al.          Expires 10 August 2026                [Page 16]

Internet-Draft          AuthZ Sharing for Agents           February 2026


   3.  Coordinated revocation: Identifying downstream delegations in
       other domains that must be invalidated

6.4.1.4.  Delegation Depth Limits

   Implementations SHOULD enforce maximum delegation depth.  Cross-
   domain delegations SHOULD count toward depth limits regardless of
   whether they're same-domain or cross-domain.

   Receiving domains MAY impose stricter depth limits than the
   originating domain.  When a delegation would exceed the receiving
   domain's depth limit, the AS MUST reject the request with an error
   indicating the depth violation.

6.4.1.5.  Delegation Claims in VCs

   To express delegation authority in VCs, the following claims are
   defined for credentialSubject:

   {
     "credentialSubject": {
       "id": "https://example.com/agents/agent-a",
       "delegation": {
         "permitted": true,
         "maxDepth": 2,
         "crossDomainDelegation": {
           "permitted": true,
           "allowedDomains": ["partner.example.org"],
           "deniedDomains": ["competitor.example.com"]
         },
         "allowedDelegateeTypes": ["tool-agent", "workflow-agent"],
         "scopeRestrictions": {
           "nonDelegatable": ["admin:*", "pii:write"],
           "crossDomainNonDelegatable": ["internal:*"]
         }
       }
     }
   }

                    Figure 4: Delegation Claims Example

   delegation.permitted  Boolean indicating whether this agent may
      delegate.  Default: false.

   delegation.maxDepth  Maximum additional delegation hops this agent
      may initiate.  Default: 0.

   delegation.crossDomainDelegation.permitted  Whether cross-domain



Diaconu, et al.          Expires 10 August 2026                [Page 17]

Internet-Draft          AuthZ Sharing for Agents           February 2026


      delegation is allowed at all.

   delegation.crossDomainDelegation.allowedDomains  Domains to which
      delegation is permitted (wildcards allowed).

   delegation.scopeRestrictions.crossDomainNonDelegatable  Scopes that
      may be delegated within the same domain but MUST NOT be delegated
      across domain boundaries.

6.4.2.  Agent Authorization Verifiable Credential Profile

   This section defines a Verifiable Credential profile that enables
   interoperable cross-domain agent authorization.  The profile
   specifies claims that Authorization Servers in different domains can
   reliably interpret.

   W3C VCDM 2.0 is intentionally flexible.  For cross-domain
   interoperability, domains must agree on claim semantics.  This
   profile provides that common language.

6.4.2.1.  Profile Objectives

   The Agent Authorization VC Profile (AAVC) enables:

   *  Cross-domain interoperability: ASs in different domains can parse
      and evaluate the same VC

   *  Semantic clarity: Claim meanings are defined, reducing policy skew
      risk

   *  Extensibility: Organizations can add custom claims without
      breaking base interoperability

   *  Selective disclosure compatibility: Claims are structured to
      support SD-JWT VC presentation

6.4.2.2.  Required Claims for Cross-Domain Interoperability

   The credentialSubject MUST include these claims for a VC to be
   recognized across domains:

   id (required)  Globally unique identifier for the agent.  SHOULD be a
      dereferenceable URI pointing to client-id metadata.

   agentType (required)  Classification of the agent.  Receiving domains
      use this to apply type-specific policies.  Implementations MUST
      support:




Diaconu, et al.          Expires 10 August 2026                [Page 18]

Internet-Draft          AuthZ Sharing for Agents           February 2026


      *  tool-agent: Provides specific tool/skill capabilities

      *  orchestrator-agent: Coordinates other agents

      *  workflow-agent: Executes multi-step workflows

      *  system-agent: Long-running infrastructure agent

      *  ephemeral-agent: Short-lived, single-task

   authorizedScopes (required)  Authorization scopes this agent may
      request.  Receiving domains map these to local authorization
      policies.

   issuerDomain (required)  Administrative domain of the credential
      issuer.  Receiving ASs use this to look up trust relationships and
      policy mappings.

6.4.2.3.  Recommended Claims for Production Deployments

   dataSensitivityClearance (recommended)  Maximum data sensitivity
      level this agent may access.  Standard values:

      *  public - Publicly available information

      *  internal - Organization-internal, non-sensitive

      *  confidential - Business-sensitive information

      *  restricted - Highly sensitive, need-to-know basis

      *  regulated - Subject to regulatory controls (PII, PHI, PCI)

   complianceAttestations (recommended)  Compliance certifications
      relevant to cross-domain trust decisions.  Should include
      standard, scope, validUntil, and optionally certificationBody.

   operationalConstraints (recommended)  Runtime constraints that
      receiving domains MAY enforce, including maxConcurrentSessions,
      maxRequestsPerMinute, allowedTimeWindows, and geofence
      restrictions.

   delegation (recommended)  Delegation permissions as defined in
      Section 6.4.1.5.







Diaconu, et al.          Expires 10 August 2026                [Page 19]

Internet-Draft          AuthZ Sharing for Agents           February 2026


6.4.2.4.  Extension Mechanism

   Organizations MAY extend the profile with additional claims by:

   1.  Defining a JSON-LD context document for the extension

   2.  Including the extension context URI in the VC's @context array

   3.  Adding extension claims under a namespace prefix

   Implementations receiving VCs with unrecognized claims SHOULD:

   *  Ignore unknown claims (do not reject the VC)

   *  Log unrecognized claims for operational visibility

   *  NOT make authorization decisions based on claims they cannot
      interpret

6.4.2.5.  Interoperability Requirements

   For cross-domain interoperability, implementations:

   MUST:

   *  Support required claims (id, agentType, authorizedScopes,
      issuerDomain)

   *  Recognize the AgentAuthorizationCredential type

   *  Verify the credential proof before processing claims

   *  Reject VCs missing required claims

   SHOULD:

   *  Support recommended claims

   *  Implement selective disclosure for cross-domain presentations

   *  Maintain logs of cross-domain VC presentations

   MAY:

   *  Define and process organization-specific extensions

   *  Implement additional validation beyond profile requirements




Diaconu, et al.          Expires 10 August 2026                [Page 20]

Internet-Draft          AuthZ Sharing for Agents           February 2026


7.  Example

   This section provides illustrative examples of how Client-ID Metadata
   can be extended with Verifiable Credentials for agent identity.
   These examples demonstrate the recommended Approach 4 and show how
   the concepts apply to scenarios similar to the travel booking use
   case described earlier.  These examples are non-normative and
   intended to demonstrate the concepts discussed in this document.

7.1.  Client-ID Metadata Example

   The following example shows OAuth client metadata that includes a
   Verifiable Credential in the "vc+jwt" field:

   {
     "client_id": "https://agents.example.com/agent-001/metadata.json",
     "client_name": "Customer Service Agent 001",
     "jwks_uri": "https://agents.example.com/agent-001/jwks.json",
     "token_endpoint_auth_method": "private_key_jwt",
     "grant_types": ["client_credentials"],
     "scope": "read:orders write:tickets",
     "vc+jwt": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJAY29udGV4dCI6W..."
   }

   The "vc+jwt" field contains a JWT-encoded Verifiable Credential.  The
   actual JWT would be significantly longer and contain the complete
   credential structure shown in the next subsection.

7.2.  Verifiable Credential Example

   The following example shows the decoded structure of a Verifiable
   Credential for an agent (before JWT encoding):

   {
     "@context": [
       "https://www.w3.org/2018/credentials/v1",
       "https://example.org/agent-credentials/v1"
     ],
     "type": ["VerifiableCredential", "AgentIdentityCredential"],
     "issuer": "did:web:issuer.example.com",
     "issuanceDate": "2025-01-15T10:30:00Z",
     "expirationDate": "2026-01-15T10:30:00Z",
     "credentialSubject": {
       "id": "https://agents.example.com/agent-001/metadata.json",
       "agentName": "Customer Service Agent 001",
       "agentVersion": "2.1.0",
       "agentType": "customer-service",
       "owner": "did:web:example.com",



Diaconu, et al.          Expires 10 August 2026                [Page 21]

Internet-Draft          AuthZ Sharing for Agents           February 2026


       "authorizedCapabilities": [
         "order-lookup",
         "ticket-creation",
         "customer-notification"
       ],
       "delegatedCredentials":[
         {
           "id": "https://agents.partner.com/agent-111/metadata.json",
           "agentName":"Sec Agent 111",
           "delegatedBy":"https://agents.example.com/agent-001/metadata.json",
           "delegationChain": [
                   "urn:uuid:*****",
                   "urn:uuid:***"
           ],
           "scope": "read:sec-remediate:isolations",
           "authorizedCapabilities": [
                   "enrichment",
                   "isolation-request"
           ],
       "constraints": {
         "dpopNonceRequired": true
           }
         }
       ],
       "complianceFrameworks": ["SOC2-TypeII", "ISO-27001"],
       "delegationLevel": 1,
       "maxDelegationDepth": 2
     },
     "credentialStatus": {
       "id": "https://issuer.example.com/status/2024/12345",
       "type": "StatusList2021Entry",
       "statusPurpose": "revocation",
       "statusListIndex": "12345",
       "statusListCredential": "https://issuer.example.com/status/2024"
     }
   }

   Note: The actual credential would include a "proof" section with
   cryptographic signatures.  The proof section is omitted here for
   clarity, as it would add significant length to the example.  The
   proof structure varies depending on the signature suite used (e.g.,
   Ed25519Signature2020, JsonWebSignature2020).

8.  Security Considerations







Diaconu, et al.          Expires 10 August 2026                [Page 22]

Internet-Draft          AuthZ Sharing for Agents           February 2026


8.1.  Security Considerations

   This section addresses security considerations specific to cross-
   domain authorization information sharing.  Implementations MUST also
   follow security guidance in [RFC6819], [W3C.VCDM2.0], and
   [I-D.ietf-oauth-client-id-metadata-document].

8.1.1.  Threat Model for Cross-Domain Authorization Sharing

   This section defines threats specific to sharing authorization
   information across administrative domain boundaries.  General OAuth
   and VC security threats are addressed in [RFC6819] and [W3C.VCDM2.0];
   this section focuses on threats that emerge or are amplified when
   credentials cross domain boundaries.

8.1.1.1.  Protected Assets in Cross-Domain Scenarios

   Beyond standard authorization assets, cross-domain sharing introduces
   additional assets requiring protection:

   Cross-Domain Trust Relationships  The established trust between
      domains that enables agents to operate across organizational
      boundaries.  Compromise affects all agents relying on that trust
      relationship.

   Shared Authorization Semantics  The agreed-upon meaning of claims,
      scopes, and compliance attestations between domains.  Semantic
      drift or manipulation can cause authorization decisions that
      violate one or both domains' policies.

   Delegation Chains Spanning Domains  When agent A in Domain X
      delegates to agent B in Domain Y, the chain itself becomes an
      asset requiring integrity protection across trust boundaries.

8.1.1.2.  Cross-Domain Specific Threat Actors

   Rogue Domain  An entire domain that participates in the trust
      federation but issues fraudulent VCs or makes incorrect
      authorization decisions—either through compromise or malicious
      operation.  Unlike a single rogue IdP, a rogue domain may control
      IdP, AS, and metadata endpoints coherently.

   Cross-Domain Insider  An administrator with legitimate access in
      Domain A who abuses cross-domain trust relationships to gain
      unauthorized access to Domain B's resources.

8.1.1.3.  Cross-Domain Attack Categories




Diaconu, et al.          Expires 10 August 2026                [Page 23]

Internet-Draft          AuthZ Sharing for Agents           February 2026


8.1.1.3.1.  Trust Anchor Attacks

   Metadata Endpoint Compromise  An attacker gains control of the URL
      hosting an agent's client-id metadata document and substitutes
      malicious metadata or VCs.  Because the metadata URL is the trust
      anchor for cross-domain identity, compromise enables complete
      identity takeover across all trusting domains.

      Cross-domain amplification: In single-domain scenarios, the AS
      typically has out-of-band trust with clients.  In cross-domain
      scenarios, the metadata endpoint IS the sole trust anchor—there's
      no fallback.

   Metadata Poisoning  Injection of false claims into legitimate
      metadata documents through supply chain attacks, DNS hijacking, or
      exploitation of hosting infrastructure.

      Cross-domain amplification: Poisoned metadata propagates trust
      violations to all domains that fetch and cache the metadata.

8.1.1.3.2.  Semantic Attacks

   Policy Skew Exploitation  An agent authorized under Domain A's
      policies operates in Domain B where different security policies
      apply.  The agent performs actions that are within Domain A's
      authorized scope but violate Domain B's policies.

   Claim Semantic Drift  Domains interpret the same claim differently,
      leading to authorization decisions that neither domain intended.

   Compliance Attestation Mismatch  Compliance attestations (SOC2, ISO-
      27001, GDPR) in VCs are accepted at face value without verifying
      that the issuing domain's certification scope covers the receiving
      domain's requirements.

8.1.1.3.3.  Delegation Attacks Across Domains

   Cross-Domain Privilege Amplification  In multi-hop delegation (A to B
      to C) where agents belong to different domains, downstream agents
      in permissive domains accumulate effective permissions that exceed
      what the originating principal intended.

   Accountability Chain Breakage  Delegation chains that cross domain
      boundaries lose forensic continuity.  When incidents occur,
      attribution cannot be reconstructed because each domain only has
      partial visibility.

   Confused Deputy Across Trust Boundaries  An attacker in Domain A



Diaconu, et al.          Expires 10 August 2026                [Page 24]

Internet-Draft          AuthZ Sharing for Agents           February 2026


      tricks a trusted agent in Domain B into performing actions on
      their behalf that the attacker couldn't perform
      directly—exploiting the cross-domain trust relationship.  See
      [Hardy1988].

8.1.1.3.4.  Cross-Domain Lateral Movement

   Using legitimate cross-domain authorization to pivot from a
   compromised position in Domain A to resources in Domain B that would
   not otherwise be accessible.  An attacker compromises a low-privilege
   agent in Domain A.  That agent has cross-domain authorization to
   Domain B.  The attacker uses the agent's credentials to establish a
   foothold in Domain B, then escalates within Domain B.

8.1.1.3.5.  Correlation and Privacy Attacks

   Linking agent activities across domains using stable identifiers in
   VCs to build profiles of organizational operations, potentially
   revealing sensitive business processes or security postures.

   Cross-domain amplification: In single-domain scenarios, the domain
   controls what's logged.  In cross-domain scenarios, each domain
   receiving the VC can correlate independently, and the agent's home
   domain cannot prevent this.

8.1.1.4.  Trust Establishment Between Domains

8.1.1.4.1.  Domain Trust Lists

   Before accepting VCs from another domain, an Authorization Server
   MUST verify that the issuing domain is in an explicitly configured
   trust list.  Implementations MUST NOT implicitly trust domains based
   solely on successful cryptographic verification of the VC.

   Trust list entries SHOULD include:

   *  Domain identifier (issuerDomain claim value)

   *  Accepted VC types from that domain

   *  Scope of trust (which local resources may be accessed)

   *  Expiration or review date for the trust relationship








Diaconu, et al.          Expires 10 August 2026                [Page 25]

Internet-Draft          AuthZ Sharing for Agents           February 2026


8.1.1.4.2.  Cross-Domain Policy Mapping

   Implementations MUST NOT assume semantic equivalence of claims across
   domains.  Before accepting a VC from another domain, the AS SHOULD
   verify:

   1.  Explicit mapping exists between the foreign domain's claim
       semantics and local policy requirements

   2.  Compliance attestations in the VC meet local regulatory
       requirements (not just the issuing domain's)

   3.  Scope values have been mapped to local authorization semantics

8.1.1.4.3.  Trust Relationship Lifecycle

   Cross-domain trust relationships MUST have defined lifecycles:

   *  Periodic review and re-validation

   *  Documented procedures for trust relationship termination

   *  Immediate revocation capability when a trusted domain is
      compromised

   *  Notification mechanisms between domains for security events

8.1.1.5.  Metadata Endpoint Security for Cross-Domain Trust

   Because the client-id metadata endpoint is the sole trust anchor for
   cross-domain agent identity, it requires enhanced protection beyond
   typical endpoint security.

8.1.1.5.1.  Endpoint Integrity Beyond Transport

   Metadata documents SHOULD be signed independently of the transport
   layer, allowing verification even if TLS is compromised or if the
   document is cached by intermediaries.

8.1.1.5.2.  Change Detection for Cached Metadata

   Authorization Servers SHOULD:

   *  Cache fetched metadata documents with appropriate TTLs

   *  Detect and alert on unexpected changes to critical fields
      (jwks_uri, vc+jwt, token_endpoint_auth_method)




Diaconu, et al.          Expires 10 August 2026                [Page 26]

Internet-Draft          AuthZ Sharing for Agents           February 2026


   *  Implement anomaly detection for metadata that changes more
      frequently than expected

8.1.1.5.3.  Cross-Domain Availability Dependencies

   When metadata endpoints are unavailable, cross-domain authorization
   fails.  Implementations SHOULD:

   *  Cache validated metadata with TTLs appropriate to the sensitivity
      of protected resources

   *  Implement circuit breakers to prevent cascading failures

   *  Define graceful degradation policies

8.1.1.6.  Delegation Security Across Domain Boundaries

8.1.1.6.1.  Domain Boundary Checkpoints

   When a delegation chain crosses a domain boundary, the receiving
   domain's AS MUST:

   *  Fully verify the upstream delegation chain before accepting

   *  Apply local policy to the delegation

   *  Log the domain boundary crossing for audit purposes

   Receiving domains SHOULD consider the status of delegated credentials
   and, where status information is available, avoid making
   authorization decisions that rely on revoked,suspended, or suspended
   delegation chain elements, according to local policy.

   Deployments concerned with stale delgations MAY apply bounded caching
   and periodic revalidation of delegation status appropriate to the
   sensitivity of protected resources.

8.1.1.6.2.  Monotonic Scope Narrowing Across Domains

   Implementations MUST enforce that effective scope can only decrease
   (or remain the same) at each delegation step, including when crossing
   domain boundaries.  The receiving domain MUST apply its local policy
   as an additional constraint on effective scope.

8.1.1.6.3.  Accountability Chain Preservation

   Delegation chains spanning domains MUST maintain cryptographically
   verifiable accountability.  Each domain SHOULD:



Diaconu, et al.          Expires 10 August 2026                [Page 27]

Internet-Draft          AuthZ Sharing for Agents           February 2026


   *  Preserve the incoming delegation chain in its audit logs

   *  Add its own delegation record when extending the chain

   *  Provide APIs for authorized forensic queries from upstream domains

8.1.1.7.  Privacy Considerations for Cross-Domain Sharing

8.1.1.7.1.  Selective Disclosure for Cross-Domain Presentations

   Agents presenting VCs across domain boundaries SHOULD use selective
   disclosure mechanisms (SD-JWT VC, BBS+ signatures) to reveal only
   claims necessary for the specific cross-domain authorization request.

8.1.1.7.2.  Correlation Risk Assessment

   Organizations SHOULD assess cross-domain correlation risks before
   establishing trust relationships, including whether agent identifiers
   enable activity tracking by foreign domains.

9.  IANA Considerations

   This document introduces a new OAuth client metadata parameter
   "vc+jwt" as described in the Solution Analysis section (Approach 4).
   If this approach is standardized, the following registration would be
   required:

   *  *Registry:* IANA [`OAuth Dynamic Client Registration
      Metadata`](https://www.iana.org/assignments/oauth-parameters/
      oauth-parameters.xhtml#client-metadata) registry

   *  *Client Metadata Name:* vc+jwt

   *  *Client Metadata Description:* JWT-encoded Verifiable Credential

   *  *Change Controller:* TBD

   *  *Reference:* https://www.w3.org/TR/vc-data-model-2.0

   This informational document does not make a formal request for IANA
   registration at this time.  Registration would be appropriate if this
   approach is adopted and progresses to a standards track
   specification.

10.  References

10.1.  Informative References




Diaconu, et al.          Expires 10 August 2026                [Page 28]

Internet-Draft          AuthZ Sharing for Agents           February 2026


   [RFC7591]  Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
              P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
              July 2015, <https://www.rfc-editor.org/info/rfc7591>.

   [I-D.abbey-scim-agent-extension]
              Abbey, J., "SCIM Extensions for Agents", 2025.

   [I-D.wahl-scim-agent-schema]
              Wahl, M., "SCIM Schema for Agents", 2025.

   [I-D.ietf-oauth-client-id-metadata-document]
              Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Client
              Identity Metadata Document", 2025.

   [W3C.VCDM2.0]
              W3C, "Verifiable Credentials Data Model v2.0", 2024,
              <https://www.w3.org/TR/vc-data-model-2.0/>.

   [RFC6819]  Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
              Threat Model and Security Considerations", January 2013,
              <https://www.rfc-editor.org/info/rfc6819>.

   [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
              Mortimore, "OAuth 2.0 Token Exchange", January 2020,
              <https://www.rfc-editor.org/info/rfc8693>.

   [Hardy1988]
              Hardy, N., "The Confused Deputy: (or why capabilities
              might have been invented)", ACM SIGOPS Operating Systems
              Review Volume 22, Issue 4, 1988.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", RFC 8174, 2017,
              <https://www.rfc-editor.org/rfc/rfc8174>.

Authors' Addresses

   Jean Diaconu
   Cisco Systems, Inc.
   Av. des Uttins 5
   CH-1180 ROLLE
   Switzerland
   Email: jdiaconu@cisco.com




Diaconu, et al.          Expires 10 August 2026                [Page 29]

Internet-Draft          AuthZ Sharing for Agents           February 2026


   Marcelo Yannuzzi
   Cisco Systems, Inc.
   Av. des Uttins 5
   CH-1180 ROLLE
   Switzerland
   Email: mayannuz@cisco.com


   Herve Muyal
   Cisco Systems, Inc.
   Av. des Uttins 5
   CH-1180 ROLLE
   Switzerland
   Email: hmuyal@cisco.com


   Frank Brockners
   Cisco Systems, Inc.
   Hansaallee 249, 3rd Floor
   40549 DUESSELDORF
   Germany
   Email: fbrockne@cisco.com


   Nik Kale
   Cisco Systems, Inc.
   170 W Tasman Dr
   SAN JOSE, CA,  95134
   United States of America
   Email: nikkal@cisco.com


   Ankit Agarwal
   Skyfire, Inc.
   Kentfield, CA,
   United States of America
   Email: ankit@skyfire.xyz


   Jeffrey Hickman
   Ory Corp, Inc.
   15169 N Scottsdale Rd Suite 205
   Scottsdale, AZ,  85254
   United States of America
   Email: jeff.hickman@ory.com






Diaconu, et al.          Expires 10 August 2026                [Page 30]

Internet-Draft          AuthZ Sharing for Agents           February 2026


   Amritha Lal
   Amazon Web Services
   Seattle, WA,
   United States of America
   Email: amrithak@amazon.com














































Diaconu, et al.          Expires 10 August 2026                [Page 31]


name: draft-cui-dmsc-agent-cdi
rev: 00
title: Cross-Domain Interoperability Framework for AI Agent Collaboration
time: 2026-02-11T02:13:49Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-15T02:13:49Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Data formats/interop", "Policy/governance", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:03.420534+00:00
abstract:
This document defines a framework for enabling seamless cross-domain
   interoperability among AI agents operating across different networks,
   administrative domains, and heterogeneous platforms.  The framework
   addresses the challenges of identity federation, trust establishment,
   policy harmonization, and secure communication that arise when AI
   agents from distinct administrative realms need to collaborate on
   shared tasks.  It specifies mechanisms for agent discovery,
   capability negotiation, trust delegation, and federated policy
   enforcement, enabling scalable and secure multi-domain AI
   collaboration without requiring centralized control.

full_text:
WG Working Group                                                  Y. Cui
Internet-Draft                                       Tsinghua University
Intended status: Informational                          11 February 2026
Expires: 15 August 2026


   Cross-Domain Interoperability Framework for AI Agent Collaboration
                      draft-cui-dmsc-agent-cdi-00

Abstract

   This document defines a framework for enabling seamless cross-domain
   interoperability among AI agents operating across different networks,
   administrative domains, and heterogeneous platforms.  The framework
   addresses the challenges of identity federation, trust establishment,
   policy harmonization, and secure communication that arise when AI
   agents from distinct administrative realms need to collaborate on
   shared tasks.  It specifies mechanisms for agent discovery,
   capability negotiation, trust delegation, and federated policy
   enforcement, enabling scalable and secure multi-domain AI
   collaboration without requiring centralized control.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-cui-dmsc-agent-cdi/.

   Discussion of this document takes place on the WG Working Group
   mailing list (mailto:WG@example.com), which is archived at
   https://example.com/WG.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/.

   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."




Cui                      Expires 15 August 2026                 [Page 1]

Internet-Draft                  CDI-Agent                  February 2026


   This Internet-Draft will expire on 15 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Cross-Domain Interoperability Framework . . . . . . . . . . .   6
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  *Architecture Components* . . . . . . . . . . . . . . . .   6
       4.2.1.  Interoperability Gateway  . . . . . . . . . . . . . .   7
       4.2.2.  Agent Registry and Directory  . . . . . . . . . . . .   7
       4.2.3.  Cross-Domain Agent Runtime  . . . . . . . . . . . . .   8
   5.  Trust Establishment Framework . . . . . . . . . . . . . . . .   8
     5.1.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Trust Establishment Protocols . . . . . . . . . . . . . .   9
       5.2.1.  Domain Federation Protocol  . . . . . . . . . . . . .   9
       5.2.2.  Agent Delegation Protocol . . . . . . . . . . . . . .  10
   6.  Identity and Access Management  . . . . . . . . . . . . . . .  10
     6.1.  Federated Identity Model  . . . . . . . . . . . . . . . .  10
       6.1.1.  Agent Identifiers . . . . . . . . . . . . . . . . . .  10
       6.1.2.  Credential Types  . . . . . . . . . . . . . . . . . .  11
     6.2.  Access Control Framework  . . . . . . . . . . . . . . . .  11
       6.2.1.  Multi-Domain Policy Model . . . . . . . . . . . . . .  11
       6.2.2.  Policy Negotiation Protocol . . . . . . . . . . . . .  11
       6.2.3.  Attribute-Based Access Control (ABAC) . . . . . . . .  12
   7.  Capability Discovery and Negotiation  . . . . . . . . . . . .  12
     7.1.  Capability Description Language . . . . . . . . . . . . .  12
     7.2.  Discovery Mechanisms  . . . . . . . . . . . . . . . . . .  13
       7.2.1.  Directory-Based Discovery . . . . . . . . . . . . . .  13
       7.2.2.  Peer-to-Peer Discovery  . . . . . . . . . . . . . . .  14
     7.3.  Capability Negotiation Protocol . . . . . . . . . . . . .  14
   8.  Communication Protocols . . . . . . . . . . . . . . . . . . .  15
     8.1.  Cross-Domain Message Format . . . . . . . . . . . . . . .  15



Cui                      Expires 15 August 2026                 [Page 2]

Internet-Draft                  CDI-Agent                  February 2026


     8.2.  Communication Patterns  . . . . . . . . . . . . . . . . .  16
       8.2.1.  Direct Agent-to-Agent Communication . . . . . . . . .  16
       8.2.2.  Gateway-Mediated Communication  . . . . . . . . . . .  17
       8.2.3.  Store-and-Forward Communication . . . . . . . . . . .  17
     8.3.  Protocol Layering . . . . . . . . . . . . . . . . . . . .  17
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
     9.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  18
     9.2.  Security Controls . . . . . . . . . . . . . . . . . . . .  18
       9.2.1.  Authentication and Authorization  . . . . . . . . . .  18
       9.2.2.  Data Protection . . . . . . . . . . . . . . . . . . .  19
       9.2.3.  Monitoring and Detection  . . . . . . . . . . . . . .  19
     9.3.  Security Assurance  . . . . . . . . . . . . . . . . . . .  19
       9.3.1.  Trust Verification  . . . . . . . . . . . . . . . . .  19
       9.3.2.  Audit and Accountability  . . . . . . . . . . . . . .  20
   10. Performance and Scalability . . . . . . . . . . . . . . . . .  20
     10.1.  Performance Metrics  . . . . . . . . . . . . . . . . . .  20
     10.2.  Scalability Considerations . . . . . . . . . . . . . . .  20
       10.2.1.  Horizontal Scaling . . . . . . . . . . . . . . . . .  20
       10.2.2.  Federation Scaling . . . . . . . . . . . . . . . . .  21
     10.3.  Resource Management  . . . . . . . . . . . . . . . . . .  21
       10.3.1.  Computational Resources  . . . . . . . . . . . . . .  21
       10.3.2.  Network Resources  . . . . . . . . . . . . . . . . .  21
   11. Deployment Considerations . . . . . . . . . . . . . . . . . .  22
     11.1.  Deployment Models  . . . . . . . . . . . . . . . . . . .  22
       11.1.1.  Centralized Gateway Model  . . . . . . . . . . . . .  22
       11.1.2.  Distributed Gateway Model  . . . . . . . . . . . . .  22
       11.1.3.  Hybrid Model . . . . . . . . . . . . . . . . . . . .  22
     11.2.  Integration with Existing Systems  . . . . . . . . . . .  23
       11.2.1.  Legacy Agent Systems . . . . . . . . . . . . . . . .  23
       11.2.2.  Cloud and Edge Deployments . . . . . . . . . . . . .  23
     11.3.  Operational Considerations . . . . . . . . . . . . . . .  23
       11.3.1.  Monitoring and Management  . . . . . . . . . . . . .  23
       11.3.2.  Update and Maintenance . . . . . . . . . . . . . . .  24
   12. Use Cases and Examples  . . . . . . . . . . . . . . . . . . .  24
     12.1.  Cross-Enterprise Supply Chain Optimization . . . . . . .  24
     12.2.  Smart City Federation  . . . . . . . . . . . . . . . . .  25
     12.3.  Cross-Border Financial Services Collaboration  . . . . .  25
     12.4.  Cross-Domain Emergency Response System . . . . . . . . .  26
     12.5.  Multi-Cloud AI Workload Orchestration  . . . . . . . . .  28
     12.6.  International Research Data Commons  . . . . . . . . . .  29
     12.7.  Smart Manufacturing Supply Chain . . . . . . . . . . . .  30
     12.8.  Cross-Jurisdictional Law Enforcement Collaboration . . .  31
     12.9.  Global Energy Grid Coordination  . . . . . . . . . . . .  32
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  33
   14. Normative References  . . . . . . . . . . . . . . . . . . . .  33
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  34
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  34




Cui                      Expires 15 August 2026                 [Page 3]

Internet-Draft                  CDI-Agent                  February 2026


1.  Introduction

   The proliferation of AI agents across different organizational
   boundaries has created a need for mechanisms that enable these agents
   to collaborate effectively across domains.  Traditional agent systems
   are typically designed to operate within a single administrative
   domain, where trust relationships, identity management, and policy
   enforcement are centrally controlled.  However, real-world
   applications increasingly require AI agents to work together across
   organizational boundaries, such as in supply chain optimization,
   cross-enterprise workflow automation, smart city coordination, and
   distributed scientific research.

   Cross-domain interoperability for AI agents presents several unique
   challenges:

   1.  *Trust Establishment*: How to establish and verify trust between
       agents from different administrative domains without a central
       authority.

   2.  *Identity Federation*: How to manage agent identities and
       credentials across domains while preserving privacy and
       sovereignty.

   3.  *Policy Harmonization*: How to reconcile potentially conflicting
       policies from different domains to enable collaborative
       operations.

   4.  *Capability Discovery*: How agents can discover and understand
       the capabilities of foreign agents while respecting domain
       boundaries.

   5.  *Secure Communication*: How to establish secure communication
       channels that cross domain boundaries with appropriate security
       guarantees.

   6.  *Accountability and Auditing*: How to maintain accountability for
       actions taken by federated agents while respecting domain
       autonomy.

   This document proposes a framework that addresses these challenges
   through a combination of federated trust mechanisms, standardized
   capability descriptions, policy negotiation protocols, and secure
   communication patterns.  The framework is designed to be
   incrementally deployable and compatible with existing single-domain
   agent architectures.





Cui                      Expires 15 August 2026                 [Page 4]

Internet-Draft                  CDI-Agent                  February 2026


2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] .

3.  Terminology

   The following terms are defined in this draft

   *  *MCP (Model Context Protocol)*: A protocol that standardizes tool
      invocation and data interaction between AI agents and external
      hosts using JSON-RPC over stdio or HTTP.

   *  *Host*: The process or service that provides tools or resources to
      the agent via MCP, typically running as a backend process or
      plugin.

   *  *Agent*: An AI entity that uses MCP to invoke external tools to
      accomplish tasks.

   *  *Security Enhancement Layer (SEL)*: An external security layer
      that provides transparent security controls for MCP communication
      without protocol modification.

   *  *Client Shield*: The security component deployed on the MCP client
      (Host) side, responsible for protecting user interests.

   *  *Server Shield*: The security component deployed on the MCP server
      (tool provider) side, responsible for protecting service provider
      interests.

   *  *Data Backflow*: The transmission of sensitive data from the agent
      environment to external tools beyond authorized scope or without
      proper safeguards.

   *  *Dual Authorization*: An authorization model requiring both
      platform policy validation and explicit user consent for sensitive
      operations.

   *  *Trace ID*: A globally unique identifier used to correlate events
      across the MCP communication chain for auditing and
      troubleshooting.

   The following abbreviations are used in this document:

   *  *CDI*: Cross-Domain Interoperability




Cui                      Expires 15 August 2026                 [Page 5]

Internet-Draft                  CDI-Agent                  February 2026


   *  *CDA*: Cross-Domain Agent

   *  *FIM*: Federated Identity Management

   *  *ABAC*: Attribute-Based Access Control

   *  *REST*: Representational State Transfer

   *  *JWT*: JSON Web Token

   *  *OIDC*: OpenID Connect

   *  *SAML*: Security Assertion Markup Language

   *  *DID*: Decentralized Identifier

   *  *VC*: Verifiable Credential

4.  Cross-Domain Interoperability Framework

4.1.  Overview

   The Cross-Domain Interoperability Framework for AI Agents is designed
   as a federated architecture that enables secure and scalable
   collaboration between agents from different administrative domains.
   The framework operates on several key principles:

   1.  *Domain Autonomy*: Each administrative domain maintains control
       over its own agents, policies, and resources.

   2.  *Minimal Trust Assumptions*: Domains establish trust
       relationships only as needed for specific collaborations.

   3.  *Graduated Interoperability*: Domains can choose different levels
       of integration based on trust and requirements.

   4.  *Auditability*: All cross-domain interactions are logged and
       auditable by all participating domains.

   5.  *Fail-Safe Design*: System failures or malicious actions in one
       domain should not compromise other domains.

4.2.  *Architecture Components*

   The framework consists of the following core components:






Cui                      Expires 15 August 2026                 [Page 6]

Internet-Draft                  CDI-Agent                  February 2026


  +----------------+       +------------------+       +----------------+
  | Domain A       |       | Interoperability |       | Domain B       |
  | Administration |<----->|   Gateway        |<----->| Administration |
  | & Control      |       |   Federation     |       | & Control      |
  +----------------+       +------------------+       +----------------+
       |                         |                       |
       | (Home Domain)           |(Gateway-mediated)     |(Home Domain)
       v                         v                       v
  +----------------+       +------------------+       +----------------+
  | Agent Registry |       |   Trust Broker   |       | Agent Registry |
  | & Directory    |       |   & Policy Engine|       | & Directory    |
  +----------------+       +------------------+       +----------------+
       |                         |                       |
       | (Local Agents)          |(Cross-Domain Agents)  |(Local Agents)
       v                         v                       v
  +----------------+       +------------------+       +----------------+
  | AI Agent A1    |<----->|   AI Agent A2    |<----->| AI Agent B1    |
  | (Domain A)     |       |   (Domain A,     |       | (Domain B)     |
  |                |       |    operating in  |       |                |
  | AI Agent A3    |       |    Domain B)     |       | AI Agent B2    |
  | (Domain A)     |       +------------------+       | (Domain B)     |
  +----------------+                                  +----------------+

4.2.1.  Interoperability Gateway

   The Interoperability Gateway serves as the primary interface between
   domains, providing:

   *  *Trust Brokerage*: Mediates trust establishment between domains
      using verifiable credentials and reputation systems.

   *  *Policy Mediation*: Translates and reconciles policies between
      domains to enable collaborative operations.

   *  *Agent Discovery*: Facilitates discovery of agents and their
      capabilities across domain boundaries.

   *  *Communication Routing*: Routes messages between agents in
      different domains with appropriate security.

   *  *Audit Collection*: Collects and correlates audit trails from
      cross-domain interactions.

4.2.2.  Agent Registry and Directory

   Each domain maintains an Agent Registry that provides:





Cui                      Expires 15 August 2026                 [Page 7]

Internet-Draft                  CDI-Agent                  February 2026


   *  *Local Agent Directory*: Catalog of agents within the domain with
      their capabilities and status.

   *  *Foreign Agent Cache*: Cached information about agents from other
      domains that have been authorized to operate locally.

   *  *Capability Repository*: Structured descriptions of agent
      capabilities using standardized schemas.

   *  *Policy Repository*: Storage for domain-specific policies
      governing agent behavior.

4.2.3.  Cross-Domain Agent Runtime

   Agents operating in foreign domains require enhanced runtime
   components:

   *  *Policy Compliance Engine*: Ensures agent behavior complies with
      both home and foreign domain policies.

   *  *Context Adaptation Module*: Adapts agent behavior based on the
      operating context and domain-specific requirements.

   *  *Secure Communication Module*: Implements cross-domain
      communication protocols with end-to-end security.

   *  *Audit Logging Module*: Maintains detailed logs of all cross-
      domain operations for accountability.

5.  Trust Establishment Framework

5.1.  Trust Model

   The framework employs a multi-layered trust model:

   1.  *Domain-to-Domain Trust*: Established through bilateral
       agreements, verifiable credentials, or reputation systems.

   2.  *Agent-to-Agent Trust*: Derived from domain trust but enhanced
       with agent-specific credentials and behavioral attestations.

   3.  *Task-Specific Trust*: Limited trust established for specific
       collaborative tasks with clearly defined boundaries.

   4.  *Revocable Trust*: All trust relationships are time-bound and
       revocable by any participating domain.





Cui                      Expires 15 August 2026                 [Page 8]

Internet-Draft                  CDI-Agent                  February 2026


5.2.  Trust Establishment Protocols

5.2.1.  Domain Federation Protocol

   Domains establish trust relationships through a multi-phase protocol:

   Phase 1: Discovery and Introduction

   +-----------+         +-----------+         +-----------+
   |  Domain A |         | Discovery |         |  Domain B |
   |           |         |  Service  |         |           |
   +-----------+         +-----------+         +-----------+
        |                        |                        |
        | 1. Query for compatible|                        |
        |    partners            |                        |
        |----------------------->|                        |
        |                        |                        |
        | 2. Return list of      |                        |
        |    potential partners  |                        |
        |<-----------------------|                        |
        |                        |                        |
        | 3. Request introduction|                        |
        |    to Domain B         |                        |
        |----------------------->|                        |
        |                        |                        |
        | 4. Forward introduction|                        |
        |    request             |                        |
        |                        |----------------------->|
        |                        |                        |

   Phase 2: Capability and Policy Exchange

        |                        |                        |
        | 5. Send capability     |                        |
        |    profile and policy  |                        |
        |    assertions          |                        |
        |<------------------------------------------------|
        |                        |                        |
        | 6. Evaluate compatibility|                      |
        |    and risk            |                        |
        |------------------------------------------------>|
        |                        |                        |

   Phase 3: Trust Agreement

        |                        |                        |
        | 7. Propose trust       |                        |
        |    agreement with terms|                        |



Cui                      Expires 15 August 2026                 [Page 9]

Internet-Draft                  CDI-Agent                  February 2026


        |    and conditions      |                        |
        |<------------------------------------------------|
        |                        |                        |
        | 8. Negotiate and       |                        |
        |    finalize agreement  |                        |
        |------------------------------------------------>|
        |                        |                        |
        | 9. Exchange signed     |                        |
        |    trust certificates  |                        |
        |<------------------------------------------------|
        |                        |                        |

5.2.2.  Agent Delegation Protocol

   Once domains establish trust, agents can be delegated to operate in
   foreign domains:

   1.  *Delegation Request*: Home domain requests delegation for
       specific agents with defined capabilities and constraints.

   2.  *Policy Alignment*: Foreign domain evaluates the request against
       its policies and may negotiate constraints.

   3.  *Credential Issuance*: Home domain issues verifiable credentials
       to agents for use in the foreign domain.

   4.  *Local Registration*: Agents register with the foreign domain's
       Agent Registry using their credentials.

   5.  *Periodic Revalidation*: Delegated credentials are periodically
       revalidated and can be revoked at any time.

6.  Identity and Access Management

6.1.  Federated Identity Model

   The framework employs a federated identity model with the following
   components:

6.1.1.  Agent Identifiers

   Each agent has multiple identifiers for different contexts:

   *  *Home Domain Identifier*: Unique identifier within the home domain
      (e.g., UUID, email-style address).

   *  *Federated Identifier*: Globally unique identifier for cross-
      domain recognition (e.g., DID, URN).



Cui                      Expires 15 August 2026                [Page 10]

Internet-Draft                  CDI-Agent                  February 2026


   *  *Session Identifiers*: Temporary identifiers for specific
      collaborative sessions.

6.1.2.  Credential Types

   *  *Domain Identity Credentials*: Verifiable credentials issued by
      the home domain attesting to the agent's identity and basic
      attributes.

   *  *Capability Credentials*: Credentials attesting to specific agent
      capabilities and skill levels.

   *  *Delegation Credentials*: Credentials authorizing an agent to
      operate in a foreign domain with specific permissions.

   *  *Task Credentials*: Limited-scope credentials for specific
      collaborative tasks.

6.2.  Access Control Framework

6.2.1.  Multi-Domain Policy Model

   Access control decisions consider policies from multiple domains:

   Access Decision = f(Home Domain Policy, Foreign Domain Policy,
   Collaborative Task Policy, Dynamic Context Factors)

6.2.2.  Policy Negotiation Protocol

   When policies conflict, domains negotiate to find acceptable
   compromises:

   1.  *Policy Disclosure*: Domains share relevant policy fragments (not
       necessarily complete policies).

   2.  *Conflict Detection*: Identify conflicts between policies from
       different domains.

   3.  *Resolution Proposal*: Propose policy modifications or exceptions
       to resolve conflicts.

   4.  *Agreement Finalization*: Domains agree on a merged policy for
       the specific collaboration.

   5.  *Policy Enforcement*: The agreed policy is enforced by all
       participating domains.





Cui                      Expires 15 August 2026                [Page 11]

Internet-Draft                  CDI-Agent                  February 2026


6.2.3.  Attribute-Based Access Control (ABAC)

   The framework uses ABAC with attributes from multiple sources:

   *  *Agent Attributes*: Identity, capabilities, reputation score, home
      domain.

   *  *Resource Attributes*: Sensitivity, ownership, location,
      classification.

   *  *Environmental Attributes*: Time, network location, threat level.

   *  *Collaboration Attributes*: Task type, participating domains,
      trust level.

7.  Capability Discovery and Negotiation

7.1.  Capability Description Language

   Agents describe their capabilities using a structured language based
   on JSON Schema:






























Cui                      Expires 15 August 2026                [Page 12]

Internet-Draft                  CDI-Agent                  February 2026


   {
     "agent_capability_profile": {
       "version": "1.0",
       "agent_id": "did:example:agent123",
       "home_domain": "example.com",
       "capabilities": [
         {
           "capability_id": "natural_language_processing",
           "category": "ai_processing",
           "subcategories": ["text_analysis", "sentiment_analysis"],
           "performance_metrics": {
             "accuracy": 0.92,
             "latency_ms": 150,
             "throughput_rps": 100
           },
           "input_formats": ["text/plain", "application/json"],
           "output_formats": ["application/json"],
           "privacy_attributes": {
             "data_retention": "ephemeral",
             "data_sharing": "none"
           },
           "resource_requirements": {
             "compute_units": 2,
             "memory_mb": 512,
             "network_bandwidth_mbps": 10
           }
         }
       ],
       "constraints": {
         "max_concurrent_tasks": 5,
         "supported_domains": ["example.com", "partner.org"],
         "geographic_restrictions": ["US", "EU"],
         "compliance_frameworks": ["GDPR", "HIPAA"]
       }
     }
   }

7.2.  Discovery Mechanisms

7.2.1.  Directory-Based Discovery

   Domains publish authorized agent capabilities in federated
   directories:

   1.  *Local Directory Registration*: Agents register capabilities with
       their home domain directory.





Cui                      Expires 15 August 2026                [Page 13]

Internet-Draft                  CDI-Agent                  February 2026


   2.  *Federated Directory Sync*: Domain directories synchronize
       authorized capability information.

   3.  *Query Interface*: Agents query directories to discover
       capabilities across domains.

   4.  *Privacy-Preserving Queries*: Support for capability discovery
       without revealing specific agent identities when not needed.

7.2.2.  Peer-to-Peer Discovery

   For dynamic or ad-hoc collaborations:

   1.  *Capability Advertisement*: Agents broadcast capability summaries
       within trusted networks.

   2.  *Matchmaking Services*: Third-party services match agents with
       complementary capabilities.

   3.  *Reputation-Based Discovery*: Discover agents based on reputation
       scores from previous collaborations.

7.3.  Capability Negotiation Protocol

   When agents with complementary capabilities are identified:


























Cui                      Expires 15 August 2026                [Page 14]

Internet-Draft                  CDI-Agent                  February 2026


  +-----------+                +-----------+               +-----------+
  | Agent A   |                | Gateway   |               | Agent B   |
  | (Domain X)|                |           |               | (Domain Y)|
  +-----------+                +-----------+               +-----------+
        |                            |                           |
        | 1. Initiate collaboration  |                           |
        |    request                 |                           |
        |--------------------------->|                           |
        |                            |                           |
        |                            |  2. Forward to suitable   |
        |                            |      partner (Agent B)    |
        |                            |-------------------------->|
        |                            |  3. Return capability     |
        |                            |     requirements and      |
        |                            |      constraints          |
        |                            |<--------------------------|
        |                            |                           |
        | 4. Check compatibility and |                           |
        |    policy compliance       |                           |
        |<---------------------------|                           |
        |                            |                           |
        | 5. Negotiate specific      |                           |
        |    parameters (quality,    |                           |
        |    cost, timing)           |                           |
        |--------------------------->|                           |
        |                            |-------------------------->|
        |                            | 6. Reach agreement        |
        |                            |                           |
        |                            |<--------------------------|
        |                            |                           |
        | 7. Finalize collaboration  |                           |
        |    contract                |                           |
        |<---------------------------|                           |
        |                            |                           |

8.  Communication Protocols

8.1.  Cross-Domain Message Format

   All cross-domain messages use a standardized envelope format:











Cui                      Expires 15 August 2026                [Page 15]

Internet-Draft                  CDI-Agent                  February 2026


   {
     "message_envelope": {
       "version": "1.0",
       "message_id": "urn:uuid:550e8400-e29b-41d4-a716-446655440000",
       "timestamp": "2024-01-15T10:30:00Z",
       "sender": {
         "agent_id": "did:example:sender123",
         "domain": "example.com",
         "credentials": ["vc:example:credential456"]
       },
       "recipient": {
         "agent_id": "did:example:recipient789",
         "domain": "partner.org"
       },
       "routing": {
         "path": ["gateway.example.com", "gateway.partner.org"],
         "hops": 2,
         "ttl": 3600
       },
       "security": {
         "encryption": "A256GCM",
         "signature": "ES256",
         "integrity_protection": true
       },
       "payload": {
         "type": "task_request",
         "content": "Base64-encoded encrypted payload",
         "content_type": "application/json"
       },
       "metadata": {
         "priority": "normal",
         "response_required": true,
         "audit_trail_id": "audit:example:trail123"
       }
     }
   }

8.2.  Communication Patterns

8.2.1.  Direct Agent-to-Agent Communication

   For high-trust, high-performance scenarios:

   1.  *Tunnel Establishment*: Establish secure tunnels through domain
       gateways.

   2.  *Peer Authentication*: Mutual authentication using domain-issued
       credentials.



Cui                      Expires 15 August 2026                [Page 16]

Internet-Draft                  CDI-Agent                  February 2026


   3.  *End-to-End Encryption*: Application-layer encryption independent
       of transport security.

   4.  *Heartbeat Monitoring*: Continuous monitoring of connection
       health and security.

8.2.2.  Gateway-Mediated Communication

   For enhanced security and policy enforcement:

   1.  *Message Inspection*: Gateways inspect messages for policy
       compliance.

   2.  *Content Transformation*: Gateways may transform content to meet
       domain requirements.

   3.  *Quality of Service*: Gateways provide QoS guarantees for cross-
       domain communication.

   4.  *Load Balancing*: Gateways distribute traffic across multiple
       agent instances.

8.2.3.  Store-and-Forward Communication

   For disconnected or asynchronous operations:

   1.  *Message Queuing*: Gateways queue messages when recipients are
       unavailable.

   2.  *Delivery Guarantees*: Configurable delivery guarantees (at-most-
       once, at-least-once, exactly-once).

   3.  *Priority Handling*: Priority-based message scheduling and
       delivery.

   4.  *Dead Letter Handling*: Processing of undeliverable messages.

8.3.  Protocol Layering

   The communication protocol stack for cross-domain agent interaction:











Cui                      Expires 15 August 2026                [Page 17]

Internet-Draft                  CDI-Agent                  February 2026


   +-----------------------------------------------------+
   |           Application-Specific Protocols            |
   |  (Task coordination, data exchange, collaboration)  |
   +-----------------------------------------------------+
   |         Cross-Domain Agent Messaging Protocol       |
   |    (Envelope format, routing, reliability, QoS)     |
   +-----------------------------------------------------+
   |              Security Layer Protocol                |
   |    (Authentication, encryption, integrity, nonce)   |
   +-----------------------------------------------------+
   |              Trust Layer Protocol                   |
   |    (Credential verification, policy enforcement)    |
   +-----------------------------------------------------+
   |             Transport Layer Protocol                |
   |        (HTTP/2, WebSocket, MQTT, AMQP)             |
   +-----------------------------------------------------+

9.  Security Considerations

9.1.  Threat Model

   The framework addresses the following threat vectors:

   1.  *Impersonation Attacks*: Malicious agents pretending to be
       legitimate agents from trusted domains.

   2.  *Policy Bypass Attacks*: Attempts to circumvent domain policies
       through technical or procedural means.

   3.  *Data Exfiltration*: Unauthorized transfer of sensitive data
       across domain boundaries.

   4.  *Denial of Service*: Attacks targeting the availability of cross-
       domain collaboration services.

   5.  *Trust Exploitation*: Abuse of trust relationships to gain
       unauthorized access or privileges.

   6.  *Audit Tampering*: Attempts to modify or delete audit logs to
       conceal malicious activities.

9.2.  Security Controls

9.2.1.  Authentication and Authorization

   *  *Multi-Factor Authentication*: Require multiple credentials for
      sensitive operations.




Cui                      Expires 15 August 2026                [Page 18]

Internet-Draft                  CDI-Agent                  February 2026


   *  *Continuous Authentication*: Re-authenticate agents periodically
      during long sessions.

   *  *Context-Aware Authorization*: Adjust permissions based on dynamic
      risk assessments.

   *  *Least Privilege Enforcement*: Grant minimal necessary permissions
      for each task.

9.2.2.  Data Protection

   *  *End-to-End Encryption*: Encrypt sensitive data throughout its
      lifecycle.

   *  *Data Minimization*: Transfer only necessary data for each
      collaboration.

   *  *Privacy-Preserving Computation*: Use techniques like federated
      learning and secure multi-party computation.

   *  *Data Sovereignty*: Respect data sovereignty requirements of each
      domain.

9.2.3.  Monitoring and Detection

   *  *Behavioral Analytics*: Monitor agent behavior for anomalies
      indicative of compromise.

   *  *Cross-Domain Correlation*: Correlate security events across
      multiple domains.

   *  *Real-Time Threat Intelligence*: Integrate threat intelligence
      feeds from all participating domains.

   *  *Automated Response*: Automated containment and mitigation of
      detected threats.

9.3.  Security Assurance

9.3.1.  Trust Verification

   *  *Credential Chain Validation*: Verify the complete chain of
      credentials from root authorities.

   *  *Revocation Checking*: Continuously check credential revocation
      status.





Cui                      Expires 15 August 2026                [Page 19]

Internet-Draft                  CDI-Agent                  February 2026


   *  *Reputation Scoring*: Use reputation systems to assess agent
      trustworthiness.

   *  *Behavioral Attestation*: Use remote attestation to verify agent
      integrity.

9.3.2.  Audit and Accountability

   *  *Immutable Audit Logs*: Store audit logs in tamper-evident
      storage.

   *  *Cross-Domain Audit Correlation*: Enable correlation of audit
      trails across domains.

   *  *Non-Repudiation*: Ensure agents cannot deny actions they have
      taken.

   *  *Forensic Readiness*: Maintain evidence for potential legal or
      investigative proceedings.

10.  Performance and Scalability

10.1.  Performance Metrics

   The framework defines the following performance metrics:

   1.  *Discovery Latency*: Time to discover suitable collaboration
       partners (target: < 5 seconds for 95% of queries).

   2.  *Trust Establishment Time*: Time to establish trust between
       previously unknown domains (target: < 30 seconds).

   3.  *Message Delivery Latency*: End-to-end latency for cross-domain
       messages (target: < 100ms for 95% of messages within same
       region).

   4.  *Policy Evaluation Time*: Time to evaluate access control
       policies (target: < 10ms per decision).

   5.  *Agent Registration Time*: Time for an agent to register in a
       foreign domain (target: < 2 seconds).

10.2.  Scalability Considerations

10.2.1.  Horizontal Scaling

   *  *Stateless Design*: Design components to be stateless where
      possible for easy scaling.



Cui                      Expires 15 August 2026                [Page 20]

Internet-Draft                  CDI-Agent                  February 2026


   *  *Load Distribution*: Distribute load across multiple instances of
      each component.

   *  *Geographic Distribution*: Deploy components in multiple
      geographic regions.

   *  *Caching Strategy*: Implement multi-level caching to reduce
      backend load.

10.2.2.  Federation Scaling

   *  *Hierarchical Federation*: Organize domains into hierarchies to
      reduce pairwise trust relationships.

   *  *Transitive Trust*: Support transitive trust with appropriate
      safeguards.

   *  *Partial Mesh Networks*: Optimize trust relationships based on
      collaboration patterns.

   *  *Domain Clustering*: Group domains with frequent collaborations to
      reduce overhead.

10.3.  Resource Management

10.3.1.  Computational Resources

   *  *Elastic Scaling*: Automatically scale resources based on demand.

   *  *Resource Quotas*: Enforce resource quotas per domain and per
      agent.

   *  *Efficient Algorithms*: Use computationally efficient algorithms
      for cryptographic operations.

   *  *Hardware Acceleration*: Leverage hardware acceleration for
      performance-critical operations.

10.3.2.  Network Resources

   *  *Bandwidth Management*: Prioritize cross-domain traffic based on
      importance.

   *  *Connection Pooling*: Reuse connections to reduce connection
      establishment overhead.

   *  *Compression*: Compress messages to reduce bandwidth usage.




Cui                      Expires 15 August 2026                [Page 21]

Internet-Draft                  CDI-Agent                  February 2026


   *  *Adaptive Protocols*: Use protocols that adapt to network
      conditions.

11.  Deployment Considerations

11.1.  Deployment Models

11.1.1.  Centralized Gateway Model

   *  *Description*: All cross-domain traffic flows through centralized
      interoperability gateways.

   *  *Advantages*: Simplified management, consistent policy
      enforcement, comprehensive auditing.

   *  *Disadvantages*: Single point of failure, potential performance
      bottleneck, higher latency.

   *  *Use Cases*: Highly regulated environments, initial deployments,
      domains with limited technical resources.

11.1.2.  Distributed Gateway Model

   *  *Description*: Each domain operates its own gateway, with gateways
      forming a peer-to-peer network.

   *  *Advantages*: No single point of failure, better performance,
      preserves domain autonomy.

   *  *Disadvantages*: More complex to manage, requires inter-gateway
      trust establishment.

   *  *Use Cases*: Large-scale deployments, domains with technical
      expertise, performance-sensitive applications.

11.1.3.  Hybrid Model

   *  *Description*: Combination of centralized and distributed elements
      based on requirements.

   *  *Advantages*: Flexibility to optimize for different use cases,
      incremental deployment.

   *  *Disadvantages*: Increased complexity, potential consistency
      challenges.

   *  *Use Cases*: Evolving deployments, heterogeneous domain
      environments, transitional architectures.



Cui                      Expires 15 August 2026                [Page 22]

Internet-Draft                  CDI-Agent                  February 2026


11.2.  Integration with Existing Systems

11.2.1.  Legacy Agent Systems

   *  *Wrapper Components*: Develop wrappers that enable legacy agents
      to participate in cross-domain collaborations.

   *  *Protocol Translation*: Translate between legacy protocols and the
      cross-domain interoperability protocols.

   *  *Policy Mapping*: Map legacy policy mechanisms to the framework's
      policy model.

   *  *Gradual Migration*: Support gradual migration from legacy systems
      to native implementations.

11.2.2.  Cloud and Edge Deployments

   *  *Cloud-Native Design*: Design components as cloud-native
      microservices.

   *  *Edge Optimization*: Optimize for edge deployments with limited
      resources.

   *  *Hybrid Cloud Support*: Support deployments spanning multiple
      cloud providers and on-premises infrastructure.

   *  *Containerization*: Package components as containers for easy
      deployment.

11.3.  Operational Considerations

11.3.1.  Monitoring and Management

   *  *Unified Dashboard*: Provide a unified dashboard for monitoring
      cross-domain collaborations.

   *  *Health Checks*: Implement comprehensive health checks for all
      components.

   *  *Alerting System*: Configurable alerting for security events and
      performance issues.

   *  *Capacity Planning*: Tools for capacity planning and resource
      allocation.






Cui                      Expires 15 August 2026                [Page 23]

Internet-Draft                  CDI-Agent                  February 2026


11.3.2.  Update and Maintenance

   *  *Rolling Updates*: Support rolling updates without disrupting
      ongoing collaborations.

   *  *Version Compatibility*: Maintain compatibility between different
      versions of the framework.

   *  *Backward Compatibility*: Ensure new versions don't break existing
      deployments.

   *  *Migration Tools*: Provide tools for migrating between framework
      versions.

12.  Use Cases and Examples

12.1.  Cross-Enterprise Supply Chain Optimization

   *Scenario*: Multiple companies in a supply chain need to collaborate
   using AI agents to optimize inventory, logistics, and production
   scheduling.

   *Challenges*:

   *  Each company has its own systems, policies, and data sovereignty
      requirements.

   *  Sensitive business information must not be exposed to competitors.

   *  Real-time coordination is needed across organizational boundaries.

   *Solution using CDI Framework*:

   1.  Each company deploys an interoperability gateway.

   2.  Supply chain partners establish limited trust relationships for
       specific collaboration areas.

   3.  Agents are delegated with carefully constrained capabilities for
       supply chain optimization.

   4.  Privacy-preserving techniques (like federated learning) are used
       to train optimization models without sharing raw data.

   5.  Audit trails are maintained for compliance and dispute
       resolution.





Cui                      Expires 15 August 2026                [Page 24]

Internet-Draft                  CDI-Agent                  February 2026


12.2.  Smart City Federation

   *Scenario*: Multiple municipalities want to collaborate on smart city
   initiatives while maintaining control over their own infrastructure
   and data.

   *Challenges*:

   *  Different municipalities have different regulations and policies.

   *  Citizens' privacy must be protected across jurisdictional
      boundaries.

   *  Emergency situations require rapid coordination.

   *Solution using CDI Framework*:

   1.  Each municipality operates as an independent domain.

   2.  A federation agreement establishes baseline trust and policies.

   3.  Specialized agents for traffic management, emergency response,
       and utility optimization can operate across municipalities.

   4.  Data sharing follows strict privacy-preserving protocols.

   5.  During emergencies, trust levels can be temporarily elevated to
       enable faster coordination.

12.3.  Cross-Border Financial Services Collaboration

   *Scenario*: Financial institutions across different regulatory
   jurisdictions need AI agents to collaborate on fraud detection, risk
   assessment, and compliance monitoring while adhering to strict
   regulatory requirements.

   *Challenges*:

   *  Different countries have different financial regulations and
      compliance requirements.

   *  Sensitive customer financial data cannot be freely shared across
      borders.

   *  Real-time fraud detection requires rapid information exchange
      while maintaining data privacy.





Cui                      Expires 15 August 2026                [Page 25]

Internet-Draft                  CDI-Agent                  February 2026


   *  Audit trails must be comprehensive and legally admissible in
      multiple jurisdictions.

   *Solution using CDI Framework*:

   1.  Each financial institution operates within its regulatory domain
       with institution-specific policies.

   2.  Cross-border trust agreements are established with legal and
       regulatory compliance baked into the trust parameters.

   3.  Specialized agents for fraud pattern recognition can operate
       across institutions using privacy-preserving techniques like
       federated learning.

   4.  Regulatory compliance agents ensure all cross-border operations
       adhere to applicable laws (e.g., GDPR, CCPA, Basel III).

   5.  All transactions are logged with cryptographic proofs that can be
       verified by regulators in any jurisdiction.

   *Key Technical Features*:

   *  *Regulatory Policy Engines*: Each domain includes policy engines
      that encode jurisdictional regulations.

   *  *Privacy-Preserving Analytics*: Use of homomorphic encryption for
      cross-institution fraud pattern analysis without exposing raw
      transaction data.

   *  *Multi-Jurisdictional Audit*: Audit logs structured to meet
      requirements of multiple regulatory bodies simultaneously.

   *  *Emergency Override Protocols*: Controlled mechanisms for
      temporary policy relaxation during financial crises or systemic
      risk events.

12.4.  Cross-Domain Emergency Response System

   *Scenario*: During natural disasters, public health emergencies, or
   cybersecurity incidents, AI agents from different organizations need
   to coordinate rapid response while maintaining security boundaries
   and respecting organizational autonomy.

   *Challenges*:

   *  Time-critical operations requiring collaboration establishment
      within minutes.



Cui                      Expires 15 August 2026                [Page 26]

Internet-Draft                  CDI-Agent                  February 2026


   *  Different organizations have varying command hierarchies and
      decision-making processes.

   *  Sensitive information must be shared only within necessary scope.

   *  Resource constraints during emergencies may affect communication
      reliability.

   *  Post-emergency accountability and after-action analysis
      requirements.

   *Solution using CDI Framework*:

   1.  *Pre-Established Trust Frameworks*: Organizations establish
       baseline trust relationships and policies during peacetime.

   2.  *Emergency Trust Elevation*: During declared emergencies, trust
       levels can be temporarily elevated with appropriate safeguards
       and post-event review requirements.

   3.  *Dynamic Policy Adaptation*: Emergency-specific policies override
       normal operating policies temporarily.

   4.  *Resource Pooling Coordination*: AI agents coordinate resource
       allocation across organizational boundaries while maintaining
       ownership tracking.

   5.  *Situational Awareness Sharing*: Secure sharing of situational
       data with granular access controls based on role and need-to-
       know.

   *Implementation Components*:

   *  *Emergency Declaration Protocol*: Standardized mechanism for
      organizations to declare emergencies and activate enhanced
      collaboration modes.

   *  *Priority Communication Channels*: Dedicated, high-priority
      communication paths for emergency coordination.

   *  *Resource Discovery and Allocation*: Dynamic discovery of
      available resources (personnel, equipment, facilities) across
      participating organizations.

   *  *Common Operational Picture*: Federated data aggregation to create
      unified situational awareness without centralizing sensitive
      information.




Cui                      Expires 15 August 2026                [Page 27]

Internet-Draft                  CDI-Agent                  February 2026


   *Example Flow - Natural Disaster Response*:

   1.  Earthquake occurs affecting multiple jurisdictions.

   2.  Emergency services from affected areas declare emergencies
       through their interoperability gateways.

   3.  Trust levels are automatically elevated based on pre-configured
       emergency protocols.

   4.  AI agents from different emergency services discover each other's
       capabilities through federated directories.

   5.  Resource coordination agents negotiate allocation of search-and-
       rescue teams, medical supplies, and evacuation routes.

   6.  Privacy-preserving techniques allow sharing of victim location
       data while protecting personally identifiable information.

   7.  Post-event, all actions are audited, trust levels revert to
       normal, and after-action reports are generated from the
       comprehensive audit logs.

12.5.  Multi-Cloud AI Workload Orchestration

   *Scenario*: Enterprises running AI workloads across multiple cloud
   providers need agents to manage resources, optimize costs, and ensure
   compliance while avoiding vendor lock-in.

   *Challenges*:

   *  Different cloud providers have proprietary APIs and management
      interfaces.

   *  Data sovereignty requirements may restrict where workloads can
      run.

   *  Cost optimization requires dynamic workload migration across
      providers.

   *  Security policies must be consistently enforced across
      heterogeneous environments.

   *Solution using CDI Framework*:

   1.  Each cloud environment operates as a separate domain with cloud-
       specific policies and capabilities.




Cui                      Expires 15 August 2026                [Page 28]

Internet-Draft                  CDI-Agent                  February 2026


   2.  Enterprise governance domain defines overarching policies that
       apply across all cloud domains.

   3.  Orchestration agents operate across cloud domains to optimize
       workload placement based on cost, performance, and compliance
       requirements.

   4.  Data movement agents manage secure data transfer between cloud
       environments with appropriate encryption and access controls.

   5.  Compliance monitoring agents ensure consistent policy enforcement
       regardless of where workloads execute.

   *Technical Implementation*:

   *  *Cloud Abstraction Layer*: Standardized interface that abstracts
      cloud provider differences.

   *  *Cost Optimization Engine*: AI agents that analyze pricing models
      and performance metrics to recommend optimal workload placement.

   *  *Data Gravity Management*: Intelligent agents that minimize data
      movement costs by colocating computation with data.

   *  *Compliance Mapping*: Automated mapping of cloud provider
      compliance certifications to enterprise regulatory requirements.

12.6.  International Research Data Commons

   *Scenario*: Global research collaborations need to share and analyze
   sensitive research data (e.g., genomic data, climate data,
   epidemiological data) while protecting participant privacy and
   respecting national data sovereignty laws.

   *Challenges*:

   *  Research data often contains sensitive personal information with
      strict privacy requirements.

   *  Different countries have different data protection laws and
      ethical review requirements.

   *  Researchers need to collaborate on analysis while maintaining
      control over their contributed data.

   *  Funding agencies require accountability for data usage and
      research outputs.




Cui                      Expires 15 August 2026                [Page 29]

Internet-Draft                  CDI-Agent                  February 2026


   *Solution using CDI Framework*:

   1.  Each research institution operates as an independent domain with
       institutional review board (IRB) approved policies.

   2.  Research consortia establish collaboration domains with
       consortium-specific policies that respect all member
       institutions' requirements.

   3.  Data analysis agents operate on federated data without needing to
       centralize sensitive information.

   4.  Publication agents coordinate multi-institution authorship and
       ensure proper attribution.

   5.  Data usage tracking agents monitor compliance with data use
       agreements across all participating institutions.

   *Key Features*:

   *  *Ethical Compliance Engine*: Automated checks for compliance with
      ethical research standards across jurisdictions.

   *  *Differential Privacy Integration*: Built-in differential privacy
      mechanisms for aggregate analysis.

   *  *Data Provenance Tracking*: Complete lineage tracking for research
      data from collection through analysis to publication.

   *  *Automated Institutional Review*: Streamlined process for cross-
      institutional research approval.

12.7.  Smart Manufacturing Supply Chain

   *Scenario*: Manufacturers, suppliers, and logistics providers in a
   smart manufacturing ecosystem need to coordinate production,
   inventory, and delivery using AI agents while protecting intellectual
   property and competitive information.

   *Challenges*:

   *  Competitors may be part of the same supply chain, requiring
      information boundaries.

   *  Real-time coordination needed for just-in-time manufacturing and
      inventory management.





Cui                      Expires 15 August 2026                [Page 30]

Internet-Draft                  CDI-Agent                  February 2026


   *  Quality control data needs to flow upstream to suppliers without
      revealing proprietary manufacturing processes.

   *  Cybersecurity threats targeting interconnected industrial control
      systems.

   *Solution using CDI Framework*:

   1.  Each company in the supply chain operates as an independent
       domain with competitive boundary policies.

   2.  Supply chain collaboration domains establish limited information
       sharing agreements for specific coordination tasks.

   3.  Production planning agents coordinate across organizations while
       preserving competitive intelligence.

   4.  Quality monitoring agents share defect information with suppliers
       without revealing manufacturing process details.

   5.  Cybersecurity monitoring agents collaborate on threat detection
       while protecting each company's security posture information.

   *Implementation Approach*:

   *  *Need-to-Know Information Sharing*: Granular controls on what
      information is shared with which partners.

   *  *Competitive Boundary Management*: Clear policies defining what
      constitutes competitive information that should not be shared.

   *  *Real-Time Coordination Protocols*: Low-latency communication for
      time-sensitive manufacturing coordination.

   *  *Industrial IoT Security*: Specialized security protocols for
      industrial control system integration.

12.8.  Cross-Jurisdictional Law Enforcement Collaboration

   *Scenario*: Law enforcement agencies from different jurisdictions
   need to collaborate on investigations while respecting legal
   boundaries, privacy laws, and chain of evidence requirements.

   *Challenges*:

   *  Different legal systems have different requirements for evidence
      collection and sharing.




Cui                      Expires 15 August 2026                [Page 31]

Internet-Draft                  CDI-Agent                  February 2026


   *  Privacy laws restrict sharing of personal information across
      borders.

   *  Chain of custody must be maintained for digital evidence.

   *  Need for rapid information sharing in time-sensitive
      investigations (e.g., kidnapping, terrorism).

   *Solution using CDI Framework*:

   1.  Each law enforcement agency operates within its jurisdictional
       domain with legally compliant policies.

   2.  Mutual legal assistance treaty (MLAT) frameworks are encoded into
       trust agreements between domains.

   3.  Investigation coordination agents facilitate information sharing
       within legal boundaries.

   4.  Evidence handling agents maintain chain of custody across
       jurisdictional transfers.

   5.  Legal compliance agents ensure all cross-jurisdictional
       operations adhere to applicable laws.

   *Technical Considerations*:

   *  *Legal Authority Verification*: Automated verification of legal
      authority for specific investigative actions.

   *  *Privacy-Preserving Matching*: Techniques for matching persons of
      interest without sharing full identity information.

   *  *Digital Evidence Chain of Custody*: Cryptographic proof of
      evidence integrity and custody chain.

   *  *Automated Legal Documentation*: Generation of legally required
      documentation for cross-jurisdictional operations.

12.9.  Global Energy Grid Coordination

   *Scenario*: Energy providers, grid operators, and renewable energy
   producers across regions need to coordinate energy production,
   distribution, and consumption while maintaining grid stability and
   respecting commercial interests.

   *Challenges*:




Cui                      Expires 15 August 2026                [Page 32]

Internet-Draft                  CDI-Agent                  February 2026


   *  Different grid operators have proprietary control systems and
      protocols.

   *  Renewable energy sources introduce variability requiring real-time
      coordination.

   *  Commercial energy trading requires secure transaction mechanisms.

   *  Grid cybersecurity requires collaborative threat detection without
      revealing vulnerability information.

   *Solution using CDI Framework*:

   1.  Each energy provider and grid operator operates as an independent
       domain.

   2.  Regional coordination domains establish protocols for grid
       stability management.

   3.  Energy trading agents facilitate secure transactions across
       organizational boundaries.

   4.  Grid optimization agents coordinate production and consumption
       across regions.

   5.  Cybersecurity agents collaborate on threat detection while
       protecting proprietary system information.

   *Key Components*:

   *  *Grid Stability Protocols*: Standardized protocols for maintaining
      grid stability across interconnected systems.

   *  *Renewable Integration Management*: Coordination of variable
      renewable energy sources across the grid.

   *  *Secure Energy Trading*: Privacy-preserving mechanisms for energy
      market transactions.

   *  *Grid Resilience Coordination*: Collaborative response to grid
      disturbances and failures.

13.  IANA Considerations

   This document has no IANA actions.

14.  Normative References




Cui                      Expires 15 August 2026                [Page 33]

Internet-Draft                  CDI-Agent                  February 2026


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

Acknowledgments

Author's Address

   Yong Cui
   Tsinghua University
   Beijing, 100084
   China
   Email: cuiyong@tsinghua.edu.cn
   URI:   http://www.cuiyong.net/




































Cui                      Expires 15 August 2026                [Page 34]


name: draft-chang-agent-context-interaction
rev: 01
title: Agent Context Interaction Optimizations
time: 2026-02-13T02:26:55Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-17T02:26:55Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "ML traffic mgmt"]
tags: []
fetched_at: 2026-02-27T22:56:03.420536+00:00
abstract:
The context distribution is important in a multi-agent system, which
   will impact the execution latency, token consumption, and task
   completion success rate, especially in a complex and multi-round
   workflow.

   This document specifies the scenarios and procedures of agent context
   distribution as well as the corresponding optimization during the
   procedures in order to provide precise control of the context
   distribution among the multiple agents.

full_text:
Working Group                                                   Z. Chang
Internet-Draft                                                   S. Peng
Intended status: Standards Track                     Huawei Technologies
Expires: 16 August 2026                                 12 February 2026


                Agent Context Interaction Optimizations
                draft-chang-agent-context-interaction-01

Abstract

   The context distribution is important in a multi-agent system, which
   will impact the execution latency, token consumption, and task
   completion success rate, especially in a complex and multi-round
   workflow.

   This document specifies the scenarios and procedures of agent context
   distribution as well as the corresponding optimization during the
   procedures in order to provide precise control of the context
   distribution among the multiple agents.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/.

   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."

   This Internet-Draft will expire on 16 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (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



Chang & Peng             Expires 16 August 2026                 [Page 1]

Internet-Draft                  PCECC-SR                   February 2026


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   3.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Agent Context Interaction Optimizations . . . . . . . . . . .   6
     4.1.  Overview of Agent Context Interaction Optimizations . . .   6
     4.2.  Context Isolation Strategy  . . . . . . . . . . . . . . .   7
   5.  JSON Specifications . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  TaskContext Schema  . . . . . . . . . . . . . . . . . . .   7
     5.2.  AgentContext Schema . . . . . . . . . . . . . . . . . . .   8
     5.3.  Interaction Process of Agent Context Interaction
           Optimizations . . . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Appendix A.  Contributor Addresses  . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   In a multi-agent system, contexts such as agents' capabilities,
   metadata, and intermediate results are exchanged among agents through
   an Agent2Agent protocol to support task execution.

   At present, agent context interaction commonly occurs in two
   scenarios: interaction among independent agents and interaction among
   collaborative agents.  In both scenarios, context information is
   typically distributed in a raw or unfiltered manner, without task-
   aware or relevance-based processing.  As a result, large volumes of
   redundant or irrelevant context are propagated across agents, leading
   to excessive token consumption.

   Furthermore, existing agent interaction protocols generally lack
   explicit task management mechanisms, such as task state tracking and
   progress awareness, for complex tasks that require multi-turn
   interactions and the coordinated invocation of multiple agents.  In
   the absence of structured task context, the LLM’s attention may drift
   across interaction rounds, which can significantly increase execution
   latency and reduce overall task success rates.




Chang & Peng             Expires 16 August 2026                 [Page 2]

Internet-Draft                  PCECC-SR                   February 2026


   In this document, we assume a task-oriented multi-agent control model
   in which a designated Master Agent is responsible for global task
   orchestration, while other agents are invoked on demand to execute
   specific subtasks.  The Master Agent receives the user request,
   constructs the overall task, decomposes it into subtasks, and
   coordinates their execution by selectively invoking appropriate
   agents.

   Invoked agents operate under the control of the Master Agent and
   focus exclusively on the execution of assigned subtasks.  They do not
   maintain a global view of the task and do not directly interact with
   end users or other invoked agents unless explicitly mediated by the
   Master Agent.  This master–invoked agent architecture establishes a
   clear separation between global task management and localized task
   execution.

   Efficient context distribution is a critical capability in such a
   master–invoked multi-agent system and is largely determined by the
   design of the agent context interaction protocol.  The protocol
   directly controls how much context is exchanged, how it is
   structured, and how it is propagated across agents.  As a result, it
   has a direct and measurable impact on execution latency, token
   consumption, and task completion success rate, particularly in
   complex and multi-round agent workflows.

   This document specifies the scenarios and procedures for agent
   context distribution and introduces corresponding optimization
   mechanisms applied during these procedures.  The goal is to provide
   precise and task-aware control over context dissemination among
   multiple agents, thereby improving execution efficiency, reducing
   unnecessary token usage, and enhancing task completion success rates.

2.  Terminology

2.1.  Conventions and Terminology

   TaskContext: A structured state object that is created and maintained
   exclusively by the Master Agent throughout the lifecycle of a complex
   task.  It provides a persistent and machine-interpretable
   representation of task progress, enabling the Master agent to manage
   attention across multiple subtasks and prevent unintended context
   drift during multi-step execution.









Chang & Peng             Expires 16 August 2026                 [Page 3]

Internet-Draft                  PCECC-SR                   February 2026


   AgentContext: The execution state that is specific to an individual
   agent within a multi-agent workflow.  It is strictly isolated between
   subtasks; during each subtask invocation, only the AgentContext
   instance corresponding to the target agent is delivered.  Upon
   completion, the corresponding agent returns exclusively its own
   updated AgentContext

   SynchronousContextInteraction: A context sharing mode in which an
   agent MUST wait for the completion of the current interaction round,
   including context exchange and result feedback, before proceeding to
   the next task or interaction.  In this mode, context distribution and
   task execution are strictly ordered, ensuring deterministic task
   progression and explicit dependency resolution among agents.

   AsynchronousContextInteraction: A context sharing mode in which an
   agent MAY exchange contexts with multiple agents concurrently without
   waiting for the completion of other ongoing interactions.  This mode
   allows parallel context distribution and task execution, enabling
   higher system throughput and reduced overall execution latency in
   multi-agent collaborative workflows.

   Master Agent: The agent responsible for receiving user requests,
   maintaining the global TaskContext, decomposing complex tasks into
   subtasks, invoking other agents, and evaluating subtask execution
   results.

   Invoked Agent: An agent that is invoked by the Master Agent to
   execute a specific subtask.  An Invoked Agent operates on an isolated
   AgentContext and returns only its updated execution state to the
   Master Agent upon completion.

2.2.  Requirements Language

   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] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Scenarios

   There are two main scenarios when comes to the context distribution
   among agents, that is, (1) Context Distribution among Independent
   Agents and (2) Context Distribution among Collaborative Agents.







Chang & Peng             Expires 16 August 2026                 [Page 4]

Internet-Draft                  PCECC-SR                   February 2026


                       +-------------+
                       |    Master   |
                       |    Agent    |
                     / +-------------+ \
                 1 /        1 |        1 \
                 / 2          |2           \2
               /              |              \
       +------------+  +-------------+  +------------+
       |   Agent 1  |  |   Agent 2   |  |   Agent 3  |
       +------------+  +-------------+  +------------+

      (1) Context Distribution among Independent Agents

                       +-------------+
                       |    Master   |
                       |    Agent    |
                     / +-------------+ \
                 1 /        3 |        5 \
                 / 2          |4           \6
               /              |              \
       +------------+  +-------------+  +------------+
       |   Agent 1  |  |   Agent 2   |  |   Agent 3  |
       +------------+  +-------------+  +------------+

      (2) Context Distribution among Collaborative Agents



               Figure 1: Agent Context Distribution Scenarios

   In the first scenario, i.e. Context Distribution among Independent
   Agents, the agents in the multi-agent system are independent.  The
   Master Agent receives the request, creates a main task and breaks
   down into several sub-tasks, and distribute those sub-tasks to
   correponding agents.  The discover of the correponding agents is out
   of the scope of this draft.  This could be for a tour-plan task,
   which could involve the agents of hotel-booking, flight-booking, and
   weather-checking.  When the Master Agent receives the tour-plan task,
   it will break it down into sub-tasks and distribute context to each
   agent to accomplish the task.

   In the second scenario, i.e. Context Distribution among Collaborative
   Agents, the agents in the multi-agent system are collaborative, that
   is, the input of the latter agent in a workflow will depend upon the
   former agent.  The Master Agent receives the request, creates a main
   task and breaks down into several sub-tasks.  It will distribute the
   sub-tasks to correponding agents in an order.  The discover of the
   correponding agents is out of the scope of this draft.  This could be



Chang & Peng             Expires 16 August 2026                 [Page 5]

Internet-Draft                  PCECC-SR                   February 2026


   for a see-a-doctor task, which could involve the agents of disease-
   diagnosis, prescription, and buy-medicine.  When the Master Agent
   receives the see-a-doctor task, it will break it down into sub-tasks
   and distribute context to the first agent, and then depending upon
   the output of the first agent, the second accomplishes its
   corresponding tasks, and then the next agent follows the same
   procedure.

4.  Agent Context Interaction Optimizations

4.1.  Overview of Agent Context Interaction Optimizations



        +--------------------------------------------------------------+
        |                          Data Layer                          |
        +--------------------------------------------------------------+
        |                                                              |
        | TaskContext  AgentContext  DeviceContext  EnvironmentContext |
        |                                                              |
        +--------------------------------------------------------------+

        +--------------------------------------------------------------+
        |                       Operation Layer                        |
        +--------------------------------------------------------------+
        |                                                              |
        | SynchronousContextInteraction  AsynchronousContextInteraction|
        |                                                              |
        +--------------------------------------------------------------+

        +--------------------------------------------------------------+
        |                      Transport Layer                         |
        +--------------------------------------------------------------+
        |                                                              |
        |    STDIO     StreamablrHTTP     WebSocket    SoftBus         |
        |                                                              |
        +--------------------------------------------------------------+




  Figure 2: Architecture of the Agent Context Interaction Optimizations

   We design a structured context interaction format to optimize context
   exchange in multi-agent systems across several key dimensions.






Chang & Peng             Expires 16 August 2026                 [Page 6]

Internet-Draft                  PCECC-SR                   February 2026


   Agent context interaction optimizations are designed across three
   layers: the data layer, the operation layer, and the transport layer.
   At the data layer, we introduce structured context formats, including
   the TaskContext and AgentContext, to precisely capture and represent
   task and agent states.  The detailed design of DeviceContext and
   EnvironmentContext will be done later.  SynchronousContextInteraction
   and AsynchronousContextInteraction are desined for both scenarios
   mentioned in Section 3, respecitively.  The corresponding transport
   protocols are designed to support different sceanrios.

   A context isolation strategy is introduced to ensure that, during
   collaborative task execution, each agent receives only the context
   strictly relevant to its assigned task.  Relevant context is
   precisely distributed to the corresponding agent in a well-structured
   manner, which reduces interference caused by unnecessary or unrelated
   contextual information.

   A fine-grained task management mechanism is defined for both the
   Master Agent and invoked agents.  Clear task progress monitoring and
   handling procedures are specified, which mitigate attention drift
   within the model and improve overall task completion success rates.

   An efficient two-layer task evaluation mechanism is further
   established.  The Master Agent evaluates the outputs of the invoked-
   agent based on specific fields in the structured context, avoiding
   the need to process or transmit full-context outputs and thereby
   reducing excessive token consumption.

   Support for context offloading is also provided.  Both the Master
   agent and invoked agents are allowed to store or offload full context
   data to external storage systems, while only structured task
   descriptions and references to the full context are exchanged.  This
   approach significantly reduces the overall token consumption of the
   multi-agent system.

4.2.  Context Isolation Strategy

5.  JSON Specifications

5.1.  TaskContext Schema

   The TaskContext schema defines a structured state object that is
   created and maintained exclusively by the Master Agent throughout the
   lifecycle of a complex task.  Its purpose is to provide a persistent
   and machine-interpretable representation of task progress, enabling
   the Master Agent to manage attention across multiple subtasks and
   prevent unintended context drift during multi-step execution.




Chang & Peng             Expires 16 August 2026                 [Page 7]

Internet-Draft                  PCECC-SR                   February 2026


    "TaskContext": {
       "TaskID": "",
       "UserQuery": "",
       "TaskName": "",
       "TaskDescription": "",
       "GoalStatus": [
           {"Goal": "", "Status": ""},
           {"Goal": "", "Status": ""},
           {"Goal": "", "Status": ""}
       ],
       "OverallStatus": "",
       "StartTime": "",
       "EndTime": "",
       "Optional": ["StartTime", "EndTime"]
       },



                    Figure 3: JSON Format - TaskContext

   The TaskContext schema includes fundamental identification and intent
   fields such as TaskID, UserQuery, TaskName, and TaskDescription,
   which collectively capture the origin and semantic scope of the task.
   The GoalStatus array records the progress of individual goals using
   explicit {Goal, Status} tuples, allowing the Master Agent to track
   partial completion and reason over intermediate milestones.  An
   aggregated OverallStatus field reflects the global execution state
   derived from these goals.

   Temporal attributes StartTime and EndTime provide optional lifecycle
   metadata for auditing and scheduling purposes.  These fields are
   listed in the Optional array to indicate that their inclusion is not
   mandatory for functional correctness and may be omitted to reduce
   token overhead when time information is not required.

   By maintaining this structured context, the Master Agent can
   explicitly steer the model’s focus toward active objectives, mitigate
   attention fragmentation across turns, and ensure consistent task
   execution semantics in long-running multi-agent workflows.

5.2.  AgentContext Schema

   The AgentContext schema represents the execution state that is
   specific to an individual agent within a multi-agent workflow.  The
   messages of different agents are strictly isolated between subtasks;
   during each subtask invocation, only the AgentContext instance
   corresponding to the target agent is delivered.  Likewise, upon
   completion, the corresponding agent returns exclusively its own



Chang & Peng             Expires 16 August 2026                 [Page 8]

Internet-Draft                  PCECC-SR                   February 2026


   updated AgentContext to the Master Agent, without access to contexts
   belonging to other agents.  This design enforces information
   isolation and prevents unintended cross-agent context contamination.

   "AgentContext": {
           "AgentID": "",
           "AgentName": "",
           "SubTaskID": "",
           "SubTaskName": "",
           "Dependencies": [],
           "Context/ContextURI": "",
           "todoItems": [
               {"itemId": "", "description": ""},
               {"itemId": "", "description": ""},
               {"itemId": "", "description": ""}
           ],
           "ItemstateUpdates": [
               {"itemId": "", "state": 0},
               {"itemId": "", "state": 1},
               {"itemId": "", "state": 0}
           ],
           "KeyInformation": [
               {"itemId": "", "outputabstract": ""},
               {"itemId": "", "outputabstract": ""},
               {"itemId": "", "outputabstract": ""}
           ],
           "LastUpdated": "",
           "Optional": ["LastUpdated"]
       },


                    Figure 4: JSON Format - AgentContext

   The AgentContext schema contains identification fields including
   AgentID, AgentName, SubTaskID, and SubTaskName, which bind the
   context to a concrete subtask instance.  The Dependencies array
   expresses prerequisite relations among subtasks, enabling the Master
   Agent to reason about execution ordering and blocking conditions.

   The field Context/ContextURI specifies the address of external or
   long-term context required for each agent to perform its task, such
   as retrieved documents, knowledge bases, or cached intermediate
   results.  This indirection avoids embedding large artifacts directly
   in the messages and supports scalable context management.

   Task execution is modelled through three coordinated structures.  The
   todoItems array enumerates actionable steps assigned to each agent.
   The ItemstateUpdates array records the completion state of each item



Chang & Peng             Expires 16 August 2026                 [Page 9]

Internet-Draft                  PCECC-SR                   February 2026


   using a binary code where 0 denotes not completed and 1 denotes
   completed.  The KeyInformation array provides concise output
   abstracts generated by the agent for each item, capturing the
   semantic evidence necessary for result validation.

   After receiving the updated AgentContext, the Master Agent evaluates
   subtask completion in a two-phase manner.  It first inspects
   ItemstateUpdates for a preliminary decision; items marked as 0 are
   considered unfinished and bypass further assessment.  For items
   marked as 1, the Master Agent performs a second-stage verification
   based on the corresponding KeyInformation, ensuring that the produced
   outputs satisfy the intent of the subtask.

   The optional field LastUpdated records the timestamp of the most
   recent modification and is listed in the Optional array to indicate
   that its inclusion is not required for functional correctness.

5.3.  Interaction Process of Agent Context Interaction Optimizations




+------+   User Query+   +------+              +------+         +------+
|      |  Sysytem Prompt |      |              |      |         |      |
|      <-----------------+      |              |      |         |      |
|      |   TaskContext   |      |              |      |         |      |
|      +----------------->      |              |      |         |      |
|      |                 |      |              |      |         |      |
|      |  TaskContext+   |      |              |      |         |      |
|      |  System Prompt  |      |              |      |         |      |
|      <-----------------+      |              |      |         |      |
|Master|   AgentContext  | ACI  |     Send     | ACI  |         |Server|
|Agent +----------------->Client| AgentContext |Server|         |Agent |
|      |                 |      +-------------->      |todoItems|      |
|      |                 |      |              |      +--------->      |
|      |                 |      |    return    |      | Results |      |
|      |ItemStateUpdates+|      | AgentContext |      <---------+      |
|      |KeyInformation   |      <--------------+      |         |      |
|      <-----------------+      |              |      |         |      |
|      |                 |      |              |      |         |      |
|      |     Evaluation  |      |              |      |         |      |
|      |      Results    |      |              |      |         |      |
|      +----------------->      |              |      |         |      |
|      |                 |      +---+          |      |         |      |
|      |                 |      |   |          |      |         |      |
|      |                 |      <---+          |      |         |      |
+------+                 +------+ Updated      +------+         +------+
                                  TaskContext



Chang & Peng             Expires 16 August 2026                [Page 10]

Internet-Draft                  PCECC-SR                   February 2026


   Figure 5: Interaction Flowchart of the Agent Context Interaction
                            Optimizations

   Figure 5 illustrates the interaction flow of the proposed Agent
   Context Interaction (ACI) optimizations in a multi-agent system.  The
   workflow begins when the Master Agent receives a user query together
   with the system prompt, forming an initial TaskContext.  The
   TaskContext is exchanged with the ACI Client, which acts as the
   interface for context transmission.

   It is worth mentioning that the ACI Client and ACI Server are
   conceptual entities utilized to illustrate the logical connection
   between the Master Agent and the invoked agents.  In practice, these
   components can be realized by an Agent2Agent (A2A) client and an A2A
   server, without introducing additional architectural constraints.

   Based on the task decomposition, the Master Agent generates an
   isolated AgentContext corresponding to a specific sub-task and sends
   it through the ACI Client and ACI Server to the target Server Agent.
   Only task-relevant information, including todoItems and the
   associated context reference, is delivered to the Server Agent,
   ensuring precise and minimal context distribution.

   After executing the assigned sub-task, the Server Agent returns an
   updated AgentContext containing ItemStateUpdates and KeyInformation.
   These updates reflect task completion status and summarized outputs
   rather than full execution traces.  The Master Agent then evaluates
   the returned information to assess task progress and correctness.

   Upon evaluation, the Master Agent updates the global TaskContext
   accordingly, enabling subsequent task scheduling or further agent
   interactions.  This flow demonstrates how structured context
   isolation, incremental state updates, and layered evaluation
   collectively reduce token consumption, control attention drift, and
   improve overall execution efficiency in multi-agent collaboration.

6.  Security Considerations

   Agent Context Interaction Optimazation defines structured context
   exchange mechanisms among cooperating agents.  While we do not
   introduce a new transport protocol, improper handling of context data
   may lead to security and privacy risks.









Chang & Peng             Expires 16 August 2026                [Page 11]

Internet-Draft                  PCECC-SR                   February 2026


   AgentContext messages may contain sensitive information, including
   user queries, intermediate reasoning artifacts, task metadata, and
   execution results.  Implementations MUST ensure confidentiality and
   integrity of AgentContext messages by relying on secure underlying
   transport mechanisms, such as TLS-protected channels, and appropriate
   authentication and access control between agents.

   The protocol promotes context isolation by design, where each agent
   receives only the context strictly required for its assigned task.
   Failure to enforce this isolation may result in unintended
   information disclosure or cross-task data leakage.

   This document does not define agent identity formats or trust
   establishment procedures.  Deployments are expected to rely on out-
   of-band mechanisms for agent authentication, authorization, and trust
   management.

7.  IANA Considerations

   This document does not require any immediate actions by IANA.  Future
   extensions of the protocol may define registries or code points that
   require IANA assignment.

8.  Acknowledgments

   We would like to thank Yiyang Shao, Jinyang Li and Tao Liu for useful
   discussion and ideas.

9.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Appendix A.  Contributor Addresses











Chang & Peng             Expires 16 August 2026                [Page 12]

Internet-Draft                  PCECC-SR                   February 2026


   Yiyang Shao
   Huawei
   China

   EMail: shaoyiyang@huawei.com

   Tao Liu
   Huawei
   China

   Email: liutao417@huawei.com

   Jinyang Li
   Huawei
   China

   EMail: lijinyang9@huawei.com



                                  Figure 6

Authors' Addresses

   Zeze Chang
   Huawei Technologies
   No. 3 Shangdi Information Rd.
   Beijing
   100085
   China
   Email: changzeze@huawei.com


   Shuping Peng
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing
   100095
   China
   Email: pengshuping@huawei.com











Chang & Peng             Expires 16 August 2026                [Page 13]


name: draft-agent-gw
rev: 00
title: Agent Communication Gateway for Semantic Routing and Working Memory
time: 2026-02-16T14:35:36Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-20T14:35:36Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:03.420539+00:00
abstract:
This document presents an architectural framework for an Intelligent
   Agent Communication Gateway (Agent-GW), designed to support large-
   scale, heterogeneous, and dynamic multi-agent collaboration.  As
   agents evolve from isolated software entities to a collaborative
   digital workforce, the underlying infrastructure must transition from
   rigid, host-based connectivity to flexible, intent-based interaction.

   This document outlines the requirements for such a transition and
   proposes the Agent-GW as a unified infrastructure hub.  The gateway
   provides native primitives for Semantic Routing—dispatching tasks
   based on intent and capability—and Working Memory, which manages
   structured context for multi-step workflows.  Furthermore, it defines
   mechanisms for automated protocol adaptation, oracle-free agent
   evaluation, and collaborative inference acceleration (KDN).  The
   architecture aims to enable agents and legacy systems to interoperate
   through standardized protocols while ensuring observability,
   security, and operational scalability.

full_text:
Agent-GW                                                    Xiaohui. Xie
Internet-Draft                                       Tsinghua University
Intended status: Standards Track                              Zian. Wang
Expires: 20 August 2026Beijing University of Posts and Telecommunications
                                                            Tianshuo. Hu
                                                     Tsinghua University
                                                        16 February 2026


  Agent Communication Gateway for Semantic Routing and Working Memory
                           draft-agent-gw-00

Abstract

   This document presents an architectural framework for an Intelligent
   Agent Communication Gateway (Agent-GW), designed to support large-
   scale, heterogeneous, and dynamic multi-agent collaboration.  As
   agents evolve from isolated software entities to a collaborative
   digital workforce, the underlying infrastructure must transition from
   rigid, host-based connectivity to flexible, intent-based interaction.

   This document outlines the requirements for such a transition and
   proposes the Agent-GW as a unified infrastructure hub.  The gateway
   provides native primitives for Semantic Routing—dispatching tasks
   based on intent and capability—and Working Memory, which manages
   structured context for multi-step workflows.  Furthermore, it defines
   mechanisms for automated protocol adaptation, oracle-free agent
   evaluation, and collaborative inference acceleration (KDN).  The
   architecture aims to enable agents and legacy systems to interoperate
   through standardized protocols while ensuring observability,
   security, and operational scalability.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/.

   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."

   This Internet-Draft will expire on 20 August 2026.



Xie, et al.              Expires 20 August 2026                 [Page 1]

Internet-Draft  Agent Communication Gateway for Semantic   February 2026


Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Network and Infrastructure Requirements . . . . . . . . . . .   4
   5.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Architectural Model . . . . . . . . . . . . . . . . . . .   4
   6.  Infrastructure Functions Enabling Active Network
           Participation . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Agent Identification and Capability Directory . . . . . .   6
     6.2.  Automated Protocol Adaptation and Interface
           Normalization . . . . . . . . . . . . . . . . . . . . . .   6
     6.3.  Infrastructure-Level Agent Evaluation and Compliance  . .   6
     6.4.  Dynamic Orchestration and Semantic Routing Mechanism  . .   7
     6.5.  Evolutionary Knowledge Management . . . . . . . . . . . .   7
     6.6.  Collaborative Inference Acceleration (KDN)  . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The rapid advancement of Large Language Models (LLMs) has catalyzed
   the emergence of the "Internet of Agents," a paradigm where
   autonomous software entities and tool-like services interconnect to
   form collaborative workflows.  Unlike traditional microservices,
   these agents possess varying degrees of autonomy, reasoning
   capabilities, and diverse interface standards.  Early agent
   deployments were typically siloed within proprietary frameworks,
   limiting their ability to collaborate across administrative domains



Xie, et al.              Expires 20 August 2026                 [Page 2]

Internet-Draft  Agent Communication Gateway for Semantic   February 2026


   or heterogeneous platforms.

   As these systems scale, the fundamental bottleneck shifts from basic
   network connectivity to context management and efficient
   orchestration.  Delivering the right context to the right agent at
   the right time—while managing the high computational cost of
   inference—becomes a critical infrastructure challenge.  Existing
   network/application gateways, designed for static endpoints and
   stateless packet forwarding, lack the semantic awareness required to
   interpret agent intents or manage the lifecycle of a collaborative
   task.

   This document introduces the Agent Communication Gateway (Agent-GW),
   an architectural entity situated between agents and external tools or
   services.  The Agent-GW elevates the network's role from a passive
   transport layer to an active semantic intermediary.  It introduces
   two core primitives: Semantic Routing, which decouples task execution
   from physical endpoints by routing based on capabilities and runtime
   state; and Working Memory, which provides a shared, incrementally
   updated context layer to support multi-step reasoning.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Terminology

   The following terms are defined in this draft:

   Agent-GW (Agent-GW)  Agent Communication Gateway; the infrastructure
      component coordinating multi-agent communication, responsible for
      protocol translation, semantic routing, and context management.

   Semantic Routing  The process of routing a request based on the
      semantic intent of the task and the capabilities of available
      agents.

   Working Memory  A structured, temporary storage mechanism within the
      gateway that maintains the context and state of a multi-turn agent
      interaction.

   KDN (Knowledge Delivery Network)  A mechanism that treats inference
      states (e.g., LLM KV caches) as reusable and distributable
      artifacts.

   MCP  Model Context Protocol; a reference standard for connecting AI



Xie, et al.              Expires 20 August 2026                 [Page 3]

Internet-Draft  Agent Communication Gateway for Semantic   February 2026


      assistants to systems/data.

4.  Network and Infrastructure Requirements

   The proliferation of intelligent agents fundamentally reshapes
   interaction patterns in future networks.  Agent interactions are
   typically short-lived, context-heavy, and driven by high-level goals
   rather than explicit commands.  To support this, the infrastructure
   must satisfy the following requirements:

   *Intent-Based Addressing:* The network must support addressing
   schemes based on what constitutes the service (Capability) rather
   than where it is located (Topology).

   *Stateful Context Management:* Unlike stateless HTTP requests,
   agentic workflows often involve multi-turn reasoning where context
   accumulates.

   *Heterogeneous Interoperability:* The ecosystem comprises diverse
   entities.  The infrastructure must provide automated adaptation
   layers.

   *Dynamic Capability Discovery:* The network requires a dynamic
   discovery mechanism that can match task needs with agent capabilities
   in real-time.

   *Inference Efficiency:* Mechanisms to cache and share intermediate
   inference states (such as KV caches) are required.

5.  Architecture Overview

   This section describes the reference architecture of the Agent
   Communication Gateway (Agent-GW).  It functions as a Semantic
   Intermediary operating at the application and cognitive layers.

5.1.  Architectural Model

   Figure 1 illustrates the logical components and their interactions
   within the Agent-GW.












Xie, et al.              Expires 20 August 2026                 [Page 4]

Internet-Draft  Agent Communication Gateway for Semantic   February 2026


[ Northbound: User / Client Agents ]
                                             |
  +------------------------------------------+------------------------------------------+
  |                      1. Access & Adaptation Plane (Ingress)                         |
  | +-----------------------+   +-------------------------+   +-----------------------+ |
  | |   Protocol Sniffer    |   |  Auto-Adapter Engine    |   |   Trust Enforcer      | |
  | | (Transport Detection) |-->| (Schema -> MCP Transform)|-->| (Auth / Sandboxing)   | |
  | +-----------------------+   +-------------------------+   +-----------------------+ |
  +------------------------------------------+------------------------------------------+
                                             | Normalized Semantic Request
  +------------------------------------------v------------------------------------------+
  |                     2. Cognitive Orchestration Plane (Control)                      |
  | +---------------------------------------------------------------------------------+ |
  | |                            Semantic Router & Planner                            | |
  | | +------------------+     +------------------------+     +---------------------+ | |
  | | |   Intent Parser  |---->|   Task DAG Decomposer  |---->|  Dynamic Dispatcher | | |
  | | +------------------+     +------------------------+     +---------------------+ | |
  | +----------------------------------------+----------------------------------------+ |
  |                                          |                                          |
  |          +-------------------------------+-------------------------------+          |
  |          v (Read/Write)                  v (Cache Hit)                   v (Sync)   |
  +----------+-------------------------------+-------------------------------+----------+
  |                      3. Knowledge & State Plane (Data & Compute)                    |
  | +-----------------------+   +---------------------------+   +---------------------+ |
  | |    Working Memory     |   |    Evolutionary Memory    |   |    KDN Accelerator    | |
  | |   (Session Context)   |   |   (Experience/Feedback)   |   | (KV Cache Sharing)  | |
  | +-----------------------+   +---------------------------+   +---------------------+ |
  +------------------------------------------+------------------------------------------+
                                             | Executable Actions / Payloads
  +------------------------------------------v------------------------------------------+
  |                   4. Ecosystem Interface Plane (Egress/Southbound)                  |
  | +---------------------------------------------------------------------------------+ |
  | |                            Unified Driver Layer                                 | |
  | +-----------+--------------------+---------------------+--------------------+-----+ |
  |             |                    |                     |                    |       |
  |             v                    v                     v                    v       |
  |   +------------------+  +------------------+  +------------------+  +-------------+ |
  |   |  Legacy Systems  |  |  Native Agents   |  |  Physical World  |  |  Peer Mesh  | |
  |   | (REST/RPC Wrappers)| | (MCP Servers)    |  | (ROS/IoT Bridge) |  | (Agent-GW Sync) | |
  |   +------------------+  +------------------+  +------------------+  +-------------+ |
  +-------------------------------------------------------------------------------------+

              Figure 1: Agent-GW Reference Architecture

6.  Infrastructure Functions Enabling Active Network Participation






Xie, et al.              Expires 20 August 2026                 [Page 5]

Internet-Draft  Agent Communication Gateway for Semantic   February 2026


6.1.  Agent Identification and Capability Directory

   This function establishes the "Root of Trust" for the agent network,
   shifting security from network-layer spoofing prevention to
   application-layer Capability Spoofing mitigation.  The Agent-GW
   maintains a dynamic, verified directory where agent entries are not
   static records but active, verified states.

   *Cryptographic Identity and Verification:* Participating agents MUST
   possess a Cryptographic Agent ID (AID) derived from an X.509v3
   digital certificate.  Upon registration, the agent submits an
   AgentCard binding its identity to a specific capability hash.  To
   prevent the registration of malicious entities, the Agent-GW
   implements a Capability Claim and Verification (CCV) mechanism.
   Utilizing Metamorphic Testing principles, the gateway issues
   "Challenge-Response" queries (e.g., semantic variants of a task) to
   verify the agent's functional consistency without accessing its
   internal model weights (Zero-Knowledge verification).

   *Semantic Heartbeat and Dynamic Pruning:* To maintain directory
   freshness, the Agent-GW enforces a Semantic Heartbeat.  Unlike
   traditional Layer 3 keep-alives that only confirm network
   reachability, this mechanism periodically verifies Layer 7 functional
   integrity.  Agents that fail these semantic challenges (indicating
   they are "Zombie Agents" or functionally impaired) are dynamically
   pruned from the directory.

6.2.  Automated Protocol Adaptation and Interface Normalization

   Residing within the Access & Adaptation Plane, this function serves
   as the "Semantic Edge" that normalizes heterogeneous external
   protocols (e.g., HTTP, MQTT, gRPC) into the unified Model Context
   Protocol (MCP) used by the internal Orchestration Plane.

   To handle unstructured or poorly documented interfaces, the Agent-GW
   implements a Generative Adaptation Mechanism with Active Probing.
   Instead of relying on static drivers, an LLM-based engine ingests raw
   interface descriptions to generate preliminary bindings.  These
   bindings are iteratively refined through a self correcting feedback
   loop.

6.3.  Infrastructure-Level Agent Evaluation and Compliance

   Agents are often deployed as "black-box" entities where internal
   logic is opaque.  The Agent-GW introduces an infrastructure-level
   evaluation mechanism to ensure reliability and compliance without
   requiring access to model weights.




Xie, et al.              Expires 20 August 2026                 [Page 6]

Internet-Draft  Agent Communication Gateway for Semantic   February 2026


   This function employs Metamorphic Testing protocols: the gateway
   generates semantic variations of task instructions (e.g., rewriting
   the prompt or injecting noise) and evaluates the consistency of the
   agent's responses.  This "Oracle-free" approach allows the gateway to
   assign a dynamic reliability score to each agent.

6.4.  Dynamic Orchestration and Semantic Routing Mechanism

   Static routing tables are insufficient for dynamic multi-agent
   collaboration.  The Agent-GW implements Semantic Routing, a mechanism
   that dispatches tasks based on high-level intent, real-time
   capability matching, and operational constraints.

   The Cognitive Orchestration Plane decomposes complex user intents
   into a Directed Acyclic Graph (DAG) of sub-tasks.  The Dynamic
   Dispatcher then assigns these sub-tasks to the most suitable agents
   based on Capability Match, Trust Score, and Operational Metrics.

6.5.  Evolutionary Knowledge Management

   To improve collaboration efficiency over time, the Agent-GW
   incorporates Evolutionary Memory.  This function transforms the
   gateway from a stateless forwarder into a learning infrastructure.

   The gateway captures execution traces, success/failure feedback, and
   user corrections from passing traffic.  In local or edge deployments,
   this allows the Agent-GW to build a localized knowledge base to
   refine routing policies and provide "Feedback Guidance" to terminal
   agents.

6.6.  Collaborative Inference Acceleration (KDN)

   Multi-agent workflows frequently involve redundant reasoning over
   shared contexts.  To address the computational inefficiency, the
   architecture proposes a Knowledge Delivery Network (KDN).

   The KDN function enables the sharing of intermediate inference
   states, specifically the Key-Value (KV) cache of the LLM, across co-
   located agents or peer gateways.  This significantly reduces the
   Time-to-First-Token (TTFT) and overall computational load.

7.  Security Considerations

   The introduction of an active Agent-GW introduces specific security
   challenges: Agent Identity Spoofing, Capability Poisoning, Context
   Leakage, and Inference Artifact Security.





Xie, et al.              Expires 20 August 2026                 [Page 7]

Internet-Draft  Agent Communication Gateway for Semantic   February 2026


8.  IANA Considerations

   This document has no IANA actions at this time.

9.  Acknowledgement

   TBD

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Authors' Addresses

   Xiaohui Xie
   Tsinghua University
   Email: xiexiaohui@tsinghua.edu.cn


   Zian Wang
   Beijing University of Posts and Telecommunications
   Email: zianwang@bupt.edu.cn


   Tianshuo Hu
   Tsinghua University
   Email: huts22@mails.tsinghua.edu.cn



















Xie, et al.              Expires 20 August 2026                 [Page 8]


name: draft-birkholz-verifiable-agent-conversations
rev: 00
title: Verifiable Agent Conversation Records
time: 2026-02-25T18:48:18Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-29T18:48:18Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "Data formats/interop", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:03.420541+00:00
abstract:
Autonomous agents based on large language models increasingly perform
   consequential tasks on behalf of humans and other agents.
   Demonstrating that recorded agent behavior truthfully represents
   actual behavior is essential for accountability, compliance, and
   human oversight.  This document defines a data format for verifiable
   agent conversation records using CDDL, with representations in both
   JSON and CBOR.  The format captures session metadata, message
   exchanges, tool invocations, reasoning traces, and system events in a
   structured, extensible CDDL definition for verifiable agent
   conversation records.  COSE is used as the signing method to allow
   for native interoperability in SCITT Transparency Services and the
   CDDL definition allows for seemless integration in Evidence as
   specified in RFC 9334.  The specification supports cross-vendor
   interoperability by defining a common representation that
   accommodates translation from multiple existing agent implementations
   with distinct data structure layouts that are typically represented
   in JSON.

full_text:
Network Working Group                                        H. Birkholz
Internet-Draft                                                          
Intended status: Standards Track                                T. Heldt
Expires: 29 August 2026                                                 
                                                               O. Steele
                                                        25 February 2026


                 Verifiable Agent Conversation Records
            draft-birkholz-verifiable-agent-conversations-00

Abstract

   Autonomous agents based on large language models increasingly perform
   consequential tasks on behalf of humans and other agents.
   Demonstrating that recorded agent behavior truthfully represents
   actual behavior is essential for accountability, compliance, and
   human oversight.  This document defines a data format for verifiable
   agent conversation records using CDDL, with representations in both
   JSON and CBOR.  The format captures session metadata, message
   exchanges, tool invocations, reasoning traces, and system events in a
   structured, extensible CDDL definition for verifiable agent
   conversation records.  COSE is used as the signing method to allow
   for native interoperability in SCITT Transparency Services and the
   CDDL definition allows for seemless integration in Evidence as
   specified in RFC 9334.  The specification supports cross-vendor
   interoperability by defining a common representation that
   accommodates translation from multiple existing agent implementations
   with distinct data structure layouts that are typically represented
   in JSON.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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/.

   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."

   This Internet-Draft will expire on 29 August 2026.




Birkholz, et al.         Expires 29 August 2026                 [Page 1]

Internet-Draft               Verifiable ACRs               February 2026


Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Conventions and Definitions . . . . . . . . . . . . . . .   6
   2.  Compliance Requirements for AI Agent Conversation Records . .   6
     2.1.  Applicable Requirement Frameworks . . . . . . . . . . . .   6
     2.2.  Common Requirements Intersection  . . . . . . . . . . . .   8
       2.2.1.  REQ-1: Automatic Event Logging  . . . . . . . . . . .   8
       2.2.2.  REQ-2: Timestamp Requirements . . . . . . . . . . . .   8
       2.2.3.  REQ-3: Actor Identification . . . . . . . . . . . . .   9
       2.2.4.  REQ-4: Action/Event Type Recording  . . . . . . . . .  10
       2.2.5.  REQ-5: Input/Output Recording (AI-Specific) . . . . .  10
       2.2.6.  REQ-6: Retention Period Requirements  . . . . . . . .  11
       2.2.7.  REQ-7: Tamper-Evidence and Integrity Protection . . .  12
       2.2.8.  REQ-8: Incident Response Support  . . . . . . . . . .  12
       2.2.9.  REQ-9: Anomaly and Risk Detection Support . . . . . .  13
       2.2.10. REQ-10: Human Oversight Enablement  . . . . . . . . .  14
       2.2.11. REQ-11: Traceability and Reproducibility  . . . . . .  14
     2.3.  Framework-Specific Requirements . . . . . . . . . . . . .  15
       2.3.1.  EU AI Act (High-Risk Systems) . . . . . . . . . . . .  15
       2.3.2.  ETSI TS 104 223 Session Logging Requirements  . . . .  16
       2.3.3.  PCI DSS AI-Specific Guidance  . . . . . . . . . . . .  16
       2.3.4.  Financial Sector Requirements (FFIEC, BSI)  . . . . .  17
     2.4.  Compliance Mapping Table  . . . . . . . . . . . . . . . .  17
     2.5.  Security Requirements addressing Regulatory Compliance  .  18
       2.5.1.  Log Integrity . . . . . . . . . . . . . . . . . . . .  18
       2.5.2.  Access Control  . . . . . . . . . . . . . . . . . . .  19
       2.5.3.  Data Protection . . . . . . . . . . . . . . . . . . .  19
     2.6.  Related Standards and Emerging Work . . . . . . . . . . .  19
   3.  CDDL Definitions for Agent Conversations Records  . . . . . .  19
     3.1.  Common Types  . . . . . . . . . . . . . . . . . . . . . .  19
     3.2.  The verifiable-agent-record Map . . . . . . . . . . . . .  20
     3.3.  The session-trace Map . . . . . . . . . . . . . . . . . .  21
     3.4.  The agent-meta Map  . . . . . . . . . . . . . . . . . . .  22



Birkholz, et al.         Expires 29 August 2026                 [Page 2]

Internet-Draft               Verifiable ACRs               February 2026


     3.5.  The recording-agent Map . . . . . . . . . . . . . . . . .  23
     3.6.  The environment Map . . . . . . . . . . . . . . . . . . .  23
     3.7.  The vcs-context Map . . . . . . . . . . . . . . . . . . .  24
     3.8.  Entry Types . . . . . . . . . . . . . . . . . . . . . . .  24
       3.8.1.  The message-entry Map . . . . . . . . . . . . . . . .  25
       3.8.2.  The tool-call-entry Map . . . . . . . . . . . . . . .  26
       3.8.3.  The tool-result-entry Map . . . . . . . . . . . . . .  26
       3.8.4.  The reasoning-entry Map . . . . . . . . . . . . . . .  27
       3.8.5.  The event-entry Map . . . . . . . . . . . . . . . . .  28
     3.9.  The token-usage Map . . . . . . . . . . . . . . . . . . .  29
     3.10. File Attribution Types  . . . . . . . . . . . . . . . . .  30
       3.10.1.  The file-attribution-record Map  . . . . . . . . . .  30
       3.10.2.  The file Map . . . . . . . . . . . . . . . . . . . .  31
       3.10.3.  The conversation Map . . . . . . . . . . . . . . . .  31
       3.10.4.  The range Map  . . . . . . . . . . . . . . . . . . .  32
       3.10.5.  The contributor Map  . . . . . . . . . . . . . . . .  32
       3.10.6.  The resource Map . . . . . . . . . . . . . . . . . .  33
     3.11. Signing Envelope Types  . . . . . . . . . . . . . . . . .  33
       3.11.1.  The signed-agent-record Structure  . . . . . . . . .  33
       3.11.2.  The trace-metadata Map . . . . . . . . . . . . . . .  34
   4.  Collated CDDL Definition for generic Agent Conversations  . .  35
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  40
     5.1.  Information Disclosure  . . . . . . . . . . . . . . . . .  40
     5.2.  Sensitive Content in Records  . . . . . . . . . . . . . .  40
     5.3.  Retention Considerations  . . . . . . . . . . . . . . . .  41
     5.4.  Correlation and Inference . . . . . . . . . . . . . . . .  41
     5.5.  Authority Access  . . . . . . . . . . . . . . . . . . . .  41
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  42
     6.1.  Record Integrity  . . . . . . . . . . . . . . . . . . . .  42
     6.2.  Signing Key Protection  . . . . . . . . . . . . . . . . .  42
     6.3.  Timestamp Integrity . . . . . . . . . . . . . . . . . . .  42
     6.4.  Adversarial Content . . . . . . . . . . . . . . . . . . .  43
     6.5.  Non-Repudiation . . . . . . . . . . . . . . . . . . . . .  43
     6.6.  Detection and Trust Boundaries  . . . . . . . . . . . . .  43
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  44
     7.1.  Media Type  . . . . . . . . . . . . . . . . . . . . . . .  44
     7.2.  CoAP Content Format . . . . . . . . . . . . . . . . . . .  45
     7.3.  CBOR Tag  . . . . . . . . . . . . . . . . . . . . . . . .  45
     7.4.  COSE Header Parameter . . . . . . . . . . . . . . . . . .  45
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  46
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  46
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  49
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  50
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  50







Birkholz, et al.         Expires 29 August 2026                 [Page 3]

Internet-Draft               Verifiable ACRs               February 2026


1.  Introduction

   The question of whether the recorded output of an autonomous agent
   faithfully represents an agent's actual behavior has found new
   urgency as the number of consequential tasks that are delegated to
   agents increases rapidly.  Autonomous Agents--typically workload
   instances of agentic artificial intelligence (AI) based on large
   language models (LLM)--interact with other actors by design.  This
   creates an interconnected web of agent interactions and conversations
   that is currently rarely supervised in a systemic manner.  In
   essence, the two main types of actors interacting with autonomous
   agents are humans and machines (e.g., other autonomous agents), or a
   mix of them.  In agentic AI systems, machine actors interact with
   other machine actors.  The number of interactions between machine
   actors grows significantly more than the number of interactions
   between human actors and machine actors.  While the responsible
   parties for agent actions ultimately are humans--whether a natural
   legal entity or an organization--agents act on behalf of humans and
   on behalf of other agents.  To demonstrate due diligence, responsible
   human parties require records of agent behavior to demonstrate policy
   compliant behavior for agents acting under their authority.  These
   increasingly complex interactions between multiple actors that can
   also be triggered by machines (recursively) increase the need to
   understand decision making and the chain of thoughts (CoT) of
   autonomous agents, retroactively (i.e., accountability and
   auditability after the fact).

   The verifiable records of agent conversations that are specified in
   this document provide an essential basis for operators to detect
   divergences between intended and actual agent behavior after the
   interaction has concluded.

   For example:

   *  An agent authorized to read files might invoke tools to modify
      production systems or exfiltrate sensitive data beyond its
      authorization scope.

   *  An agent's visible CoT output might diverge from the reasoning
      that actually produced its actions.

   *  An agent might deliberately underperform during capability
      evaluations while performing at full capacity during deployment.

   This document defines conversation records representing activities of
   autonomous agents such that long-term preservation of the evidentiary
   value of these records across chains of custody (CoC) is possible.




Birkholz, et al.         Expires 29 August 2026                 [Page 4]

Internet-Draft               Verifiable ACRs               February 2026


   This document defines verifiable records of agent conversations as a
   building block towards seven dedicated goals:

   1.  The first goal is to assure that the recording of an agent
       conversation (a distinct segment of the interaction with an
       autonomous agent) being proffered is the same as the agent
       conversation that actually occurred.

   2.  The second goal is to provide a general structure of agent
       conversations that can represent most common types of agent
       conversation frames, is extensible, and allows for future
       evolution of agent conversation complexity and corresponding
       actor interaction.

   3.  The third goal is to use existing IETF building blocks to present
       believable evidence about how an agent conversation is recorded
       utilizing Evidence generation as laid out in the Remote
       ATtestation ProcedureS architecture [RFC9334].

   4.  The fourth goal is to use existing IETF building blocks to render
       conversation records auditable after the fact and enable non-
       repudiation as laid out in the Supply Chain Integrity,
       Transparency, and Trust architecture
       [I-D.ietf-scitt-architecture].

   5.  The fifth goal is to enable detection of behavioral anomalies in
       agent interactions, including unauthorized tool invocations,
       inconsistencies between reasoning traces and actions, and
       performance modulation across evaluation and deployment contexts,
       through structured, comparable conversation records.

   6.  The sixth goal is to enable cross-vendor interoperability by
       defining a common representation for agent conversations that can
       be translated from multiple existing agent implementations with
       distinct native formats.

   7.  The seventh goal is to produce records suitable for demonstrating
       compliance with emerging regulatory requirements for AI system
       documentation, traceability, and human oversight.

   Most agent conversations today are represented in "human-readable"
   text formats.  For example, JSON [STD90] is considered to be "human-
   readable" as it can be presented to humans in human-computer-
   interfaces (HCI) via off-the-shelf tools, e.g., pre-installed text
   editors that allow such data to be consumed or modified by humans.
   The Concise Binary Object Representation (CBOR [STD94]) is used as an
   alternative representation next to the established representation
   that is JSON.



Birkholz, et al.         Expires 29 August 2026                 [Page 5]

Internet-Draft               Verifiable ACRs               February 2026


   In this version of the document the signing of JSON payloads is done
   via [STD90].  Using [STD90] enables interoperability with
   Transparency Services specified by the IETF
   [I-D.ietf-scitt-architecture] and enables low-threshold cross-
   application and cross-stakeholder interoperability across the
   Internet.

   Note: further improvements in support of in-memory processing,
   further compacting human-readable text strings, and using CBOR as an
   alternative representation for verifiable records of agent
   conversations will follow.

1.1.  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] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   In this document, CDDL [RFC8610] is used to describe the data formats
   of agent conversations for JSON and CBOR (with no optimization for
   CBOR, currently).

   The reader is assumed to be familiar with the vocabulary and concepts
   defined in [RFC9334] and [I-D.ietf-scitt-architecture].

2.  Compliance Requirements for AI Agent Conversation Records

   This section identifies the intersection of logging, traceability,
   and record-keeping requirements across major compliance frameworks
   applicable to AI systems.  The verifiable agent conversation format
   defined in this document addresses these requirements by providing a
   standardized, cryptographically verifiable record of AI agent
   interactions.

2.1.  Applicable Requirement Frameworks

   The following frameworks were analyzed for their requirements on AI
   agent traceability and session logging:











Birkholz, et al.         Expires 29 August 2026                 [Page 6]

Internet-Draft               Verifiable ACRs               February 2026


    +==========================+=============+=============+==========+
    | Framework                |Jurisdiction |Sector       |Status    |
    +==========================+=============+=============+==========+
    | EU AI Act                |EU           |Cross-sector |In force  |
    | [EU_AI_ACT_2024]         |             |             |Aug 2024  |
    +--------------------------+-------------+-------------+----------+
    | Cyber Resilience Act     |EU           |Products with|In force  |
    | [EU_CRA_2024]            |             |digital      |Dec 2024  |
    |                          |             |elements     |          |
    +--------------------------+-------------+-------------+----------+
    | NIS2 Directive           |EU           |Essential/   |Transposed|
    | [EU_NIS2_2022]           |             |important    |Oct 2024  |
    |                          |             |entities     |          |
    +--------------------------+-------------+-------------+----------+
    | ETSI TS 104 223          |EU/          |AI systems   |Published |
    | [ETSI_TS_104223_2025]    |International|             |Apr 2025  |
    +--------------------------+-------------+-------------+----------+
    | SOC 2 Trust Services     |US/          |Service      |Active    |
    | Criteria                 |International|organizations|          |
    | [AICPA_TSC_2017]         |             |             |          |
    +--------------------------+-------------+-------------+----------+
    | FedRAMP                  |US           |Federal cloud|Active    |
    | [NIST_SP_800_53_R5]      |             |services     |          |
    | [OMB_M_21_31]            |             |             |          |
    +--------------------------+-------------+-------------+----------+
    | PCI DSS [PCI_DSS_V4_0_1] |International|Payment card |Mandatory |
    |                          |             |industry     |Mar 2025  |
    +--------------------------+-------------+-------------+----------+
    | ISO/IEC 42001            |International|AI management|Published |
    | [ISO_IEC_42001_2023]     |             |systems      |2023      |
    +--------------------------+-------------+-------------+----------+
    | FFIEC IT Handbook        |US           |Financial    |Updated   |
    | [FFIEC_IT_HANDBOOK_2024] |             |institutions |2024      |
    +--------------------------+-------------+-------------+----------+
    | BSI AI Finance Test      |Germany      |Financial    |Published |
    | Criteria                 |             |sector AI    |2024      |
    | [BSI_AI_FINANCE_2024]    |             |             |          |
    +--------------------------+-------------+-------------+----------+
    | NIST AI 100-2            |US           |Cross-sector |Published |
    | [NIST_AI_100_2_E2025]    |             |             |2025      |
    +--------------------------+-------------+-------------+----------+

                                  Table 1








Birkholz, et al.         Expires 29 August 2026                 [Page 7]

Internet-Draft               Verifiable ACRs               February 2026


2.2.  Common Requirements Intersection

   The analysis of the frameworks listed above results in eleven
   categories of requirements that appear across ALL or MOST frameworks.
   These categories frame and represent a minimum baseline that
   verifiable agent conversation records MUST support.

2.2.1.  REQ-1: Automatic Event Logging

   All frameworks require automatic, system-generated logging of events
   without reliance on manual recording.  Explicit requirements are
   listed as follows:

   +===================+===============================================+
   | Framework         | Requirement                                   |
   +===================+===============================================+
   | EU AI Act Art.    | "High-risk AI systems shall technically allow |
   | 12                | for the automatic recording of events (logs)" |
   +-------------------+-----------------------------------------------+
   | ETSI TS 104223    | "System Operators shall log system and user   |
   | 5.4.2-1           | actions"                                      |
   +-------------------+-----------------------------------------------+
   | SOC 2 CC7.2       | "Complete and chronological record of all     |
   |                   | user actions and system responses"            |
   +-------------------+-----------------------------------------------+
   | FedRAMP AU-12     | "Audit Record Generation" control requirement |
   +-------------------+-----------------------------------------------+
   | PCI DSS 4.0       | "Audit logs implemented to support detection  |
   | Req 10            | of anomalies"                                 |
   +-------------------+-----------------------------------------------+
   | ISO 42001         | "AI system recording of event logs"           |
   | A.6.2.8           |                                               |
   +-------------------+-----------------------------------------------+

                                  Table 2

   Mapping to this specification: The entries array in session-trace
   captures all events automatically.  Each entry represents a discrete,
   system-recorded event with structured metadata.

2.2.2.  REQ-2: Timestamp Requirements

   Most frameworks require precise temporal information for each logged
   event.  Explicit requirements are listed as follows:







Birkholz, et al.         Expires 29 August 2026                 [Page 8]

Internet-Draft               Verifiable ACRs               February 2026


       +======================+====================================+
       | Framework            | Requirement                        |
       +======================+====================================+
       | EU AI Act Art. 12(2) | "Precise timestamps for each usage |
       |                      | session" (biometric systems)       |
       +----------------------+------------------------------------+
       | PCI DSS 4.0 Req 10.6 | "Time-synchronization mechanisms   |
       |                      | support consistent time settings"  |
       +----------------------+------------------------------------+
       | SOC 2                | "When the activity was performed   |
       |                      | via timestamp"                     |
       +----------------------+------------------------------------+
       | NIS2                 | "Precise logging of when an        |
       |                      | incident was first detected"       |
       +----------------------+------------------------------------+

                                  Table 3

   Mapping to this specification: The timestamp field in each entry uses
   abstract-timestamp which accepts both RFC 3339 strings and POSIX
   Seconds since Epoch, ensuring interoperability across
   implementations.

2.2.3.  REQ-3: Actor Identification

   Most frameworks require some attribution of actions to identifiable
   actors (human or system).  Explicit requirements are listed as
   follows:

       +===============+==========================================+
       | Framework     | Requirement                              |
       +===============+==========================================+
       | EU AI Act     | "Identification of the natural persons   |
       | Art. 12(3)(d) | involved in the verification of results" |
       +---------------+------------------------------------------+
       | SOC 2         | "The process or user who initiated the   |
       |               | activity (Who)"                          |
       +---------------+------------------------------------------+
       | PCI DSS 4.0   | Attribution to "Who" performed each      |
       |               | action                                   |
       +---------------+------------------------------------------+
       | FedRAMP AC-2  | Account management and identification    |
       +---------------+------------------------------------------+

                                 Table 4






Birkholz, et al.         Expires 29 August 2026                 [Page 9]

Internet-Draft               Verifiable ACRs               February 2026


   Mapping to this specification: The contributor type captures actor
   attribution with type (human/ai/mixed/unknown) and optional model-id.
   Session-level agent-meta identifies the AI system.

2.2.4.  REQ-4: Action/Event Type Recording

   All frameworks require recording of what action or event occurred.
   Explicit requirements are listed as follows:

     +===================+==========================================+
     | Framework         | Requirement                              |
     +===================+==========================================+
     | EU AI Act Art. 12 | "Events relevant for identifying         |
     |                   | situations that may result in...risk"    |
     +-------------------+------------------------------------------+
     | ETSI TS 104223    | "Audit log of changes to system prompts  |
     | 5.2.4-3           | or other model configuration"            |
     +-------------------+------------------------------------------+
     | SOC 2             | "The action they performed such as file  |
     |                   | transferred, created, or deleted (What)" |
     +-------------------+------------------------------------------+
     | PCI DSS 4.0       | "What" component of audit trail          |
     +-------------------+------------------------------------------+

                                 Table 5

   Mapping to this specification: The type field in each entry
   discriminates event types: user, assistant, tool-call, tool-result,
   reasoning, system-event.

2.2.5.  REQ-5: Input/Output Recording (AI-Specific)

   All AI-specific frameworks require recording of inputs (prompts) and
   outputs (responses).  Explicit requirements are listed as follows:

















Birkholz, et al.         Expires 29 August 2026                [Page 10]

Internet-Draft               Verifiable ACRs               February 2026


       +================+==========================================+
       | Framework      | Requirement                              |
       +================+==========================================+
       | EU AI Act Art. | "The input data for which the search has |
       | 12(3)(c)       | led to a match"                          |
       +----------------+------------------------------------------+
       | PCI DSS AI     | "Logging should be sufficient to audit   |
       | Guidance       | the prompt inputs and reasoning process" |
       +----------------+------------------------------------------+
       | ETSI TS 104223 | "Operation, and lifecycle management of  |
       | 5.1.2-3        | models, datasets and prompts"            |
       +----------------+------------------------------------------+
       | FFIEC VII.D    | "Lack of explainability...unclear how    |
       |                | inputs are translated into outputs"      |
       +----------------+------------------------------------------+

                                  Table 6

   Mapping to this specification:

   *  message-entry (type: "user"): User/system input (prompt)

   *  message-entry (type: "assistant"): Model response

   *  tool-call-entry.input: Tool invocation parameters

   *  tool-result-entry.output: Tool execution results

   *  reasoning-entry.content: Chain-of-thought (where available)

2.2.6.  REQ-6: Retention Period Requirements

   Most frameworks specify minimum retention periods for audit logs.
   Explicit requirements are listed as follows:

    +===================+============================================+
    | Framework         | Minimum Retention                          |
    +===================+============================================+
    | EU AI Act Art. 19 | 6 months (longer for financial services)   |
    +-------------------+--------------------------------------------+
    | FedRAMP (M-21-31) | 12 months active + 18 months cold storage  |
    +-------------------+--------------------------------------------+
    | PCI DSS 4.0       | 12 months total, 3 months immediate access |
    +-------------------+--------------------------------------------+
    | NIS2              | Per member state law                       |
    +-------------------+--------------------------------------------+

                                 Table 7



Birkholz, et al.         Expires 29 August 2026                [Page 11]

Internet-Draft               Verifiable ACRs               February 2026


   Recommendation: Implementations SHOULD retain verifiable agent
   conversation records for at least 12 months to satisfy the most
   common requirement threshold.

2.2.7.  REQ-7: Tamper-Evidence and Integrity Protection

   All frameworks require some protection against unauthorized
   modification of logs.  Explicit requirements are listed as follows:

       +======================+===================================+
       | Framework            | Requirement                       |
       +======================+===================================+
       | PCI DSS 4.0 Req 10.5 | "Tamper-proof audit trails...logs |
       |                      | cannot be altered retroactively"  |
       +----------------------+-----------------------------------+
       | FedRAMP              | "Effective chain of evidence to   |
       |                      | ensure integrity"                 |
       +----------------------+-----------------------------------+
       | SOC 2                | Log integrity as security control |
       +----------------------+-----------------------------------+
       | CRA                  | "Tamper-proof SBOMs and           |
       |                      | vulnerability disclosures"        |
       +----------------------+-----------------------------------+

                                 Table 8

   Mapping to this specification: The signed-agent-record type
   (COSE_Sign1 envelope) provides cryptographic integrity protection.
   The content-hash field in trace-metadata enables verification of
   payload integrity.

2.2.8.  REQ-8: Incident Response Support

   All frameworks require some logs to support incident investigation
   and response.  Explicit requirements are listed as follows:
















Birkholz, et al.         Expires 29 August 2026                [Page 12]

Internet-Draft               Verifiable ACRs               February 2026


   +================+==================================================+
   | Framework      | Requirement                                      |
   +================+==================================================+
   | NIS2 Art. 23   | 24-hour initial notification,                    |
   |                | 72-hour assessment                               |
   +----------------+--------------------------------------------------+
   | CRA            | 24-hour vulnerability notification               |
   |                | to ENISA                                         |
   +----------------+--------------------------------------------------+
   | ETSI TS 104223 | Logs for "incident investigations,               |
   | 5.4.2-1        | and vulnerability remediation"                   |
   +----------------+--------------------------------------------------+
   | FedRAMP        | Incident reporting and continuous                |
   |                | monitoring                                       |
   +----------------+--------------------------------------------------+

                                  Table 9

   Mapping to this specification: The structured format enables rapid
   extraction of relevant entries by timestamp range, event type, or
   tool invocation for incident reconstruction.

2.2.9.  REQ-9: Anomaly and Risk Detection Support

   All frameworks require some logs to enable detection of anomalous or
   risky behavior.  Explicit requirements are listed as follows:

     +=========================+====================================+
     | Framework               | Requirement                        |
     +=========================+====================================+
     | EU AI Act Art. 12(2)(a) | "Identifying situations that may   |
     |                         | result in...risk"                  |
     +-------------------------+------------------------------------+
     | ETSI TS 104223 5.4.2-2  | "Detect anomalies, security        |
     |                         | breaches, or unexpected behaviour" |
     +-------------------------+------------------------------------+
     | FedRAMP SI-4            | "Anomaly detection"                |
     +-------------------------+------------------------------------+
     | SOC 2                   | "Anomaly detection" for security   |
     |                         | monitoring                         |
     +-------------------------+------------------------------------+

                                 Table 10

   Mapping to this specification: The standardized entry types and
   structured tool-call/tool-result pairs enable automated analysis for
   detecting:




Birkholz, et al.         Expires 29 August 2026                [Page 13]

Internet-Draft               Verifiable ACRs               February 2026


   *  Unusual tool invocation patterns

   *  Failed operations (via status and is-error fields)

   *  Unexpected reasoning patterns

   *  Token usage anomalies

2.2.10.  REQ-10: Human Oversight Enablement

   All AI-specific frameworks require logs to support human review and
   oversight.  Explicit requirements are listed as follows:

   +======================+============================================+
   | Framework            | Requirement                                |
   +======================+============================================+
   | EU AI Act Art.       | "Monitoring the operation of high-risk AI  |
   | 26(5)                | systems"                                   |
   +----------------------+--------------------------------------------+
   | ETSI TS 104223       | "Capabilities to enable human oversight"   |
   | 5.1.4-1              |                                            |
   +----------------------+--------------------------------------------+
   | ISO 42001            | Human responsibility and accountability    |
   +----------------------+--------------------------------------------+
   | FFIEC VII.D          | "Dynamic updating...challenges to          |
   |                      | monitoring and independently reviewing AI" |
   +----------------------+--------------------------------------------+

                                  Table 11

   Mapping to this specification: The reasoning-entry type captures
   chain-of-thought content (where available), enabling human reviewers
   to understand AI decision-making processes.  The hierarchical
   children field preserves conversation structure.

2.2.11.  REQ-11: Traceability and Reproducibility

   All frameworks require some ability to trace system behavior and
   reconstruct events.  Explicit requirements are listed as follows:












Birkholz, et al.         Expires 29 August 2026                [Page 14]

Internet-Draft               Verifiable ACRs               February 2026


    +===========+====================================================+
    | Framework | Requirement                                        |
    +===========+====================================================+
    | EU AI Act | "Level of traceability of the                      |
    | Art. 12   | functioning...appropriate to the intended purpose" |
    +-----------+----------------------------------------------------+
    | ISO 42001 | "Traceability" as key factor including "data       |
    |           | provenance, model traceability"                    |
    +-----------+----------------------------------------------------+
    | CRA       | "Traceability in the software supply chain"        |
    +-----------+----------------------------------------------------+
    | ETSI TS   | "Track, authenticate, manage version control"      |
    | 104223    |                                                    |
    | 5.2.1-2   |                                                    |
    +-----------+----------------------------------------------------+

                                 Table 12

   Mapping to this specification:

   *  session-id: Links entries to sessions

   *  entry-id and parent-id: Enables conversation tree reconstruction

   *  vcs-context: Git commit/branch for code state

   *  agent-meta: Model version and CLI version

   *  file-attribution: Code provenance tracking

2.3.  Framework-Specific Requirements

2.3.1.  EU AI Act (High-Risk Systems)

   For AI systems classified as high-risk under Annex III of the EU AI
   Act [EU_AI_ACT_2024], additional requirements apply:

   1.  Biometric identification systems (Annex III, 1(a)) require
       logging of:

       *  Precise timestamps for start/end of each usage session

       *  Reference database used during input data validation

       *  Input data leading to matches

       *  Natural persons involved in result verification




Birkholz, et al.         Expires 29 August 2026                [Page 15]

Internet-Draft               Verifiable ACRs               February 2026


   2.  Log retention: Minimum 6 months; financial services may require
       longer per sector-specific regulation.

   3.  Authority Access: Art. 19 of [EU_AI_ACT_2024] requires provision
       of logs to competent authorities upon reasoned request.

2.3.2.  ETSI TS 104 223 Session Logging Requirements

   ETSI TS 104 223 [ETSI_TS_104223_2025] provides the most detailed AI-
   specific logging requirements:

    +===========+=================================+==================+
    | Provision | Requirement                     | This Spec        |
    |           |                                 | Mapping          |
    +===========+=================================+==================+
    | 5.1.2-3   | Audit trail for "operation, and | session-trace,   |
    |           | lifecycle management of models, | agent-meta       |
    |           | datasets and prompts"           |                  |
    +-----------+---------------------------------+------------------+
    | 5.2.4-1   | "Document and maintain a clear  | recording-agent, |
    |           | audit trail of their system     | open maps        |
    |           | design"                         |                  |
    +-----------+---------------------------------+------------------+
    | 5.2.4-3   | "Audit log of changes to system | event-entry with |
    |           | prompts or other model          | prompt changes   |
    |           | configuration"                  |                  |
    +-----------+---------------------------------+------------------+
    | 5.4.2-1   | "Log system and user actions to | entries array    |
    |           | support security compliance,    |                  |
    |           | incident investigations"        |                  |
    +-----------+---------------------------------+------------------+
    | 5.4.2-2   | "Analyse their logs to          | Structured       |
    |           | ensure...desired outputs and to | format enables   |
    |           | detect anomalies"               | analysis         |
    +-----------+---------------------------------+------------------+
    | 5.4.2-3   | "Monitor internal states of     | reasoning-entry, |
    |           | their AI systems"               | token-usage      |
    +-----------+---------------------------------+------------------+

                                 Table 13

2.3.3.  PCI DSS AI-Specific Guidance

   The PCI Security Standards Council has published guidance on AI in
   payment environments [PCI_DSS_V4_0_1]: "Where possible, logging
   should be sufficient to audit the prompt inputs and reasoning process
   used by the AI system that led to the output provided."




Birkholz, et al.         Expires 29 August 2026                [Page 16]

Internet-Draft               Verifiable ACRs               February 2026


   This specification directly addresses this requirement through:

   *  message-entry (type: "user"): Captures prompt inputs

   *  reasoning-entry: Captures chain-of-thought (where available)

   *  message-entry (type: "assistant"): Captures model outputs

   *  tool-call-entry / tool-result-entry: Captures agentic actions

2.3.4.  Financial Sector Requirements (FFIEC, BSI)

   Financial institutions face additional scrutiny for AI systems per
   [FFIEC_IT_HANDBOOK_2024] and [BSI_AI_FINANCE_2024]:

    +================+===========================+===================+
    | Requirement    | FFIEC                     | BSI AI Finance    |
    | Area           |                           |                   |
    +================+===========================+===================+
    | Explainability | "Lack of transparency or  | Test criteria for |
    |                | explainability" risk      | explainability    |
    +----------------+---------------------------+-------------------+
    | Dynamic        | "Challenges to monitoring | Continuous        |
    | updating       | and independently         | validation        |
    |                | reviewing AI"             |                   |
    +----------------+---------------------------+-------------------+
    | Audit trail    | Log management (VI.B.7)   | Complete audit    |
    |                |                           | trail             |
    +----------------+---------------------------+-------------------+

                                 Table 14

2.4.  Compliance Mapping Table

   The following table maps this specification's data elements to
   compliance requirements:















Birkholz, et al.         Expires 29 August 2026                [Page 17]

Internet-Draft               Verifiable ACRs               February 2026


    +=============+========+=========+=====+=======+=====+=======+====+
    |Data Element |EU AI   |ETSI     |SOC 2|FedRAMP|PCI  |ISO    |NIS2|
    |             |Act     |104223   |     |       |DSS  |42001  |    |
    +=============+========+=========+=====+=======+=====+=======+====+
    |timestamp    |Art.    |5.4.2-1  |CC7.2|AU-8   |10.6 |A.6.2.8|Art.|
    |             |12(2)   |         |     |       |     |       |23  |
    +-------------+--------+---------+-----+-------+-----+-------+----+
    |session-id   |Art. 12 |5.2.4-1  |CC7.2|AU-3   |10.2 |A.6.2.8|-   |
    +-------------+--------+---------+-----+-------+-----+-------+----+
    |entry.type   |Art.    |5.4.2-1  |CC7.2|AU-3   |10.2 |A.6.2.8|-   |
    |             |12(2)   |         |     |       |     |       |    |
    +-------------+--------+---------+-----+-------+-----+-------+----+
    |contributor  |Art.    |5.1.4    |CC6.1|AC-2   |10.2 |A.6.2.8|-   |
    |             |12(3)(d)|         |     |       |     |       |    |
    +-------------+--------+---------+-----+-------+-----+-------+----+
    |message-     |Art.    |5.1.2-3  |-    |-      |AI   |-      |-   |
    |entry.content|12(3)(c)|         |     |       |Guide|       |    |
    +-------------+--------+---------+-----+-------+-----+-------+----+
    |reasoning-   |Art. 12 |5.4.2-3  |-    |-      |AI   |A.7.1  |-   |
    |entry        |        |         |     |       |Guide|       |    |
    +-------------+--------+---------+-----+-------+-----+-------+----+
    |tool-call-   |Art. 12 |5.4.2-1  |CC7.2|AU-12  |10.2 |A.6.2.8|-   |
    |entry / tool-|        |         |     |       |     |       |    |
    |result-entry |        |         |     |       |     |       |    |
    +-------------+--------+---------+-----+-------+-----+-------+----+
    |signed-agent-|Art. 19 |5.2.4-1.2|CC6.1|AU-9   |10.5 |-      |-   |
    |record       |        |         |     |       |     |       |    |
    +-------------+--------+---------+-----+-------+-----+-------+----+
    |vcs-context  |-       |5.2.1-2  |-    |CM-3   |-    |A.6.2.8|-   |
    +-------------+--------+---------+-----+-------+-----+-------+----+
    |token-usage  |-       |5.4.2-4  |-    |-      |-    |-      |-   |
    +-------------+--------+---------+-----+-------+-----+-------+----+

                                  Table 15

2.5.  Security Requirements addressing Regulatory Compliance

2.5.1.  Log Integrity

   Per PCI DSS [PCI_DSS_V4_0_1] Req 10.5 and FedRAMP [NIST_SP_800_53_R5]
   AU-9, logs MUST be protected against modification.  Implementations
   SHOULD:

   1.  Use the signed-agent-record envelope for cryptographic integrity

   2.  Store the content-hash for offline verification

   3.  Implement write-once storage for log archives



Birkholz, et al.         Expires 29 August 2026                [Page 18]

Internet-Draft               Verifiable ACRs               February 2026


2.5.2.  Access Control

   Per FedRAMP [NIST_SP_800_53_R5] AC-3 and ETSI [ETSI_TS_104223_2025]
   5.2.2-1, access to logs MUST be controlled:

   1.  Logs containing sensitive prompts or outputs require access
       control

   2.  Reasoning content may contain confidential information

   3.  Authority access (EU AI Act Art. 19) requires audit of log access
       itself

2.5.3.  Data Protection

   Logs may contain personal data subject to GDPR/privacy regulations:

   1.  message-entry.content may contain PII

   2.  tool-result-entry.output may contain query results with PII

   3.  Retention periods must balance compliance requirements with data
       minimization

2.6.  Related Standards and Emerging Work

   The ISO/IEC JTC 1/SC 42 committee is developing [ISO_IEC_DIS_24970],
   a draft international standard specifically addressing AI system
   logging requirements.  This work aligns with and complements the
   verifiable agent conversation format defined in this document.

   Research on emergent misalignment [EMERGENT_MISALIGNMENT_2025]
   demonstrates that narrow fine-tuning can produce broadly misaligned
   LLMs, underscoring the importance of comprehensive conversation
   logging for detecting behavioral anomalies that may not be apparent
   from individual interactions.

3.  CDDL Definitions for Agent Conversations Records

   This section defines each complex data type specified in the
   verifiable agent conversation record CDDL data definition.  Each
   subsection illustrates a CDDL fragment for one type, a brief
   description, and per-member documentation.

3.1.  Common Types

   The schema uses the following generic type definitions throughout.




Birkholz, et al.         Expires 29 August 2026                [Page 19]

Internet-Draft               Verifiable ACRs               February 2026


   abstract-timestamp:  An RFC 3339 date-time string or numeric epoch
      milliseconds.  New implementations SHOULD use RFC 3339 strings;
      consumers MUST accept both forms.

   session-id:  An opaque string uniquely identifying a conversation
      session.  Values may be UUID v4, UUID v7, SHA-256 hashes, or other
      formats.

   entry-id:  A per-entry unique reference within a session, enabling
      parent-child linking and tool call-result correlation.

3.2.  The verifiable-agent-record Map

   The CDDL definition for the verifiable-agent-record map is specified
   as follows:

   verifiable-agent-record = {
       version: tstr
       id: tstr
       session: session-trace
       ? created: abstract-timestamp
       ? file-attribution: file-attribution-record
       ? vcs: vcs-context
       ? recording-agent: recording-agent
       * tstr => any
   }

   The verifiable-agent-record is the top-level container for all data
   produced by or about an agent conversation.  It unifies two
   complementary perspectives: the session trace captures how code was
   produced (the full conversation replay), while file attribution
   captures what code was produced (which files were modified and by
   whom).

   The following describes each member of this map.

   version:  The schema version string following semantic versioning
      (e.g., "3.0.0-draft").  Consumers use this field to select the
      appropriate parser or validation logic.

   id:  A unique identifier for this record, typically a UUID.
      Distinguishes records when multiple are stored or transmitted
      together.

   session:  The full conversation trace including all entries, tool
      calls, reasoning steps, and system events.

   created:  The timestamp when this record was generated.  Distinct



Birkholz, et al.         Expires 29 August 2026                [Page 20]

Internet-Draft               Verifiable ACRs               February 2026


      from session timestamps, which record when the conversation
      occurred.

   file-attribution:  Structured data about which files were modified
      and which line ranges were written by the agent.

   vcs:  Version control metadata at the record level (repository,
      branch, revision).

   recording-agent:  Identifies the tool or agent that generated this
      record, as distinct from the agent that conducted the
      conversation.

3.3.  The session-trace Map

   The CDDL definition for the session-trace map is specified as
   follows:

   session-trace = {
       ? format: tstr
       session-id: session-id
       ? session-start: abstract-timestamp
       ? session-end: abstract-timestamp
       agent-meta: agent-meta
       ? environment: environment
       entries: [* entry]
       * tstr => any
   }

   A session-trace captures the full conversation between a user and an
   autonomous agent.  It contains an ordered array of entries
   representing messages, tool invocations, reasoning steps, and system
   events.  The session-trace preserves the complete interaction history
   including all native agent metadata, enabling both replay and audit
   of the conversation.

   The following describes each member of this map.

   format:  Classifies the session style, such as "interactive" (human-
      in-the-loop) or "autonomous" (fully automated).  Informative only;
      does not change the structure.

   session-id:  Unique identifier for this session.

   session-start:  When the session began.

   session-end:  When the session ended.




Birkholz, et al.         Expires 29 August 2026                [Page 21]

Internet-Draft               Verifiable ACRs               February 2026


   agent-meta:  Metadata about the agent and model that conducted this
      conversation.

   environment:  Execution environment context, such as working
      directory and version control state.

   entries:  An ordered array of conversation entries.

3.4.  The agent-meta Map

   The CDDL definition for the agent-meta map is specified as follows:

   agent-meta = {
       model-id: tstr
       model-provider: tstr
       ? models: [* tstr]
       ? cli-name: tstr
       ? cli-version: tstr
       * tstr => any
   }

   The agent-meta type identifies the coding agent and language model
   used during a conversation session.  Agent identification is
   essential for provenance tracking: knowing which model produced which
   output enables auditing, capability assessment, and compliance
   verification.

   The following describes each member of this map.

   model-id:  The primary language model identifier, using the naming
      convention of the provider (e.g., "claude-opus-4-5-20251101",
      "gemini-2.0-flash").

   model-provider:  The provider of the primary model (e.g.,
      "anthropic", "google", "openai").

   models:  List of all model identifiers used during the session.
      Relevant for multi-model sessions where the agent switches between
      models.

   cli-name:  The name of the CLI tool or agent framework (e.g.,
      "claude-code", "gemini-cli", "codex-cli").

   cli-version:  The version of the CLI tool.







Birkholz, et al.         Expires 29 August 2026                [Page 22]

Internet-Draft               Verifiable ACRs               February 2026


3.5.  The recording-agent Map

   The CDDL definition for the recording-agent map is specified as
   follows:

   recording-agent = {
       name: tstr
       ? version: tstr
       * tstr => any
   }

   The recording-agent map identifies the tool that generated this
   verifiable agent record, as distinct from the agent that conducted
   the conversation.  This distinction matters for provenance chains:
   the recording tool's version affects how native data is translated
   into the canonical CDDL data definition specified in this document.

   The following describes each member of this map.

   name:  The name of the recording tool or agent.

   version:  The version of the recording tool.

3.6.  The environment Map

   The CDDL definition for the environment map is specified as follows:

   environment = {
       working-dir: tstr
       ? vcs: vcs-context
       ? sandboxes: [* tstr]
       * tstr => any
   }

   The environment type captures execution context for the conversation:
   where the agent was running, what version control state was active,
   and whether sandboxing was in effect.  This context is important for
   reproducibility and for understanding the scope of file
   modifications.

   The following describes each member of this map.

   working-dir:  The primary working directory path.  File paths in tool
      calls are typically relative to this directory.

   vcs:  Version control state at the time of the session (branch,
      revision, etc.).




Birkholz, et al.         Expires 29 August 2026                [Page 23]

Internet-Draft               Verifiable ACRs               February 2026


   sandboxes:  Paths to sandbox mount points.  Some agents run in
      sandboxed environments where the working directory is a temporary
      mount.

3.7.  The vcs-context Map

   The CDDL definition for the vcs-context map is specified as follows:

   vcs-context = {
       type: tstr
       ? revision: tstr
       ? branch: tstr
       ? repository: tstr
       * tstr => any
   }

   The vcs-context type captures version control metadata for
   reproducibility.  Knowing the exact repository, branch, and commit at
   the time of a conversation enables consumers to reconstruct the
   codebase state and verify file attributions.

   The following describes each member of this map.

   type:  The version control system type (e.g., "git", "jj", "hg",
      "svn").

   revision:  The commit SHA or change identifier at session time.

   branch:  The active branch name.

   repository:  The repository URL.

3.8.  Entry Types

   The CDDL definition specifies five entry types representing the
   different kinds of events in an agent conversation.  Each type uses a
   type field as the discriminator.  All entry types support optional
   children for hierarchical nesting and * tstr => any for preserving
   native agent fields that do not map to canonical fields.

   entry = message-entry
         / tool-call-entry
         / tool-result-entry
         / reasoning-entry
         / event-entry






Birkholz, et al.         Expires 29 August 2026                [Page 24]

Internet-Draft               Verifiable ACRs               February 2026


3.8.1.  The message-entry Map

   The CDDL definition for the message-entry map is specified as
   follows:

   message-entry = {
       type: "user" / "assistant"
       ? content: any
       ? timestamp: abstract-timestamp
       ? id: entry-id
       ? model-id: tstr
       ? parent-id: entry-id
       ? token-usage: token-usage
       ? children: [* entry]
       * tstr => any
   }

   A message-entry represents a conversational turn: either human input
   (type: "user") or agent response (type: "assistant").  This is the
   most common entry type, carrying the primary dialogue content of a
   session.  For assistant messages, additional metadata may be present:
   the model that generated the response and token usage statistics.

   The following describes each member of this map.

   type:  The message direction. "user" indicates human (or upstream
      agent) input; "assistant" indicates the agent's response.

   content:  The message body.  May be a plain text string, an array of
      typed content parts, or absent when the agent places content
      exclusively in child entries.

   timestamp:  When this message was produced.

   id:  Unique identifier for this entry within the session.

   model-id:  The model that generated this response.  Present on
      assistant entries; absent on user entries.

   parent-id:  References the parent entry, enabling tree-structured
      conversations.

   token-usage:  Token consumption metrics for this response.

   children:  Nested entries within this message.  Used when the native
      format embeds tool calls or reasoning blocks inside an assistant
      message.




Birkholz, et al.         Expires 29 August 2026                [Page 25]

Internet-Draft               Verifiable ACRs               February 2026


3.8.2.  The tool-call-entry Map

   The CDDL definition for the tool-call-entry map is specified as
   follows:

   tool-call-entry = {
       type: "tool-call"
       name: tstr
       input: any
       ? call-id: tstr
       ? timestamp: abstract-timestamp
       ? id: entry-id
       ? children: [* entry]
       * tstr => any
   }

   A tool-call-entry represents a tool invocation: which tool was called
   and with what arguments.  Tool calls are central to agent
   conversation records because tool use is the primary mechanism by
   which agents interact with external environment.

   The following describes each member of this map.

   type:  Fixed discriminator value "tool-call".

   name:  The tool name (e.g., "Bash", "Edit", "Read", "apply_patch").

   input:  The arguments passed to the tool, preserved in their native
      structure.

   call-id:  Links this call to its corresponding result.

   timestamp:  When this tool call occurred.

   id:  Unique identifier for this entry.

   children:  Nested entries within this tool call.

3.8.3.  The tool-result-entry Map

   The CDDL definition for the tool-result-entry map is specified as
   follows:









Birkholz, et al.         Expires 29 August 2026                [Page 26]

Internet-Draft               Verifiable ACRs               February 2026


   tool-result-entry = {
       type: "tool-result"
       output: any
       ? call-id: tstr
       ? status: tstr
       ? is-error: bool
       ? timestamp: abstract-timestamp
       ? id: entry-id
       ? children: [* entry]
       * tstr => any
   }

   A tool-result-entry represents the output returned by a tool after
   execution.  It is linked to its corresponding tool-call-entry via the
   call-id field.  The result carries the tool's response data and
   optional status metadata indicating success or failure.

   The following describes each member of this map.

   type:  Fixed discriminator value "tool-result".

   output:  The tool's response, preserved in native structure.

   call-id:  Links this result to its corresponding call.

   status:  Outcome status of the tool execution, such as "success",
      "error", or "completed".

   is-error:  Boolean error flag, present when the tool execution
      failed.

   timestamp:  When this tool result was returned.

   id:  Unique identifier for this entry.

   children:  Nested entries within this tool result.

3.8.4.  The reasoning-entry Map

   The CDDL definition for the reasoning-entry map is specified as
   follows:










Birkholz, et al.         Expires 29 August 2026                [Page 27]

Internet-Draft               Verifiable ACRs               February 2026


   reasoning-entry = {
       type: "reasoning"
       content: any
       ? encrypted: tstr
       ? subject: tstr
       ? timestamp: abstract-timestamp
       ? id: entry-id
       ? children: [* entry]
       * tstr => any
   }

   A reasoning-entry captures CoT, thinking, or internal reasoning
   content from the agent.  Not all agents expose reasoning traces; when
   they do, the content may be plaintext, structured blocks, or
   encrypted.  Reasoning entries are valuable for auditing decision-
   making processes and understanding why an agent took particular
   actions.

   The following describes each member of this map.

   type:  Fixed discriminator value "reasoning".

   content:  The reasoning text or structured content.  May be an empty
      string when only encrypted content is available.

   encrypted:  Encrypted reasoning content.  Used where the model
      provider encrypts chain-of-thought output.

   subject:  A topic label for the reasoning block.

   timestamp:  When this reasoning was produced.

   id:  Unique identifier for this entry.

   children:  Nested entries within the reasoning block.

3.8.5.  The event-entry Map

   The CDDL definition for the event-entry map is specified as follows:












Birkholz, et al.         Expires 29 August 2026                [Page 28]

Internet-Draft               Verifiable ACRs               February 2026


   event-entry = {
       type: "system-event"
       event-type: tstr
       ? data: { * tstr => any }
       ? timestamp: abstract-timestamp
       ? id: entry-id
       ? children: [* entry]
       * tstr => any
   }

   An event-entry records system lifecycle events that are not part of
   the conversation dialogue but are relevant for understanding the
   session context.  Examples include session start/end markers, token
   usage summaries, permission changes, and configuration events.

   The following describes each member of this map.

   type:  Fixed discriminator value "system-event".

   event-type:  Classifies the event, such as "session-start", "session-
      end", "token-count", or "permission-change".  The values are not
      enumerated in the schema to accommodate vendor-specific event
      types.

   data:  Event-specific payload.  The structure varies by event type.

   timestamp:  When this event occurred.

   id:  Unique identifier for this entry.

   children:  Nested entries within this event.

3.9.  The token-usage Map

   The CDDL definition for the token-usage map is specified as follows:

   token-usage = {
       ? input: uint
       ? output: uint
       ? cached: uint
       ? reasoning: uint
       ? total: uint
       ? cost: number
       * tstr => any
   }






Birkholz, et al.         Expires 29 August 2026                [Page 29]

Internet-Draft               Verifiable ACRs               February 2026


   The token-usage type captures token consumption metrics for a model
   response.  Token usage data is essential for cost tracking, quota
   management, and understanding model behavior.  All fields are
   optional because different agents report different subsets of token
   metrics.

   Editor's Note: add a non-empty generic here

   The following describes each member of this map.

   input:  The number of input tokens consumed by this response.

   output:  The number of output tokens generated.

   cached:  The number of input tokens served from cache rather than
      reprocessed.

   reasoning:  Tokens consumed by chain-of-thought or reasoning
      computation.

   total:  The total token count.

   cost:  The monetary cost in US dollars for this response.

3.10.  File Attribution Types

   NOTE: This section is specified but not yet validated against real
   session data.  Implementation is pending.

   File attribution captures what code was produced: which files were
   modified, which line ranges were changed, and who authored them.

3.10.1.  The file-attribution-record Map

   The CDDL definition for the file-attribution-record map is specified
   as follows:

   file-attribution-record = {
       files: [* file]
   }

   The file-attribution-record is the top-level container for file
   attribution data.  It holds an array of files, each with their
   attributed line ranges and contributor information.

   The following describes each member of this map.

   files:  Array of files with attributed ranges.



Birkholz, et al.         Expires 29 August 2026                [Page 30]

Internet-Draft               Verifiable ACRs               February 2026


3.10.2.  The file Map

   The CDDL definition for the file map is specified as follows:

   file = {
       path: tstr
       conversations: [* conversation]
   }

   A file represents a single source file that was modified during the
   conversation.  It groups all conversations that contributed changes
   to this file.

   The following describes each member of this map.

   path:  The file path relative to the repository root.

   conversations:  The conversations that contributed modifications to
      this file.

3.10.3.  The conversation Map

   The CDDL definition for the conversation map is specified as follows:

   conversation = {
       ? url: tstr .regexp uri-regexp
       ? contributor: contributor
       ranges: [* range]
       ? related: [* resource]
   }

   A conversation links a specific session to the line ranges it
   produced in a file.  This enables tracing from a line of code back to
   the conversation that generated it.

   The following describes each member of this map.

   url:  A URL pointing to the conversation source (e.g., a web UI
      permalink).

   contributor:  The default contributor for all ranges in this
      conversation.  Can be overridden per-range.

   ranges:  The line ranges in the file that were produced by this
      conversation.

   related:  External resources related to this conversation (e.g.,
      issue trackers, documentation).



Birkholz, et al.         Expires 29 August 2026                [Page 31]

Internet-Draft               Verifiable ACRs               February 2026


3.10.4.  The range Map

   The CDDL definition for the range map is specified as follows:

   range = {
       start-line: uint
       end-line: uint
       ? content-hash: tstr
       ? content-hash-alg: tstr
       ? contributor: contributor
   }

   A range identifies a contiguous block of lines in a file that were
   produced by a specific conversation.  Line numbers are 1-indexed and
   inclusive.  The optional content hash enables position-independent
   tracking when lines move due to later edits.

   The following describes each member of this map.

   start-line:  The first line of the range (1-indexed).

   end-line:  The last line of the range (1-indexed, inclusive).

   content-hash:  A hash of the range content for position-independent
      identification.

   content-hash-alg:  The hash algorithm used (default: "sha-256").

   contributor:  Overrides the conversation-level contributor for this
      specific range.

3.10.5.  The contributor Map

   The CDDL definition for the contributor map is specified as follows:

   contributor = {
       type: "human" / "ai" / "mixed" / "unknown"
       ? model-id: tstr
   }

   A contributor identifies who authored a range of code.  The type
   field distinguishes between human-authored, AI-generated, mixed, and
   unknown authorship.

   The following describes each member of this map.

   type:  The authorship category.




Birkholz, et al.         Expires 29 August 2026                [Page 32]

Internet-Draft               Verifiable ACRs               February 2026


   model-id:  The model identifier for AI-authored ranges.

3.10.6.  The resource Map

   The CDDL definition for the resource map is specified as follows:

   resource = {
       type: tstr
       url: tstr .regexp uri-regexp
   }

   A resource represents an external reference related to a
   conversation, such as an issue tracker entry, a pull request, or a
   documentation page.

   The following describes each member of this map.

   type:  The resource type (e.g., "issue", "pr", "documentation").

   url:  The URL of the resource.

3.11.  Signing Envelope Types

   The signing envelope provides cryptographic integrity protection for
   verifiable agent records using COSE_Sign1 ([STD96]).

3.11.1.  The signed-agent-record Structure

   The CDDL definition for a signed-agent-record structure is specified
   as follows:

   signed-agent-record = #6.18([
       protected: bstr .cbor protected-header
       unprotected: unprotected-header
       payload: bstr / null
       signature: bstr
   ])

   A signed-agent-record is a COSE_Sign1 envelope (CBOR Tag 18) that
   wraps a verifiable agent record with a cryptographic signature.
   Signing provides data provenance and tamper evidence, satisfying some
   requirements of RATS Evidence generation ([RFC9334]) and SCITT
   auditability ([I-D.ietf-scitt-architecture]) requirements.  The
   payload may be included or detached (null); in detached mode, the
   record is supplied separately during verification.

   The following describes each element of this structure.




Birkholz, et al.         Expires 29 August 2026                [Page 33]

Internet-Draft               Verifiable ACRs               February 2026


   protected:  The serialized protected header containing the algorithm
      identifier, content type, and CWT claims.

   unprotected:  The unprotected header carrying trace metadata at label
      100.

   payload:  The serialized record bytes, or null for detached payloads.

   signature:  The cryptographic signature over the protected header and
      payload.

3.11.2.  The trace-metadata Map

   The CDDL definition for the trace-metadata map is specified as
   follows:

   trace-metadata = {
       session-id: session-id
       agent-vendor: tstr
       trace-format: trace-format-id
       timestamp-start: abstract-timestamp
       ? timestamp-end: abstract-timestamp
       ? content-hash: tstr
       ? content-hash-alg: tstr
   }

   The trace-metadata type carries summary information about the signed
   record in the COSE_Sign1 unprotected header.  This enables consumers
   to inspect key properties of a signed record without deserializing
   the full payload.

   The following describes each member of this map.

   session-id:  The session identifier from the signed record.

   agent-vendor:  The agent provider name (e.g., "anthropic", "google").

   trace-format:  Identifies the format of the signed payload (e.g.,
      "ietf-vac-v3.0" for canonical records).

   timestamp-start:  When the session began.

   timestamp-end:  When the session ended.

   content-hash:  SHA-256 hex digest of the payload bytes, enabling
      integrity checking independent of the COSE signature.

   content-hash-alg:  The hash algorithm used (default: "sha-256").



Birkholz, et al.         Expires 29 August 2026                [Page 34]

Internet-Draft               Verifiable ACRs               February 2026


4.  Collated CDDL Definition for generic Agent Conversations

   start = verifiable-agent-record / signed-agent-record

   ; RFC 3339 string OR epoch milliseconds (for interop).
   abstract-timestamp = tstr .regexp date-time-regexp / uint

   ; Opaque string: UUID, SHA-256 hash in base64url, etc.
   session-id = tstr / bstr

   ; Per-entry unique reference within a session.
   entry-id = tstr

   ; RFC 3339 date-time pattern
   date-time-regexp = "([0-9]{4})-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])T([01][0-9]|2[0-3]):([0-5][0-9]):(60|[0-5][0-9])([.][0-9]+)?(Z|[+-]([01][0-9]|2[0-3]):[0-5][0-9])"

   ; URI pattern (RFC 3986)
   uri-regexp = "(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\\?([^#]*))?(#(.*))?"

   verifiable-agent-record = {
       version: tstr                       ; Schema version (semver)
       id: tstr                            ; Record identifier
       session: session-trace              ; Conversation trace (required)
       ? created: abstract-timestamp       ; Record creation time
       ? file-attribution: file-attribution-record
       ? vcs: vcs-context                  ; Record-level VCS context
       ? recording-agent: recording-agent  ; Tool that generated this record
       * tstr => any
   }

   session-trace = {
       ? format: tstr                      ; "interactive" / "autonomous" / vendor
       session-id: session-id
       ? session-start: abstract-timestamp
       ? session-end: abstract-timestamp
       agent-meta: agent-meta
       ? environment: environment
       entries: [* entry]
       * tstr => any
   }

   agent-meta = {
       model-id: tstr                      ; e.g., "claude-opus-4-5-20251101"
       model-provider: tstr                ; e.g., "anthropic", "google"
       ? models: [ * tstr ]                  ; All models (multi-model sessions)
       ? cli-name: tstr                    ; e.g., "claude-code", "gemini-cli"
       ? cli-version: tstr
       * tstr => any



Birkholz, et al.         Expires 29 August 2026                [Page 35]

Internet-Draft               Verifiable ACRs               February 2026


   }

   recording-agent = {
       name: tstr
       ? version: tstr
       * tstr => any
   }

   environment = {
       working-dir: tstr
       ? vcs: vcs-context
       ? sandboxes: [ * tstr ]               ; Sandbox mount paths
       * tstr => any
   }

   vcs-context = {
       type: tstr                          ; "git" / "jj" / "hg" / "svn"
       ? revision: tstr                    ; Commit SHA or change ID
       ? branch: tstr
       ? repository: tstr                  ; Repository URL
       * tstr => any
   }

   entry = message-entry
         / tool-call-entry
         / tool-result-entry
         / reasoning-entry
         / event-entry

   message-entry = {
       type: "user" / "assistant"
       ? content: any                      ; Text string or structured content blocks
       ? timestamp: abstract-timestamp
       ? id: entry-id
       ? model-id: tstr                    ; Model (assistant only)
       ? parent-id: entry-id              ; Parent message reference
       ? token-usage: token-usage
       ? children: [ * entry ]
       * tstr => any
   }

   tool-call-entry = {
       type: "tool-call"
       name: tstr                          ; Tool name (e.g., "Bash", "Edit", "Read")
       input: any                          ; Tool arguments
       ? call-id: tstr                     ; Links call ↔ result
       ? timestamp: abstract-timestamp
       ? id: entry-id



Birkholz, et al.         Expires 29 August 2026                [Page 36]

Internet-Draft               Verifiable ACRs               February 2026


       ? children: [ * entry ]
       * tstr => any
   }

   tool-result-entry = {
       type: "tool-result"
       output: any                         ; Tool output
       ? call-id: tstr                     ; Links call ↔ result
       ? status: tstr                      ; "success" / "error" / "completed"
       ? is-error: bool
       ? timestamp: abstract-timestamp
       ? id: entry-id
       ? children: [ * entry ]
       * tstr => any
   }

   reasoning-entry = {
       type: "reasoning"
       content: any                        ; Plaintext reasoning or structured
       ? encrypted: tstr                   ; Encrypted content (provider-protected)
       ? subject: tstr                     ; Topic label
       ? timestamp: abstract-timestamp
       ? id: entry-id
       ? children: [ * entry ]
       * tstr => any
   }

   event-entry = {
       type: "system-event"
       event-type: tstr                    ; Event classifier
       ? data: { * tstr => any }           ; Event-specific payload
       ? timestamp: abstract-timestamp
       ? id: entry-id
       ? children: [ * entry ]
       * tstr => any
   }

   token-usage = {
       ? input: uint                       ; Input tokens
       ? output: uint                      ; Output tokens
       ? cached: uint                      ; Cached input tokens
       ? reasoning: uint                   ; Reasoning/thinking tokens
       ? total: uint                       ; Total tokens
       ? cost: number                      ; Dollar cost
       * tstr => any
   }

   file-attribution-record = {



Birkholz, et al.         Expires 29 August 2026                [Page 37]

Internet-Draft               Verifiable ACRs               February 2026


       files: [* file]
   }

   file = {
       path: tstr                          ; Relative path from repo root
       conversations: [* conversation]
   }

   conversation = {
       ? url: tstr .regexp uri-regexp
       ? contributor: contributor          ; Default contributor for ranges
       ranges: [* range]
       ? related: [* resource]
   }

   range = {
       start-line: uint                    ; 1-indexed
       end-line: uint                      ; 1-indexed, inclusive
       ? content-hash: tstr
       ? content-hash-alg: tstr            ; Default: "sha-256"
       ? contributor: contributor          ; Override for this range
   }

   contributor = {
       type: "human" / "ai" / "mixed" / "unknown"
       ? model-id: tstr
   }

   resource = {
       type: tstr
       url: tstr .regexp uri-regexp
   }

   ; SCITT-interoperable COSE Envelope
   ; including from draft-ietf-cose-merkle-tree-proofs and
   ; draft-ietf-scitt-architecture for validation

   signed-agent-record = #6.18([           ; COSE_Sign1 tag
       protected: bstr .cbor protected-header ; {alg, content-type, scitt-stuff}
       unprotected: unprotected-header     ; Trace metadata
       payload: bstr / null                ; Detached if null
       signature: bstr
   ])

   protected-header = {
     &(CWT_Claims: 15) => CWT_Claims
     ? &(alg: 1) => int
     ? &(content_type: 3) => tstr / uint



Birkholz, et al.         Expires 29 August 2026                [Page 38]

Internet-Draft               Verifiable ACRs               February 2026


     ? &(kid: 4) => bstr
     ? &(x5t: 34) => COSE_CertHash
     ? &(x5chain: 33) => COSE_X509
     * label => any
   }

   CWT_Claims = {
     &(iss: 1) => tstr
     &(sub: 2) => tstr
     * label => any
   }

   unprotected-header = {
     ? &(trace-metadata-key: 100) => trace-metadata ; 100 is placeholder
     ? &(x5chain: 33) => COSE_X509
     ? &(receipts: 394)  => [ + Receipt ]
     * label => any
   }

   trace-metadata = {
       session-id: session-id
       agent-vendor: tstr
       trace-format: trace-format-id
       timestamp-start: abstract-timestamp
       ? timestamp-end: abstract-timestamp
       ? content-hash: tstr                ; SHA-256 hex digest of payload
       ? content-hash-alg: tstr
   }

   ; Known values: "ietf-vac-v3.0" (canonical), "claude-jsonl", "gemini-json",
   ; "codex-jsonl", "opencode-json", "cursor-jsonl". Extensible via tstr.
   trace-format-id = tstr

   COSE_X509 = bstr / [ 2*certs: bstr ]
   COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ]
   label = int / tstr

   ; COSE Receipt CDDL for use in SCITT compliant COSE Envelope

   Receipt = #6.18(COSE_Sign1)

   cose-label = int / tstr
   cose-value = any

   Protected_Header = {
     * cose-label => cose-value
   }




Birkholz, et al.         Expires 29 August 2026                [Page 39]

Internet-Draft               Verifiable ACRs               February 2026


   Unprotected_Header = {
     &(receipts: 394)  => [+ bstr .cbor Receipt]
     * cose-label => cose-value
   }

   COSE_Sign1 = [
     protected   : bstr .cbor Protected_Header,
     unprotected : Unprotected_Header,
     payload     : bstr / null,
     signature   : bstr
   ]

         Figure 1: CDDL definition of an Agent Conversation Record

5.  Privacy Considerations

   Verifiable agent conversation records reveal substantial information
   about agent behavior, system state, and user interactions.  The
   privacy considerations of [RFC6973] apply.

5.1.  Information Disclosure

   User prompts captured in message entries may contain personal
   identifiers, business confidential information, credentials
   inadvertently included in prompts, or behavioral patterns.  Agent
   responses and reasoning traces may reveal inference results that
   expose information about users not explicitly provided, confidential
   information retrieved by tools, or system architecture details
   through tool names and parameters.  Implementations MUST treat user-
   provided content as potentially containing personally identifiable
   information.

   Record metadata exposes operational details that may have privacy
   implications.  Model identifiers reveal AI capabilities, CLI versions
   enable targeted attacks against known vulnerabilities, working
   directories expose file system structure, and VCS context discloses
   repository names and commit timing.  Token usage patterns may enable
   inference about conversation content even when the content itself is
   protected.

5.2.  Sensitive Content in Records

   Reasoning entries may contain inferences that constitute special
   category data, including health-related inferences from user queries,
   political opinions derived from conversation context, or biometric
   data processed by AI systems.  The reasoning-entry.encrypted field
   reflects that some model providers encrypt chain-of-thought content;
   when reasoning is encrypted, audit capabilities depend on the



Birkholz, et al.         Expires 29 August 2026                [Page 40]

Internet-Draft               Verifiable ACRs               February 2026


   provider's cooperation.

   Tool inputs and outputs warrant particular attention.  Tool call
   inputs may contain credentials, API keys, or file contents.  Tool
   results may contain query results with personal data from databases
   or external services.  Implementations SHOULD provide configurable
   redaction rules for common patterns and support selective entry type
   recording based on deployment requirements.

5.3.  Retention Considerations

   Multiple frameworks impose retention requirements that may conflict
   with data minimization principles.  Organizations must balance
   compliance obligations requiring extended retention against privacy
   principles requiring timely deletion.

   Compliant data management may require separating raw personal data
   from audit trail metadata, implementing automated deletion for
   personal data after compliance-minimum periods, and maintaining
   cryptographic commitments enabling verification without retaining
   content.

5.4.  Correlation and Inference

   Presentations of the same record to multiple parties can be
   correlated by matching on the signature component.  Session
   identifiers enable linking of records across time, potentially
   revealing long-term behavioral patterns or organizational structure.
   Implementations SHOULD use unlinkable session identifiers where
   correlation is not required.

   Without accessing record content, observers may infer conversation
   frequency and duration patterns, types of tools used, error rates, or
   timing correlations with external events.  Metadata exposure in
   unprotected headers warrants careful consideration; the trace-
   metadata in the COSE unprotected header reveals session identifiers,
   agent vendor, and timestamps even when the payload is encrypted.

5.5.  Authority Access

   Regulatory frameworks may require provision of records to authorities
   upon request.  Access to records has to be logged, capturing who
   accessed which records, when access occurred, what legal basis
   justified access, and what data was disclosed.  This creates a
   recursive consideration: access logs may themselves contain personal
   data requiring protection.





Birkholz, et al.         Expires 29 August 2026                [Page 41]

Internet-Draft               Verifiable ACRs               February 2026


6.  Security Considerations

6.1.  Record Integrity

   The signed-agent-record envelope provides cryptographic integrity
   protection for the serialized record payload.  A valid signature
   establishes that the claimed signer produced the record but does not
   guarantee the truthfulness of its contents.  Modifications to the
   record structure after signing invalidate the signature, but
   modifications before signing cannot be detected.  Implementations
   generating records incrementally during a conversation MUST sign only
   after the conversation concludes or at defined checkpoints.

6.2.  Signing Key Protection

   The security of signed records depends critically on the protection
   of private signing keys.  If an attacker obtains a signing key, they
   can forge records indistinguishable from genuine ones.  Protection
   mechanisms range from operating system process isolation in
   development environments to hardware security modules with physical
   tampering resistance in high-assurance deployments.  Compromised
   signing keys require rejection of records signed after the compromise
   date and notification to Relying Parties.

   Key provisioning processes must guarantee that exclusively valid
   attestation key material is established.  Off-device key generation
   requires confidentiality protection during transmission, creating
   recursive security dependencies.  On-device key generation eliminates
   transmission risks but requires chain-of-custody integrity to prevent
   attackers from obtaining endorsement for keys they control.

6.3.  Timestamp Integrity

   Timestamps establish temporal ordering of events within records.
   Attackers who can manipulate timestamps can backdate records, freeze
   participants in chosen time periods to evade freshness checks, or
   manipulate perceived temporal relationships between entries.
   Timestamps within records are attested by the signer, not
   independently verified.  Implementations requiring independent
   timestamp verification SHOULD use external timestamping services or
   transparency logs such as those defined in
   [I-D.ietf-scitt-architecture].









Birkholz, et al.         Expires 29 August 2026                [Page 42]

Internet-Draft               Verifiable ACRs               February 2026


6.4.  Adversarial Content

   Processing verifiable agent conversation records involves parsing
   content that may be produced by adversaries.  This applies both to
   user-supplied prompts and to model outputs that may have been
   influenced by adversarial inputs.  The open extensibility (* tstr =>
   any) in record types allows arbitrary additional fields;
   implementations MUST NOT assume that unrecognized fields are safe to
   process or display.

   Records may contain content designed to exploit downstream systems.
   Malicious prompts preserved in records may execute if records are
   subsequently processed by AI systems.  Tool results may contain
   executable content that executes if rendered unsafely in web
   interfaces.  File paths in tool calls or file attribution entries may
   attempt directory traversal.  Implementations MUST apply appropriate
   sanitization before rendering content, executing it in agent
   contexts, or using paths for file system operations.

6.5.  Non-Repudiation

   The signed-agent-record envelope alone provides authenticity and
   integrity, not non-repudiation.  A signer can claim key compromise or
   dispute the signing time without independent evidence.  Non-
   repudiation requires additional infrastructure such as transparency
   services [I-D.ietf-scitt-architecture] that provide independent
   timestamp proof via registration receipts, append-only logs
   preventing retroactive denial, and third-party witnesses to the
   signing event.

6.6.  Detection and Trust Boundaries

   Verifiable agent conversation records primarily enable detection of
   anomalous behavior rather than prevention.  Detection requires that
   records accurately reflect actual agent behavior; an agent that
   controls its own recording can omit or falsify entries.  The
   recording-agent field distinguishes the recording tool from the
   conversing agent, enabling Relying Parties to assess trust in the
   recording process.

   Trust boundaries exist between the agent runtime and recording
   system, between the recording system and storage, between storage and
   verification, and between verification and decision-making.  Attacks
   at any boundary may compromise record integrity or confidentiality.







Birkholz, et al.         Expires 29 August 2026                [Page 43]

Internet-Draft               Verifiable ACRs               February 2026


7.  IANA Considerations

7.1.  Media Type

   IANA is requested to add "application/agent-conversation" as a new
   media type for Verifiable Agent Conversation Records to the "Media
   Types" registry [IANA.media-types] in the Standards Tree [RFC6838]:

    +====================+================================+===========+
    | Name               | Template                       | Reference |
    +====================+================================+===========+
    | agent-conversation | application/agent-conversation | RFCthis   |
    +--------------------+--------------------------------+-----------+

         Table 16: Verifiable Agent Conversation Record Media Type

   Type name:  application

   Subtype name:  agent-conversation

   Required parameters:  N/A

   Optional parameters:  N/A

   Encoding considerations:  byte string

   Security considerations:  See Security Considerations {secconsec}

   Interoperability considerations:  N/A

   Published specification:  RFCthis

   Applications that use this media type:  Applications that need to
      describe AI agent conversation for verification and auditability.

   Fragment identifier considerations:  N/A

   Additional information:  Deprecated alias names for this type:  N/A

                            Magic number(s):  N/A

                            File extension(s):  acr

                            Macintosh file type code(s):  N/A

   Person/email address to contact for further information:  TBD

   Intended usage:  COMMON



Birkholz, et al.         Expires 29 August 2026                [Page 44]

Internet-Draft               Verifiable ACRs               February 2026


   Restriction on usage:  none

   Author:  See Author's Addresses section

   Change controller:  IETF

   Provisional registration:  no

7.2.  CoAP Content Format

   IANA is requested to assign a Content-Format ID for Verifiable Agent
   Conversation Records in the "CoAP Content-Formats" registry, within
   the "Constrained RESTful Environments (CoRE) Parameters" registry
   group [IANA.core-parameters]:

        +====================+================+======+===========+
        | Content-Type       | Content Coding | ID   | Reference |
        +====================+================+======+===========+
        | application/agent- | -              | TBD1 | RFCthis   |
        | conversation       |                |      |           |
        +--------------------+----------------+------+-----------+

          Table 17: Verifiable Agent Conversation Record Content
                                  Format

   If possible, TBD1 should be assigned in the 256...9999 range.

7.3.  CBOR Tag

   IANA is requested to allocate a tag for Verifiable Agent Conversation
   Records in the "CBOR Tags" registry [IANA.cbor-tags], preferably with
   the specific value requested:

           +======+===========+===============================+
           | Tag  | Data Item | Semantics                     |
           +======+===========+===============================+
           | 4149 | binary    | Verifiable Agent Conversation |
           |      |           | Records as defined in RFCthis |
           +------+-----------+-------------------------------+

              Table 18: Verifiable Agent Conversation Record
                                 CBOR Tag

7.4.  COSE Header Parameter

   IANA is requested to allocated the COSE header parameter defined in
   Table 19 in the "COSE Header Parameters" registry
   [IANA.cose_header-parameters].



Birkholz, et al.         Expires 29 August 2026                [Page 45]

Internet-Draft               Verifiable ACRs               February 2026


   +================+=====+=====+==========+==============+===========+
   | Name           |Label|Value| Value    | Description  | Reference |
   |                |     |Type | Registry |              |           |
   +================+=====+=====+==========+==============+===========+
   | trace-metadata |TBD  |CBOR | -        | A metadata   | RFCthis,  |
   |                |     |map  |          | summary of   | Section   |
   |                |     |     |          | an Agent     | 3.11.2    |
   |                |     |     |          | Conversation |           |
   |                |     |     |          | Record       |           |
   +----------------+-----+-----+----------+--------------+-----------+

                   Table 19: New COSE Header Parameters

8.  References

8.1.  Normative References

   [AICPA_TSC_2017]
              American Institute of Certified Public Accountants and
              Chartered Institute of Management Accountants, "Trust
              Services Criteria for Security, Availability, Processing
              Integrity, Confidentiality, and Privacy (With Revised
              Points of Focus - 2022)", AICPA Trust Services Criteria,
              2017, <https://www.aicpa-cima.com/resources/download/2017-
              trust-services-criteria-with-revised-points-of-focus-
              2022>.

   [BCP26]    Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://doi.org/10.17487/RFC8126>.

   [BSI_AI_FINANCE_2024]
              Bundesamt fuer Sicherheit in der Informationstechnik,
              "Test Criteria Catalogue for AI Systems in Finance",
              BSI AI Finance Test Criteria, 2024,
              <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/
              AI-Finance_Test-Criteria.pdf>.

   [ETSI_TS_104223_2025]
              European Telecommunications Standards Institute, "Securing
              Artificial Intelligence (SAI); Baseline Cyber Security
              Requirements for AI Models and Systems", ETSI TS 104 223,
              V1.1.1, April 2025, <https://www.etsi.org/deliver/
              etsi_ts/104200_104299/104223/01.01.01_60/
              ts_104223v010101p.pdf>.





Birkholz, et al.         Expires 29 August 2026                [Page 46]

Internet-Draft               Verifiable ACRs               February 2026


   [EU_AI_ACT_2024]
              European Parliament and Council of the European Union,
              "Regulation (EU) 2024/1689 (Artificial Intelligence Act)",
              CELEX: 32024R1689, Official Journal of the European
              Union L 2024/1689, July 2024,
              <https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.

   [EU_CRA_2024]
              European Parliament and Council of the European Union,
              "Regulation (EU) 2024/2847 (Cyber Resilience Act)",
              CELEX: 32024R2847, Official Journal of the European
              Union L 2024/2847, November 2024,
              <https://eur-lex.europa.eu/eli/reg/2024/2847/oj>.

   [EU_NIS2_2022]
              European Parliament and Council of the European Union,
              "Directive (EU) 2022/2555 (NIS 2 Directive)",
              CELEX: 32022L2555, Official Journal of the European
              Union L 333, December 2022.

   [FFIEC_IT_HANDBOOK_2024]
              Federal Financial Institutions Examination Council,
              "Information Technology Examination Handbook", FFIEC IT
              Examination Handbook, August 2024,
              <https://ithandbook.ffiec.gov/>.

   [IANA.cbor-tags]
              IANA, "Concise Binary Object Representation (CBOR) Tags",
              <https://www.iana.org/assignments/cbor-tags>.

   [IANA.core-parameters]
              IANA, "Constrained RESTful Environments (CoRE)
              Parameters",
              <https://www.iana.org/assignments/core-parameters>.

   [IANA.cose_header-parameters]
              IANA, "COSE Header Parameters",
              <https://www.iana.org/assignments/cose>.

   [IANA.cwt] IANA, "CBOR Web Token (CWT) Claims",
              <https://www.iana.org/assignments/cwt>.

   [IANA.jwt] IANA, "JSON Web Token (JWT)",
              <https://www.iana.org/assignments/jwt>.

   [IANA.media-types]
              IANA, "Media Types",
              <https://www.iana.org/assignments/media-types>.



Birkholz, et al.         Expires 29 August 2026                [Page 47]

Internet-Draft               Verifiable ACRs               February 2026


   [ISO_IEC_42001_2023]
              International Organization for Standardization and
              International Electrotechnical Commission, "Information
              technology - Artificial intelligence - Management system",
              ISO/IEC 42001:2023, December 2023,
              <https://www.iso.org/standard/42001>.

   [NIST_AI_100_2_E2025]
              National Institute of Standards and Technology,
              "Adversarial Machine Learning: A Taxonomy and Terminology
              of Attacks and Mitigations", NIST AI 100-2 E2025, March
              2025, <https://csrc.nist.gov/pubs/ai/100/2/e2025/final>.

   [NIST_SP_800_53_R5]
              National Institute of Standards and Technology, "Security
              and Privacy Controls for Information Systems and
              Organizations", NIST Special Publication 800-53, Revision
              5, September 2020,
              <https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final>.

   [OMB_M_21_31]
              Office of Management and Budget, "Improving the Federal
              Government's Investigative and Remediation Capabilities
              Related to Cybersecurity Incidents", OMB
              Memorandum M-21-31, August 2021,
              <https://www.whitehouse.gov/wp-content/uploads/2021/08/
              M-21-31-Improving-the-Federal-Governments-Investigative-
              and-Remediation-Capabilities-Related-to-Cybersecurity-
              Incidents.pdf>.

   [PCI_DSS_V4_0_1]
              PCI Security Standards Council, "Payment Card Industry
              Data Security Standard", PCI DSS Version 4.0.1, June 2024,
              <https://www.pcisecuritystandards.org/document_library/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://doi.org/10.17487/RFC2119>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://doi.org/10.17487/RFC4648>.








Birkholz, et al.         Expires 29 August 2026                [Page 48]

Internet-Draft               Verifiable ACRs               February 2026


   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://doi.org/10.17487/RFC5280>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://doi.org/10.17487/RFC6838>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://doi.org/10.17487/RFC7252>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://doi.org/10.17487/RFC7515>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://doi.org/10.17487/RFC7519>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://doi.org/10.17487/RFC8174>.

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://doi.org/10.17487/RFC8610>.

   [STD90]    Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://doi.org/10.17487/RFC8259>.

   [STD94]    Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://doi.org/10.17487/RFC8949>.

8.2.  Informative References






Birkholz, et al.         Expires 29 August 2026                [Page 49]

Internet-Draft               Verifiable ACRs               February 2026


   [EMERGENT_MISALIGNMENT_2025]
              Betley, J., Tan, D., Warncke, N., Sztyber-Betley, A., Bao,
              X., Soto, M., Labenz, N., and O. Evans, "Emergent
              Misalignment: Narrow finetuning can produce broadly
              misaligned LLMs", PMLR 267:4043-4068, arXiv 2502.17424,
              February 2025, <https://arxiv.org/abs/2502.17424>.

   [I-D.ietf-scitt-architecture]
              Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
              Y., and S. Lasker, "An Architecture for Trustworthy and
              Transparent Digital Supply Chains", Work in Progress,
              Internet-Draft, draft-ietf-scitt-architecture-22, 10
              October 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-scitt-architecture-22>.

   [ISO_IEC_DIS_24970]
              International Organization for Standardization and
              International Electrotechnical Commission, "Artificial
              intelligence - AI system logging", ISO/IEC DIS 24970,
              2025, <https://www.iso.org/standard/88723.html>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <https://doi.org/10.17487/RFC6973>.

   [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
              W. Pan, "Remote ATtestation procedureS (RATS)
              Architecture", RFC 9334, DOI 10.17487/RFC9334, January
              2023, <https://doi.org/10.17487/RFC9334>.

   [STD96]    Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", STD 96, RFC 9052,
              DOI 10.17487/RFC9052, August 2022,
              <https://doi.org/10.17487/RFC9052>.

Acknowledgments

   The authors would like to thank: xor-hardener

Authors' Addresses

   Henk Birkholz
   Email: henk.birkholz@ietf.contact


   Tobias Heldt



Birkholz, et al.         Expires 29 August 2026                [Page 50]

Internet-Draft               Verifiable ACRs               February 2026


   Email: tobias@xor.tech


   Orie Steele
   Email: orie@or13.io














































Birkholz, et al.         Expires 29 August 2026                [Page 51]


