Requirements for Agent Session Establishment, Capability Negotiation, and Sessionless Interaction

Introduction Autonomous agents collaborating across administrative domains require a common understanding of when a session begins, what each side is capable of, and which capabilities and authorizations are in effect for a given operation. They also exchange notifications, probes, and atomic requests for which establishing a session may be unnecessary. Both modes require clear security, state, and authority boundaries. This document states requirements 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 . The DAWN terminology likewise defines capability exchange, negotiation, and selection as out of scope for DAWN . Intent routing 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 revision incorporates feedback received on version -00 regarding authenticated endpoint binding, the interpretation of capability declarations, session lifecycle changes, and the relationship between session establishment and execution authorization.

Scope This document defines requirements for: the establishment of sessions between entities; the negotiation of capabilities for prospective sessions; the authentication of session endpoints; and authorization decisions and changes within established sessions; session lifecycle, state consistency, and cached-state freshness; and interactions that do not establish or rely on a session. 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 an interaction MUST be an agent as defined in Section 3. An interaction between two deterministic systems, neither of which is an agent, is outside the scope of this document. The following are out of scope: discovery of entities (covered by DAWN ); routing of intent or requests between entities (covered by ); the transport protocol over which a session is carried; and any particular authentication, capability negotiation, authorization, or session establishment mechanism. This document is a requirements document, not a solution document. It deliberately does not specify how the requirements are to be met.

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

Agent:: An autonomous software entity capable of perceiving its environment, making decisions, and acting to achieve goals on behalf of a user or another agent.
Entity:: A party to an interaction. An entity MAY be an agent, a deterministic program such as an MCP server, a human, or a system acting on a human's behalf. The term is consistent with its use in the DAWN work .
Interaction:: An exchange between entities. An interaction may take place within an established session or may be sessionless.
Sessionless Interaction:: An interaction, such as a notification, probe, or atomic request, that neither establishes a session nor relies on session state. A sequence of related sessionless messages does not become a session unless the entities explicitly complete session establishment.
Peer:: An entity participating in a prospective or established session. The term does not by itself imply a client/server relationship, equal capabilities, support for both request roles, or a particular transport topology.
Originator:: For a particular request, the peer that originates that request. The role is assigned per request and does not imply that the peer initiated the session or retains the role for later requests.
Handler:: For a particular request, the peer that receives and handles that request. A handler for one request MAY be the originator of another request in the same session.
Capability:: A function, service, or behavior that an entity is able to offer.
Authentication:: The process by which entities establish the identities to which the prospective session will be bound. In this document, the authentication phase includes the declaration and negotiation of authentication requirements as well as the performance of authentication.
Authorization:: A decision by an applicable authority that permits an action or class of actions to be performed within an established session. Authorization is distinct from authentication and from capability negotiation.
Minimum Session Authority:: The authority granted by session establishment that is necessary to participate in session control and the authorization lifecycle. It permits authorization requests and decisions to be exchanged but does not authorize use of a negotiated capability to perform an application operation.
Session:: An association established between two entities for the purpose of collaboration, encompassing the authenticated identities, negotiated capabilities, agreed session parameters, authorization state, and interactions that take place under them.

Interaction Model The requirements in Section 5 are organized around two interaction modes. The model defines no message sequence, credential format, authorization mechanism, or transport protocol, and introduces no normative requirements of its own. ``` Session-Based Interaction Authentication Phase -> Capability Negotiation Phase -> Session Parameter Agreement and State Binding -> Session Establishment -> Continuous Authorization and Operation Sessionless Interaction Self-contained security and state context -> Notification, Probe, or Atomic Request ``` For a session-based interaction, authentication (REQ-1, REQ-3, and REQ-4) is the first phase of session establishment. Each entity declares its authentication requirements and supported forms of authentication. The entities determine whether mutually acceptable authentication is possible and perform the selected authentication. After successful authentication, capability negotiation (REQ-2, REQ-3, and REQ-4) allows the authenticated entities to declare and negotiate capabilities and independently decide whether to accept the result. Successful negotiation establishes agreement on capability declarations; it does not prove continued availability or authorize their use. The entities also agree the parameters needed for subsequent interaction and bind the authenticated identities, negotiation outcomes, and parameters to the same prospective session (REQ-5). The session becomes established only when both entities have accepted it and can determine its completion state (REQ-6). Session initiation does not assign permanent originator or handler roles. An established session begins with minimum session authority (REQ-7). Authorization can then be requested, granted, constrained, denied, adjusted, or revoked throughout the session. Capability changes and other lifecycle events are governed by REQ-8, and cached information by REQ-9. A sessionless interaction (REQ-10) neither establishes a session nor inherits session state. It carries or obtains the security and state context needed for the individual interaction. A sessionless exchange may subsequently lead the entities to establish a session, but that transition is explicit and follows the session-establishment requirements.

Requirements

REQ-1: Authentication Phase and Endpoint Binding Session establishment MUST include an authentication phase in which the entities declare their authentication requirements and supported forms of authentication, determine whether mutually acceptable authentication is possible, and perform the selected authentication. The declaration and negotiation of supported forms of authentication MUST NOT be treated as successful authentication. Each entity MUST determine whether the selected form of authentication satisfies its local authentication policy. The authentication phase MUST NOT be considered successful unless the entities have authenticated each other and the resulting identities are bound to the authentication context agreed during that phase. Rationale: Entities that have not previously interacted may need to determine whether they can satisfy each other's authentication requirements before authentication can be performed. Such negotiation does not itself authenticate either entity or waive a relying entity's current local requirements; this boundary is consistent with . Direct connectivity likewise provides no security property: a logical connection may traverse relays and proxies, and topology alone provides no confidentiality, integrity, or identity guarantees.

REQ-2: Capability Negotiation Phase Following successful authentication, the entities MUST be able to declare their capabilities and requirements, negotiate the capability set applicable to the prospective session, and independently decide whether to establish the session. A session MUST NOT be considered established unless capability negotiation has completed successfully and both entities have accepted the resulting capability set. Capability negotiation MUST be integrity-protected and bound to the authenticated identities established under REQ-1. Where disclosure of capability content creates risk, confidentiality SHOULD be provided. Capability declarations are claims made by the declaring entity. Successful negotiation establishes agreement on compatible declarations; it does not by itself establish capability possession, continued availability, successful execution, or authorization to use a capability. Rationale: Capability negotiation determines the capability scope to which the entities are willing to commit for the session. The relying entity remains responsible for applying its own policy to capability claims and for responding to subsequent changes in availability.

REQ-3: Decision Autonomy Across Phases Each entity MUST retain control over decisions attributed to it during authentication, capability negotiation, and authorization. This includes the selection and acceptance of authentication requirements, capability declarations and negotiation decisions, acceptance of the resulting capability set, and authorization requests and decisions. A decision MAY be informed or made by a user or external authority when permitted by the entity's local policy. Discovery, routing, relay, and other intermediary layers MUST NOT make or substitute for a decision on behalf of an entity unless explicitly authorized to do so. Rationale: Authentication choices, capability declarations, session acceptance, and authorization decisions cross security and autonomy boundaries. An intermediary that substitutes its own decision for that of an entity, without explicit authority, can change the identity, capability scope, or execution authority on which the session relies.

REQ-4: Role Flexibility and Mutual Choice Across Phases The session model MUST NOT assign permanent originator or handler roles solely according to which entity initiated the session. An entity MAY act as an originator, a handler, or both, according to its capabilities and local policy. A peer MUST NOT be required to assume a request role that it has not declared and accepted during capability negotiation. Both entities MUST retain the right to accept or decline proposed authentication forms, capability sets, session conditions, authorization requests, and authorization constraints according to their respective local policies. Either entity MAY propose an alternative during authentication, capability negotiation, or authorization. If the entities cannot agree on acceptable authentication or on the capability set and conditions for the prospective session, the session MUST NOT be established. If they cannot agree on authorization for an operation within an established session, that operation MUST NOT be admitted; the authorization failure does not by itself require the session to terminate. Rationale: Session initiation is an event, not a permanent assignment of client and server roles. This does not require symmetric capabilities: an agent may support both request roles while a deterministic tool supports only the handler role. Where a peer supports both roles, it may originate one request while handling another. Neither peer can unilaterally impose an authentication method, capability commitment, or authorization outcome on the other. The consequence of disagreement depends on its phase: establishment cannot proceed without agreement on authentication and capabilities, whereas disagreement about one operation need not invalidate the entire session.

REQ-5: Session Parameter Agreement and State Binding Before a session is established, the entities MUST agree on the session parameters required for subsequent interaction. These parameters MAY include a communication profile, endpoint information, request-role support, constraints, and other properties needed to use the session. The authentication result, negotiated capability set, agreed session parameters, and peer acceptance decisions MUST be unambiguously bound to the same prospective session and authenticated identities. Authorization decisions, operations, and lifecycle events within an established session MUST likewise be bound to that session and its applicable state. Replayed information or information originating from a different session or establishment attempt MUST NOT be accepted as current session state or be allowed to alter the session. Rationale: Session establishment combines results produced at different stages. Without a common binding, an attacker or implementation error can substitute an endpoint, capability set, acceptance decision, or authorization from another interaction. This requirement states the necessary continuity property without requiring a particular identifier, token, transcript, or replay-protection mechanism.

REQ-6: Establishment Completion and Failure Handling The session model MUST define distinguishable pending, established, failed, and terminated outcomes, or equivalent states. A session MUST NOT be presented as established until both entities have accepted the authentication result, negotiated capability set, and agreed session parameters, and each entity can determine that establishment completed. An incomplete or failed establishment attempt MUST be detectable and MUST be terminable or recoverable. Retries, duplicate messages, delayed messages, or partial failure MUST NOT silently create multiple sessions or cause the entities to rely indefinitely on inconsistent session states. Resources retained for incomplete attempts MUST be bounded and releasable. Rationale: Establishment is a distributed state transition. Message loss, delay, retry, or endpoint failure can otherwise leave one entity treating a session as established while the other treats it as pending or failed. Solutions may use acknowledgments, reliable transports, idempotent state transitions, recovery exchanges, or other mechanisms to satisfy the requirement.

REQ-7: Continuous Authorization Upon session establishment, each entity MUST have the minimum session authority necessary to participate in session control and the authorization lifecycle. This authority MUST include the ability to request authorization and to exchange authorization decisions. It MUST NOT by itself authorize an operation that uses a negotiated capability. Either entity MUST be able to request authorization from the other entity for an operation or class of operations during the session. The entity receiving the request MUST be able to grant, deny, or grant the request subject to constraints, according to its local policy and authority. An authorization decision MAY also depend on a user, an external authority, or previously established authorization information. Authorization MUST be treated as dynamic session state. An authorization decision MAY be introduced, restricted, replaced, or revoked during the session. It MUST identify the scope of operations it covers sufficiently to determine whether an operation is authorized. An operation MUST NOT be admitted unless it is covered by the authorization state applicable when the operation is admitted. Permission to exchange session-control or authorization-related information MUST NOT be interpreted as authorization to perform the requested application operation. A change to authorization state MUST be explicit and MUST NOT silently broaden the authority available within the session. Rationale: Authentication and capability negotiation answer who the entities are and what capabilities they have agreed may be available. They do not answer whether a particular action may be performed. Authorization in an agent session is therefore a continuous process rather than a one-time establishment step. Minimum session authority allows that process to begin, while authority to perform application operations is granted incrementally according to least-privilege principles.

REQ-8: Session Lifecycle Management Session revocation, transfer or delegation of session state, loss of a negotiated capability, declaration of a newly available capability, and proposed changes to the negotiated capability set MUST be expressible and observable by the affected entities. A peer MAY declare a newly available capability during an established session. The capability MUST NOT be treated as part of the negotiated capability set until capability renegotiation has completed successfully and both peers have accepted the change. The session model MUST permit the negotiated capability set to be updated through explicit renegotiation without requiring establishment of a new session. Operations unaffected by the proposed change MAY continue while renegotiation is in progress. If a negotiated capability becomes unavailable, it MUST NOT continue to be presented or used as available while renegotiation is pending. The loss MUST be made observable to the other peer, and operations whose prerequisites are no longer satisfied MUST NOT be admitted. Operations that do not depend on the lost capability MAY continue. An operation outside the currently negotiated capability scope MUST NOT be treated as covered by that negotiation. Any additional capability negotiation and authorization required for the operation MUST complete before the operation is admitted. An operation admitted while capability renegotiation is in progress MUST be evaluated against an identifiable negotiated capability state. A change to capability state MUST NOT retroactively alter the interpretation of an operation that was already admitted. The effect of a capability change on operations already in progress MUST be explicit. A lifecycle event MUST NOT silently broaden authorization, discard an applicable constraint, or present a capability as available for an operation whose prerequisites are no longer satisfied. The authority and inheritance semantics applicable to a transfer, delegation, or state change MUST be explicit before an entity relies on the resulting state. Rationale: Sessions are not static. Capabilities may be added, changed, or become unavailable; authorization may change; and collaboration state may be transferred or delegated. A newly declared capability requires mutual agreement before use, whereas a lost capability cannot remain available while agreement catches up with reality. Neither case inherently requires unrelated work to stop or the session to be replaced. Expressing a transition without making its security-relevant effect observable leaves the peers unable to determine the capability and authorization state on which they may safely rely.

REQ-9: Cached-State Freshness Cached identity, endpoint, authentication, capability, session-parameter, and authorization information MUST have explicit freshness and invalidation semantics appropriate to the information being cached. An entity MUST NOT treat expired or invalidated information as current. Reuse of cached information MUST NOT bypass authentication, capability negotiation, authorization, or local-policy checks that remain applicable to the new interaction. When an entity detects that cached information is inconsistent with current information, it MUST revalidate or stop relying on the cached information before admitting an affected operation. Rationale: Caching can reduce establishment and negotiation cost, but stale identity, endpoint, capability, or authorization information can redirect an interaction or preserve authority that no longer applies. This requirement does not prescribe a time-to-live, version number, hash, or cache structure.

REQ-10: Sessionless Interactions A sessionless interaction MUST be distinguishable from an interaction within an established session. It MUST NOT implicitly acquire minimum session authority, a negotiated capability set, session parameters, or authorization state from an established or prior session. A sessionless interaction MUST carry or reference sufficient context for the receiving entity to determine the interaction's purpose, the authentication assurance provided for its origin, the operation or effect being requested, and the authorization policy that applies. Integrity and confidentiality MUST be provided when required by the risks of the interaction and the receiving entity's local policy. A notification or probe that requests no application operation MAY be accepted without establishing a session according to the receiving entity's local policy. If a sessionless interaction requests an operation that produces a side effect, accesses protected information, or uses a protected capability, the receiving entity MUST perform the applicable authentication and authorization checks before admitting the operation. Duplicate or replayed sessionless messages MUST NOT cause an operation to be admitted more than permitted by the applicable authorization and operation semantics. A response to a sessionless interaction MUST NOT by itself establish a session or confer authority for a subsequent interaction. A sessionless interaction MAY lead to session establishment. Such a transition MUST be explicit and MUST satisfy REQ-1 through REQ-6. Information learned from the sessionless interaction MAY be used as input to establishment, but MUST NOT be treated as authenticated, negotiated, or authorized session state unless the establishment process verifies and accepts it. Rationale: Notifications, probes, and atomic requests may not justify the cost or retained state of a session. Sessionless operation is therefore a first-class interaction mode, not a way to bypass the security and authority boundaries that would apply to the requested effect.

Security Considerations The declaration and negotiation of supported forms of authentication do not authenticate either entity. An attacker may attempt to remove a supported form, introduce a weaker choice, or cause the entities to associate the result with the wrong peer. REQ-1 therefore requires each entity to apply its local authentication policy and requires authenticated identities to be bound to the authentication context agreed during the authentication phase. Capability negotiation is integrity-protected and bound under REQ-2 to the authenticated identities established under REQ-1. Confidentiality is a separate property; where capability disclosure creates risk, the confidentiality requirement of REQ-2 applies. Capability declarations remain claims rather than proof of possession or availability. Each relying entity is responsible for applying its own trust and verification policy to those claims. Session establishment confers only the minimum session authority needed to participate in session control and the authorization lifecycle. It does not confer authority to perform an application operation. REQ-7 requires each admitted operation to be covered by the authorization state applicable at that time and requires authorization changes to be explicit. Where local policy requires human approval, session establishment MUST NOT be presented to the human as having provided that approval. Minimum session authority exposes an authorization-request surface to each authenticated entity. Receiving a request creates no obligation to grant it, and implementations need to bound resource consumption and repeated requests according to local policy. Permission to exchange authorization requests and decisions cannot be used as evidence that the requested operation was authorized. Binding and distributed-state failures can cause information from one establishment attempt or session to be accepted in another, or cause the peers to disagree about whether a session exists. REQ-5 requires the security-relevant inputs and outcomes to be bound to the same session, and REQ-6 requires detectable completion, failure, and cleanup semantics. Implementations also need to prevent replay, duplication, and retry from creating unintended state or unbounded pending resources. Session lifecycle events can otherwise be used to bypass constraints or create inconsistent views of capability and authorization state. A newly declared capability can be used prematurely if declaration is confused with completed renegotiation, while a lost capability can remain falsely available if withdrawal is delayed. REQ-8 therefore requires affected peers to observe the security-relevant effect of revocation, transfer, delegation, capability addition or loss, and state changes before relying on the resulting state. Cached information creates a separate stale-state risk across interactions. An expired endpoint can redirect communication, a stale capability can misrepresent what is available, and stale authorization can preserve authority after revocation. REQ-9 requires explicit freshness, invalidation, and revalidation semantics without prescribing a cache mechanism. Sessionless interactions do not benefit from retained authenticated, negotiated, or authorization state. A receiver therefore cannot infer security properties merely because a message resembles one previously accepted or refers to a known entity. REQ-10 requires each sessionless interaction to provide sufficient context for the applicable policy and prevents notifications, probes, replies, duplicates, or replays from silently creating a session or execution authority. A compromised discovery or routing layer may redirect, delay, suppress, or observe connection attempts. The authenticated endpoint binding and authorization boundary in this document are intended to ensure that such a compromise alone does not authenticate an endpoint, alter the negotiated capability set without detection, or confer execution authority.

IANA Considerations This document has no IANA actions.

Acknowledgments Thanks to Iman Schrock for identifying the security gap in the "direct connection" framing and proposing authenticated endpoint binding; to Sumit P. Ahuja for identifying the inheritance ambiguity in session transfer; to Bradley B for tightening the authority boundary on conditions carried across transfer; to Mikhail Sergeev for clarifying that negotiation establishes compatibility of declared capabilities rather than capability presence; and to Guigui Wang for the verifiability requirement on authorization binding.