Security Principal and Verifier Binding for Agent Communication Protocols
draft-bu-agentproto-security-principal-binding-06
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-08-16 | ||
| 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-06
Agent Communication Protocols S. Bu
Internet-Draft 17 August 2026
Intended status: Informational
Expires: 18 February 2027
Security Principal and Verifier Binding for Agent Communication
Protocols
draft-bu-agentproto-security-principal-binding-06
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.
The document also defines row-outcome semantics and dependency-
closure rules for composed mappings. These rules prevent a composite
result from becoming stronger than its verified inputs, distinguish
failed checks, unsupported verifier capabilities, checks skipped
after a failed prerequisite, and unavailable or ambiguous inputs,
propagate transitive dependency failures, and make cyclic, stale,
downgraded, or revision-incoherent dependencies visible to reviewers.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bu Expires 18 February 2027 [Page 1]
Internet-Draft Agent Principal Binding August 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 February 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 . . . . . . . . . . . . . . . . . . . . . . 7
5. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Applicability and Review Modes . . . . . . . . . . . . . . . 9
8. Security Principal Model . . . . . . . . . . . . . . . . . . 9
9. Claim Classes and Initial Claim Registry . . . . . . . . . . 11
10. Verifier Matrix . . . . . . . . . . . . . . . . . . . . . . . 12
11. Matrix Review Rules . . . . . . . . . . . . . . . . . . . . . 14
12. Layer Vocabulary . . . . . . . . . . . . . . . . . . . . . . 16
13. Two-Level Review Model . . . . . . . . . . . . . . . . . . . 16
14. Status Value Semantics . . . . . . . . . . . . . . . . . . . 18
15. Evidence Scenario Dispositions . . . . . . . . . . . . . . . 20
16. Evaluation Context and Row Outcomes . . . . . . . . . . . . . 22
17. Dependency Closure and Composition Invariants . . . . . . . . 23
18. Protocol Mapping Template . . . . . . . . . . . . . . . . . . 25
19. Machine-Readable Mapping Sets . . . . . . . . . . . . . . . . 28
20. Evidence and Test Vector References . . . . . . . . . . . . . 30
Bu Expires 18 February 2027 [Page 2]
Internet-Draft Agent Principal Binding August 2026
21. Inheritance Targets and Artifact-Layer Mechanisms . . . . . . 32
22. Composition Profiles and Accountability Slots . . . . . . . . 32
23. Phase and Result Boundaries . . . . . . . . . . . . . . . . . 33
24. Reusable Review Row Patterns . . . . . . . . . . . . . . . . 35
24.1. Condition-Bound Possession . . . . . . . . . . . . . . . 35
24.2. Optional Human-Principal Assertion . . . . . . . . . . . 36
24.3. Scoped Human Continuity . . . . . . . . . . . . . . . . 37
24.4. Scoped Standing Grant . . . . . . . . . . . . . . . . . 39
24.5. External C-013 Mapping: Command Authority Envelope . . . 40
25. Protocol-Neutral Worked Example . . . . . . . . . . . . . . . 41
26. Negative Test Cases . . . . . . . . . . . . . . . . . . . . . 43
27. Guidance for Candidate Protocol Drafts . . . . . . . . . . . 52
28. Current-Draft Versus Future Mechanism . . . . . . . . . . . . 52
29. Security Considerations . . . . . . . . . . . . . . . . . . . 53
30. Privacy Considerations . . . . . . . . . . . . . . . . . . . 55
31. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
32. Initial Application to AGENTPROTO Discussion . . . . . . . . 56
33. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 58
34. Changes from -05 . . . . . . . . . . . . . . . . . . . . . . 59
35. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60
36. References . . . . . . . . . . . . . . . . . . . . . . . . . 62
36.1. Normative References . . . . . . . . . . . . . . . . . . 62
36.2. Informative References . . . . . . . . . . . . . . . . . 62
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 64
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.
Bu Expires 18 February 2027 [Page 3]
Internet-Draft Agent Principal Binding August 2026
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
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
Bu Expires 18 February 2027 [Page 4]
Internet-Draft Agent Principal Binding August 2026
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. 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.
Bu Expires 18 February 2027 [Page 5]
Internet-Draft Agent Principal Binding August 2026
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
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.
Claim grounding
The basis on which a claim obtains its asserted meaning, such as a
signed assertion, verifier-derived fact, independently appraised
attestation result, or inherited external result. A signed
assertion does not become an attested property unless the verifier
checks evidence that measures or otherwise establishes that
property under the stated appraisal policy.
Relying-party decision
The local application or policy decision made after consuming one
or more verifier-produced results. A relying-party decision is
distinct from the result itself: an indeterminate, not-equivalent,
or otherwise limited verification result does not, without a
stated policy rule, mean allow, refuse, retry, or authorize.
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.
Evaluation context
The versioned inputs under which a verifier evaluates a row,
including the protocol and profile revisions, policy revision,
action or session binding, evaluation time, trust inputs, and
dependency results that can affect the outcome.
Row outcome
Bu Expires 18 February 2027 [Page 6]
Internet-Draft Agent Principal Binding August 2026
A verifier-facing state for one evaluation of a mapping row. The
outcome states defined by this document are satisfied,
unsatisfied, indeterminate, unsupported, not-evaluated, and not-
applicable. A row outcome is distinct from specification status,
implementation status, and the relying-party decision.
Effective row outcome
The outcome used by composition after validating the row result,
its evaluation context, and the transitive outcomes of every
declared dependency. A raw satisfied outcome can therefore have
an effective outcome of unsatisfied or indeterminate.
Composition request
The relying-party input that pins the mapping-set identifier and
revision, required claim identifiers, decision-time binding,
policy revision, and decision time for one aggregate evaluation.
Dependency closure
The property that every result on which a row depends is named,
evaluated in a compatible context, and available with the outcome
required by the consuming row.
Critical row
A row whose absence, unknown identifier, invalid mapping,
unsatisfied outcome, or indeterminate outcome prevents an
aggregate result from being reported as satisfied under the
applicable profile.
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
Bu Expires 18 February 2027 [Page 7]
Internet-Draft Agent Principal Binding August 2026
* 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.
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:
Bu Expires 18 February 2027 [Page 8]
Internet-Draft Agent Principal Binding August 2026
* define a new agent transport protocol;
* define a credential format;
* define a delegation-token format;
* define an audit-record format;
* 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
Bu Expires 18 February 2027 [Page 9]
Internet-Draft Agent Principal Binding August 2026
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
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.
Bu Expires 18 February 2027 [Page 10]
Internet-Draft Agent Principal Binding August 2026
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
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?
Bu Expires 18 February 2027 [Page 11]
Internet-Draft Agent Principal Binding August 2026
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?
C-014: Scoped human continuity
Do repeated valid presentations correspond to the same verified
unique human within a declared continuity scope, without treating
that continuity value as identity, authentication, presence,
approval, or authority?
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.
Bu Expires 18 February 2027 [Page 12]
Internet-Draft Agent Principal Binding August 2026
Claim grounding
Whether the claim is a signed assertion, verifier-derived fact,
independently appraised attestation result, or inherited external
result, including the evidence and appraisal rule required for the
stated meaning.
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".
Relying-party decision
The policy action taken after consuming the verifier-produced
result, such as allow, refuse, quarantine, request another factor,
or leave the decision to another component. This field SHOULD
remain separate from the accepted result.
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.
Implemented revision
The exact specification revision, profile version, source
revision, or immutable implementation identifier against which the
implementation evidence was produced.
Specification status
Whether the row is specified in the current draft, planned for a
later revision, inherited from another document, or an
architectural assumption.
Bu Expires 18 February 2027 [Page 13]
Internet-Draft Agent Principal Binding August 2026
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.
Evidence coverage
The exact positive paths, negative paths, normative checks, and
failure branches exercised by the evidence, together with material
unexercised paths. Coverage distinguishes standing verifier-
capability limitations from checks implemented by the verifier but
not reached for a particular input. Stable results for a bounded
regression set do not establish conformance for normative
requirements outside that set.
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 18 February 2027 [Page 14]
Internet-Draft Agent Principal Binding August 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. A signed or tamper-evident assertion is not an independently
appraised property. If an accepted result claims user
verification, human presence, platform state, or another
attested property, the row needs to identify the evidence and
appraisal rule that establish that property.
10. A verifier-produced result is not a relying-party policy
decision. Results such as indeterminate, not equivalent, or
verified under a limited profile MUST NOT be silently relabeled
as allow, refuse, retry, or authorize.
11. 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.
12. 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.
13. 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.
14. 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 18 February 2027 [Page 15]
Internet-Draft Agent Principal Binding August 2026
15. An implementation claim needs to identify the exact draft
revision, profile version, source revision, or immutable
artifact used by the test. Evidence produced against one
revision MUST NOT be silently upgraded to a later revision.
16. 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.
17. 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 18 February 2027 [Page 16]
Internet-Draft Agent Principal Binding August 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 such as [I-D.morrison-ot-command-authority], standing
permissions, capability grants, or other independently revocable
artifacts that authorize a class of future actions rather than one
specific action instance.
Bu Expires 18 February 2027 [Page 17]
Internet-Draft Agent Principal Binding August 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, claim grounding, freshness
rule, accepted result, relying-party decision, layer label, failure
behavior, implementation status, implemented revision, 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 18 February 2027 [Page 18]
Internet-Draft Agent Principal Binding August 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 18 February 2027 [Page 19]
Internet-Draft Agent Principal Binding August 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. Evidence Scenario Dispositions
A mapping that names positive, negative, interoperability, or
deployment scenarios SHOULD record one evidence disposition for each
scenario. The evidence dispositions are measured, not-run, and not-
applicable.
measured
The scenario was executed against the identified implementation,
environment, protocol revision, verifier revision, and test
inputs. The evidence reference identifies the observation and its
outcome.
not-run
The scenario is reachable under the declared environment and is
relevant to the mapped claim, but no qualifying observation is
available. It remains an evidence gap and MUST NOT be counted as
positive or negative coverage.
not-applicable
The scenario cannot arise under the pinned implementation and
environment. The record identifies the architectural, profile, or
deployment fact that excludes it, who asserted that fact, an
immutable reference to the assertion, whether an independent
reviewer can check the fact or must rely on the reporting party's
account of its environment, the exact evidence set whose
denominator it affects, and whether the assertion preceded or
followed observation of data that bears on that exclusion. It is
neither measured coverage nor an evidence gap, and it limits the
implementation claim to that environment.
Evidence dispositions describe the coverage of a test suite or
review; they are distinct from specification status, implementation
status, and row outcomes. In particular, a not-run scenario is not a
not-evaluated row. The former records that no test observation
exists; the latter records that a verifier could perform a row check
but did not reach it for a particular input. A reachable scenario
MUST NOT be relabeled not-applicable merely to improve a coverage
denominator.
Bu Expires 18 February 2027 [Page 20]
Internet-Draft Agent Principal Binding August 2026
The relevant temporal boundary is the observation of data that bears
on the exclusion, not the beginning or end of an ambiguously named
run. A campaign can contain a pilot, diagnostics, repairs, and a
final grid. An exclusion record therefore identifies the affected
campaign or evidence set and any prior observations available when
the exclusion was declared. An assertion pinned before those
observations can constrain the original evaluation plan. An
exclusion informed by already observed data MUST NOT retroactively
remove a scenario from the original coverage denominator. It is
recorded as a versioned post-observation amendment, including the
prior-observation references, reason for the amendment, and direction
of any selection effect; the original disposition remains reviewable.
A sequence of individually disclosed amendments can still ratchet an
evaluation toward a preferred result. Before corrections begin, the
evaluation record therefore pins an amendment policy that identifies
its scope and a finite set of correction allowances. Each post-
observation amendment identifies the policy, the allowance it
consumes, and that allowance's ordinal. Two distinct amendments MUST
NOT consume the same allowance slot, and an amendment MUST NOT exceed
the predeclared limit. Each allowance MUST also identify the basis
for its declared limit as campaign-structure-derived, based on a
stated prior expectation, or reporter-asserted, and MUST include a
reviewable explanation. This basis is a terminal provenance type
rather than another numeric quantity, so it does not create a
recursive justification requirement. A campaign-structure-derived
allowance MUST identify, by immutable reference, both the exact
campaign property from which the limit is derived and the derivation
rule relating that property to the limit. The evaluator MUST
establish the declared limit from those references. If the property
or derivation cannot be independently checked, the allowance MUST be
classified as reporter-asserted instead; access to a campaign
definition alone does not establish that a declared number follows
from it. An allowance based on a stated prior expectation MUST also
carry an immutable reference to the record containing that
expectation, and the evaluator MUST establish that the referenced
record predates the first affected observation. If that temporal
relationship cannot be independently established, the allowance MUST
be classified as reporter-asserted instead. Adding an allowance
after observing the affected data is itself a new versioned policy
and MUST NOT rewrite the earlier campaign's stopping rule.
An architectural or profile exclusion is independently checkable when
its cited source is available to the reviewer. A deployment
exclusion can be valid while remaining reporter-asserted because an
external reviewer cannot observe the complete environment. A report
MUST distinguish these cases and MUST NOT describe a reporter-
asserted deployment fact as independently verified.
Bu Expires 18 February 2027 [Page 21]
Internet-Draft Agent Principal Binding August 2026
16. Evaluation Context and Row Outcomes
Specification status and implementation status describe a mapping and
its evidence. They do not describe the result of evaluating a
particular input. A verifier that evaluates a row SHOULD return one
of the following row outcomes together with the row identifier and
evaluation context.
satisfied
The verifier completed the stated checks under the recorded
context and produced the row's constrained accepted result.
unsatisfied
The verifier completed enough checks to determine that the input
violates the row's verification, binding, freshness, scope, or
status rule. The result records the failed rule without
converting the failure into an unrelated policy decision.
indeterminate
The verifier cannot establish either satisfied or unsatisfied
because required input, status, trust information, dependency
output, authoritative state, or evaluation context is missing,
unavailable, or ambiguous after the verifier attempted the
applicable evaluation.
unsupported
The row requires a protocol, profile, algorithm, evidence type, or
semantic check that this verifier revision does not implement.
This is a standing verifier-capability limitation and is reported
even when another row or an outer policy can still produce a
decision.
not-evaluated
The verifier implements the row, but did not attempt it for this
input because a prerequisite failed, processing terminated
earlier, or the evaluation plan deliberately did not reach the
row. The result identifies the prerequisite or plan decision that
prevented the check.
not-applicable
The row is outside the declared scope of this mapping and is not
required by the applicable profile or relying-party policy. A
required but absent row is not not-applicable.
Bu Expires 18 February 2027 [Page 22]
Internet-Draft Agent Principal Binding August 2026
Unsupported is not a synonym for not-evaluated. The former describes
what the verifier cannot perform at that revision; the latter
describes what it could perform but did not perform for this input.
Neither is a successful verification, and neither may be relabeled as
unsatisfied merely to make an outer policy fail closed.
The evaluation context SHOULD identify the mapped specification
revision, verifier or profile revision, applicable policy revision,
action, session, or object binding, evaluation time, and the exact
dependency results consumed. Where current status or condition-
liveness affects a result, the context also records the status source
or local enforcement boundary and the freshness bound applied at
consumption.
Where evaluation order can change whether a row is reported as not-
evaluated or indeterminate, the evaluation context SHOULD identify
the evaluation-plan revision and the ordered prerequisites or checks
that were attempted. A verifier that cannot establish whether an
implemented check was reached reports indeterminate rather than
inferring not-evaluated from a final failure alone.
A row outcome MUST NOT be silently reused after a security-relevant
context field changes. A new action digest, resumed session, policy
revision, verifier revision, grant status, trust anchor, or expired
freshness bound requires re-evaluation of the affected row or an
explicit profile rule that proves the earlier result remains valid.
When a result is consumed outside the verifier's trust boundary, the
result SHOULD have a stable identifier and SHOULD identify the exact
mapping-set identifier and revision under which it was produced. A
dependency reference SHOULD identify the dependency row, the exact
result identifier consumed, and that result's raw outcome. Reusing
the row name while substituting an older or differently scoped result
does not preserve dependency closure.
17. Dependency Closure and Composition Invariants
A mapping set can assign stable row identifiers and name dependencies
between rows. Before reporting an aggregate result, the composition
verifier SHOULD establish the transitive dependency closure of every
critical row. Checking only the directly referenced raw outcome is
insufficient: if row C depends on row B and row B depends on row A,
the effective outcome of C also depends on the effective outcome of
A. A reference to another draft, service, token, or row is not
closure unless the consuming row identifies the exact dependency
result and checks that result in a compatible evaluation context.
Bu Expires 18 February 2027 [Page 23]
Internet-Draft Agent Principal Binding August 2026
For a conjunctive composition profile, the effective outcome of a row
is derived as follows:
* An absent or invalid result, an unresolved dependency reference,
or an incompatible or expired evaluation context has an effective
outcome of indeterminate.
* A raw unsatisfied outcome remains unsatisfied. A raw
indeterminate, unsupported, not-evaluated, or not-applicable
outcome remains explicit and does not become satisfied through
composition.
* A raw satisfied outcome becomes effectively unsatisfied if any
transitive dependency is effectively unsatisfied. It becomes
effectively indeterminate if no dependency is unsatisfied but at
least one is indeterminate, unsupported, not-evaluated, not-
applicable, unknown, or missing. It remains satisfied only when
every declared dependency is effectively satisfied.
The aggregate outcome for a valid conjunctive profile is satisfied
only when every critical row is effectively satisfied. It is
unsatisfied when at least one critical row is effectively
unsatisfied; this reports a known failure even if another critical
row is indeterminate. Otherwise, the aggregate is indeterminate. An
unsupported, not-evaluated, not-applicable, or indeterminate outcome
for a row required by the composition request is therefore
indeterminate at the aggregate boundary, while preserving the raw
reason in the report. Profiles that permit alternatives, thresholds,
or other Boolean expressions MUST define those expressions, their
dependency closure, and their failure semantics explicitly; changing
critical flags alone is not such a definition.
The relying party SHOULD supply or select a composition request that
pins the accepted mapping-set identifier and revision, policy
revision, required claim identifiers, action or object binding, and
decision time. The composition verifier MUST NOT report satisfied if
the selected mapping set omits a claim required by that request, if a
required claim has no critical mapping row, or if a row result names
a different mapping-set revision. This prevents an older profile
from silently demoting a newly required security property.
A dependency cycle has no independently established base result. A
composition verifier MUST treat every result that relies solely on
such a cycle as indeterminate. A profile can permit an iterative or
fixed-point construction only if it defines the trusted initial
state, convergence rule, termination bound, and failure behavior.
Merely having two rows refer to each other does not establish either
claim.
Bu Expires 18 February 2027 [Page 24]
Internet-Draft Agent Principal Binding August 2026
The following invariants apply to composed results:
1. *No elevation by composition:* an aggregate result MUST NOT imply
a claim stronger than the accepted results of its verified input
rows.
2. *Critical-row preservation:* an unsatisfied, indeterminate,
unsupported, not-evaluated, not-applicable, unknown, or missing
critical row MUST NOT be omitted or relabeled so that the
aggregate becomes satisfied.
3. *Context coherence:* joined rows identify compatible action or
object bindings, protocol and policy revisions, evaluation times,
and digest representations. Equality of one digest does not
repair disagreement in the other context fields.
4. *Failure preservation:* the aggregate reports which row failed or
remained indeterminate and does not replace that state with a
generic success produced by another row.
5. *Result authenticity:* a consumer authenticates the verifier that
produced each accepted result and verifies the result's scope,
binding, freshness, and profile before composition.
An aggregate verifier can return a new, explicitly scoped accepted
result after enforcing these invariants. That result SHOULD identify
the contributing row identifiers and outcomes, the composition
profile and revision, decision-time binding, contributing result
identifiers, and important non-claims. It does not inherit
authority, independence, completion, or policy sufficiency merely
because all inputs share an action digest.
A structural validator can check identifiers, revision pins,
dependency closure, context equality, and the shape of accepted
results. It cannot determine from field names alone that one
accepted result semantically implies another, nor can matching
verifier metadata replace producer authentication. The no-elevation
property therefore still requires review of each row's claim,
verifier rule, accepted-result scope, and authenticated result-
protection mechanism.
18. 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:
Bu Expires 18 February 2027 [Page 25]
Internet-Draft Agent Principal Binding August 2026
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.
Claim grounding
Whether the claim is a signed assertion, verifier-derived fact,
independently appraised attestation result, or inherited external
result, including the evidence and appraisal rule required for the
stated meaning. The grounding field is distinct from Evidence
type, which describes support for the mapping row or
implementation rather than the basis of the protocol claim.
Signer role and principal relationship
The role in which the signer acts, such as attester, device,
automated client, operator, grant issuer, or accountable
principal, and the verified relationship between that signer and
the principal named by the claim. If that relationship is
supplied by enrollment or another external process, the row
identifies it as a dependency or assumption.
Digest or output representation
The representation carried or compared, such as raw octets,
hexadecimal text, base64url text, or a profile-defined structure,
together with the canonical decoding or comparison rule. A row
that does not define the representation does not obtain value
equality from textual similarity alone.
Freshness
The replay, revocation, expiration, sequence, nonce, recency, or
condition-liveness rule.
Accepted result or success behavior
Bu Expires 18 February 2027 [Page 26]
Internet-Draft Agent Principal Binding August 2026
The verifier-produced result that the relying application may
consume after successful verification, including scope of reliance
and important non-claims.
Relying-party decision
The application or policy action taken after consuming the
verifier-produced result. If that decision is outside the row's
scope, the row states that boundary rather than embedding a policy
conclusion in the verifier result.
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.
Implemented revision
The exact specification revision, profile version, source
revision, or immutable implementation identifier used by the cited
implementation evidence.
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.
Evidence coverage
Bu Expires 18 February 2027 [Page 27]
Internet-Draft Agent Principal Binding August 2026
The positive and negative paths, normative schema or protocol
checks, and failure branches exercised by the cited evidence,
including any known unexercised or implementation-local paths. It
separately identifies checks absent from the verifier and checks
implemented but not reached for the evaluated input.
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 an external interoperability profile maps a draft to an action
model that the draft does not define, the mapping should report the
missing material fields and an indeterminate mapping result rather
than inventing native fields. Such a result describes the scope of
that external mapping; it is not, by itself, a conformance failure or
a defect in the source draft.
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.
19. Machine-Readable Mapping Sets
A companion artifact MAY represent mapping rows and dependencies in a
machine-readable mapping set. The representation is a review and
interoperability aid; it is not an agent wire format, does not create
a new security claim, and does not make the example field names
normative.
A mapping set should identify the profile, mapping-set identifier and
revision, mapped protocol, specification and policy revisions,
required claim identifiers, stable row identifiers, critical rows,
expected verifier profiles, and row dependencies. Row contents
remain subject to the verifier-facing fields in Section 18. A
validator should reject duplicate row identifiers, claim identifiers
that disagree with the referenced row, required claims without
critical rows, missing dependency targets, path or reference
ambiguity, and dependency cycles without a defined base result.
Bu Expires 18 February 2027 [Page 28]
Internet-Draft Agent Principal Binding August 2026
{
"profile": "example-interop-profile-0.1",
"mapping_set_id": "example.agent-protocol",
"mapping_set_revision": "2026-08-04.1",
"protocol": "example-agent-protocol",
"specification_revision": "draft-example-agent-04",
"policy_revision": "example-policy-7",
"required_claim_ids": ["C-002", "C-013"],
"rows": [
{
"row_id": "authority.external",
"claim_id": "C-002",
"critical": true,
"depends_on_rows": [],
"expected_verifier": {
"id": "example.authority-verifier",
"profile_revision": "authority-profile-1"
}
},
{
"row_id": "grant.semantic",
"claim_id": "C-013",
"critical": true,
"depends_on_rows": ["authority.external"],
"expected_verifier": {
"id": "example.grant-verifier",
"profile_revision": "grant-profile-4"
}
}
]
}
A separate composition request allows the relying component to retain
control over the security properties needed for one decision:
{
"profile": "example-interop-profile-0.1",
"mapping_set": {
"id": "example.agent-protocol",
"revision": "2026-08-04.1"
},
"decision_time": "2026-08-04T02:02:00Z",
"binding_ref": "sha256:example-action-001",
"policy_revision": "example-policy-7",
"required_claim_ids": ["C-002", "C-013"]
}
Bu Expires 18 February 2027 [Page 29]
Internet-Draft Agent Principal Binding August 2026
A mapping set SHOULD be pinned to the exact source and schema
revision used by its validator. Unknown non-critical rows can be
retained for forwarding or later review if the profile permits that
behavior. An unknown critical row prevents a satisfied aggregate
result because the verifier cannot establish its semantics or
required failure behavior.
The example field names are not a generic signature or
canonicalization format. A profile that exchanges these artifacts
across a trust boundary still needs to define the protected bytes,
producer authentication, algorithm and key selection, replay
handling, and trust-anchor policy.
20. 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.
The row SHOULD also state evidence coverage. A regression suite that
remains stable after an implementation correction supports only the
paths that the suite actually exercises. It does not establish that
required claims are present, unknown claims are rejected, value types
and ranges are checked, duplicate members are refused, replay state
is durable, or other normative branches are implemented unless those
behaviors are exercised or otherwise independently verified.
Uncovered normative paths require a partial status rather than a
conformance claim.
Coverage reporting has two dimensions that MUST NOT be collapsed. A
standing capability limitation names a check that the pinned verifier
does not implement, such as an unsupported signature algorithm or an
Bu Expires 18 February 2027 [Page 30]
Internet-Draft Agent Principal Binding August 2026
unresolved trust-reference quorum. A per-input execution gap names a
check that is implemented but was not reached because an earlier
prerequisite failed or processing stopped. The former belongs in the
mapping's implementation coverage; the latter belongs in the result
for the evaluated input. A third, orthogonal distinction is
reachability: a reachable but unmeasured path is not the same as a
path that cannot arise under the declared profile.
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.
A prepared cross-protocol exchange is not cross-implementation
interop evidence until an independent implementation consumes the
exact pinned source bytes and returns its result over those inputs.
Two separately successful local mappings, or a shared digest that
remains stable while one carrier becomes invalid, can support
narrower rows but do not by themselves establish an independent end-
to-end cross-run.
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 18 February 2027 [Page 31]
Internet-Draft Agent Principal Binding August 2026
21. 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.
22. 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 18 February 2027 [Page 32]
Internet-Draft Agent Principal Binding August 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.
23. 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 18 February 2027 [Page 33]
Internet-Draft Agent Principal Binding August 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 18 February 2027 [Page 34]
Internet-Draft Agent Principal Binding August 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.
24. 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.
24.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 18 February 2027 [Page 35]
Internet-Draft Agent Principal Binding August 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.
24.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 18 February 2027 [Page 36]
Internet-Draft Agent Principal Binding August 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.
24.3. Scoped Human Continuity
A scope-local continuity value is not a human-principal assertion.
It can let a verifier determine that repeated valid presentations map
to the same verified unique human within a declared scope while
deliberately revealing neither a global identifier nor the person's
authority. The Human Continuity HTTP draft
[I-D.brezun-human-continuity-http] is an informative example of this
claim shape.
ID and claim
C-014. Under the selected continuity profile, repeated valid
presentations for the same verified unique human produce the same
opaque handle within the same declared continuity scope, while
handles across distinct scopes are not treated as correlatable.
Carrier
A profile-specific, challenge-bound presentation. The opaque
continuity handle is verifier output, not a bearer authenticator
and not a substitute for the presentation that produced it.
Verifier and rule
Bu Expires 18 February 2027 [Page 37]
Internet-Draft Agent Principal Binding August 2026
The profile verifier validates the artifact, challenge nonce,
realm and attestation-audience policy, purpose, holder or
presentation binding, replay rule, and the profile's unique-human
and handle-derivation requirements. Handle equality is evaluated
only within the exact continuity-scope tuple of realm, attestation
audience, and purpose. A profile revision is pinned evaluation
context rather than a fourth scope member; every profile offered
under the same tuple is required to produce the same handle for
the same verified human.
Binding and freshness
The presentation is evaluated under the selected profile and is
bound to the effective realm, effective attestation audience,
concrete purpose, and verifier-issued challenge nonce. In the
cited -00 draft, the attestation-audience value is the request's
canonical HTTPS origin; origin is not an additional scope member.
Challenge freshness establishes presentation freshness; it does
not by itself establish the lifetime, recovery semantics, or
cross-device stability of the continuity handle.
Accepted result
A valid presentation produced an opaque continuity handle for the
recorded continuity scope under the pinned profile. The result
does not establish real-world or account identity, human presence,
approval, authorization, application authority, agent delegation,
or authentication of the HTTP request. If policy needs to
associate the result with an authenticated agent or account
principal, that binding is a separate row.
Failure behavior
An invalid presentation yields unsatisfied. Missing metadata,
trust material, authoritative replay state, or another input
needed to complete an implemented check yields indeterminate. The
matrix refines the protocol's unverifiable state to unsupported
only when an explicit capability record or diagnostic establishes
that the pinned verifier lacks the required profile or algorithm;
a bare unverifiable result remains indeterminate. A check skipped
after a failed prerequisite yields not-evaluated only as a matrix
diagnostic when the evaluation pipeline can establish that fact.
Absence of a presentation is reported separately and is not
silently converted into invalid, unverifiable, or not-applicable.
Origin policy may choose the same HTTP disposition for several
states. Retaining their distinct stored outcomes is a mapping or
audit-policy requirement, not a requirement of the cited -00
protocol.
Status and evidence
Bu Expires 18 February 2027 [Page 38]
Internet-Draft Agent Principal Binding August 2026
Specification status: external and specified in
[I-D.brezun-human-continuity-http]. Implementation status: none
claimed here. Evidence type: document. A complete mapping should
add vectors for same-scope stability, cross-scope separation,
challenge mismatch, replay failure, unavailable verifier input,
unsupported profile, and omitted presentation.
24.4. 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
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. Coverage is evaluated against the specific requested
action. Every security-relevant element of that action MUST fall
within the grant's scope; partial overlap is not coverage of the
whole action. A grant broader than the action yields no stronger
accepted result than coverage of that action under the stated
constraints.
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
Bu Expires 18 February 2027 [Page 39]
Internet-Draft Agent Principal Binding August 2026
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.
24.5. External C-013 Mapping: Command Authority Envelope
This informative mapping is intentionally limited to the scoped
standing-grant claim in the Command Authority Envelope (CAE)
[I-D.morrison-ot-command-authority]. Other CAE mechanisms, including
request-signature authentication, per-action resolution, and audit
recording, belong in separate rows. Combining them into one
aggregate row would obscure which verifier establishes each result.
ID and claim
C-013. A consent grant referenced by a CAE covers the specific
requested action under its stated asset, resource, control-verb,
audience, constraint, validity-window, and revocation semantics.
Carrier
The CAE's consent-grant reference and the referenced consent
grant. A content-addressed reference is a locator and binding
aid; it is not itself the semantic authority decision.
Signer role and principal relationship
The grant issuer acts as the standing-authority issuer under the
deployment's enrollment and trust rules. The automated agent's
request-signing key is a separate signer and does not become the
grant issuer merely because the request signature verifies.
Verifier and rule
The conduit or relying policy component resolves the referenced
grant and verifies its issuer, integrity, scope, covered asset or
resource, permitted control verb, audience, constraints, validity
window, revocation state, and binding to the requested action.
Every security-relevant action element must be covered.
Bu Expires 18 February 2027 [Page 40]
Internet-Draft Agent Principal Binding August 2026
Binding, representation, and freshness
The mapping depends on the CAE profile defining how the consent-
grant reference and relevant CAE fields are encoded and integrity
protected. The current external draft leaves part of that
encoding and transport binding to profiles. Validity-window
checking does not establish current non-revocation unless status
evidence is also an input to the verifier.
Accepted result
The referenced standing grant covers this action under the
verified constraints. The result is not a per-action human
approval, proof that the physical effect occurred, or proof that
every CAE field was signature-covered unless the applicable CAE
profile specifies and verifies that coverage.
Failure behavior
Resolution failure, invalid issuer or integrity, stale or revoked
status, incompatible encoding, action-binding failure, or partial
scope overlap fails the C-013 row. Request-signature
authentication can still succeed as a separate row.
Status and evidence
Specification status: external and specified in
[I-D.morrison-ot-command-authority]. Implementation status: none
claimed here. Evidence type: document. The protocol's produced
audit record is an action-evidence carrier, not implementation or
interoperability evidence for this mapping.
25. 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
Bu Expires 18 February 2027 [Page 41]
Internet-Draft Agent Principal Binding August 2026
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
Bu Expires 18 February 2027 [Page 42]
Internet-Draft Agent Principal Binding August 2026
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.
26. 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
Bu Expires 18 February 2027 [Page 43]
Internet-Draft Agent Principal Binding August 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.
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. This failure
applies when those different byte strings are themselves protocol
inputs, such as inputs to another hash or signature.
Digest value compared as display text
Two components carry declared canonical encodings of a digest
value, but an implementation compares the display strings
directly. The verifier first confirms compatible digest contexts
and decodes each declared canonical representation to the
underlying digest octets. If those octets match, a hexadecimal-
versus-base64url display difference alone is not a value mismatch.
An unknown context, undeclared encoding, non-canonical encoding,
or decoding failure yields an indeterminate or refused binding
result rather than guessed equality.
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
Bu Expires 18 February 2027 [Page 44]
Internet-Draft Agent Principal Binding August 2026
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
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.
Bu Expires 18 February 2027 [Page 45]
Internet-Draft Agent Principal Binding August 2026
Post-hoc ratification presented as pre-execution authority
An action-specific approval or authorization artifact is created
only after the action took effect, but the application presents it
as proof that authority was accepted before execution. The C-002
row fails unless independently verified ordering evidence relates
both the authorization result and the effect. That evidence can
come from one independently authenticated record whose producing
boundary covered both terms and established their order.
Alternatively, it can come from two independently authenticated
records whose producing boundaries are related through the same
operation, jointly cover the authorization result and the effect,
and establish their order through a trusted sequencing mechanism.
Reconciliation that establishes only correspondence does not
establish temporal order. A timestamp produced beside the
signature observes only the signature and does not establish pre-
effect ordering by itself. A protocol rule requiring such gating
is a runtime requirement; the standalone authorization artifact
does not prove that an implementation followed it.
Attester assertion treated as named-principal authority
An enrolled attester signs a token asserting user verification,
but the application treats that assertion as proof that a specific
named human or organization authorized the action. The C-002 row
fails unless the verifier also checks the enrollment binding from
the attester to the named principal, the exact semantics attested
for user verification, the action binding, and the applicable
freshness and trust assumptions.
Available user-verification evidence not checked
A signed object carries a user-verification value and the
attestation surface can convey platform evidence establishing how
that value was enforced, but the verifier accepts the assertion
without checking the available evidence. The signature can
support an assertion-integrity result, but the human-presence or
platform-enforcement row is unsatisfied. The condition-removed
control checks the evidence and cross-checks the assertion before
returning an attested result.
Unavailable user-verification evidence reported as verifier
failure
The selected platform or profile cannot convey the evidence needed
to establish user-verification enforcement, but the result is
reported identically to a verifier that received and ignored such
evidence. The row returns unsupported when the pinned verifier or
profile lacks the required capability, or indeterminate when an
implemented evaluation lacks required evidence. It does not
return an attested result, and the limitation is not hidden as an
ordinary failed input check.
Bu Expires 18 February 2027 [Page 46]
Internet-Draft Agent Principal Binding August 2026
Scoped continuity handle treated as identity or authority
An application accepts a valid scope-local continuity handle as an
authenticator, real-world or account identity, human approval,
application authority, or agent delegation. The underlying C-014
presentation result remains satisfied; the stronger inference or
relying-party decision fails separately. A continuity result can
be consumed only for the scoped equality property established by
the pinned profile; every stronger claim requires a separate
verified row.
Continuity handles compared across incompatible scopes
An application compares, joins, or derives identity from otherwise
valid handles produced under different realms, attestation
audiences, or purposes. The underlying presentation results
remain satisfied; the attempted comparison fails separately. No
same-human or different-human conclusion can be derived across the
two scope tuples. Profile choice alone does not create a
different scope.
Continuity absence, invalidity, and unverifiability collapsed
An origin's mapping or audit record collapses absence, invalidity,
and unverifiability into one stored verifier outcome. The audit-
policy case fails because absence is separate, invalid maps to
unsatisfied, unavailable required input maps to indeterminate, an
explicitly evidenced capability limitation maps to unsupported,
and a provably skipped check may be recorded as not-evaluated.
Origin policy can choose the same HTTP response for several
conditions. The cited -00 protocol does not itself require
persistence of the original states.
Refusal consumes single-use authorization
A verifier or executor establishes that a single-use authorization
is available, provisionally reserves its replay identifier, and
then refuses because the exact action, subject, policy, or another
required check fails. The refusal nevertheless leaves the
identifier or its group recorded as consumed. The C-009 failure-
handling row and the C-011 accepted-result row are unsatisfied
because a presenter can burn a valid authorization without causing
its intended effect. The positive control releases every
provisional reservation on refusal and consumes the reliance unit
only after all required checks succeed and the executor is
committed to the effect. Section 4.1 of
[I-D.thallapelly-oasnt-caid] specifies one protocol example of
this boundary.
Reachable scenario hidden as not-applicable
Bu Expires 18 February 2027 [Page 47]
Internet-Draft Agent Principal Binding August 2026
A conformance report does not execute a security-relevant scenario
that can arise in the declared environment, but records it as not-
applicable. The evidence report fails because the scenario is
not-run and remains a gap. A not-applicable disposition is
permitted only when a reviewable implementation, profile, or
deployment fact excludes the scenario from that exact environment.
Post-observation exclusion rewrites the coverage denominator
A scenario is reachable under the pinned evaluation plan and is
not measured. After observing data that bears on the exclusion,
the reporting party introduces an exclusion and removes the
scenario from the denominator. The report fails because the
exclusion did not precede the affected observations. It remains
not-run in the original result and any later exclusion is a
versioned amendment that names the prior observations and states
its selection effect.
Amendment sequence has no predeclared stopping rule
A campaign records several individually dated and reasoned
corrections, each of which is reviewable, but no amendment policy
was pinned before the corrections began. The report fails because
a reviewer cannot distinguish a bounded correction process from
stopping when the result became favorable. Each amendment must
consume an allowance under the predeclared policy, and the
sequence must stop at that policy's limit.
Amendment allowance has no stated basis
A campaign predeclares an allowance of ten corrections and
consumes six without exceeding or reusing a slot. The record
still fails when it does not state whether the limit was derived
from campaign structure, based on a stated prior expectation, or
merely asserted. A finite value alone does not distinguish a
bounded correction design from a generously sized allowance
selected without a reviewable basis.
Reporter-asserted deployment exclusion presented as independently
verified
A report marks a deployment scenario not-applicable based on the
operator's account of its environment, but labels the excluding
fact as independently checkable. The report fails unless an
independent reviewer can evaluate the cited fact. Reporter-
asserted exclusions remain permitted when they are labeled and
bounded as such.
Evaluation-order-dependent result without a pinned plan
Two conformant implementations process the same input in different
orders. One reports a later check not-evaluated after an early
refusal; the other reaches the check and reports indeterminate for
Bu Expires 18 February 2027 [Page 48]
Internet-Draft Agent Principal Binding August 2026
missing input. A report that omits the evaluation-plan revision
or attempted order cannot distinguish either result from an
implementation defect and therefore remains indeterminate.
Verifier result collapsed into policy decision
A mapper or verifier returns indeterminate, not equivalent, or a
narrowly scoped verified result, and the application treats the
label itself as a refusal, authorization, retry permission, or
success. The test fails unless a separately stated relying-party
policy consumes the result and produces that decision.
Revision drift hidden by an implementation claim
Implementation or interoperability evidence was produced against
one draft revision, profile version, or source commit, but the
mapping reports it as evidence for a later revision without
rerunning the relevant positive and negative tests. The
implementation status remains pinned to the tested revision until
the evidence is refreshed.
Bounded regression stability presented as full conformance
A reference verifier is corrected for normative schema or protocol
requirements, but its previously published result tally does not
change because no row exercised the corrected paths. The
unchanged tally supports stability of the exercised rows only.
The implementation MUST NOT be reported as conformant unless
required fields, closed-schema or unknown-field behavior, value
types and ranges, parser ambiguity, fail-closed error handling,
replay state, and other applicable normative branches are covered
or independently verified.
Conveyed delegation bypassed by ambient authority
An agent presents a valid, narrowly scoped delegation, but can
reach the same resource through ambient credentials or another
authority path that does not enforce the delegation. Verification
establishes the scope of the authority that was presented; it does
not establish that the delegation governed the action. A relying
party MUST NOT make that stronger claim unless the enforcement
point binds the action to the delegated path or independently
excludes or accounts for alternative authority paths.
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.
Bu Expires 18 February 2027 [Page 49]
Internet-Draft Agent Principal Binding August 2026
Partial standing-grant overlap accepted as full coverage
A valid, unexpired, and unrevoked standing grant covers only part
of the requested action, such as one resource, control verb,
audience, or constraint in a compound request, but the application
accepts the whole action. The C-013 row fails unless every
security-relevant element of the specific requested action is
within the verified grant scope. A broader grant that fully
contains the action is accepted only for that action and does not
produce a stronger result because of its breadth.
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
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.
Cyclic dependency presented as mutual validation
Two or more rows rely on each other's accepted result, but no row
has an independently established base result. The composition
remains indeterminate unless a profile defines and satisfies a
trusted initial state and bounded convergence rule.
Bu Expires 18 February 2027 [Page 50]
Internet-Draft Agent Principal Binding August 2026
Transitive dependency failure laundered through an intermediate
row
Row A is unsatisfied, row B nevertheless reports a raw satisfied
outcome while depending on A, and critical row C reports satisfied
while depending on B. The test fails if C is accepted by checking
only B's raw outcome. A's failure propagates through B, making
both B and C effectively unsatisfied.
Stale dependency result substituted under the same row identifier
A consuming row names the correct dependency row but references a
prior result identifier or prior raw outcome. The composition is
indeterminate until the dependency reference identifies the exact
result presented and evaluated for the current binding.
Failed critical row omitted from an aggregate
A composition report includes only satisfied rows and omits a
required row that is unsatisfied, indeterminate, unsupported, not-
evaluated, not-applicable, unknown, or missing. The aggregate
MUST NOT be reported as satisfied under that profile.
Mixed evaluation contexts joined as one result
Rows carry the same action digest but were evaluated under
incompatible protocol revisions, policy revisions, trust inputs,
digest representations, or freshness bounds. The join fails until
the context mismatch is resolved or the composition profile
defines a safe transformation.
Expired or future-dated result used at the decision boundary
A row result expired before the relying-party decision time, or
claims an evaluation time after that decision. The result is
indeterminate for that decision even if its accepted-result syntax
and signature are otherwise valid.
Mapping-set revision substituted after result production
A row result was produced under a different mapping-set revision
from the composition request. The test fails if matching row
names are used to import the result without re-evaluating the
changed criticality, dependencies, verifier profile, and accepted-
result scope.
Unauthenticated verifier result substitution
A syntactically valid accepted result is supplied by a different
verifier, profile, or administrative boundary than the relying
component expects. The result is indeterminate or refused unless
its producer, scope, binding, revision, and freshness are
authenticated.
Unknown critical row ignored during profile downgrade
Bu Expires 18 February 2027 [Page 51]
Internet-Draft Agent Principal Binding August 2026
A peer selects an older mapping profile that does not recognize a
critical claim or row and then reports the remaining subset as
satisfied. The aggregate fails unless downgrade policy explicitly
preserves every required security property.
27. 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.
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.
28. 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.
Bu Expires 18 February 2027 [Page 52]
Internet-Draft Agent Principal Binding August 2026
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.
29. 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;
* 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.
Bu Expires 18 February 2027 [Page 53]
Internet-Draft Agent Principal Binding August 2026
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.
Verifier-produced results need integrity, producer authentication,
scope, revision, and freshness protection when they cross process,
administrative, or protocol boundaries. Authenticating the original
claim carrier does not authenticate a later normalized result unless
the result itself is protected or consumed inside the verifier's
trusted boundary.
Composition logic should treat unknown critical rows, unresolved
dependencies, dependency cycles, and incompatible evaluation contexts
as indeterminate or failed according to the applicable profile. It
MUST NOT discard those states merely because another row or aggregate
signature verifies successfully.
Dependency evaluation MUST use effective outcomes over the full
transitive closure, not raw success values at only the immediately
referenced edge. Otherwise an intermediate row can launder an
earlier failure into a successful critical result. Result
identifiers and mapping-set revision pins reduce accidental or
adversarial substitution, but they provide security only when
protected by the result producer's authenticated channel or signed
result format.
The relying party also needs to protect profile selection. Accepting
a mapping set that removes a required claim, changes a critical row
to non-critical, weakens the expected verifier, or broadens the
aggregate accepted-result scope can be a security downgrade even when
every supplied row validates under the newly selected profile.
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 18 February 2027 [Page 54]
Internet-Draft Agent Principal Binding August 2026
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.
30. 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.
Machine-readable mapping sets can create additional linkability when
they expose stable row identifiers, verifier identities, policy
revisions, dependency graphs, or long-lived evidence references.
Published mapping sets should minimize deployment-specific
identifiers and distinguish review metadata from values that need to
appear in protocol messages.
31. 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.
Bu Expires 18 February 2027 [Page 55]
Internet-Draft Agent Principal Binding August 2026
32. 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
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.
A version-pinned application of this document to [I-D.gebauer-iacp]
expands the thirteen claim classes into seventeen verifier-role rows.
Separate rows are needed for peer and local instance identity,
equivocation and payload evidence, generation and escrow freshness,
and L4 and L7 standing-grant processing. In particular, the L4
result is limited to structural forwarding of an opaque envelope and
is explicitly not a C-013 standing-grant result. The L7 result
requires issuer and signature validation, subject and request
binding, exact resource and verb coverage, constraints, expiry, and
revocation checks.
The public protocol-flow demonstration was reviewed at commit
9883bdfd0c346a42b1e464164da15cedb7c86d51, with the evaluated
iacp_direct.py file pinned by SHA-256
d6ab1b1a09846dc03515415179b696285f0282a651b4817b21f6acbe9dbfed03. A
set of twenty-two executable vectors covered positive handshake and
payload paths, signature enforcement, expected peer identity, cookie
transcript matching, payload integrity, replay, state mutation,
malformed input, fragmentation, and coalescing. Nine observations
met the required behavior and thirteen did not. The deviations
included receive paths accepting invalid signatures, an unexpected
Bu Expires 18 February 2027 [Page 56]
Internet-Draft Agent Principal Binding August 2026
sender EID, mismatched or zero cookies, modified ciphertext or MAC
values, and data protected under another session key; loss of the
second coalesced frame; and receive-state advancement before
malformed encrypted payloads were rejected. These results are
evidence only for the exact source revision and exercised paths.
They are not a protocol-security, conformance, interoperability, or
deployment result.
Four additional IACP Appendix D failure cases concerning opaque
authorization envelopes, unevaluated USIV pointers, reported
outcomes, and wrong-scope, expired, or revoked grants remain
specification-level vectors because the pinned demonstration does not
implement their L4, L7, USIV, policy-verdict, physical-observation,
or status-verification components. The same review found a C-011
reference defect: the evidence column cites Section 4.1.5.3 while the
current IACP revision ends that subsection series at Section 4.1.5.2.
The C-011 verdict encoding, verifier and policy binding, and
consumption contract therefore remain explicit mapping dependencies
rather than tested implementation results.
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
Bu Expires 18 February 2027 [Page 57]
Internet-Draft Agent Principal Binding August 2026
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.
33. 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 future profile standardize a machine-readable mapping-set
schema, or should implementations continue to exchange
independently versioned companion artifacts?
* How should a future profile express alternatives, thresholds, or
other Boolean composition rules without allowing a profile change
to weaken required claims or hide transitive failures?
* 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 18 February 2027 [Page 58]
Internet-Draft Agent Principal Binding August 2026
* 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?
* 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?
34. Changes from -05
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.
* Required a not-applicable evidence disposition to identify the
exclusion source, asserting party, immutable reference,
reviewability, affected evidence set, and declaration time
relative to the observations that bear on the exclusion.
* Prohibited post-observation exclusions from retroactively changing
the original coverage denominator and required versioned
amendments to identify prior observations and state their
selection effect.
* Required a finite amendment policy to be pinned before corrections
begin, with each post-observation amendment consuming a declared
allowance without exceeding or reusing its ordinal, and required
each allowance limit to carry a typed, explicit basis. A stated
prior expectation now requires an immutable reference whose
temporal priority to the affected observations can be established.
Bu Expires 18 February 2027 [Page 59]
Internet-Draft Agent Principal Binding August 2026
A campaign-structure- derived basis now requires immutable
references to both the campaign property and the derivation rule,
and degrades to reporter-asserted when the relationship cannot be
independently established.
* Separated independently checkable architectural or profile facts
from reporter-asserted deployment facts without prohibiting
either.
* Required evaluation-plan context when processing order can change
whether a row is not-evaluated or indeterminate.
* Added negative cases for post-observation denominator rewriting,
amendment sequences without a predeclared stopping rule, allowance
limits without a stated basis, misrepresented deployment
exclusions, and evaluation-order-dependent results without a
pinned plan.
* Refined the OASNT-CAID review vectors to distinguish contextual
from intrinsic refusal causes, require recorded overlap and
repeated runs for the concurrent single-use behavior test, state
the expiry-twin applicability precondition, and count the
unpublished group case as not-run while excluding it from row
evidence until a published enforcement profile defines its
semantics.
* Corrected the Human Continuity mapping so the scope is exactly
realm, attestation audience, and purpose; treated profile revision
as evaluation context; preserved valid C-014 presentation results
when a downstream identity or authority inference fails; and
labeled diagnostic, applicability, and storage requirements at
their proper layers.
35. 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,
schema- validation and replay-state review, and inheritance-target
treatment for artifact-layer mechanisms. The author thanks Sumit
Ahuja and Bradley B for review that made amendment-allowance
provenance and its independently checkable derivations explicit. The
Bu Expires 18 February 2027 [Page 60]
Internet-Draft Agent Principal Binding August 2026
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 and for identifying the C-013 partial-overlap failure
case.
The author thanks Mohamad Khalil-Yossif for protocol-mapping review
and public correction of reference-verifier coverage that motivated
explicit signer-role, output-representation, user-verification,
evidence-coverage, and pre-execution-ordering boundaries.
The author thanks Lars Kersten Kroehl for a byte-pinned prepared
verifier-seam mapping that clarified the status boundary between
separate successful mappings and a completed independent cross-run.
The author thanks Barak Shelef for identifying the distinction
between verifying a conveyed delegation and establishing that the
action was governed by that delegation when ambient authority remains
available.
The author thanks Mikhail Sergeev for review that clarified the
coverage and temporal-order requirements for single-record and two-
record pre-execution evidence, including why reconciliation alone
cannot establish that authorization preceded an effect, and for
distinguishing available appraisal evidence that a verifier failed to
check from evidence that a constrained platform cannot convey. The
author also thanks him for distinguishing independently checkable
exclusions from deployment facts that rely on the reporting party's
account of its environment.
The author thanks Michael Msebenzi for separating standing verifier
capability limitations from checks not reached for a particular
input, for identifying the authority boundary of not-applicable
assertions, and for showing why evaluation order can be part of a
verifier result. The author thanks Sumit Ahuja for replacing a
single-run timing assumption with an observation-relative boundary
for multi-stage campaigns, and for showing why a predeclared
Bu Expires 18 February 2027 [Page 61]
Internet-Draft Agent Principal Binding August 2026
amendment stopping rule is needed in addition to complete per-
amendment disclosure, and why the allowance limit itself needs a
stated provenance. The author thanks Bradley B for showing why that
provenance can terminate as an enumerated type without recursive
justification, why a stated prior expectation still needs a reference
that establishes its temporal priority, and why the capability-
versus-reachability distinction needs an executable negative case
rather than only explanatory prose. The author thanks Aurélien
Brézun for identifying scoped human continuity as a claim distinct
from human identity, presence, approval, and authority; for
clarifying that the attestation audience, not origin as a separate
member, belongs in the three-part scope; and for separating
presentation outcomes from downstream misuse, matrix diagnostics,
applicability decisions, and audit policy.
The author thanks Arun Thallapelly for distinguishing reachable but
unexecuted scenarios from scenarios excluded by the test environment,
and for contributing the OASNT-CAID consume-on-refusal case as a
concrete protocol-specific negative vector.
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.
36. References
36.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,
<https://www.rfc-editor.org/info/bcp14>.
[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>.
36.2. Informative References
Bu Expires 18 February 2027 [Page 62]
Internet-Draft Agent Principal Binding August 2026
[I-D.brezun-human-continuity-http]
Brézun, A., "Human Continuity for HTTP", Work in Progress,
Internet-Draft, draft-brezun-human-continuity-http-00, 6
August 2026, <https://datatracker.ietf.org/doc/draft-
brezun-human-continuity-http/>.
[I-D.gebauer-iacp]
Gebauer, L., "Internet Agent Communication Protocol", Work
in Progress, Internet-Draft, draft-gebauer-iacp-03, 28
July 2026,
<https://datatracker.ietf.org/doc/draft-gebauer-iacp/>.
[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.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,
<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.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/>.
[I-D.morrison-ot-command-authority]
Morrison, B., "Command Authority Envelope for Agent-
Originated Operational-Technology Actions", Work in
Progress, Internet-Draft, draft-morrison-ot-command-
authority-01, July 2026,
<https://datatracker.ietf.org/doc/draft-morrison-ot-
command-authority/>.
Bu Expires 18 February 2027 [Page 63]
Internet-Draft Agent Principal Binding August 2026
[I-D.rampalli-scitt-capsule-provenance-binding]
Rampalli, K., "Binding Per-Action Authorization and Memory
Provenance into Agent Action Capsules", Work in Progress,
Internet-Draft, draft-rampalli-scitt-capsule-provenance-
binding-00, 4 July 2026,
<https://datatracker.ietf.org/doc/draft-rampalli-scitt-
capsule-provenance-binding/>.
[I-D.thallapelly-oasnt-caid]
Thallapelly, A., "Canonical Action Identifiers for OASNT",
Work in Progress, Internet-Draft, draft-thallapelly-oasnt-
caid-01, 5 August 2026, <https://datatracker.ietf.org/doc/
draft-thallapelly-oasnt-caid/>.
[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,
<https://datatracker.ietf.org/doc/draft-winmagic-wimse-
condition-bounded-credentials/>.
[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>.
[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>.
Author's Address
Songbo Bu
Email: bluedognull@gmail.com
Bu Expires 18 February 2027 [Page 64]