Agent Communication Protocols S. Bu Internet-Draft 18 July 2026 Intended status: Informational Expires: 19 January 2027 Security Principal and Verifier Binding for Agent Communication Protocols draft-bu-agentproto-security-principal-binding-03 Abstract Agent communication protocols often carry claims about user authority, agent instance identity, tool or external-resource identity, delegation state, session continuity, and action evidence. These claims have different verifiers, freshness requirements, failure modes, and security consequences. If they are collapsed into a single token, identity label, session identifier, or audit record, protocol text can accidentally imply more authority or accountability than the receiver can actually verify. This document defines a verifier-facing model for separating those claims. It provides a reusable matrix format that protocol authors can use to state, for each security-relevant claim, which field carries it, which party verifies it, what binding or freshness rule applies, what failure behavior is required when the claim is absent, stale, inconsistent, or not verifiable, and what constrained result an application may consume after successful verification. It also separates specification status, implementation status, and evidence type so that reviewers can distinguish current protocol text, implementation evidence, inherited mechanisms, and architectural assumptions. The document is protocol-neutral. It is intended to help compare candidate agent communication drafts and to provide security-considerations and requirements text for agent session and delegation binding. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Bu Expires 19 January 2027 [Page 1] Internet-Draft Agent Principal Binding July 2026 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 19 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 5. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Applicability and Review Modes . . . . . . . . . . . . . . . 8 8. Security Principal Model . . . . . . . . . . . . . . . . . . 8 9. Claim Classes and Initial Claim Registry . . . . . . . . . . 9 10. Verifier Matrix . . . . . . . . . . . . . . . . . . . . . . . 11 11. Matrix Review Rules . . . . . . . . . . . . . . . . . . . . . 12 12. Layer Vocabulary . . . . . . . . . . . . . . . . . . . . . . 14 13. Two-Level Review Model . . . . . . . . . . . . . . . . . . . 14 14. Status Value Semantics . . . . . . . . . . . . . . . . . . . 16 15. Protocol Mapping Template . . . . . . . . . . . . . . . . . . 18 16. Evidence and Test Vector References . . . . . . . . . . . . . 19 17. Inheritance Targets and Artifact-Layer Mechanisms . . . . . . 21 18. Composition Profiles and Accountability Slots . . . . . . . . 21 19. Phase and Result Boundaries . . . . . . . . . . . . . . . . . 22 20. Reusable Review Row Patterns . . . . . . . . . . . . . . . . 24 20.1. Condition-Bound Possession . . . . . . . . . . . . . . . 24 20.2. Optional Human-Principal Assertion . . . . . . . . . . . 25 20.3. Scoped Standing Grant . . . . . . . . . . . . . . . . . 26 21. Protocol-Neutral Worked Example . . . . . . . . . . . . . . . 27 22. Negative Test Cases . . . . . . . . . . . . . . . . . . . . . 29 Bu Expires 19 January 2027 [Page 2] Internet-Draft Agent Principal Binding July 2026 23. Guidance for Candidate Protocol Drafts . . . . . . . . . . . 32 24. Current-Draft Versus Future Mechanism . . . . . . . . . . . . 33 25. Security Considerations . . . . . . . . . . . . . . . . . . . 33 26. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35 27. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 28. Initial Application to AGENTPROTO Discussion . . . . . . . . 35 29. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 37 30. Changes from -02 . . . . . . . . . . . . . . . . . . . . . . 38 31. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 32. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 32.1. Normative References . . . . . . . . . . . . . . . . . . 39 32.2. Informative References . . . . . . . . . . . . . . . . . 40 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41 1. Introduction Agent protocols are being proposed for long-lived communication among agents, tools, gateways, services, and human or organizational principals. These protocols need to express several different kinds of security meaning: * who authorized the task; * which live agent or runtime instance is acting; * which tool, gateway, or external resource is being invoked; * what authority has been delegated, by whom, and under what scope; * what is bound to the current session or channel; and * what evidence can later be verified about an action. These are not the same claim. A valid organizational identifier does not by itself prove a live agent instance. A session identifier does not by itself prove delegated authority. A transparency receipt does not by itself prove that the action was authorized. A tool invocation record does not by itself prove that the tool was within delegated scope. The purpose of this document is to make these boundaries reviewable. It does not define a new agent protocol, token format, audit log, transparency service, or authorization system. Instead, it defines a claim-to-verifier discipline that other drafts can map to. Bu Expires 19 January 2027 [Page 3] Internet-Draft Agent Principal Binding July 2026 2. Conventions and Definitions BCP 14 is the requirement-keyword convention used by this document [BCP14]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document is currently intended as Informational guidance. Requirement language is used to make security expectations reviewable by protocol authors; it does not by itself define a wire protocol. 3. Terminology Agent An automated software component that initiates, receives, mediates, or performs actions on behalf of a human, organization, account, workload, or policy authority. Security principal An entity whose authority, identity, state, or responsibility is relevant to a security decision. Claim A security-relevant statement that a protocol participant, credential, token, receipt, attestation, record, or external system asserts or carries. Carrier The protocol field, credential, record, header, receipt, attestation, envelope, or external reference that carries a claim. Verifier The party that evaluates a claim for a particular security decision. Binding The relationship between a claim and the specific state to which it applies, such as a session transcript, task digest, delegation chain, subject identifier, tool invocation, or evidence record. Freshness Bu Expires 19 January 2027 [Page 4] Internet-Draft Agent Principal Binding July 2026 The replay, expiration, revocation, sequence, rotation, challenge, nonce, or recency rule used to determine whether a claim can still be relied upon. A matrix row should name the freshness mechanism it uses rather than treating all recency, status, and sequence signals as interchangeable. Wire freshness A challenge, nonce, transcript, channel binding, sequence rule, or equivalent mechanism that prevents a claim or proof from being replayed in a different protocol exchange. Wire freshness does not by itself establish current authorization, non-revocation, or local platform condition. Status freshness The evidence and rule used to determine whether an authority, credential, grant, delegation, or policy state is current. Examples include a validity window, revocation or status response, event-derived state, or bounded re-assessment lease. Condition-liveness freshness A freshness model in which a claim remains usable only while a local release condition continues to hold. In this model, the same component that assesses the condition also prevents the next key use or operation when the condition fails. This is different from a validity window, revocation list, or remote event feed. Clone-detection signal An advisory signal, such as a per-registration signature counter, that can indicate concurrent use of copied key material. A clone- detection signal is not a wire-freshness challenge and SHOULD NOT become an availability gate unless the protocol specifies reliable ordering, reset, synchronization, and failure semantics. Standing grant A scoped authority grant issued before a particular action. A standing grant can authorize a class of future actions for an asset, subject, resource, control verb, audience, time window, or revocation rule. It is different from a per-action authorization receipt and from a delegation chain. Failure behavior The required behavior when a claim is missing, stale, inconsistent, not verifiable, or out of scope for the decision being made. Accepted result Bu Expires 19 January 2027 [Page 5] Internet-Draft Agent Principal Binding July 2026 The constrained verifier output that an application, gateway, policy engine, or relying party is allowed to consume after successful verification. An accepted result is not the raw peer- provided token, receipt, claim, or attestation. It is the verifier-produced result, including its scope and limitations. Layer label A descriptive label for where a verifier decision is made or where a claim is carried. The label can use ordinary protocol-layer terminology, such as application, transport, or network, or an agent-native architectural taxonomy, but the vocabulary needs to be defined by the draft that uses it. Evidence reference A stable reference to a public test vector, example, test case, implementation note, interop record, issue, pull request, or other reviewable artifact that supports a mapping row. 4. Problem Statement Agent communication drafts can become difficult to review when a single architectural label is used to imply several security properties. Common examples include: * treating an account, organization, or credential identifier as evidence that a particular live agent instance is acting; * treating session continuity as evidence of delegated authority; * treating tool invocation evidence as evidence that the tool invocation was authorized; * treating an audit record or transparency receipt as proof of correctness, completeness, or authorization; * treating a governance or reputation mechanism as a current protocol guarantee when the current draft does not specify the verifier, evidence, or failure path; and * treating post-execution attribution as if it were pre-execution authorization, or treating pre-execution authorization as if it proved what actually happened after execution; and * treating inherited mechanisms from other drafts as if they were fully specified by the draft under review. Bu Expires 19 January 2027 [Page 6] Internet-Draft Agent Principal Binding July 2026 These ambiguities are not merely editorial. They affect interoperability and security review. Two implementations can agree on a field name while making different decisions about who verifies the field, what state the field is bound to, and what happens when the field cannot be validated. This document addresses that problem by giving protocol authors a common way to map each security-relevant claim to a carrier, verifier, verification rule, binding, freshness rule, accepted result, layer, and failure behavior. 5. Goals * Separate security principals and security claims that are often conflated in agent communication protocols. * Define a reusable verifier matrix for agent protocol drafts. * Make delegation, session binding, freshness, replay, revocation, and failure behavior mechanically reviewable. * Define accepted results so that applications consume verifier- produced decisions rather than raw peer-provided claims. * Encourage row-specific evidence references and negative tests for claims that are asserted as implemented or specified. * Support comparison among candidate protocols without requiring them to share the same wire format. * Provide candidate security-considerations text for agent communication work. * Make explicit which mechanisms are specified by the current draft, inherited from another document, planned for future work, or only architectural assumptions. 6. Non-Goals This document does not: * define a new agent transport protocol; * define a credential format; * define a delegation-token format; * define an audit-record format; Bu Expires 19 January 2027 [Page 7] Internet-Draft Agent Principal Binding July 2026 * define a transparency-receipt format; * require any specific public key, certificate, Verifiable Credential, SCITT, WIMSE, OAuth, GNAP, RATS, or vLEI mechanism; * decide whether any existing draft satisfies the matrix; or * select a single protocol as the architectural solution for all claims. 7. Applicability and Review Modes This document is applicable when an agent communication draft carries, depends on, or inherits claims about authority, live instance identity, delegated scope, session continuity, tool or resource identity, action evidence, freshness, revocation, or verifier output. A draft does not need to define all of these claims to use the matrix; it only needs to identify the claims it carries or depends on. The matrix can be used at several levels of formality. A mature draft can include a complete verifier matrix in its Security Considerations section or appendix. An early draft can use partial rows to make open questions explicit. A design team can maintain the mapping in a companion document, repository, issue, or pull request before importing stable text into an Internet-Draft. The review mode should match the status claimed by a row. A row marked as specified should contain enough detail for independent implementation. A row marked as implemented should identify the implementation boundary and evidence type. A row marked as inherited, planned, partial, none, or assumption should not be treated as a current protocol guarantee. 8. Security Principal Model The following principals commonly appear in agent communication designs. Human or organizational authority The person, organization, role, legal entity, account, or policy authority on whose behalf the agent acts. Agent instance The concrete live agent, runtime, workload, or execution environment that participates in the protocol exchange. Agent provider or runtime provider Bu Expires 19 January 2027 [Page 8] Internet-Draft Agent Principal Binding July 2026 The party that supplies, hosts, or controls an agent implementation or runtime environment. Tool or external resource A tool, API, service, file, database, payment endpoint, browser, physical device, or other resource invoked by an agent. Gateway, broker, or mediator An intermediary that translates, routes, composes, gates, or mediates agent interactions. Delegator The party that grants authority to another party or agent. Delegatee The party or agent that receives attenuated authority. Verifier or relying party The party that decides whether a claim is sufficient for a specific protocol action. Evidence consumer A party that later reviews, audits, composes, or relies on evidence of an action. A protocol can use one credential, key, session, or record to carry more than one claim, but the draft needs to identify each claim separately. Reusing a carrier does not make the claims equivalent. Workload identity documents, such as the WIMSE architecture [I-D.ietf-wimse-arch] and workload identity practices [I-D.ietf-wimse-workload-identity-practices], are useful examples of why an instance, workload, or execution environment claim should be separated from human or organizational authority and from delegated task scope. 9. Claim Classes and Initial Claim Registry A draft SHOULD identify which of the following claim classes it carries or depends on. The identifiers below are provisional and are intended to make early review concrete. They are not an IANA registry and do not by themselves define protocol conformance. C-001: Instance identity Which live agent, runtime, workload, endpoint, or process is acting now? C-002: Human or organizational authority Bu Expires 19 January 2027 [Page 9] Internet-Draft Agent Principal Binding July 2026 Who authorized the task, policy, role, or delegation? C-003: Delegated scope What authority has been delegated, by whom, to whom, under what scope and attenuation? C-004: Session continuity What state is bound to the current channel, connection, long-lived session, or task? C-005: Action evidence What action was requested, attempted, completed, blocked, or failed? C-006: Tool or resource identity Which tool or external resource is being invoked or affected? C-007: Evidence provenance What evidence, signature, receipt, attestation, log entry, or record supports an action or decision? C-008: Freshness or revocation Is the authority, delegation, instance state, tool binding, or session state still current? C-009: Failure handling What happens when the verifier cannot validate the claim for the requested action? C-010: Composition boundary Which claims are preserved, transformed, or lost when agents, gateways, receipts, or tools are composed? C-011: Accepted result What normalized result may the application consume after successful verification, and what does that result not authorize? C-012: Authorization and attribution boundary Is the row claiming pre-execution authority, delegated scope, post-execution attribution, execution evidence, audit enforcement, or relying-party acceptance, and which of those does it not claim? C-013: Scoped standing grant Does a pre-issued, independently revocable grant authorize a class of future actions for a stated asset, subject, resource, control verb, audience, or time window? Bu Expires 19 January 2027 [Page 10] Internet-Draft Agent Principal Binding July 2026 The registry is intentionally claim-oriented rather than protocol- oriented. More than one candidate protocol can map to the same claim, and a protocol can map to only a subset of the registry. The initial list is expected to change as AGENTPROTO discussion identifies additional claim classes or merges overlapping ones. 10. Verifier Matrix For each security-relevant claim, a protocol draft SHOULD provide a row with the following fields. Claim ID The registry identifier for the claim being mapped. Claim The precise security statement being made. Carrier The protocol field, token, credential, record, header, receipt, attestation, or out-of-band reference that carries the claim. Verifier The party that validates the claim. Verification rule The check performed by the verifier. Binding The other state to which the claim is bound, such as a session identifier, TLS exporter, action digest, delegation chain, subject identifier, or tool invocation. Freshness The replay, expiration, revocation, rotation, sequence, or recency rule. Failure behavior The required behavior when the claim is missing, stale, inconsistent, or not verifiable. Accepted result The constrained output that a verifier returns to the relying application when the row succeeds. It should name the normalized claim or decision state, the scope in which it may be used, and any important non-claims. For example, a successful possession check might return "holder of enrolled key under current release policy" without returning "delegated authority is sufficient" or "human authorization is present". Bu Expires 19 January 2027 [Page 11] Internet-Draft Agent Principal Binding July 2026 Layer The protocol layer or architectural review dimension associated with the row. This field is descriptive. It does not impose a fixed layer taxonomy on every protocol, and it does not require a protocol to spread claims across different layers. Implementation status Whether the row is implemented, not implemented, partially implemented, or external. Specification status Whether the row is specified in the current draft, planned for a later revision, inherited from another document, or an architectural assumption. Dependency The draft, standard, service, governance process, transparency log, authorization system, attestation system, registry, or operational practice on which the row depends, if any. Evidence reference An optional reference to a public test vector, example, test case, implementation artifact, interop note, issue, pull request, or other stable evidence that makes the row checkable. Evidence type The kind of evidence being referenced, such as source-level, unit- level, local-harness, interop, deployment, document, issue, pull- request, or other evidence. 11. Matrix Review Rules The matrix is intended to make review strict enough that a draft cannot obtain a security property merely by naming an adjacent mechanism. The following rules apply to a verifier matrix. 1. A carrier does not imply a claim unless the claim is explicitly stated. 2. A claim does not imply a verifier unless the verifier is identified for the decision being made. 3. A verifier decision is not complete unless the binding, freshness rule, and failure behavior are stated. If another component consumes the successful decision, the accepted result also needs to be stated. Bu Expires 19 January 2027 [Page 12] Internet-Draft Agent Principal Binding July 2026 4. An inherited mechanism is not a current protocol guarantee unless the dependency and failure behavior are stated. 5. A receipt, log entry, or audit record proves only the statement it records; it does not automatically prove authorization, completeness, or correct execution. 6. A row that is marked as planned, inherited, partial, or assumption MUST NOT be used as evidence that the current draft fully specifies the corresponding security property. 7. A layer label is not itself a security property. It helps reviewers locate where a claim is carried or verified, but the security property still depends on the carrier, verifier, binding, freshness rule, and failure behavior. 8. A raw token, credential, attestation, receipt, or protocol field is not by itself an accepted result. If an application consumes a successful verifier output, the draft SHOULD state the normalized accepted result and the scope of reliance. 9. A carrier-only mechanism is not a new claim class unless it asserts a distinct security property. An opaque envelope, payload pointer, fast-path forwarding field, or content- addressed reference can carry or bind another row without causing the forwarding component to verify that row's internal authority, provenance, policy, or status semantics. 10. An evidence reference is not required for every early row, but when one is present it needs to support the specific verifier decision described by the row. 11. An evidence type is not an assurance level. It describes the boundary of the supporting material so reviewers do not treat source evidence, local tests, interop vectors, and deployment evidence as equivalent. 12. A successful happy-path exchange is not sufficient implementation evidence for a security row. The implementation needs to perform the stated verification and reject a negative case for the same property. Emitting a signature, MAC, counter, or encrypted field without checking it at the receiving boundary does not establish the corresponding security property. Bu Expires 19 January 2027 [Page 13] Internet-Draft Agent Principal Binding July 2026 13. A digest join is not reviewable unless the draft identifies the canonical input bytes, hash algorithm, domain or context separation, version, and digest representation. Raw digest bytes and their textual hexadecimal encoding are different inputs. 14. Evidence from an emulator or software trust anchor can support protocol-flow and appraisal-logic claims, but it MUST NOT be presented as evidence of a hardware-root or non-extractability property. 12. Layer Vocabulary The Layer field needs to be explicit because candidate agent communication drafts do not all use the same architectural model. A draft MAY use conventional protocol-layer language, such as application, transport, and network, when that is the clearest description of where the relevant carrier or verifier behavior sits. A draft MAY instead use an agent-native architectural taxonomy, such as substrate, composition, application, governance, or audit. If it does so, the draft needs to define that taxonomy and explain how the labels are used. For example, a "governance" label might be useful for review when a claim depends on a policy, registry, reputation process, slashing process, or administrative authority; however, that label is not a protocol layer unless the draft defines it as one. The Layer field is open-ended per row. A protocol can place all of its relevant carriers or verifier behavior at the transport layer if that is how the protocol is designed. Conversely, a protocol can use an architectural label when the verifier decision depends on composition, audit, or governance behavior outside the transport exchange. The matrix does not require either vocabulary; it requires the chosen vocabulary to be explicit. 13. Two-Level Review Model The matrix can be maintained as linked review artifacts, not only as a pair of tables. A useful minimum is a claim registry and one or more protocol mapping records. A mature effort can also maintain evidence records, vector records, issue records, implementation notes, or per-profile appendices that reference the same claim identifiers. Bu Expires 19 January 2027 [Page 14] Internet-Draft Agent Principal Binding July 2026 The first level is a claim registry for AGENTPROTO review. It assigns stable identifiers to security claims or requirements, without selecting one protocol as the general solution for every row. Each row can name one or more candidate protocols that map to that claim. C-001: Agent or workload instance identity Candidate mappings include AGTP, IACP, a WIMSE profile, or another candidate. C-002: Human or organizational authority Candidate mappings include vLEI, OAuth, GNAP, an authorization receipt, or another candidate. C-003: Delegated scope Candidate mappings include a delegation chain, delegation receipt, or capability profile. C-004: Session continuity Candidate mappings include protocol session state, transport binding, or a migration profile. C-005: Action evidence Candidate mappings include an audit receipt, capsule, transparency statement, or evidence graph. C-011: Accepted result Candidate mappings include the verifier-produced result that an application, gateway, policy engine, or relying party is allowed to consume after successful verification. C-012: Authorization and attribution boundary Candidate mappings include human-authorization receipts, delegation records, mandate records, attribution records, audit records, action-evidence graphs, or other mechanisms whose security meaning depends on whether they speak before execution, during execution, after execution, or at relying-party acceptance time. C-013: Scoped standing grant Candidate mappings include consent grants, command-authority envelopes, standing permissions, capability grants, or other independently revocable artifacts that authorize a class of future actions rather than one specific action instance. Bu Expires 19 January 2027 [Page 15] Internet-Draft Agent Principal Binding July 2026 The second core artifact is the set of protocol mapping records. Each candidate draft can provide one or more records for the claims it carries or depends on. This prevents a protocol from being treated as a complete architecture merely because it covers one claim well, and it lets the working group compare drafts row by row. External mapping records can be maintained in a draft appendix, repository, implementation note, or companion document. Their purpose is not to force every candidate protocol into one wire format; it is to keep the claim taxonomy and per-protocol requirements visible at the same time. When an external mapping introduces a carrier such as an opaque authorization envelope, payload pointer, fast-path field, or content-addressed reference, the row needs to say whether that carrier is merely transporting another artifact or whether the current protocol verifies a distinct claim and produces its own accepted result. A protocol mapping row records the claim ID, claim text, carrier, verifier, verification rule, binding, freshness rule, accepted result, layer label, failure behavior, implementation status, specification status, any external dependency, evidence reference, and evidence type. For example, an instance-identity row might state that the carrier is a protocol field, the verifier is the peer, the binding is the handshake transcript, freshness is supplied by a nonce or epoch, the accepted result is a session-scoped instance decision, the failure behavior is connection rejection, and the evidence type is interop or local-harness evidence. The claim registry is not a conformance target by itself. The protocol mapping record set is the review surface: it states what the draft actually specifies, what is implemented, what is inherited from another component, what remains an architectural assumption, and what evidence or test vector can be used to check the row. 14. Status Value Semantics The implementation and specification status fields are security relevant. They prevent an author, implementer, or reviewer from treating an intended mechanism as a current protocol guarantee. The specification-status vocabulary is specified, planned, inherited, and assumption. The implementation-status vocabulary is implemented, partial, none, and external. Bu Expires 19 January 2027 [Page 16] Internet-Draft Agent Principal Binding July 2026 The two vocabularies are independent. A row can be specified but have no known implementation, implemented experimentally but not yet specified in the draft, inherited from another document with external implementation evidence, or planned without any current implementation claim. specified The current draft contains enough protocol text for an independent implementer to identify the carrier, verifier, binding, freshness rule, accepted result when applicable, and failure behavior. inherited The row depends on another specification or system. The dependency needs to be identified, and the draft needs to state what happens if the dependency is absent or not trusted. An inherited row is not complete if it merely names another document; it also needs to identify the inherited verifier, binding, freshness rule, accepted result when applicable, and failure behavior or state that they are outside the current draft's scope. planned The row is intended for a later revision and MUST NOT be treated as a current security guarantee. assumption The row depends on architecture, deployment, governance, or operational behavior that the draft does not specify. implemented At least one implementation performs the verification behavior described by the row. The row SHOULD identify whether that evidence is source-level, unit-level, local-harness, interop, or deployment evidence. If a public test vector or reproducible artifact exists, the row SHOULD include an evidence reference. A row is not implemented merely because the carrier is emitted or a positive exchange completes; the evidence needs to show the stated verifier decision and at least one security-relevant rejection path. partial The draft or implementation covers part of the row, but at least one of the carrier, verifier, binding, freshness rule, accepted result, or failure behavior is incomplete. none No implementation evidence is currently claimed for the row. external Bu Expires 19 January 2027 [Page 17] Internet-Draft Agent Principal Binding July 2026 The implementation evidence exists outside the candidate draft's own implementation. The row should identify the external system, artifact, or implementation boundary. External evidence can support a row without broadening the current draft's claim; the evidence boundary should remain narrower than the protocol guarantee unless the draft explicitly inherits and verifies the external mechanism. 15. Protocol Mapping Template Candidate protocol drafts can use the following compact template in a Security Considerations section, appendix, or companion document. The mapping row fields are: ID The claim identifier from the registry. Claim The precise statement being asserted or depended upon. Carrier The protocol field, credential, token, receipt, attestation, envelope, or external reference that carries the claim. Verifier The party that performs the check. Verification rule The rule applied by the verifier. Binding The state to which the claim is bound. Freshness The replay, revocation, expiration, sequence, nonce, recency, or condition-liveness rule. Accepted result or success behavior The verifier-produced result that the relying application may consume after successful verification, including scope of reliance and important non-claims. Layer The protocol layer or architectural review dimension used by the draft for this row. Failure behavior Bu Expires 19 January 2027 [Page 18] Internet-Draft Agent Principal Binding July 2026 The behavior when the claim is absent, stale, inconsistent, or not verifiable. Implementation status One of implemented, partial, none, or external. Specification status One of specified, planned, inherited, or assumption. Dependency The external document, system, service, registry, or operational process on which the row depends, if any. Evidence reference A stable public pointer to the test vector, example, test case, implementation artifact, interop record, issue, or pull request that supports the row, if available. Evidence type The type of evidence, such as source-level, unit-level, local- harness, interop, deployment, document, issue, pull-request, or other evidence. When a draft does not carry a claim, the corresponding row MAY be omitted. If the draft relies on the claim for a security decision, the row SHOULD NOT be omitted; it should instead state the dependency or assumption explicitly. When a row produces a result that application logic consumes, the row SHOULD define the accepted result. For example, a verifier can return a constrained result such as "session-bound token possessed on this connection" without also returning "this request target is authorized" or "human authorization is present". When a row maps an opaque envelope, content-addressed reference, payload pointer, fast-path header, or similar carrier, the row should make the non-claim explicit. Carrying or forwarding an artifact is not the same as verifying the artifact's authority, provenance, status, independence, or policy sufficiency. 16. Evidence and Test Vector References A verifier matrix becomes more useful when its rows are checkable rather than only asserted. A row therefore MAY include an evidence reference. The reference can point to a public test vector, example, conformance test, implementation test, interop note, issue, pull request, or other stable artifact. Bu Expires 19 January 2027 [Page 19] Internet-Draft Agent Principal Binding July 2026 An evidence reference does not need to prove that a protocol is complete. It needs to support the specific row. For example, a test vector for session replay resistance supports a freshness or binding row; it does not by itself prove delegated authority. A receipt verification example supports an evidence-carrier row; it does not by itself prove that the recorded action was authorized. When evidence is implementation-related, the row SHOULD distinguish the evidence type. Useful categories include source-level evidence, unit-level evidence, local-harness evidence, cross-implementation interop evidence, and deployment evidence. This distinction prevents a draft from treating a local unit test, public interop vector, and deployment signal as equivalent. A useful evidence reference is row-specific. It identifies the input object, the canonicalization or serialization rule when bytes are compared, the verifier decision being tested, the expected positive result, and at least one negative case that fails for the same row. If the evidence depends on a private deployment or non-public implementation, the row should say so instead of treating the evidence as publicly reproducible. For digest-bound composition, the evidence reference should also identify the hash algorithm, domain or context separator, protocol version, exact input-byte construction, and output representation. A vector that hashes 32 raw digest bytes is not interchangeable with one that hashes the 64 UTF-8 bytes of their hexadecimal display form. Immutable artifact or commit identifiers improve reproducibility, but an independently repeated positive calculation does not replace the required negative vectors. When a row produces an accepted result, the evidence reference should identify both the successful verifier output and at least one case in which a raw, stale, unbound, or incomplete claim is not passed to the application as an accepted result. Executable negative vectors are especially useful when composition is being reviewed. A useful vector can show that a capsule, receipt, log record, or envelope remains syntactically valid and digest-bound while a referenced authority, provenance, revocation, independence, or accepted-result row fails. That failure demonstrates that the join is checkable without moving the referenced row into the carrier's trust boundary. Bu Expires 19 January 2027 [Page 20] Internet-Draft Agent Principal Binding July 2026 17. Inheritance Targets and Artifact-Layer Mechanisms Some mechanisms used by agent communication protocols are not communication protocols themselves. For example, an authorization receipt, transparency statement, action-evidence graph, revocation statement, or attestation result can be an artifact-layer mechanism that is carried by, referenced by, or bound to a communication exchange. Such a mechanism can be a valid inheritance target for a protocol mapping row. If a draft marks a row as inherited, the row SHOULD identify the inherited mechanism and the decision state it supplies. The row should state the inherited verifier, carrier, binding, freshness rule, accepted result, failure behavior, and evidence reference when available. Marking a row as inherited is preferable to silently implying a guarantee. It allows a communication protocol to stay focused on its transport or session design while still making authority, action evidence, revocation, or audit dependencies visible to reviewers. Offline verification needs particular care. A signed grant, receipt, attestation, capsule, or revocation statement can be verified for authenticity, issuer, content digest, and validity window while still not proving global currency or absence of revocation. A row that claims current status needs to state the status source, revocation evidence, freshness window, and failure behavior. If those inputs are outside the verifier boundary, the accepted result should be limited to what was actually checked. 18. Composition Profiles and Accountability Slots Some agent accountability drafts describe review in terms of slots or profiles rather than a single protocol. The same matrix discipline applies. Each slot should be representable as one or more mapping rows with its own carrier, verifier, binding, freshness rule, accepted result, failure behavior, and evidence reference. For example, the composition model in [I-D.mih-sato-agent-accountability-composition] uses CAN, WHO, WHAT, and AUDIT profiles joined by a shared action digest. In this document's terms, the shared digest is a binding and composition aid for C-005 and C-010. It is not, by itself, an accepted result for authority, delegation, human authorization, completeness, runtime enforcement, or relying-party policy sufficiency. Bu Expires 19 January 2027 [Page 21] Internet-Draft Agent Principal Binding July 2026 Pre-execution approval, delegated authority, post-execution attribution, observed action evidence, and audit enforcement can name the same principal and the same action. They nevertheless remain different claims unless a draft specifies a verifier that intentionally joins them and defines the accepted result and failure behavior for that joined decision. A shared digest can make the join checkable; it does not make the rows interchangeable. The same rule applies to capsule, receipt, transparency-record, and gateway-envelope profiles that carry references to external artifacts. A record verifier can establish that the record is well- formed, signed, logged, or digest-bound without establishing that the referenced authority, provenance, independent observation, physical completion, or relying-party acceptance row succeeded. If a profile wants to rely on those stronger claims, it needs separate verifier rows or an explicit joined-verifier rule. Composition profiles also need byte-level interoperability rules. A shared action digest joins rows only when every producer and verifier uses the same canonical input, algorithm, context separation, version, and output representation. A representation mismatch, including raw digest bytes versus an ASCII hexadecimal string, is a binding failure rather than a tolerable presentation difference. An AUDIT or attestation profile should state the trust boundary of its implementation evidence. For example, a software-emulated TPM can exercise quote parsing, freshness reconstruction, PCR extension, and appraisal logic. That evidence does not establish a hardware root of trust, resistance to key extraction, or deployment assurance. 19. Phase and Result Boundaries Several agent-accountability discussions use the same principal name, action digest, or session binding across multiple checks. The matrix treats those checks as separate rows unless a draft explicitly defines a verifier that joins them. The separation is especially important across phases of an action. Common phase-separated rows include: Live possession Accepted result: the presenter currently holds an enrolled key, credential, or protected signing capability under the stated conditions. Important non-claim: delegated authority, human approval, and policy sufficiency are not established by possession alone. Bu Expires 19 January 2027 [Page 22] Internet-Draft Agent Principal Binding July 2026 Delegated scope Accepted result: the presented delegation chain or capability covers the requested action within the stated scope. Important non-claim: the current holder or runtime is not proven unless a possession or instance row also succeeds. Human authorization Accepted result: a named human, organization, role, or quorum authorized the exact action before execution under the stated rule. Important non-claim: post-execution attribution and live key possession are not established by authorization alone. Human-principal assertion Accepted result: a voluntary, consent-bound, or otherwise accountable human principal is associated with the request under a stated grant. Important non-claim: the bot or automated-client signing key is not thereby changed into a human key. Action evidence or attribution Accepted result: a record, receipt, capsule, or evidence graph refers to an observed or recorded action. Important non-claim: the record does not by itself prove pre- execution authority, completeness, or relying-party acceptance. Controller-reported outcome Accepted result: a downstream controller, tool, or external system reports a terminal status under its own semantics. Important non-claim: the report does not by itself prove physical completion, environmental safety, independent verification, or pre-execution authority. Session pause or resume Accepted result: the relying party or session manager has placed a session in a paused state or has resumed it after obtaining the required fresh verifier result. Important non-claim: pause is not credential revocation by itself, and resume is not proof that all authority, delegation, or policy rows remain valid unless the draft says which rows were rechecked. Relying-party acceptance Bu Expires 19 January 2027 [Page 23] Internet-Draft Agent Principal Binding July 2026 Accepted result: the consuming application, gateway, or policy engine accepts a set of verifier-produced results for a particular action. Important non-claim: acceptance is not inherited by any single upstream row unless the draft specifies that decision rule. A draft can use the same action digest, transcript hash, request ID, or subject identifier across these rows. That shared value is a binding aid. It does not collapse the rows into one result. 20. Reusable Review Row Patterns The following row patterns capture recent review cases that recur across candidate agent protocols. They are examples, not mandatory mappings. Their purpose is to show how a draft can reference externally supplied mechanisms without inheriting broader guarantees by implication. 20.1. Condition-Bound Possession A condition-bound possession row is useful for a protected key, credential, or signing capability that exists only while a local release policy currently holds. Claim The presenter can use the enrolled protected key for this operation. Any claim about the actor, workload, environment, or release policy is limited to inputs that enrollment evidence actually measured, bound to that key, and caused policy to accept. Carrier A live possession proof such as a TLS CertificateVerify signature over the handshake transcript, an attested credential, or another proof bound to enrollment and release-policy evidence. Verifier and rule The relying party, gateway, sidecar, or verifier checks the enrolled key or credential and the live proof. If the accepted result includes measured actor, workload, environment, or release- policy inputs, the verifier also checks enrollment or attestation evidence that explicitly enumerates and binds those inputs. Unmeasured inputs are not inferred from key existence. Binding and freshness The row is bound to the enrolled protected key, the enumerated enrollment inputs, and the current protocol exchange. Wire freshness comes from the transcript, challenge, nonce, or Bu Expires 19 January 2027 [Page 24] Internet-Draft Agent Principal Binding July 2026 equivalent live proof. Condition-liveness governs whether the next key use can occur after a local condition failure. A clone- detection counter, when present, is a separate advisory signal and not the wire-freshness mechanism. If a profile requires termination of an already established long-lived connection, that behavior needs a separate session-management rule, connection- lifetime bound, or event channel. Accepted result The accepted result is limited to live possession of the enrolled protected capability for this exchange and to any explicitly measured-and-bound enrollment inputs that the verifier checked. It does not by itself establish delegated authority, human approval, current device health, operation scope, action sufficiency, or relying-party policy acceptance. Failure behavior Missing required enrollment evidence, an unmeasured claimed input, invalid attestation binding, stale required status, local condition failure, or failed possession proof fails as a possession or condition failure, independently of delegated-scope and human-authorization failures. Evidence status The row should distinguish implemented paths, partial paths, and open paths. Evidence should include a successful live proof and a rejection for an invalid proof or unavailable key. A human- presence path might have a public implementation while a workload path remains unimplemented; the evidence field should say so rather than implying equal maturity. 20.2. Optional Human-Principal Assertion A bot or automated-client authentication protocol can remain focused on the automated client while still allowing a separate optional row for a human principal, consent grant, or accountability assertion. A profile needs to state whether the human is merely associated with the request, consented to it, authorized it, or accepts accountability; those are not interchangeable results. Claim A named human principal has the exact relationship to this request stated by the profile, such as association, consent, authorization, or accountability, under a defined grant or evidence rule. Carrier Bu Expires 19 January 2027 [Page 25] Internet-Draft Agent Principal Binding July 2026 A consent receipt, authorization receipt, signed grant, external reference, or profile-specific artifact. The carrier is not the automated-client signing key itself. Verifier and rule The origin, relying party, or policy engine verifies the human- principal artifact under its own issuer, key, audience, scope, and trust rules, separately from bot-key or client-key verification. Binding and freshness The row should bind the human-principal artifact to the request, origin, purpose, scope, time window, and, where applicable, a request digest or action digest. Accepted result The accepted result states the verified human-principal relationship for this request without broadening it from association to consent or from consent to authorization. It does not change the automated-client key into a human key and does not make human presence mandatory for every bot request. Failure behavior Automated-client authentication can succeed while the optional human-principal row fails. The application then treats the request as lacking that assurance and applies its local policy. 20.3. Scoped Standing Grant Some protocols use a pre-issued grant rather than a fresh per-action authorization receipt. The matrix treats that as a separate claim class because its verification rule, freshness rule, and accepted result differ from both per-action human authority and delegated scope. Claim A grant issuer authorizes a class of future actions for a stated asset, subject, resource, control verb, audience, scope, or time window. The claim is about standing permission, not proof that a particular action was approved at execution time. Carrier A signed consent grant, command-authority envelope, standing permission, capability grant, or content-addressed reference to such an artifact. Verifier and rule Bu Expires 19 January 2027 [Page 26] Internet-Draft Agent Principal Binding July 2026 The relying party verifies the grant issuer, signature, intended audience, covered asset or resource, permitted control verb, expiry, revocation state, and binding to the request or action digest. Binding and freshness The grant is bound to its issuer, subject or resource, permitted operation class, time window, revocation rule, and, when consumed for a specific action, the action digest or request context used at presentation. Offline verification of a signed grant can establish authenticity and validity-window checks, but it does not prove current non-revocation unless the row also specifies the status or revocation evidence that was checked. Accepted result The accepted result is that a standing grant covers the current request under the stated constraints. It is not a per-action human authorization receipt, not an audit record that the action occurred, and not proof that delegated scope was correctly attenuated. If revocation status is outside the row's verifier input, the accepted result should say authenticity and validity- window result, not current status result. Failure behavior If the grant has an invalid issuer or signature, names the wrong subject, resource, control verb, audience, or constraints, is expired or revoked, lacks required current-status evidence, is bound to a different request context, or is presented as the wrong claim class, the standing-grant row fails independently of per- action authorization, delegation, possession, and action-evidence rows. 21. Protocol-Neutral Worked Example The following example is deliberately protocol-neutral. It is not a complete mapping for AGTP [I-D.hood-independent-agtp], IACP [I-D.gebauer-iacp], WIMSE [I-D.ietf-wimse-arch], or any other candidate draft. It illustrates how rows should separate claims, verifier decisions, accepted results, and failure behavior. C-002: user or organization authorized the task Possible carriers include a role credential, account policy, vLEI, OAuth token, GNAP grant [RFC9635], or equivalent. The verifier is the receiving agent or policy verifier. The claim is bound to the task, scope, subject, and resource. Freshness comes from token lifetime, revocation, or policy version. Failure behavior is rejection or fresh authorization. Bu Expires 19 January 2027 [Page 27] Internet-Draft Agent Principal Binding July 2026 C-001: live agent instance is acting Possible carriers include channel authentication, an agent credential, attestation, or a condition-bound protected key. The verifier is a peer, gateway, or relying party. The claim is bound to a session or channel transcript and to any declared protection conditions. Freshness comes from handshake freshness, attestation recency, nonce challenge, or equivalent live-key check. The accepted result is limited to live instance or key-possession status under those conditions; it does not by itself prove delegated task scope or human authority. Failure behavior is session rejection or capability downgrade. C-003: delegation is in scope Possible carriers include a delegation token or chain. The verifier is the recipient or gateway. The claim is bound to the delegator, delegatee, action class, and resource. Freshness comes from expiry, revocation, or attenuation version. Failure behavior is rejection of the delegated action. C-006: tool invocation is in scope Possible carriers include a tool call envelope or capability reference. The verifier is the tool gateway or policy engine. The claim is bound to delegated scope and tool identity. Freshness comes from a per-call nonce, session binding, or sequence. Failure behavior is denial of the invocation and failure recording if audit is claimed. C-005: action evidence refers to the same action Possible carriers include an action digest, receipt, capsule, or audit record. The verifier is the profile verifier or composition verifier. The claim is bound to the canonical action-input bytes and native record. The row identifies the hash algorithm, context or domain separator, version, and output representation. Freshness comes from digest context version and receipt policy. Failure behavior is refusal to compose the records as evidence of the same action. C-011: verifier returns a constrained accepted result After validating a row, the verifier returns a normalized result that states what the next component may rely on. For example, a gateway might return "this connection currently holds the enrolled live key" but not "this request is authorized for this resource" unless the authority and delegated-scope rows also succeed. C-012: pre-execution and post-execution claims remain separate A human authorization receipt can show that a named human or quorum approved an action before execution. An attribution or audit record can show who was recorded as delegating, performing, Bu Expires 19 January 2027 [Page 28] Internet-Draft Agent Principal Binding July 2026 or observing the action after execution. Even when both records are joined by the same action digest, the verifier returns separate accepted results for pre-execution authority and post- execution attribution unless another specified rule intentionally combines them. 22. Negative Test Cases Protocol authors SHOULD consider negative tests for each row in the verifier matrix. The following cases are intended as examples. Stale delegation A delegation token or chain is structurally valid but expired, revoked, or superseded. The verifier rejects the delegated action or requests fresh authorization. Unbound tool invocation A tool call envelope is valid, but the envelope is not bound to the delegation scope, resource identifier, or session state used for the decision. The tool invocation is denied. Replay across sessions A claim or receipt from one session is replayed in another session. The verifier detects that the claim is not bound to the current session transcript, nonce, exporter, or equivalent channel state. Clone signal substituted for freshness An advisory signature or use counter is treated as the replay challenge or as a mandatory availability gate even though the protocol does not guarantee ordered, synchronized, non-resettable values. The freshness row fails unless a transcript, nonce, sequence rule, or other specified live challenge independently establishes wire freshness. Transport framing mistaken for session continuity A stream implementation succeeds when each write is returned by a separate read, but loses a second frame when the transport coalesces two frames or blocks when a frame is fragmented. The implementation cannot support the session-continuity row until framing retains unread bytes, handles partial input, and enforces a frame-size limit. Mismatched action evidence A receipt, log entry, capsule, or evidence record refers to a different action digest, input, resource, or policy version than the action being reviewed. The records are not composed as evidence of the same action. Bu Expires 19 January 2027 [Page 29] Internet-Draft Agent Principal Binding July 2026 Digest representation mismatch Two components claim to extend or compare the same digest, but one consumes the raw digest bytes while the other consumes the UTF-8 bytes of its hexadecimal display form. The binding row fails even if both values print as the same hexadecimal string. Inherited mechanism absent A draft states that another component supplies authorization, attestation, or evidence, but does not identify the dependency or the failure behavior when the dependency is unavailable. The row is marked as inherited or assumption, not as a current protocol guarantee. Emulated root presented as hardware evidence A test using a software emulator exercises quote parsing, freshness, measurement extension, or appraisal logic, but the row is reported as evidence of a hardware root, non-extractable key, or physical platform property. The implementation status is limited to the tested software boundary. Raw claim pass-through A protocol field, token, credential, receipt, or attestation is structurally valid, but the application consumes the raw object directly instead of a verifier-produced accepted result. The test fails unless the draft defines what normalized result may be consumed and what scope that result has. Cryptographic field emitted but not verified An implementation emits a signature, MAC, authentication tag, or encrypted field and completes a positive exchange, but the receive path accepts a deliberately invalid value. The corresponding authentication, integrity, or confidentiality row is partial or unimplemented rather than implemented. Possession without authority A live-key, protected-key, or session-binding check succeeds, but the requested action is outside the delegated scope or lacks human or organizational authority. The key-possession row can pass while the authority or delegation row fails. Condition failure after connection establishment A condition-bound key becomes unavailable after a connection is established. The next key operation or key agreement fails, but the already established connection is not assumed to terminate unless the draft specifies a session-management rule, connection lifetime bound, or event-driven termination behavior. Session resumed without fresh verifier result Bu Expires 19 January 2027 [Page 30] Internet-Draft Agent Principal Binding July 2026 A session is paused after a condition failure or policy event and later resumed because the local condition appears healthy again. The resume test fails unless the draft states which possession, delegation, status, or policy rows are rechecked and which fresh accepted result is consumed before resuming. Bot authentication mistaken for human-principal assurance An automated-client or bot signing key verifies successfully, but the application treats that result as proof that a human principal consented to, approved, or stands behind the request. The test fails unless a separate human-principal row is independently satisfied. Per-action receipt presented as standing grant A receipt proves that a specific action was authorized or witnessed, but the application treats it as a reusable grant for future actions. The standing-grant row fails unless the artifact separately carries the issuer, scope, resource, control verb, expiry, revocation, and permitted-use semantics required for C-013. Standing grant consumed as per-action authority A standing grant covers a class of actions, but the application treats it as proof that the current action was separately approved at execution time. The per-action authority row fails unless a distinct action-specific authorization or approval artifact is independently verified. Valid carrier with invalid grant semantics An opaque envelope and its outer integrity check are valid, but the carried or referenced grant names the wrong subject, resource, control verb, audience, constraints, expiry, or revocation state. An integrity-only forwarder can pass the carrier onward but MUST NOT emit a C-013 result; the semantic grant verifier refuses the standing-grant row. Reported outcome treated as physical completion A downstream controller or tool reports success under its own status semantics, but the application treats that report as proof that the intended physical effect occurred, that the environment was safe, or that an independent observer verified completion. The physical completion or independent-verification row fails unless a separate claim with its own verifier and evidence is satisfied. Same-party evidence treated as independent verification Bu Expires 19 January 2027 [Page 31] Internet-Draft Agent Principal Binding July 2026 A capsule, receipt, or evidence graph carries a statement supplied by the same actor that performed, delegated, or reported the action, and the application treats that statement as independent verification. The independent-observation row fails unless the verifier identifies a distinct observer, trust basis, binding, and freshness rule. Digest equality treated as sufficiency Two records carry the same action digest, and the implementation treats that equality as authorization, completeness, correctness, or policy sufficiency. The test fails unless the relevant authority, evidence, audit, and accepted-result rows are separately verified. Attribution substituted for authorization A post-execution attribution or audit record names a principal, but the system treats that record as proof that the principal approved the action before execution. The verifier rejects the substitution unless a pre-execution authorization row is independently satisfied. 23. Guidance for Candidate Protocol Drafts A candidate agent communication draft can use this document in four ways. 1. It can include a verifier matrix in its Security Considerations section. 2. It can publish a companion mapping document that maps its protocol fields to the claim registry. 3. It can state that a claim is intentionally out of scope, inherited from another document, or left to deployment policy. 4. It can link public vectors or evidence references for rows that have executable or reproducible evidence. A draft that takes the third path remains reviewable if it identifies the dependency and failure behavior. The main review problem is not that a protocol omits a claim; the problem is when a protocol relies on a claim while leaving the verifier, binding, freshness rule, or failure behavior implicit. Bu Expires 19 January 2027 [Page 32] Internet-Draft Agent Principal Binding July 2026 Tables can be useful for compact review, but the table shape is not itself a security property. A draft can use a table, definition list, YAML or JSON record, Markdown issue, or prose appendix if the review fields remain explicit. For long text fields, authors should prefer a format that preserves accepted results and important non- claims over a compact layout that hides those boundaries. 24. Current-Draft Versus Future Mechanism When a draft supplies a verifier matrix, it SHOULD distinguish: * mechanisms implemented or normatively specified in the current draft; * mechanisms described as future work; * mechanisms inherited from another draft or external system; and * mechanisms that are architectural assumptions rather than protocol checks. This distinction is important for review. A row that depends on a future reputation system, slashing process, governance committee, or external log can still be useful, but it should not be presented as a current protocol guarantee. 25. Security Considerations An agent communication protocol MUST NOT rely on a single identifier, token, session handle, log entry, or credential to imply multiple security properties unless the draft explicitly specifies the verification rule for each property. In particular: * authority and live-instance identity need separate validation; * possession of a session key does not by itself prove delegation scope; * a delegation chain does not by itself prove current session continuity; * a tool call does not by itself prove that the tool was within delegated authority; * a successful key-possession, live-instance, or attestation check does not by itself authorize a request target; Bu Expires 19 January 2027 [Page 33] Internet-Draft Agent Principal Binding July 2026 * an audit log or transparency receipt does not by itself prove authorization, truth, completeness, or correct execution; and * an architectural label such as "identity at the wire" should be mapped to concrete protocol checks. A successful verification step should produce a constrained accepted result for the relying component. Protocol authors should avoid designs in which application logic consumes raw peer-provided claims, tokens, receipts, or attestations as if their mere presence were a completed security decision. The accepted result needs to preserve the scope, binding, freshness, and limitations of the verifier decision. If a claim is required for a security decision and the verifier cannot validate that claim, the protocol MUST specify whether the action is rejected, downgraded, quarantined, delayed for additional authorization, or allowed with a recorded warning. Silent acceptance is not an acceptable default for a security-relevant claim. Protocol authors should also consider cross-protocol composition. A claim that is valid in one protocol context might lose its security meaning when it is copied into a receipt, gateway envelope, audit record, or delegated session without preserving the binding and freshness state needed by the verifier. Where attestation evidence is used, this document follows the RATS distinction among claims, evidence, appraisal, and relying-party decisions described in [RFC9334]. Where transparency services or signed-statement receipts are used, this document treats those receipts as evidence carriers and not as automatic proof of authorization or correct execution; see the SCITT architecture in [RFC9943]. Protocol and implementation reviews also need to test the rejecting boundary. Naming an algorithm or emitting a cryptographic field does not establish authentication or integrity if invalid values are accepted. Likewise, a stream implementation needs framing tests for fragmented and coalesced input before it supports a session- continuity claim, and evidence from an emulated trust anchor needs to remain scoped to the software and appraisal logic actually exercised. Bu Expires 19 January 2027 [Page 34] Internet-Draft Agent Principal Binding July 2026 26. Privacy Considerations Verifier-facing matrices can expose privacy-relevant design choices. A draft that binds actions to human authority, organizational identifiers, tool invocations, or long-lived sessions should state whether the binding creates linkability across actions, sessions, deployments, or administrative domains. Drafts should avoid requiring globally linkable identifiers unless the security property being claimed requires them. Where possible, a matrix row should state whether the verifier needs a stable identifier, a pairwise identifier, a role or capability assertion, a freshness proof, or only evidence that a locally authorized policy decision was made. Accepted results can also affect privacy. A verifier can often return a scoped decision such as "authorized for this task in this session" instead of exposing the raw credential, stable identifier, receipt, or attestation evidence to application logic. Drafts should describe when raw identifying material is preserved, transformed, minimized, or withheld from the accepted result. 27. IANA Considerations This document makes no IANA requests. If later versions define a reusable registry of claim identifiers, verifier matrix fields, or protocol mapping status values, that registry will need a separate IANA considerations section. 28. Initial Application to AGENTPROTO Discussion The AGTP [I-D.hood-independent-agtp] and IACP [I-D.gebauer-iacp] discussion threads provide useful early examples. This section does not judge whether either draft satisfies the matrix; it only identifies useful first mapping targets. AGTP appears to expose candidate carriers for authority, agent identity, delegation, session state, composition-layer tool identity, and audit evidence. The next useful step is to turn those carriers into mapping records that state who verifies each claim, what accepted result is returned, what evidence type supports the row, and what failure behavior applies. IACP has already been sketched by its author as a verifier-facing matrix. For reviewability, the useful next step is to separate rows that are currently in [I-D.gebauer-iacp] from rows that are future work, inherited from other mechanisms, or dependent on governance Bu Expires 19 January 2027 [Page 35] Internet-Draft Agent Principal Binding July 2026 systems not yet specified in the current I-D. In that review, carrier fields such as opaque authorization envelopes, local session keys, payload pointers, or fast-path forwarding handles should be distinguished from verifier- produced accepted results. A protocol- flow demonstration can support source-level or local-harness evidence, but a security row remains partial until the implementation performs the stated verification and rejects the corresponding invalid input. The accountability composition work in [I-D.mih-sato-agent-accountability-composition] is another early application. Its CAN, WHO, WHAT, and AUDIT slots can be reviewed as mapping rows. The most important boundary for interop is that the shared action digest joins independently verified rows; it does not replace the native verifier for any slot and does not by itself produce an accepted result. Its byte-level interoperability surface also needs to pin canonical input bytes, algorithm, context separation, version, and digest representation so that a textual encoding is not substituted for the raw digest. Both mappings can help converge a shared requirements note without requiring either protocol to adopt the other's wire format. The capsule provenance-binding work in [I-D.rampalli-scitt-capsule-provenance-binding] illustrates the same boundary for artifact-layer composition. A capsule can bind authorization and provenance references into a transparency-checkable record while leaving authority truth, provenance truth, physical completion, independent observation, and relying-party acceptance to their own verifier rows. Recent WIMSE discussion, including the condition-bounded credential draft in [I-D.winmagic-wimse-condition-bounded-credentials], also illustrates a condition-bound possession row: a protected signing capability can prove live possession under a release policy while leaving delegated authority, human authorization, and relying-party acceptance to separate rows. The same discussion separates three jobs: transcript or nonce freshness for replay on the wire, condition-liveness for whether the next local key operation can occur, and an advisory counter for clone evidence. Endpoint-side key unavailability does not terminate an already established connection unless a separate session-management rule says so. Pause and resume should consume the fresh verifier results named by that rule, not act as automatic proof that all previously accepted rows remain valid. Recent Web Bot Auth discussion illustrates the complementary human- principal case: an automated-client key can remain a bot key while an optional consent-bound or accountability artifact supplies a separate human-principal row. Bu Expires 19 January 2027 [Page 36] Internet-Draft Agent Principal Binding July 2026 29. Open Issues * Should the matrix be a requirements document, a security- considerations companion, or a section to be imported by candidate protocol drafts? * What is the minimal set of mandatory claim classes for AGENTPROTO? * Should the matrix define conformance language, or remain an Informational review aid? * Should a shared repository hold the claim registry and protocol mapping records before the Internet-Draft is posted, or should the initial I-D define the record format first? * How should action evidence be bound to delegation and session state without forcing a single audit-record format? * Which negative test cases should protocol authors provide for stale delegation, replayed sessions, unbound tool calls, and mismatched evidence? * Should privacy and linkability expectations be part of the same matrix, or a separate privacy considerations profile? * Should evidence references remain optional, or should implemented rows require a public evidence reference before being marked as implemented? * Which freshness classes should be mandatory to label explicitly, including wire, validity-window, status, and condition-liveness freshness, and where should advisory clone-detection signals be recorded? * Should optional human-principal assertions be modeled as a subtype of human or organizational authority, or should they receive a distinct claim class when they are consent-bound but not full authorization? * What minimum negative vectors should be required before a condition-bound possession row, human-principal row, or digest- joined composition row is marked implemented? * Should session pause and resume be represented as part of C-004 session continuity, or should they be modeled as a separate session-management row that consumes fresh verifier results? Bu Expires 19 January 2027 [Page 37] Internet-Draft Agent Principal Binding July 2026 * When, if ever, should same-party evidence be acceptable for a row that claims independent observation, and what extra verifier rule would make that distinction reviewable? * Should a row be allowed to claim implemented status without a public or reviewable negative test that exercises the stated rejection path? 30. Changes from -02 This section summarizes the principal review-facing changes in this working revision. It can be removed if the document is later adopted and the working-group process prefers a separate change history. * Added C-013 for scoped standing grants and separated grant semantics from opaque carriers and per-action authorization. * Added constrained accepted-result, phase-boundary, and non-claim guidance for possession, delegation, human-principal assertions, action evidence, controller-reported outcomes, pause or resume, and relying-party acceptance. * Added reusable row patterns for condition-bound possession, optional human-principal assertions, and scoped standing grants. * Strengthened implementation-status and evidence rules so positive protocol flow, algorithm labels, external artifacts, emulators, and carrier fields cannot imply untested security guarantees. * Separated wire freshness, status freshness, condition-liveness, and clone-detection signals. * Added byte-exact digest-composition requirements and negative tests for representation mismatch, unverified cryptographic fields, stream framing, emulated trust roots, session resume, same-party evidence, and claim-class substitution. * Updated the initial AGENTPROTO applications and informative references to reflect current IACP, WIMSE, SCITT, and accountability composition discussion. Bu Expires 19 January 2027 [Page 38] Internet-Draft Agent Principal Binding July 2026 31. Acknowledgments The author thanks Leonard Gebauer for proposing the two-level claim- registry and per-protocol mapping-record structure, supplying IACP- oriented mapping examples, and making an implementation prototype available for negative-path review. The author thanks Chris Hood for clarifying open-ended layer vocabulary and AGTP transport-layer mapping considerations. The author thanks Iman Schrock for evidence-backed mapping rows, scoped standing-grant details, executable negative-vector framing, and inheritance-target treatment for artifact-layer mechanisms. The author thanks Steven Mih and Tom Sato for accountability-composition and conformance-vector discussion that clarified action-digest joins and slot-style review. The author thanks Anton Sokolov for concrete discussion of raw digest bytes versus textual hexadecimal representation, emulated-TPM evidence boundaries, and gate-specific negative vectors. The author thanks Thi Nguyen-Huu, Sergei Nikitin, and John O'Leary for condition-bound credential and live-key discussion that clarified measured enrollment inputs, transcript freshness, condition-liveness, clone-detection signals, and established-session boundaries. The author thanks Karthik Rampalli for composed-stack review and failure classes, Akira Okutomi for discussion that motivated clearer accepted-result and success-output boundaries, and Blake Morrison for discussion of optional human-principal assertions above bot authentication. The author also thanks participants on the AGENTPROTO, WIMSE, SCITT, and related mailing lists for discussion of security-principal separation, verifier-facing review matrices, protocol comparison, evidence boundaries, and claim-level coordination among candidate drafts. Acknowledgment does not imply endorsement of this document or of any particular protocol mapping. 32. References 32.1. Normative References [BCP14] Bradner, S. and B. Leiba, "Key Words for Use in RFCs to Indicate Requirement Levels and Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 2119, RFC 8174, May 2017, . Bu Expires 19 January 2027 [Page 39] Internet-Draft Agent Principal Binding July 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 32.2. Informative References [I-D.gebauer-iacp] Gebauer, L., "Internet Agent Communication Protocol", Work in Progress, Internet-Draft, draft-gebauer-iacp-02, 6 July 2026, . [I-D.hood-independent-agtp] Hood, C., "Agent Transfer Protocol (AGTP)", Work in Progress, Internet-Draft, draft-hood-independent-agtp-09, 28 June 2026, . [I-D.ietf-wimse-arch] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-08, 6 July 2026, . [I-D.ietf-wimse-workload-identity-practices] Schwenkschuster, A. and Y. Rosomakho, "Workload Identity Practices", Work in Progress, Internet-Draft, draft-ietf- wimse-workload-identity-practices-05, 30 June 2026, . [I-D.mih-sato-agent-accountability-composition] Mih, S., Sato, T., Bu, S., and I. Schrock, "Agent Accountability: Composition and Conformance", Work in Progress, Internet-Draft, draft-mih-sato-agent- accountability-composition-00, 5 July 2026, . [I-D.rampalli-scitt-capsule-provenance-binding] Rampalli, K., "Binding Per-Action Authorization and Memory Provenance into Agent Action Capsules", Work in Progress, Bu Expires 19 January 2027 [Page 40] Internet-Draft Agent Principal Binding July 2026 Internet-Draft, draft-rampalli-scitt-capsule-provenance- binding-00, 4 July 2026, . [I-D.winmagic-wimse-condition-bounded-credentials] Nguyen-Huu, T., Nikitin, S., and J. O'Leary, "Condition- Bounded Credentials for Workload and Agent Identity: Non- Exfiltratable Keys and Validity by Presence", Work in Progress, Internet-Draft, draft-winmagic-wimse-condition- bounded-credentials-01, 6 July 2026, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9635] Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, . [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . Author's Address Songbo Bu Email: bluedognull@gmail.com Bu Expires 19 January 2027 [Page 41]