A Layered Requirements Mapping for Cross-Organization Agent Delegation
draft-rampalli-cross-org-delegation-mapping-05
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 | KARTHIK RAMPALLI | ||
| Last updated | 2026-07-06 | ||
| 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-rampalli-cross-org-delegation-mapping-05
Network Working Group K. Rampalli
Internet-Draft Glyphzero, Inc.
Intended status: Informational 6 July 2026
Expires: 7 January 2027
A Layered Requirements Mapping for Cross-Organization Agent Delegation
draft-rampalli-cross-org-delegation-mapping-05
Abstract
This document records a comparative mapping of two evidence layers
for cross-organization AI agent delegation: a per-hop delegation
chain (PEDIGREE) and a named-human authorization root (the EMILIA
Protocol binding and evidence-graph drafts), evaluated against the
nine requirements of draft-reece-wimse-cross-org-delegation under a
no-shared-operator assumption. It also records a verifier-facing
composition model in which key possession, delegated authority, and
pre-execution human authorization are diagnostically separate inputs
with independent failure behavior, joined by action digest. The
mapping was developed on the WIMSE mailing list; corrections continue
there.
Status of This Mapping
This document is a point-in-time record of a mailing-list discussion.
Verdicts apply to the specific draft revisions cited and do not carry
forward to later revisions automatically. The canonical venue for
corrections is the WIMSE mailing list; agreed corrections will be
folded into future revisions of this document.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 January 2027.
Rampalli Expires 7 January 2027 [Page 1]
Internet-Draft Layered Delegation Mapping July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Assumptions and Verdict Discipline . . . . . . . . . . . 3
2. Combined Requirements Mapping . . . . . . . . . . . . . . . . 3
2.1. Summary Table . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Row Notes . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Verifier-Facing Composition: Diagnostically Separate
Inputs . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. The Delegation-Chain Row, Stated Explicitly . . . . . . . 9
3.2. The Human-Authorization Row, Stated by Its Supplier . . . 10
3.3. The Possession Row, Stated by Its Supplier . . . . . . . 11
3.4. Template Compatibility . . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Informative References . . . . . . . . . . . . . . . . . . . 14
Changes Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 15
Changes Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 16
Changes Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 16
Changes Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 16
Changes Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Requirements R1 through R9 of [I-D.reece-wimse-cross-org-delegation]
describe what cross-organization delegation of authority to AI agents
must provide when the relying party and the originating organization
share no operator, no runtime, and no bilateral agreement specific to
the interaction. During the July 2026 discussion of those
requirements on the WIMSE mailing list, two candidate mechanisms were
mapped against them independently and were then found to occupy
different layers of the same problem:
Rampalli Expires 7 January 2027 [Page 2]
Internet-Draft Layered Delegation Mapping July 2026
* a delegation-chain layer, in which authority conveyed by a root
principal is narrowed at every hop and re-verified end-to-end by
the relying party ([I-D.rampalli-pedigree]); and
* a human-authorization root layer, in which a named human, or an
M-of-N quorum of distinct humans, authorizes a specific action,
and that evidence is bound into agent-action records and evaluated
with fail-closed verdicts
([I-D.schrock-human-authorization-binding],
[I-D.schrock-ep-action-evidence-graph]).
Neither layer claims the other's property. The chain proves that
authority was conveyed and attenuated; the root layer proves that an
accountable human authorized the act. Where the two meet, they join
by digest equality, and digest equality is a join key, not a claim of
sufficiency.
This document records the combined mapping (Section 2) and the
verifier-facing composition model that the discussion converged on
(Section 3). It defines no protocol and no new evidence format.
1.1. Assumptions and Verdict Discipline
The no-shared-operator assumption applies throughout. Each verdict
states what holds offline and unconditionally versus what depends on
a named assumption, following the conditional form requested in the
originating thread. Several entries are not clean passes and are
marked as such; deployments should read a "met" verdict together with
its stated condition, never without it.
2. Combined Requirements Mapping
2.1. Summary Table
"Chain" is the delegation layer ([I-D.rampalli-pedigree]). "Root" is
the human-authorization layer
([I-D.schrock-human-authorization-binding],
[I-D.schrock-ep-action-evidence-graph]). The composition column
states how the layers relate on that row.
+===+=================+========================+====================+
|Req|Chain (PEDIGREE) |Root (EP) |Composition |
+===+=================+========================+====================+
|R1 |Met; inline |Out of layer by design |Chain-only property |
| |conveyance | | |
| |condition | | |
+---+-----------------+------------------------+--------------------+
|R2 |Conditional: met |Conditional, mechanism |Both layers name |
Rampalli Expires 7 January 2027 [Page 3]
Internet-Draft Layered Delegation Mapping July 2026
| |only when the |specified (the |general, non- |
| |deployment pins a|authority-introduction |bilateral |
| |general anchor- |companion draft, cited |mechanisms, served |
| |trust mechanism |in the row note; |from the org origin |
| |usable by any |Informational; public |and transparency- |
| |party without |implementation with |logged, and state |
| |per-counterparty |tests). Authority |the assumption |
| |negotiation. A |Document: signed, hash- |explicitly, |
| |general channel |chained, sequence- |narrowing R2. |
| |is named as one |numbered key |Shared residual: the|
| |conforming way |declaration served from |first-contact |
| |but not required,|the org origin and |bootstrap, coming to|
| |and static per- |registrable to a |trust an originating|
| |counterparty |transparency log; |anchor for an |
| |provisioning is |rotations carry a |organization with no|
| |admitted, which |normative continuity |prior arrangement. |
| |relocates rather |signature (MUST be |Narrowed, explicit |
| |than discharges |flagged if absent), and |open item, not a |
| |R2. Same profile|artifacts resolve the |satisfied |
| |move as R1 inline|key valid at issuance. |assumption. |
| |conveyance. |Acceptance is graded | |
| | |per action class over | |
| | |introduction evidence | |
| | |(chain consistency, | |
| | |domain binding, | |
| | |transparency-log | |
| | |inclusion and age, | |
| | |pinned-anchor | |
| | |endorsements), widening | |
| | |mechanically as history | |
| | |accrues with no | |
| | |relying-party | |
| | |reconfiguration. | |
| | |Residual, admitted in | |
| | |the draft: first | |
| | |contact is made | |
| | |checkable, not | |
| | |eliminated. Met for | |
| | |lower-consequence | |
| | |classes; high- | |
| | |consequence cross-org | |
| | |actions between parties | |
| | |with no shared pinned | |
| | |anchor or logged | |
| | |history remain open. | |
+---+-----------------+------------------------+--------------------+
|R3 |Met offline given|Met offline |Both fail closed |
| |conveyance |(deterministic policy |rather than fetch |
Rampalli Expires 7 January 2027 [Page 4]
Internet-Draft Layered Delegation Mapping July 2026
| | |replay) | |
+---+-----------------+------------------------+--------------------+
|R4 |Deferred to |Not addressed |Shared gap: neither |
| |transport (proof | |layer proves |
| |of possession at | |possession; WIMSE- |
| |the wire) | |native answers at |
| | | |the wire are WPT and|
| | | |HTTP message |
| | | |signatures; composed|
| | | |stack: possession at|
| | | |the wire, |
| | | |attenuation along |
| | | |the chain, human |
| | | |authorization at the|
| | | |root. The |
| | | |possession row is |
| | | |now supplied by name|
| | | |(Section 3.3) |
+---+-----------------+------------------------+--------------------+
|R5 |Invariance along |Native to the artifact |Root proves who; |
| |the chain (re- |(single or quorum); B2 |chain proves nobody |
| |verification) |ties it to the host |swapped them |
| | |record | |
+---+-----------------+------------------------+--------------------+
|R6 |Conjunction |Policy identity plus |Entitlements stay |
| |native; |replay; entitlements |relying-party data |
| |entitlements |relying-party local | |
| |relying-party | | |
| |local | | |
+---+-----------------+------------------------+--------------------+
|R7 |Lifetime bound |Normative fail-closed: |Root layer closes |
| |offline; fail- |a stale verdict never |the gap the chain |
| |closed on stale |authorizes; B4 |layer names |
| |revocation data | | |
| |is an admitted | | |
| |revision item | | |
+---+-----------------+------------------------+--------------------+
|R8 |Signed hops; |Evidence graph; |Join by digest: |
| |SCITT capsule |unbacked edges poison; |scope versus act, |
| |binding for the |signed Reliance Result |neither claims the |
| |post-execution | |other's property |
| |half | | |
+---+-----------------+------------------------+--------------------+
|R9 |Met (JWT/JOSE, |Met (JSON/JCS, maps |No new formats on |
| |pluggable policy)|onto existing host |either side |
| | |formats) | |
+---+-----------------+------------------------+--------------------+
Rampalli Expires 7 January 2027 [Page 5]
Internet-Draft Layered Delegation Mapping July 2026
Table 1: Combined R1-R9 Mapping
The R5 and R4 cells reflect corrections agreed on-list on 2026-07-05:
the named-human and quorum property is native to the receipt and
quorum artifacts themselves, with binding requirement B2 tying the
artifact's action binding to the host record; and R4's composition
cell carries the constructive composed-stack line alongside the
shared-gap statement.
2.2. Row Notes
The full per-layer mappings live in the originating thread; these
notes carry only what the one-line verdicts compress too much.
R1, recursive attenuation:
The chain meets it from conveyed material alone: per-hop scope
subsetting and mandate narrowing are re-checked at verification,
not only at mint, and the verifier re-verifies every parent token.
The condition is inline conveyance of parents. The root layer
does not narrow scope, and should not: it names the human and
binds the action. A division of labor, not a gap.
R2, cross-organizational verification:
Row text contributed by the requirements author (2026-07-05),
included verbatim. Reframed per his correction: pinning the
originating anchor relocates the assumption rather than
discharging it; the load-bearing part is how the relying party
comes to trust that anchor. R2 is met only when the anchor
arrives through a general mechanism any party can use without per-
counterparty negotiation (public transparency log, open
federation, verifiable credential from a recognized issuer, or
trust-domain discovery), and the row names the mechanism. An
anchor arranged in advance between the two organizations moves the
forbidden bilateral agreement into the provisioning step.
Both layers have moved from bare open items toward explicit
mechanisms. The chain layer names a general channel but does not
require it and admits static provisioning, so its verdict is
conditional on pinning a general mechanism. The root layer
specifies one ([I-D.schrock-ep-authority-introduction]): a signed,
hash-chained authority document served from the org origin and
transparency-logged, with normative continuity on rotation, keys
resolved at issuance, and graded per-action-class acceptance in
which un-pinned issuers never receive full acceptance and high-
consequence actions still require a pinned anchor.
Rampalli Expires 7 January 2027 [Page 6]
Internet-Draft Layered Delegation Mapping July 2026
Both narrow R2 honestly and make the residual explicit. The
shared residual is the first-contact bootstrap: domain binding is
worth what Web PKI is worth, log consistency is worth what the log
operator is worth, and endorsements are worth nothing until the
relying party pins one, so trust is not created from nothing. R2
is therefore conditional and narrowed, met for lower-consequence
classes when a general channel is pinned, with the high-
consequence cross-org bootstrap an explicit open item, not a
satisfied assumption.
R4, proof of possession:
The one row where the layers do not cover each other: neither
proves possession. The chain binds the holder's key and defers
the presentation-time proof to the transport (a WPT
[I-D.ietf-wimse-s2s-protocol], HTTP message signatures [RFC9421],
or a context-bound per-request token); the root layer addresses
evidence binding, not possession. A deployment composing both
layers still needs a possession-proving transport underneath,
which is why the transport profile holds a first-class seat in the
composition model of Section 3.
R5, principal binding and invariance:
The mirror image of R1. The root layer is native here: an
accountable named human, or a quorum, signs, and the artifact's
action binding must agree with the host record. The chain's
contribution is preservation: re-verification of every hop means
an intermediary cannot alter the principal without breaking a
signature it cannot forge. The root proves who authorized; the
chain proves nobody swapped them en route.
R7, authentic bounded-staleness revocation:
On the chain side, staleness is bounded by lifetime, offline and
unconditionally; event-driven cascade revocation rides a channel
assumption; and fail-closed behavior on stale revocation data is
an admitted gap, scheduled for the next PEDIGREE revision. On the
root side the discipline is already normative: freshness bounds
are policy inputs, the verdict set is closed with precedence
unverifiable over conflicted over stale over missing_evidence over
admissible, and the absence of evidence is insufficient rather
than a default. The root layer closes, by construction, exactly
the gap the chain layer names. When the chain layer states the
same rule normatively, this row becomes two independent
enforcements of one rule rather than one layer covering for the
other.
R8, tamper-evident composable audit:
The chain proves scope: every hop is a signed object, and post-
execution composition binds per-action authorization and
Rampalli Expires 7 January 2027 [Page 7]
Internet-Draft Layered Delegation Mapping July 2026
provenance references into SCITT Agent Action Capsules
([I-D.rampalli-scitt-capsule-provenance-binding]), with the
anchored tier assuming a transparency service. The evidence layer
proves the act: a content-addressed graph in which an edge the
bytes do not back poisons the verdict, plus a signed Reliance
Result that adds accountability, never authority. They join by
digest equality.
R3, R6, R9:
As the table states; the per-layer mappings in the originating
thread carry the detail.
3. Verifier-Facing Composition: Diagnostically Separate Inputs
The same list discussion, on a parallel thread about condition-
bounded credentials, converged on a verifier-facing structure in
which the inputs to an authorization decision are conjunctive for the
final decision but diagnostically separate, so that each input class
has its own failure path:
* enrolled key, actor, workload, and environment binding;
* live key possession at connection time;
* local condition failure and key unavailability;
* external lifecycle or policy events, such as a Shared Signals /
CAEP-class channel;
* authorization inputs: audience, scope, operation, and time bounds;
* an inherited delegation-chain input, where PEDIGREE or another
chain mechanism supplies the authority path; and
* pre-execution human authorization: a named human, or an M-of-N
quorum of distinct humans, authorized this exact operation, bound
to the same action digest the other rows join on; and
* application acceptance: the relying party's own decision to accept
the action, taken over the other inputs and separate from all of
them.
Rampalli Expires 7 January 2027 [Page 8]
Internet-Draft Layered Delegation Mapping July 2026
A live key with a valid, sufficiently scoped chain still fails closed
if a required human authorization is absent, stale, or bound to
different action bytes; a valid chain whose holder cannot prove
possession fails as a presentation failure; a valid key whose
terminal scope does not cover the operation fails as an authorization
failure. The inputs are conjunctive for the final decision but
diagnostically separate, and no row inherits or grants another row's
guarantees.
Three boundaries surfaced on-list keep the rows from collapsing into
one another, and they share one shape: the same action digest,
different claims, independent failure. Presence versus approval: the
human verified present at a platform (the possession row) is not the
human who approved this operation (the human-authorization row),
often the same person, never the same row. Attribution versus
approval: a post-execution record of who is accounted to have
delegated or performed an action is not a pre-execution approval of
it. May versus did: authorization that an action was permitted is
not evidence that it occurred. A verifier must be able to affirm or
fail each independently; digest equality joins them, and digest
equality is a join key, not a claim of sufficiency.
3.1. The Delegation-Chain Row, Stated Explicitly
The mapping-table rules of
[I-D.bu-agentproto-security-principal-binding] require that an
inherited mechanism state its dependency and failure behavior before
it counts as a guarantee. The delegation-chain row, with PEDIGREE as
the supplier, in those terms:
Claim: authority for this exact operation was conveyed from the root
principal and narrowed at every hop; the terminal scope covers the
operation.
Carrier: the per-hop delegation tokens, conveyed inline with the
request.
Verifier and rule: the relying party, offline: re-verify each hop's
signature against its issuer key, check per-hop scope subsetting
and mandate narrowing, take effective expiry as the minimum over
hops, and require the operator-ceiling conjunct.
Binding and freshness: bound to the root principal and to the
holder's key; staleness bounded by chain lifetime; cascade
revocation rides a Shared Signals / CAEP-class channel where one
exists.
Failure behavior: any hop signature failure, subset violation, or
Rampalli Expires 7 January 2027 [Page 9]
Internet-Draft Layered Delegation Mapping July 2026
expiry fails the request as an authorization failure,
independently of key possession and of human authorization. A
revocation feed older than the configured bound must fail closed;
making that normative is a scheduled PEDIGREE revision item.
Dependency: the originating organization's trust anchor (root only;
intermediate hops use self-certifying identifiers), inline
conveyance of parent tokens, and the possession row at the
transport for holder proof.
Stated that way, nothing is inherited implicitly: the chain row
supplies the authority path and its attenuation, and it explicitly
depends on the possession row rather than assuming it.
3.2. The Human-Authorization Row, Stated by Its Supplier
Iman Schrock contributed the human-authorization row on-list on
2026-07-05, stated in the same template terms as the chain row. It
is included here with only editorial normalization.
Claim: a named, accountable human, or an M-of-N quorum of distinct
humans, optionally ordered, authorized this exact operation before
execution; asserted as human authority, not organizational policy,
and the row names which.
Carrier: the authorization receipt (EP-RECEIPT-v1, or EP-QUORUM-v1
for multi-party), a self-contained signed JSON artifact conveyed
inline or referenced by digest from the host record.
Verifier and rule: the relying party, offline, with no account:
Ed25519 over the canonical action bytes (JCS [RFC8785]) against a
pinned issuer key; for a quorum, threshold met by distinct
principals over the same digest, with order enforced when
declared. Verified and accepted remain separate results, and
neither implies sufficiency.
Binding and freshness: bound to the action digest (the shared join
key; digest equality is a join key, never authorization) and to
the named principal, with a validity window on the artifact. One-
time use is enforcement-point state, not offline-verifiable; the
state holder is named in the dependency, so the offline part and
the enforcement part stay visible separately.
Failure behavior: missing, invalid, stale, replayed, or out-of-scope
Rampalli Expires 7 January 2027 [Page 10]
Internet-Draft Layered Delegation Mapping July 2026
evidence fails the request as a human-authorization failure,
independently of key possession and of chain attenuation. The
refusal is machine-readable (an HTTP 428 challenge [RFC6585]
naming the missing evidence), so a refusal is itself evidence, not
silence.
Dependency: relying-party key pinning (a binding from an unpinned
issuer must not be accepted); an enforcement point for one-time
consumption, deployed by the resource owner; and holder proof at
presentation rides the possession row at the transport, the same
shared dependency recorded at R4. The row makes no possession
claim of its own.
Evidence: public vectors, positive and negative (receipt and quorum
suites in the EP reference repository), reproducible with the ep-
verify tool.
One asymmetry, stated rather than papered over: the chain row of
Section 3.1 does not yet cite public evidence vectors, and its
evidence entry is open until vectors are published. An evidence
column is only useful if an empty cell is allowed to say so.
3.3. The Possession Row, Stated by Its Supplier
This is the possession row as reconciled on-list by its supplier
(Nguyen-Huu and Bu, 2026-07-06), stated in the same template terms,
together with the split the rows sit on: one authentication anchor,
several authorization inputs decided above the key. It is included
as reconciled, with only editorial normalization.
Claim: the presenter is the genuine attested actor or workload at
this hop, and its signing key exists only while its attested
release conditions currently hold (right user present, platform
sound, workload genuine). This proves live possession under
configured conditions; it does not by itself prove delegated
authority, human authorization, operation scope, action
sufficiency, or relying-party acceptance of the action. Not "a
key answered the handshake," but "a key whose continued existence
is those conditions answered."
Carrier: the mTLS possession proof (the CertificateVerify signature
over the handshake, on a hardware-bound key registered with the
relying party; raw public key or certificate, or X.509-SVID,
immaterial to this row), together with the enrollment and
attestation material binding the actor/workload/environment tuple,
the protected key, and the key-release policy. The signature is
producible only if the release policy is satisfied at that
instant.
Rampalli Expires 7 January 2027 [Page 11]
Internet-Draft Layered Delegation Mapping July 2026
Verifier and rule: the relying party, sidecar, gateway, or verifier,
offline, per connection: validate the key against the enrolled
trust bundle it already holds, with no per-connection issuer call,
and take a completed handshake as possession under the current
condition. The attestation and enrollment evidence, bound at
enrollment and re-attestation, explains why that key is usable
only while the stated conditions hold. A cryptographic fact
prepared ahead of time, not a policy claim made in the moment.
Binding and freshness: bound to the platform (the key cannot exist
outside its boundary), to the enrolled actor/workload/environment
tuple and release policy, and, where present, to the verified
human at that platform (distinct from the approving human in the
human-authorization row: one is present, the other approved the
action). Freshness is condition-liveness, not a validity window:
the entity that assesses the condition and the entity that
withdraws the key are the same, the endpoint, so validity ends by
absence, with no revocation message to travel or go stale. The
condition is re-proven at every key agreement, and this is
airtight at key-agreement granularity: key erasure guarantees the
next key agreement fails. At connection granularity it must be
stated, not assumed: an in-flight connection is not torn down by
key absence alone, the same boundary a rotated certificate has, so
immediate termination of a long-lived connection after a condition
change is a separately specified behavior, delivered by bounding
connection lifetime or driven from the event channel.
Failure behavior: missing or invalid enrollment or attestation
evidence, stale lifecycle state beyond the configured bound, local
condition failure that makes the key unavailable, or failure to
prove possession, all fail as a possession/condition failure,
independent of delegation-chain failure and of human-authorization
failure. For locally detectable failure no message travels;
absence enforces. Distrust of a still-sound platform decided
elsewhere rides a CAEP-class channel, as the other rows' external
inputs do.
Dependency: the hardware or protected key-release mechanism
enforcing "cannot exist outside its boundary"; the attestation
verifier or enrollment authority; and any lifecycle or event
channel used for externally originated change. The row makes no
authority claim of its own: it supplies the holder proof the
delegation-chain and human-authorization rows depend on at the
transport, and nothing more.
Evidence: reference implementation at github.com/WinMagic/LIT. The
Rampalli Expires 7 January 2027 [Page 12]
Internet-Draft Layered Delegation Mapping July 2026
verified-human presence-bound path is demonstrated. The workload
path is not yet implemented, and this cell says so. When the
workload vectors publish they will carry this row's negative
analogue in the shape the thread set (transport attempted,
required condition unmet, possession fails closed), the
possession-layer counterpart to the composition negative the root
layer already ships.
With this reconciled row, every layer of the composed stack is stated
by its supplier: possession under condition at the wire, attenuation
along the chain, human authorization at the root, each failing
independently, all joined on the same action digest. In this row
freshness is liveness rather than a window, because the assessor of
the condition and the stopper of the grant are the same place.
3.4. Template Compatibility
Each row of Table 1 and each input class above is kept expressible in
the mapping-table template of
[I-D.bu-agentproto-security-principal-binding] (claim, carrier,
verifier and rule, binding and freshness, failure behavior,
dependency, evidence reference). If the working group settles on
that shared shape for comparative tables, moving this document into
it is a re-rendering rather than a rewrite.
4. Security Considerations
This document defines no protocol elements and introduces no new
attack surface. Its risks are risks of misreading:
* A conditional verdict read as unconditional. Every "met" in
Table 1 carries its stated condition; a deployment that drops the
condition (for example, accepting a chain without inline
conveyance of parents, or trusting an unpinned issuer) does not
have the property the verdict names.
* Implicit inheritance across layers. The layers compose by digest
and by conjunction; neither inherits the other's guarantees, and
Section 3 exists precisely to keep their failure classes separate.
In particular, neither layer proves possession (R4); a deployment
without a possession-proving transport is open to replay of
captured material regardless of how strong the chain and the root
evidence are.
* Version drift. Verdicts apply to the cited revisions only. A
future revision of any mapped draft can invalidate a row without
notice; the mailing-list thread, not this document, is the
canonical record of corrections between revisions.
Rampalli Expires 7 January 2027 [Page 13]
Internet-Draft Layered Delegation Mapping July 2026
5. IANA Considerations
This document has no IANA actions.
6. Informative References
[I-D.bu-agentproto-security-principal-binding]
Bu, S., "Security Principal and Verifier Binding for Agent
Communication Protocols", Work in Progress, Internet-
Draft, draft-bu-agentproto-security-principal-binding-01,
June 2026, <https://datatracker.ietf.org/doc/html/draft-
bu-agentproto-security-principal-binding-01>.
[I-D.ietf-wimse-s2s-protocol]
IETF WIMSE Working Group, "WIMSE Workload-to-Workload
Authentication", Work in Progress, Internet-Draft, draft-
ietf-wimse-s2s-protocol, 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
s2s-protocol>.
[I-D.rampalli-pedigree]
Rampalli, K., "PEDIGREE: Per-Agent Delegation Identity
with Governance-Enforced Execution", Work in Progress,
Internet-Draft, draft-rampalli-pedigree-01, July 2026,
<https://datatracker.ietf.org/doc/html/draft-rampalli-
pedigree-01>.
[I-D.rampalli-scitt-capsule-provenance-binding]
Rampalli, K., "Binding Delegation Authorization and
Provenance References into SCITT Agent Action Capsules",
Work in Progress, Internet-Draft, draft-rampalli-scitt-
capsule-provenance-binding-00, July 2026,
<https://datatracker.ietf.org/doc/html/draft-rampalli-
scitt-capsule-provenance-binding-00>.
[I-D.reece-wimse-cross-org-delegation]
Reece, M., "Requirements for Cross-Organization Delegation
of Authority to AI Agents", Work in Progress, Internet-
Draft, draft-reece-wimse-cross-org-delegation-00, June
2026, <https://datatracker.ietf.org/doc/html/draft-reece-
wimse-cross-org-delegation-00>.
Rampalli Expires 7 January 2027 [Page 14]
Internet-Draft Layered Delegation Mapping July 2026
[I-D.schrock-ep-action-evidence-graph]
Schrock, I., "Action Evidence Graphs and Evidence Policy
Replay for High-Risk Agent Actions (EP-AEG)", Work in
Progress, Internet-Draft, draft-schrock-ep-action-
evidence-graph-00, July 2026,
<https://datatracker.ietf.org/doc/html/draft-schrock-ep-
action-evidence-graph-00>.
[I-D.schrock-ep-authority-introduction]
Schrock, I., "Authority Documents and Graded Introduction:
Trust Establishment for Agent-Action Evidence Without
Prior Federation", Work in Progress, Internet-Draft,
draft-schrock-ep-authority-introduction-00, July 2026,
<https://datatracker.ietf.org/doc/html/draft-schrock-ep-
authority-introduction-00>.
[I-D.schrock-human-authorization-binding]
Schrock, I., "Binding Named-Human Authorization Evidence
into Agent-Action Records", Work in Progress, Internet-
Draft, draft-schrock-human-authorization-binding-00, July
2026, <https://datatracker.ietf.org/doc/html/draft-
schrock-human-authorization-binding-00>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
<https://www.rfc-editor.org/info/rfc6585>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/info/rfc9421>.
Changes Since -04
* Replaced Section 3.3 with the possession row as reconciled on-list
by its supplier (Nguyen-Huu and Bu), including the explicit non-
claim of relying-party acceptance, the key-agreement versus
connection granularity distinction, and the promised workload-path
negative vector.
Rampalli Expires 7 January 2027 [Page 15]
Internet-Draft Layered Delegation Mapping July 2026
* Added application acceptance as a separate relying-party input in
Section 3, and recorded the three cross-row boundaries surfaced
on-list (presence versus approval, attribution versus approval,
may versus did) as the discipline that keeps the rows conjunctive
without inheritance.
Changes Since -03
* Added Section 3.3: the possession row as contributed on-list by
Thi Nguyen-Huu, completing the named suppliers of the composed
stack. The supplier-admitted open evidence entry for the workload
path is recorded as such.
* The R4 composition cell now points to the supplied possession row.
Changes Since -02
* Replaced all three R2 cells and the R2 row note with row text
contributed by the requirements author, superseding the interim
wording. The root-cell mechanism (authority documents with
continuity signatures and graded introduction, per the supplier's
companion draft) is recorded under the requirements author's test,
with the first-contact bootstrap as the shared, explicit residual.
Changes Since -01
* Reframed R2 per a correction from the requirements author:
verdicts are now conditional on the anchor-trust mechanism, and
unspecified anchor provisioning is recorded as an open item rather
than a satisfied assumption.
Changes Since -00
* Added Section 3.2: the human-authorization row as contributed on-
list by Iman Schrock, in the same template terms as the chain row.
* Stated the open evidence entry on the chain row explicitly.
* Added informative references for JCS and HTTP status code 428.
Acknowledgments
This mapping is a record of a discussion, and the discussion did the
work. Morgan Reece framed the requirements, asked for the
conditional form, corrected the R2 verdicts, and contributed the R2
row text of this revision verbatim. Iman Schrock proposed the two-
layer frame, reviewed the EP column of the combined table,
contributed the pre-execution human-authorization input class, and
Rampalli Expires 7 January 2027 [Page 16]
Internet-Draft Layered Delegation Mapping July 2026
supplied the human-authorization row of Section 3.2 in template terms
and the R2 provisioning-mechanism correction. Songbo Bu proposed the
diagnostically-separate-rows structure and the mapping-table
discipline this document keeps itself expressible in. Thi Nguyen-Huu
and Songbo Bu supplied and reconciled the possession row of
Section 3.3 and the authentication-anchor framing above it. Thanks
also to the participants in the WIMSE mailing-list threads in which
this mapping developed.
Author's Address
Karthik Rampalli
Glyphzero, Inc.
Email: karthik@glyphzerolabs.com
Rampalli Expires 7 January 2027 [Page 17]