A Layered Requirements Mapping for Cross-Organization Agent Delegation

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.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.¶

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.¶

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 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.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 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 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

Thi Nguyen-Huu contributed the possession row on-list on 2026-07-05, 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 here with only editorial normalization.¶

Claim:

the principal at this hop is the genuine attested actor or workload, and its signing key exists only while its release conditions currently hold: right user present, platform sound, workload genuine. Not "a key answered the handshake," but "a key whose continued existence is those conditions answered."¶

Carrier:

mTLS with a hardware-bound key registered with the relying party; the CertificateVerify signature is the possession proof, producible only if the release policy is satisfied at that instant. (Raw public key or certificate: immaterial to this row.)¶

Verifier and rule:

the relying party, offline, per connection: validate the key against the trust bundle it already holds, with no per-connection issuer call, and take a completed handshake as possession under current condition. The condition-gating is made verifier-observable by attestation (RATS evidence binding the key's release policy to the platform measurement) at enrollment and re-attestation; the handshake then proves possession under that attested policy for the session. 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) 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 this operation). Freshness is not a validity window. Whoever assesses the condition also stops the grant, in the same place: the endpoint erases the key the instant the condition fails, so no revocation message travels and there is no gap for the key to outlive the condition. A workload session is a stream of mTLS connections, each needing the key, so the condition is re-proven every connection. Condition-bound validity, not time-bound.¶

Failure behavior:

local condition failure (lock, posture loss, user absent, measurement change) removes the key at the source; the next key agreement cannot complete. A possession/presentation failure, independent of chain attenuation and of human authorization. No message travels for what the endpoint can see itself; absence enforces. Distrust of a still-sound platform, decided elsewhere, is the authorization case; it rides a CAEP-class channel, the same complement the other rows use.¶

Dependency:

a hardware root of trust enforcing "cannot exist outside its boundary": a TPM for users, a confidential-computing-anchored vTPM with anti-rollback for workloads; enrollment-time attestation binding the release policy to the measurement; and the relying party's enrolled trust bundle. The row makes no authority claim of its own; it supplies the holder proof the chain and human-authorization rows depend on at the transport, and nothing more.¶

Evidence:

reference implementation at github.com/WinMagic/LIT. The verified-human presence-bound path is demonstrated; the workload path is not yet implemented, and this cell says so.¶

With this 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.¶