| Internet-Draft | Agent-Human Interaction | November 2026 |
| Okutomi | Expires 5 May 2027 | [Page] |
This design note proposes an overlay for Human and Agent participation in existing Task and Action protocols. It separates the responsible Participant from the authenticated Actor, records Human interactions, excludes Humans from Agent discovery, and binds each change to its authorized request. It specifies no wire protocol and does not treat Humans as Agents.¶
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 May 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.¶
A long-running task can pass from Agent A through Human B to Agent C in another administrative domain. The receiving system needs to check which task and Assignment continue, which conditions still apply, and who is authorized to send the next operation. A local Human interface alone cannot establish those facts for the receiver.¶
Humans may reply later or more than once, correct a response, delegate work, or become unreachable. Treating this as one Agent call or Task state obscures responsibility, response history, and privacy boundaries. The consultation example in Section 3.1 illustrates these concerns across hospitals.¶
This document proposes an optional overlay for exchanges across administrative domains. It does not standardize a local Human interface, contact-delivery service, or complete workflow engine. It remains an individual discussion document; it does not imply adoption by an IETF working group.¶
An implementation selects existing Task and, when needed, Action protocols. A binding identifies their extension points and the security mechanism used to accept operations. Grant issuance, token exchange, and authorization delegation remain with that mechanism. The table lists reusable concepts.¶
| Specification | Reused concepts |
|---|---|
| A2A 1.0 [A2A] | Task, Message, Task state, and Agent Card |
| MCP 2026-07-28 [MCP-TOOLS] | Tool discovery, Tool calls, and input-required results |
| WS-HumanTask 1.1 [WS-HUMANTASK] | People assignment, ownership, delegation, and Human Task handling |
| ROS 2 Actions [ROS2-ACTIONS] | Accepted, executing, canceling, and terminal execution states |
| W3C PROV-DM [PROV-DM] | Association, role, delegation, and provenance (history and origin) |
These specifications retain their wire formats and full state machines. Although PROV-DM uses Agent broadly enough to include a person, this document keeps Human and Agent as separate entity classes.¶
Human or Agent -- holds ----> Participant role Assignment ----- links ----> Participant and Task Interaction Event records -> interaction history Action ---------- runs -----> under an accepted Assignment Agent ----------- calls ----> Tool Actor ----------- sends ----> operation
A natural person who can accept responsibility.¶
An automated entity that can accept responsibility, run an Action, or act for a Human when its authority has been verified.¶
A callable function or resource. A Tool cannot accept an Assignment; a service with continuing responsibility is an Agent.¶
A responsibility role held by a Human or Agent, not a fourth entity class.¶
The authenticated sender of an operation, which may differ from the Participant.¶
The continuing responsibility link between a Participant and a Task. This role does not by itself determine legal liability or professional duties.¶
A recorded question, response, correction, or withdrawal.¶
An execution governed by the selected protocol and linked to an accepted Assignment.¶
An LLM may be a Tool or part of an Agent, but is not a responsibility class.¶
In the A-to-B-to-C example, B can hold an Assignment while B's gateway is the authenticated Actor. Replacing that gateway or renewing its credentials does not transfer B's responsibility. A receiver in C's domain checks the authenticated parent Task and Assignment references and the authority for the next operation under its own policy. A correlation identifier alone proves neither delegation nor continuity.¶
An Agent at Hospital A sends consultation questions and material snapshot v7 to a specialist at Hospital B. The specialist requests additional information, then returns a response stating its conditions and identifying the snapshot and additional information reviewed. Hospital A's Agent routes it to the treating clinician.¶
Before using the response, Hospital A receives a new result and prepares snapshot v8. Its Agent keeps the response linked to the reviewed materials. The clinical workflow checks whether the change affects the stated conditions and seeks clarification if the response does not cover the changed information. A new snapshot does not by itself invalidate an earlier response. Corrections remain linked to the original response, as described in Section 4.3.¶
The specialist accepts an Assignment to provide the consultation response. The treating clinician at Hospital A remains responsible for the next clinical step. Recording the response does not authorize treatment or transfer that responsibility. Being the patient or consenting to data sharing does not itself create an Assignment. Patient permission to share information is separate from a clinical decision and from the Actor's authority to send an operation.¶
The specialist's gateway may be the Actor; Section 6 describes the evidence needed when an operation requires the Human's approval. The reviewed materials can remain in clinical systems under their access controls, with references and integrity bindings carried by the overlay.¶
FHIR R5 ServiceRequest [FHIR-R5-SERVICEREQUEST] can represent the consultation request, and FHIR R5 Task [FHIR-R5-TASK] can track its fulfillment. A concrete FHIR binding remains to be specified and tested. The example provides no evidence of diagnostic accuracy or clinical safety.¶
Execution state belongs to the selected Task or Action protocol, not the Assignment. A slow Human response alone is not an Assignment or Action failure. Action success does not automatically fulfill an Assignment, and release or revocation does not automatically cancel an Action.¶
For uncertain execution, WAITING means the resume condition is known, INDETERMINATE that an external effect is unknown, and ORPHANED that the executor is lost. A timeout alone is not failure, and lease expiry is not cancellation. If a timeout may hide an external effect, retry waits for reconciliation to establish the outcome or rule out a duplicate effect. The selected protocol defines the concrete states and events.¶
A WAITING Action retains its resume condition across restarts. A timer or probe permits another check; it does not satisfy the condition, nor does moving the Action to PAUSED. PAUSED requires a confirmed stop, not merely a request or lost response. RESUME and TAKEOVER require fresh authorization and a new lease generation; the system applying the effect rejects older generations. Uncertain execution remains INDETERMINATE pending reconciliation. If the executor is lost during cancellation, recovery continues cancellation or reconciliation.¶
Task deadlines and waiting conditions are separate from credential validity, channel lifetime, and executor leases. A long Human wait does not extend a grant. After credentials or a channel expire, a new operation needs current authorization and a new authenticated binding to the retained Task and Assignment state. Renewal does not silently reset a deadline or remove an existing condition.¶
Physical Effects (Non-Normative). In semiconductor fabrication, Action completion alone proves neither a physical effect nor product quality. A correction to a running operation is separately bound and cannot rewrite an earlier request or effect. Domain records may support reconciliation. SEMI E40 [SEMI-E40] covers processing management, while SEMI E157 [SEMI-E157] covers process tracking. These are background references, with no conformance claim.¶
Delegating an accepted Assignment creates an OFFERED child while the parent remains ACCEPTED. The parent event, child offer, and immutable delegation record are stored together in the receiver's authoritative local records; if any fails, none is stored. The protocol binding defines delivery, acceptance, and retry across administrative domains. The binding's authorization mechanism verifies that the child's authority is within the parent's, and the system checks that decision against both authority digests. Delegation is not a Task dependency.¶
Interaction Events are immutable and do not change Assignments. Multiple RESPONSE events may point to one QUESTION through in_reply_to. CORRECTION and WITHDRAWAL point through supersedes to the author's earlier RESPONSE or CORRECTION, which remains stored.¶
A RESPONSE or CORRECTION may be INTERIM or FINAL. FINAL expresses only the author's intent; it does not close the interaction, fulfill an Assignment, or complete an Action. content_ref locates the content, content_digest identifies its bytes, and each complete event identifies both Participant and Actor.¶
A response that may guide a later operation identifies its question, Task, Assignment, and author. It binds the reviewed material references to their versions and integrity values, and records the response's scope, stated conditions, and any validity period. The protocol binding specifies how these fields are represented and which receiver-side authority can assess applicability.¶
Before using a response, the receiver records an assessment against the current materials and the proposed operation. The assessment distinguishes applicable, not applicable, and unresolved. These are semantic outcomes, not required wire values. A change of scope or relevant material calls for another assessment; a new version does not by itself invalidate an earlier response. Missing required clarification or domain assessment leaves the result unresolved.¶
A decision to use a response identifies the exact selected event, the current material references and integrity values, and the stated conditions assessed. A withdrawn or superseded event cannot be selected as the current response. A CORRECTION or WITHDRAWAL preserves the earlier events but does not silently reactivate a superseded response. Competing corrections without a resolved successor are reported as unresolved. The receiver checks this history again before the dependent operation proceeds.¶
Accepting an Interaction Event records the exchange; it does not establish applicability or execution authority. A successful applicability assessment does not complete an Assignment or Action. A dependent operation still requires current authorization under Section 6.¶
| Outcome | Meaning for the dependent operation |
|---|---|
| Event rejected | The append did not commit. Its claimed response is not accepted interaction history. |
| Not applicable | The selected response does not cover the proposed use. It cannot support that operation. |
| Unresolved | Required evidence, clarification, or correction resolution is missing. The response cannot yet support the operation. |
| Applicable | The selected response covers the assessed use. Authorization and execution outcomes remain separate checks. |
This is an optional reachability extension. An exchange that already identifies its Participants does not need Human discovery or a relay. The following rules describe disclosure boundaries; they do not select a user interface or contact-delivery protocol.¶
Humans are excluded from Agent search. Human discovery uses a separate opt-in process, and peer-supplied data cannot reclassify a Human as an Agent.¶
Consent is limited to a Human-requester pair, purpose, capability, channel, and period. Search returns a pairwise opaque candidate ID, capability and channel metadata, a contact-request reference, and an expiry. It reveals no Participant ID, consent proof, or direct contact.¶
After separate Human approval, a reachability grant supplies a purpose-limited HTTPS relay-session reference, not a direct contact. Consent and grants are revocable, and current Participant status is checked on use.¶
The protocol binding selects how the receiver obtains a trusted Participant record and an authenticated Actor. In the ASB implementation, the registry supplies the responsible ACTIVE HUMAN Participant, and verified grant and channel-proof data supply the Actor. The receiver binds both identities and all decision-relevant fields to the request digest and accepted channel instance. The verifier-side acceptance profile in [I-D.okutomi-session-bound-agent-identity] is one possible security binding.¶
Acceptance of a gateway Actor does not prove that the Human held a key, saw a prompt, or approved its exact contents. If the operation requires that evidence, the protocol binding identifies its issuer, verification rule, and binding to the exact operation. A registry entry or gateway statement alone does not provide it.¶
If a required policy returns Permit, Deny, Indeterminate, or NotApplicable, only Permit with evidence bound to the exact operation can authorize the change. Deny rejects the request. Indeterminate reports missing information or evaluation failure; NotApplicable means the policy does not apply. These policy outcomes are distinct from Human responses, response applicability, and execution results. This overlay specifies no wire encoding for them.¶
Trusted Actor identity, Human kind and status, any channel-binding facts required by the selected security binding, Store state, and replay results come from receiver-side sources, not caller assertions. Before a new mutation commits, the receiver checks expiry, revocation, replay, revision, and duplicate event IDs.¶
Expired credentials or proofs cannot authorize a new operation under the selected security binding. Their expiry does not itself stop an accepted Action or alter an Assignment. If a transport timeout leaves the result unknown, the caller uses a new authenticated binding to query the operation record. A retry keeps the same logical event ID and canonical request digest, with fresh authentication under the selected binding. For ASB, this requires a fresh proof and nonce. Authentication-attempt identifiers remain separate from the logical event ID. A reused event ID with a different digest is rejected.¶
A binding that supports result recovery defines how the receiver authorizes lookup, locates a committed result before applying revision checks for a new mutation, and distinguishes a committed operation from one that is absent or still unresolved. An absent record is not by itself permission to repeat a non-idempotent effect. The binding specifies how to establish that retry is safe, including any required reconciliation. A replay reservation alone cannot establish that fact. Returning a stored result does not reuse the old authorization or execute the operation again.¶
The response distinguishes verification acceptance, a committed coordination change, and an execution outcome. Recording a cancellation request does not prove that execution stopped.¶
Pause, resume, cancel, takeover, and execution-changing corrections are new operations. Each uses a new event ID, an exact request digest, and fresh authentication under the selected binding.¶
The overlay and the ASB repository profiles do not by themselves establish interoperability with A2A, MCP, or another Task protocol. A concrete binding needs to fix the following items. Unsupported operations and state mappings are reported explicitly rather than inferred from similar names.¶
| Item | What the binding specifies |
|---|---|
| Identity and continuity | Task, Assignment, Participant, and Actor namespaces; authenticated sources; parent references; current-policy checks on reconnection and handoff. |
| Operation encoding | Profile version, supported operations, field order and encoding, absent values, unknown-field handling, and exact digest inputs. Revision, target, conditions, and effect-changing parameters are covered when they affect the operation. |
| Response applicability | When a response guides an operation, its binding to the question and reviewed materials, scope, conditions, validity period, and assessing authority. The binding fixes the decision point, history and material revisions used, handling of concurrent corrections or withdrawals, and cross-domain freshness limits. |
| Retry and results | Logical event identity, request equivalence, fresh authentication attempts, authorized result lookup, retention, and committed, absent, or unresolved responses. |
| State and effects | Mapping to the selected Task and Action states without equating waiting, lost executors, or unknown effects with failure. Supported takeover and reconciliation operations identify the evidence and enforcement point. |
| Commit boundary | Which records become visible together, revision-conflict handling, duplicate suppression, and when success is acknowledged. Local storage commits do not establish atomicity with an external effect. |
Conformance examples include a constrained successful result, a changed request under the same event ID, a lost response after commit, continuation with expired authority, and a gateway claim without required Human approval evidence. A response-applicability example also identifies when changed materials require clarification, as in Section 3.1. These examples identify expected outcomes; they are not claims that the current implementation passes them.¶
A Task dependency means waiting for another Task; delegation is not one. A binding may reuse ALL, ANY, or QUORUM conditions from an existing workflow model. To avoid false positives, it reports no deadlock while a target is unknown or external progress, such as a timer, signal, or Human response, remains possible.¶
If dependency state crosses an administrative boundary, the binding identifies who may report satisfaction and what evidence the receiver checks. A peer-provided satisfied flag or a locally observed lack of progress does not establish a globally satisfied dependency or global deadlock.¶
This section is to be removed before publishing as an RFC.¶
This section follows [RFC7942] and describes ASB main commit ba477dd8, inspected on 1 November 2026. Release qualification and independent interoperability were not assessed.¶
ASB includes Participants, Assignments, Interaction Events, dependencies, Human matching and reachability, JSON Schemas, and in-memory and SQLite Stores. The Human HTTP ingress exposes four mutation request kinds and, with a transactional Store, a separately authenticated OPERATION_RECOVER request. The implementation still has an AUTOMATED_SERVICE Participant kind, so it does not fully match the proposed Human-Agent-Tool model.¶
The in-process Action APIs model waiting, takeover, and reconciliation. The SQLite adapter atomically rechecks the current ACCEPTED Assignment before execution start, resume, takeover, and lease renewal. External execution and physical effects remain outside that transaction.¶
SQLite commits replay use, the mutation, an outbox entry, and the first response in one transaction. An authorized execute retry for a committed event returns HTTP 409. Recovery uses a separate request with the same Human Participant, gateway Actor, and original request digest; it does not re-execute the mutation. Ingress rechecks proof expiry immediately before its transaction callback returns; failure rolls back the writes. An arbitrary nontransactional Store cannot make the final expiry check and write atomic and does not support recovery. The SQLite adapter is limited to one host. These checks do not establish exactly-once external effects.¶
The Human delegation adapter reports Permit, Deny, Indeterminate, or NotApplicable. Only Permit with matching verified delegation evidence can advance the Assignment.¶
The Python prototype in examples/medical_consultation, added on 18 September 2026, explores the consultation flow and Section 4.4 with synthetic authorization, domain assessments, and in-memory state. Local tests cover contract checks and SDK approval, serialization, and resumption using a scripted model. The SDK mapping is documented separately. The prototype has no live ASB or FHIR connection and provides no clinical safety or interoperability evidence.¶
The repository is available at https://github.com/ToppyMicroServices/agents-secure-binding.¶
| Layer | Implemented values | Availability |
|---|---|---|
| Participant registry status | ACTIVE, SUSPENDED, REVOKED | Inspected checkout |
| Assignment responsibility state | OFFERED, ACCEPTED, DECLINED, RELEASED, REVOKED, FULFILLED | Inspected checkout |
| Action execution state | ACCEPTED, RUNNING, WAITING, PAUSED, ORPHANED, CANCELING, INDETERMINATE, SUCCEEDED, FAILED, CANCELED | Development code |
| Reconciliation status | "REQUIRED", "RUNNING", "RESOLVED" | Development code |
| Reconciliation result | NO_EFFECT, SUCCEEDED, FAILED, CANCELED | Development code |
| Outcome status | SUCCEEDED, FAILED, CANCELED | Development code |
The repository has no separate Task state machine; the selected Task protocol supplies it. QUESTION, RESPONSE, CORRECTION, and WITHDRAWAL are event kinds, while INTERIM and FINAL are response assertions. These are not states. A Tool receives no Assignment and therefore has no Assignment state.¶
Network input is not itself a trusted operation. The receiver derives the Actor from its selected security binding, Participant status from a trusted registry, and revision from the Store. For the ASB binding, channel facts come from the accepted connection. Before a new mutation commits, the application checks request binding, expiry, revocation, replay, and revision; any failure rejects the mutation. Reverse-proxy headers cannot replace trusted TLS termination. Access to an earlier result is separately authorized and does not transfer the earlier Actor's authority.¶
Participant, interaction, dependency, and contact records can reveal who is involved, availability, communications, and work structure. Human matching limits disclosure through pairwise candidate IDs and relay references rather than direct contacts.¶
The repository's in-memory example is not an encrypted contact store and provides no production relay, abuse prevention, or retention controls. Deployments keep direct contacts outside the coordination package and normal logs, and enforce consent, revocation, and retention at the relay.¶
Public contact data does not grant permission for indexing or automated use.¶
This document requests no IANA actions.¶