Security Principal and Verifier Binding for Agent Communication Protocols
draft-bu-agentproto-security-principal-binding-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Songbo Bu | ||
| Last updated | 2026-07-05 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bu-agentproto-security-principal-binding-02
Agent Communication Protocols S. Bu
Internet-Draft 6 July 2026
Intended status: Informational
Expires: 7 January 2027
Security Principal and Verifier Binding for Agent Communication
Protocols
draft-bu-agentproto-security-principal-binding-02
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 7 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 7 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 . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Applicability and Review Modes . . . . . . . . . . . . . . . 7
8. Security Principal Model . . . . . . . . . . . . . . . . . . 7
9. Claim Classes and Initial Claim Registry . . . . . . . . . . 8
10. Verifier Matrix . . . . . . . . . . . . . . . . . . . . . . . 10
11. Matrix Review Rules . . . . . . . . . . . . . . . . . . . . . 11
12. Layer Vocabulary . . . . . . . . . . . . . . . . . . . . . . 12
13. Two-Level Review Model . . . . . . . . . . . . . . . . . . . 13
14. Status Value Semantics . . . . . . . . . . . . . . . . . . . 14
15. Protocol Mapping Template . . . . . . . . . . . . . . . . . . 15
16. Evidence and Test Vector References . . . . . . . . . . . . . 17
17. Inheritance Targets and Artifact-Layer Mechanisms . . . . . . 18
18. Composition Profiles and Accountability Slots . . . . . . . . 18
19. Protocol-Neutral Worked Example . . . . . . . . . . . . . . . 19
20. Negative Test Cases . . . . . . . . . . . . . . . . . . . . . 20
21. Guidance for Candidate Protocol Drafts . . . . . . . . . . . 21
22. Current-Draft Versus Future Mechanism . . . . . . . . . . . . 22
23. Security Considerations . . . . . . . . . . . . . . . . . . . 22
24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
Bu Expires 7 January 2027 [Page 2]
Internet-Draft Agent Principal Binding July 2026
26. Initial Application to AGENTPROTO Discussion . . . . . . . . 24
27. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25
28. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
29. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
29.1. Normative References . . . . . . . . . . . . . . . . . . 26
29.2. Informative References . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27
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.
2. Conventions and Definitions
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.
Bu Expires 7 January 2027 [Page 3]
Internet-Draft Agent Principal Binding July 2026
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
The replay, expiration, revocation, sequence, rotation, challenge,
nonce, or recency rule used to determine whether a claim can still
be relied upon.
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 7 January 2027 [Page 4]
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 7 January 2027 [Page 5]
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 7 January 2027 [Page 6]
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 7 January 2027 [Page 7]
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 7 January 2027 [Page 8]
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?
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.
Bu Expires 7 January 2027 [Page 9]
Internet-Draft Agent Principal Binding July 2026
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".
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.
Bu Expires 7 January 2027 [Page 10]
Internet-Draft Agent Principal Binding July 2026
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.
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.
Bu Expires 7 January 2027 [Page 11]
Internet-Draft Agent Principal Binding July 2026
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. 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.
10. 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. 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.
Bu Expires 7 January 2027 [Page 12]
Internet-Draft Agent Principal Binding July 2026
13. Two-Level Review Model
The matrix can be maintained as two linked review levels: a claim
registry and one or more protocol mapping records.
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.
Bu Expires 7 January 2027 [Page 13]
Internet-Draft Agent Principal Binding July 2026
The second level 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.
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.
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
Bu Expires 7 January 2027 [Page 14]
Internet-Draft Agent Principal Binding July 2026
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.
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
The implementation evidence exists outside the candidate draft's
own implementation. The row should identify the external system,
artifact, or implementation boundary.
15. Protocol Mapping Template
Candidate protocol drafts can use the following compact template in a
Security Considerations section, appendix, or companion document.
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.
Bu Expires 7 January 2027 [Page 15]
Internet-Draft Agent Principal Binding July 2026
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, or recency
rule.
Accepted result or success behavior
The verifier-produced result that the relying application may
consume after successful verification. This field should state
the scope of reliance and important non-claims.
Layer
The protocol layer or architectural review dimension used by the
draft for this row.
Failure behavior
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.
Bu Expires 7 January 2027 [Page 16]
Internet-Draft Agent Principal Binding July 2026
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".
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.
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.
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.
Bu Expires 7 January 2027 [Page 17]
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.
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.
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.
Bu Expires 7 January 2027 [Page 18]
Internet-Draft Agent Principal Binding July 2026
19. 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.
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
Bu Expires 7 January 2027 [Page 19]
Internet-Draft Agent Principal Binding July 2026
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 and
native record. 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,
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.
20. 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.
Mismatched action evidence
Bu Expires 7 January 2027 [Page 20]
Internet-Draft Agent Principal Binding July 2026
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.
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.
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.
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.
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.
21. 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.
Bu Expires 7 January 2027 [Page 21]
Internet-Draft Agent Principal Binding July 2026
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.
22. 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.
23. 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;
Bu Expires 7 January 2027 [Page 22]
Internet-Draft Agent Principal Binding July 2026
* 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;
* 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].
Bu Expires 7 January 2027 [Page 23]
Internet-Draft Agent Principal Binding July 2026
24. 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.
25. 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.
26. 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.
Bu Expires 7 January 2027 [Page 24]
Internet-Draft Agent Principal Binding July 2026
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 draft-gebauer-iacp-01 from rows that are future
work, inherited from other mechanisms, or dependent on governance
systems not yet specified in the current I-D.
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.
Both mappings can help converge a shared requirements note without
requiring either protocol to adopt the other's wire format.
27. 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?
Bu Expires 7 January 2027 [Page 25]
Internet-Draft Agent Principal Binding July 2026
28. Acknowledgments
The author thanks Leonard Gebauer for proposing a two-level claim-
registry and per-protocol mapping-record structure and for providing
IACP-oriented mapping examples; Chris Hood for clarifying open-ended
layer vocabulary and AGTP transport-layer mapping considerations;
Iman Schrock for proposing evidence-backed mapping rows and
inheritance-target framing for artifact-layer mechanisms; and Steven
Mih and Tom Sato for accountability-composition and conformance-
vector discussion that helped clarify action-digest joins and slot-
style review. The author thanks Akira Okutomi for discussion that
motivated clearer accepted-result and success-output boundaries,
Karthik Rampalli for discussion of composed-stack review and failure
classes, and Thi Nguyen-Huu for discussion of condition-bound
credentials and live-key examples. The author also thanks
participants on the AGENTPROTO mailing list for discussion of
security-principal separation, verifier-facing review matrices,
protocol comparison, and claim-level coordination among candidate
drafts. Acknowledgment does not imply endorsement of this document
or of any particular protocol mapping.
29. References
29.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
29.2. Informative References
[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, <https://www.rfc-editor.org/info/rfc9334>.
[RFC9635] Richer, J., Ed. and F. Imbault, "Grant Negotiation and
Authorization Protocol (GNAP)", RFC 9635,
DOI 10.17487/RFC9635, October 2024,
<https://www.rfc-editor.org/info/rfc9635>.
Bu Expires 7 January 2027 [Page 26]
Internet-Draft Agent Principal Binding July 2026
[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,
<https://www.rfc-editor.org/info/rfc9943>.
[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-07, 2 March 2026,
<https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/>.
[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,
<https://datatracker.ietf.org/doc/draft-ietf-wimse-
workload-identity-practices/>.
[I-D.hood-independent-agtp]
Hood, C., "Agent Transfer Protocol (AGTP)", Work in
Progress, Internet-Draft, draft-hood-independent-agtp-09,
28 June 2026, <https://datatracker.ietf.org/doc/draft-
hood-independent-agtp/>.
[I-D.gebauer-iacp]
Gebauer, L., "Internet Agent Communication Protocol", Work
in Progress, Internet-Draft, draft-gebauer-iacp-01, 29
June 2026,
<https://datatracker.ietf.org/doc/draft-gebauer-iacp/>.
[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,
<https://datatracker.ietf.org/doc/draft-mih-sato-agent-
accountability-composition/>.
Author's Address
Songbo Bu
Email: bluedognull@gmail.com
Bu Expires 7 January 2027 [Page 27]