| Internet-Draft | Agent Session Requirements | August 2026 |
| Feng | Expires 16 February 2027 | [Page] |
This document defines requirements for the establishment of sessions between entities and for the negotiation of capabilities within such sessions. It is assumed that the entities involved already know of each other; how they came to know each other is outside the scope of this document. At least one party to a session is an agent as defined in Section 3. This document is intended as a contribution to the agentproto working group's use cases, gap analysis, and requirements deliverable.¶
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 February 2027.¶
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.¶
Autonomous agents collaborating across administrative domains require a common understanding of when a session begins, what each side is capable of, and which capabilities are in effect for a given interaction. This document states requirements for session establishment and capability negotiation that follow from these needs.¶
Session establishment is orthogonal to peer location. Two entities may come to know of each other through intent routing, through directory-based discovery, or because one side cached the other's information from a previous session. In all cases, the same session establishment flow applies. This document therefore assumes that the entities already know of each other and does not presuppose any particular locating mechanism.¶
The need for this document follows from gaps stated by adjacent work. The DAWN problem statement explicitly places the exchange that follows discovery outside its scope: "after discovery, an interview-style exchange may be conducted using the communication method indicated by the entity — outside the scope of DAWN" [I-D.akhavain-moussa-dawn-problem-statement]. The DAWN terminology likewise defines capability exchange, negotiation, and selection as out of scope for DAWN [I-D.farrel-dawn-terminology]. Intent routing [I-D.feng-dmsc-intent-routing-requirements] addresses how a request reaches an entity, not what happens once it does. Session establishment and capability negotiation, the subject of this document, fall between these efforts.¶
This document defines requirements for:¶
It is assumed that the entities involved already know of each other. How they came to know each other — whether through intent routing, directory-based discovery, information cached from a prior session, or any other mechanism — is outside the scope of this document and does not affect the requirements stated herein.¶
At least one party to a session MUST be an agent as defined in Section 3. A session between two deterministic systems, neither of which is an agent, is outside the scope of this document.¶
The following are out of scope:¶
This document is a requirements document, not a solution document. It deliberately does not specify how the requirements are to be met.¶
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.¶
Capability negotiation MUST be completed before the session is considered established. A session MUST NOT be presented as usable for collaboration unless capability negotiation has succeeded.¶
Rationale: An originator cannot meaningfully commit to a session if it does not know whether the handler can satisfy the intended action. Negotiation is a precondition of the session, not a detail of it.¶
Capability declaration and negotiation MUST be decided by the entities that hold them. Discovery and routing layers MUST NOT make or substitute for capability decisions on behalf of either entity.¶
Rationale: Capability is a property of the entity. Any party that does not hold the capability cannot truthfully declare it, and any intermediate layer that preselects on capability inserts itself into an autonomy boundary it does not own.¶
Once a direct connection between the two entities is established, capability negotiation MUST take place over that connection and MUST NOT traverse any intermediate intent routing or discovery layer.¶
Rationale: Negotiation content is private to the session entities. Routing layers are involved only in getting the entities to each other; once they are connected, the negotiation proceeds directly between them. An implementation in which negotiation traverses an intermediate layer violates this requirement.¶
Both entities MUST retain selection rights. The originator selects the handler it wishes to engage, and the handler MAY choose to connect to the originator actively, to respond passively, or to decline.¶
Rationale: Selection is not one-directional. A handler is an autonomous party with its own interests and constraints; its choice of whether and how to engage is part of the negotiation, not an outcome imposed by the originator.¶
Successful session establishment MUST NOT be presented as authorization to execute the requested action. Execution authorization is a separate decision that MUST be made explicitly.¶
Rationale: Routing and session establishment answer "can these entities talk to each other"; they do not answer "may this action be performed". Conflating the two creates a security boundary violation, particularly when a routing layer is involved in getting the entities together.¶
Session revocation, transfer of session ownership, and the termination of negotiated capabilities MUST be expressible explicitly by either entity.¶
Rationale: Sessions are not static. A handler may lose a capability, an originator may need to transfer a session to another entity, and either side may revoke. A session model that cannot express these transitions cannot be managed safely.¶
The security properties of this document follow from REQ-3 and REQ-5. Because negotiation occurs over the direct connection (REQ-3), intermediate layers have no opportunity to observe or tamper with capability content. Because session establishment does not confer execution authority (REQ-5), the blast radius of a compromised routing or discovery layer is limited to connection establishment, not to the actions performed within the session.¶
Entities SHOULD authenticate each other before engaging in capability negotiation. Capability declarations are claims made by the declaring entity and are subject to its own trust and verification policies. Where one entity is a human, execution authorization is ultimately a human decision; session establishment must not be presented to the human as having authorized execution.¶
This document has no IANA actions.¶