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. A session is a bilateral association between authenticated peers. A peer's coordination of application work with a third party does not change the peers or state of the existing session and does not, by itself, confer authority established within that session. Interaction with a different entity can use either a newly established session or a sessionless interaction, as appropriate. The different entity becomes a peer only of a new session that it participates in establishing, while resumption of the existing logical session is limited to the same authenticated entities. Application-level task handoff, cross-entity responsibility transfer, and operational audit coordination are separate concerns from the base session abstraction.

Scope This document defines requirements for: transport-independent interaction binding and connection mapping; the establishment of sessions between entities; the negotiation of capabilities for prospective sessions; the authentication of session endpoints; 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. The following are out of scope: interactions in which neither party is an agent as defined in Section 3; how entities come to know of or locate one another, including entity discovery (covered by DAWN ), intent routing (covered by ), information cached from a prior interaction, or any other locating mechanism; the selection or definition of a particular transport protocol; any particular authentication, capability negotiation, authorization, or session establishment mechanism; protocols for coordinating delegation or handoff of application tasks to entities that are not peers of the session; semantics for transferring application responsibility between different entities; and operational management, audit, and durable evidence mechanisms used to reconstruct or assess application-layer actions. Although selection or definition of a particular transport protocol is out of scope, REQ-1 specifies the transport-independent properties that a binding to an underlying communication substrate must preserve. The last three topics may benefit from separate standardization. In particular, another requirements document could define application-level delegation, task handoff, accountability, and audit properties without making them part of the base session abstraction. A separate specification or profile may require conforming implementations to produce, bind, retain, or expose evidence when a session decision is made so that the decision can be independently evaluated later. Such requirements are not part of base session conformance unless that specification or profile is explicitly used. 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.
Transport Connection:: A communication association provided by an underlying transport or communication substrate. A transport connection is not a session and does not, by itself, establish authenticated peer identity, negotiated capability state, or authorization state.
Transport Binding:: The mapping by which session-based or sessionless interactions are carried over an underlying communication substrate. A transport binding may use one or more transport connections and does not imply a particular transport protocol.
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.
Third-Party Delegation:: An application-layer decision by which a peer uses another entity to perform part of its work. The other entity is not thereby made a peer of the existing session, and the delegating peer remains responsible for its obligations in that session.
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.
Capability Card:: A structured description of an entity's capabilities, as defined in the DAWN work . A capability card is a container; its content representation is not specified by DAWN.
Capability Description Language (CDL):: A machine-readable language defined by the AIN architecture for describing the capabilities contained in a capability card. CDL is one possible representation and is not required by this document.
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.
Session Resumption:: Continuation of a logical session by the same authenticated peer entities after a connection, endpoint, or runtime-instance change. Resumption does not permit a different entity to replace a peer.

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. REQ-1 defines the common transport-binding foundation for both interaction modes. It is a cross-cutting requirement rather than a phase of session establishment; authentication remains the first session-establishment phase. A session is bilateral. If a peer uses another entity to perform part of an application task, that coordination occurs outside the session and does not add the other entity as a peer. Direct interaction between an existing peer and that other entity uses a separate session or a sessionless interaction, as appropriate. The two interaction modes are summarized below.

For a session-based interaction, authentication (REQ-2, REQ-4, and REQ-5) 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-3, REQ-4, and REQ-5) 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-6). The session becomes established only when both entities have accepted it and can determine its completion state (REQ-7). Session initiation does not assign permanent originator or handler roles. An established session begins with minimum session authority (REQ-8). Authorization can then be requested, granted, constrained, denied, adjusted, or revoked throughout the session. Capability changes and other lifecycle events are governed by REQ-9, and cached information by REQ-10. A sessionless interaction (REQ-11) 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: Transport Independence and Interaction Binding The interaction model MUST NOT depend on a particular transport protocol. A transport binding MUST define how session-based and sessionless messages are carried and which delivery, ordering, security, and failure properties are provided by the underlying communication substrate or by the binding itself. The existence or state of a session MUST NOT be inferred solely from the existence or state of a transport connection. Opening a transport connection MUST NOT by itself establish a session, and connection loss or replacement MUST NOT by itself establish, resume, or successfully terminate a session. A sessionless interaction MUST NOT acquire session state merely because it uses a connection that also carries an established session. The interaction model MUST NOT assume a one-to-one relationship between sessions and transport connections. It MUST permit transport bindings in which multiple sessions share a connection and bindings in which the same logical session uses successive connections, provided the binding preserves session isolation and satisfies the continuity requirements of REQ-6 and REQ-9. A particular transport binding or deployment MAY support only a subset of these mappings, but that limitation MUST be explicit and MUST NOT change the semantics of the affected sessions. Each message and state transition MUST be unambiguously associated with the applicable session or identified as sessionless. Multiplexing multiple interactions over a shared connection MUST NOT allow authenticated identity, negotiated capability state, session parameters, authorization state, or lifecycle events from one session to be accepted as state of another. The transport binding and any protection supplied by the interaction layer MUST collectively provide the confidentiality, integrity, authenticated peer binding, and replay protection required by the applicable interaction. Security properties supplied by an underlying transport MUST NOT be assumed to apply to an entity, session, or message unless they are unambiguously bound to that object. To the extent that loss, duplication, reordering, delay, partial delivery, or connection failure is not handled by the underlying substrate, the transport binding or interaction protocol MUST define how the condition is detected and handled. Such conditions MUST NOT silently create a session, duplicate an admitted operation, or cause state from one interaction to be accepted in another. Rationale: A transport connection is a delivery mechanism, whereas a session is an association between authenticated entities with negotiated and authorized state. Treating them as the same object prevents safe multiplexing and resumption and can cause a connection event to change session state without peer agreement. This requirement specifies the properties that the mapping must preserve without selecting TCP, QUIC, HTTP, WebTransport, or any other transport or application substrate.

REQ-2: 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-3: 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-2. 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. An entity MAY express its capability declarations and requirements in a capability card. When a capability card is used for negotiation, its content needs to be sufficiently precise and machine-readable for the entities to determine compatibility and identify the negotiated capability set. CDL is one language that can be used to define that content; this document does not require CDL or any particular capability card format. 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-4: 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-5: 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-6: 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-7: 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-8: 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-9: Session Lifecycle and Peer Continuity Session revocation, loss of a negotiated capability, declaration of a newly available capability, proposed changes to the negotiated capability set, and resumption by the same authenticated entities MUST be expressible and observable by the affected peers. A peer's delegation of application work to a third party MUST NOT make that third party a peer of the existing session and MUST NOT transfer the session to that third party. Delegation of application work MUST NOT, by itself, be interpreted as conferring on the third party any authority granted within the session. The delegating peer remains responsible for satisfying the authorization state and constraints applicable to its participation in the session. How that peer coordinates with or manages the third party is an application-layer matter outside the scope of this document. A different entity MUST NOT replace an authenticated peer within an existing session. If an existing peer is to interact directly with a different entity, those entities MUST establish a new session in accordance with REQ-1 through REQ-7, or use a sessionless interaction satisfying REQ-11. Context learned from another interaction MAY be provided as input, but authentication results, negotiated capabilities, session parameters, and authorization state from the existing session MUST NOT be treated as state of the new interaction unless independently verified and accepted under the requirements applicable to that interaction. Evidence that authority has been separately delegated or derived MAY be considered as an input to an authorization decision in another interaction. Such consideration does not transfer peer status or session state and does not bypass the authentication, capability negotiation, session establishment, or authorization requirements applicable to that interaction. A logical session MAY survive a change of transport connection, endpoint, or runtime instance only when each peer can verify that the resumed session remains bound to the same authenticated entities and applicable session state. If continuity of either authenticated peer identity or the applicable state cannot be established, a new session MUST be established. 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 effect of a state change on applicable authorization and constraints MUST be explicit before a peer relies on the resulting state. Rationale: Sessions are not static. Capabilities may be added, changed, or become unavailable; authorization may change; and connections, endpoints, or runtime instances may change while the authenticated peer entities remain the same. 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. A different entity, however, has not participated in the authentication, capability negotiation, parameter agreement, or authorization decisions of the existing session and therefore cannot become a peer by delegation or state transfer. 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-10: 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-11: 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-7. 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 Confusing a transport connection with a session can allow connection reuse, reconnection, or multiplexing to cross authentication and authorization boundaries. REQ-1 therefore requires each message and state transition to be associated with the applicable session or identified as sessionless, and requires security properties supplied by a transport to be bound to the entity, session, or message that relies on them. Connection establishment, loss, or replacement cannot by itself establish, resume, or successfully terminate a session. 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-2 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-3 to the authenticated identities established under REQ-2. Confidentiality is a separate property; where capability disclosure creates risk, the confidentiality requirement of REQ-3 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-8 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-6 requires the security-relevant inputs and outcomes to be bound to the same session, and REQ-7 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. A third party can also be incorrectly treated as having inherited peer status or authority that was established only between the authenticated peers. REQ-9 therefore requires affected peers to observe the security-relevant effect of revocation, capability addition or loss, resumption, and state changes before relying on the resulting state, and prohibits delegation from changing the peers or being treated, by itself, as transferring session authority. Application-level delegation may introduce separate confidentiality, authorization, accountability, and audit obligations for the delegating peer. Those obligations are governed by the peer's applicable policy and the constraints of the existing session; they do not create a protocol relationship between the other peer and the third party. Standardized task-handoff records, delegation chains, and durable audit evidence may be useful, but are outside the scope of these session requirements. A determinability or audit profile can require evidence to be produced or bound while a session decision is made, because later processing cannot reconstruct a fact that was never made available or durably bound. Such a profile can impose additional conformance requirements without making participant-independent retrospective determination a requirement of every base session implementation. 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-10 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-11 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.

Change Log

Changes from -01 to -02 Added a common transport-independence and interaction-binding requirement as REQ-1, and renumbered the previous REQ-1 through REQ-10 as REQ-2 through REQ-11. Clarified that a transport connection is distinct from a session, that session state is not inferred from connection state, and that transport bindings preserve interaction isolation, security properties, and failure semantics without selecting a particular transport protocol. Clarified that a session is a bilateral association and that coordinating application work with a third party does not add or replace a session peer. Replaced the ambiguous transfer or delegation of session state with an explicit peer-continuity model: a different entity requires a new session, while session resumption is limited to the same authenticated entities. Clarified that delegation of application work does not, by itself, transfer authority established within a session. Evidence of separately delegated or derived authority may nevertheless be considered by the authorization policy applicable to another interaction. Defined Third-Party Delegation and Session Resumption, and renamed REQ-9 to Session Lifecycle and Peer Continuity. Clarified that protocols for task handoff, cross-entity responsibility transfer, operational audit, and participant-independent retrospective determination are outside the base session requirements. Clarified that a separate determinability or audit profile may impose evidence-generation and retention requirements at decision time without making those requirements part of base session conformance.

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 and Bradley B for discussions that helped clarify the boundary between bilateral session state and application-layer delegation; to Douglas Wadkins for clarifying the distinction between session peer continuity and authorization provenance; 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.