<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     docName="draft-rampalli-cross-org-delegation-mapping-04"
     category="info" ipr="trust200902" submissionType="IETF"
     tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>
    <title abbrev="Layered Delegation Mapping">A Layered Requirements
    Mapping for Cross-Organization Agent Delegation</title>
    <seriesInfo name="Internet-Draft"
        value="draft-rampalli-cross-org-delegation-mapping-04"/>
    <author fullname="Karthik Rampalli" initials="K." surname="Rampalli">
      <organization>Glyphzero, Inc.</organization>
      <address>
        <email>karthik@glyphzerolabs.com</email>
      </address>
    </author>
    <date year="2026" month="July" day="6"/>
    <area>Security</area>
    <keyword>WIMSE</keyword>
    <keyword>delegation</keyword>
    <keyword>agent</keyword>

    <abstract>
      <t>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.</t>
    </abstract>

    <note removeInRFC="false">
      <name>Status of This Mapping</name>
      <t>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.</t>
    </note>
  </front>

  <middle>

    <section anchor="intro">
      <name>Introduction</name>
      <t>Requirements R1 through R9 of
      <xref target="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:</t>
      <ul spacing="normal">
        <li>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
        (<xref target="I-D.rampalli-pedigree"/>); and</li>
        <li>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
        (<xref target="I-D.schrock-human-authorization-binding"/>,
        <xref target="I-D.schrock-ep-action-evidence-graph"/>).</li>
      </ul>
      <t>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.</t>
      <t>This document records the combined mapping
      (<xref target="mapping"/>) and the verifier-facing composition
      model that the discussion converged on
      (<xref target="composition"/>). It defines no protocol and no new
      evidence format.</t>

      <section anchor="assumptions">
        <name>Assumptions and Verdict Discipline</name>
        <t>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.</t>
      </section>
    </section>

    <section anchor="mapping">
      <name>Combined Requirements Mapping</name>

      <section anchor="summary">
        <name>Summary Table</name>
        <t>"Chain" is the delegation layer
        (<xref target="I-D.rampalli-pedigree"/>). "Root" is the
        human-authorization layer
        (<xref target="I-D.schrock-human-authorization-binding"/>,
        <xref target="I-D.schrock-ep-action-evidence-graph"/>). The
        composition column states how the layers relate on that
        row.</t>
        <table anchor="combined-table">
          <name>Combined R1-R9 Mapping</name>
          <thead>
            <tr>
              <th>Req</th>
              <th>Chain (PEDIGREE)</th>
              <th>Root (EP)</th>
              <th>Composition</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>R1</td>
              <td>Met; inline conveyance condition</td>
              <td>Out of layer by design</td>
              <td>Chain-only property</td>
            </tr>
            <tr>
              <td>R2</td>
              <td>Conditional: met only when the deployment pins a
              general anchor-trust mechanism usable by any party
              without per-counterparty negotiation. A general channel
              is named as one conforming way but not required, and
              static per-counterparty provisioning is admitted, which
              relocates rather than discharges R2. Same profile move
              as R1 inline conveyance.</td>
              <td>Conditional, mechanism specified (the
              authority-introduction companion draft, cited in the
              row note; Informational; public implementation with
              tests).
              Authority Document: signed, hash-chained,
              sequence-numbered key declaration served from the org
              origin and registrable to a transparency log; rotations
              carry a normative continuity signature (MUST be flagged
              if absent), and artifacts resolve the key valid at
              issuance. 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.</td>
              <td>Both layers name general, non-bilateral mechanisms,
              served from the org origin and transparency-logged, and
              state the assumption explicitly, narrowing R2. Shared
              residual: the first-contact bootstrap, coming to trust
              an originating anchor for an organization with no prior
              arrangement. Narrowed, explicit open item, not a
              satisfied assumption.</td>
            </tr>
            <tr>
              <td>R3</td>
              <td>Met offline given conveyance</td>
              <td>Met offline (deterministic policy replay)</td>
              <td>Both fail closed rather than fetch</td>
            </tr>
            <tr>
              <td>R4</td>
              <td>Deferred to transport (proof of possession at the
              wire)</td>
              <td>Not addressed</td>
              <td>Shared gap: neither layer proves possession;
              WIMSE-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
              (<xref target="possession-row"/>)</td>
            </tr>
            <tr>
              <td>R5</td>
              <td>Invariance along the chain (re-verification)</td>
              <td>Native to the artifact (single or quorum); B2 ties it
              to the host record</td>
              <td>Root proves who; chain proves nobody swapped them</td>
            </tr>
            <tr>
              <td>R6</td>
              <td>Conjunction native; entitlements relying-party
              local</td>
              <td>Policy identity plus replay; entitlements
              relying-party local</td>
              <td>Entitlements stay relying-party data</td>
            </tr>
            <tr>
              <td>R7</td>
              <td>Lifetime bound offline; fail-closed on stale
              revocation data is an admitted revision item</td>
              <td>Normative fail-closed: a stale verdict never
              authorizes; B4</td>
              <td>Root layer closes the gap the chain layer names</td>
            </tr>
            <tr>
              <td>R8</td>
              <td>Signed hops; SCITT capsule binding for the
              post-execution half</td>
              <td>Evidence graph; unbacked edges poison; signed
              Reliance Result</td>
              <td>Join by digest: scope versus act, neither claims the
              other's property</td>
            </tr>
            <tr>
              <td>R9</td>
              <td>Met (JWT/JOSE, pluggable policy)</td>
              <td>Met (JSON/JCS, maps onto existing host formats)</td>
              <td>No new formats on either side</td>
            </tr>
          </tbody>
        </table>
        <t>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.</t>
      </section>

      <section anchor="notes">
        <name>Row Notes</name>
        <t>The full per-layer mappings live in the originating thread;
        these notes carry only what the one-line verdicts compress too
        much.</t>
        <dl spacing="normal" newline="true">
          <dt>R1, recursive attenuation:</dt>
          <dd>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.</dd>
          <dt>R2, cross-organizational verification:</dt>
          <dd>
            <t>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.</t>
            <t>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
            (<xref target="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.</t>
            <t>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.</t>
          </dd>
          <dt>R4, proof of possession:</dt>
          <dd>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 <xref target="I-D.ietf-wimse-s2s-protocol"/>, HTTP
          message signatures <xref target="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 <xref target="composition"/>.</dd>
          <dt>R5, principal binding and invariance:</dt>
          <dd>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.</dd>
          <dt>R7, authentic bounded-staleness revocation:</dt>
          <dd>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.</dd>
          <dt>R8, tamper-evident composable audit:</dt>
          <dd>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
          (<xref target="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.</dd>
          <dt>R3, R6, R9:</dt>
          <dd>As the table states; the per-layer mappings in the
          originating thread carry the detail.</dd>
        </dl>
      </section>
    </section>

    <section anchor="composition">
      <name>Verifier-Facing Composition: Diagnostically Separate
      Inputs</name>
      <t>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:</t>
      <ul spacing="normal">
        <li>enrolled key, actor, workload, and environment binding;</li>
        <li>live key possession at connection time;</li>
        <li>local condition failure and key unavailability;</li>
        <li>external lifecycle or policy events, such as a Shared
        Signals / CAEP-class channel;</li>
        <li>authorization inputs: audience, scope, operation, and time
        bounds;</li>
        <li>an inherited delegation-chain input, where PEDIGREE or
        another chain mechanism supplies the authority path; and</li>
        <li>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.</li>
      </ul>
      <t>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. No row inherits or grants another row's
      guarantees.</t>

      <section anchor="chain-row">
        <name>The Delegation-Chain Row, Stated Explicitly</name>
        <t>The mapping-table rules of
        <xref target="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:</t>
        <dl spacing="normal" newline="false">
          <dt>Claim:</dt>
          <dd>authority for this exact operation was conveyed from the
          root principal and narrowed at every hop; the terminal scope
          covers the operation.</dd>
          <dt>Carrier:</dt>
          <dd>the per-hop delegation tokens, conveyed inline with the
          request.</dd>
          <dt>Verifier and rule:</dt>
          <dd>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.</dd>
          <dt>Binding and freshness:</dt>
          <dd>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.</dd>
          <dt>Failure behavior:</dt>
          <dd>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.</dd>
          <dt>Dependency:</dt>
          <dd>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.</dd>
        </dl>
        <t>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.</t>
      </section>

      <section anchor="human-row">
        <name>The Human-Authorization Row, Stated by Its Supplier</name>
        <t>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.</t>
        <dl spacing="normal" newline="false">
          <dt>Claim:</dt>
          <dd>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.</dd>
          <dt>Carrier:</dt>
          <dd>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.</dd>
          <dt>Verifier and rule:</dt>
          <dd>the relying party, offline, with no account: Ed25519 over
          the canonical action bytes (JCS <xref target="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.</dd>
          <dt>Binding and freshness:</dt>
          <dd>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.</dd>
          <dt>Failure behavior:</dt>
          <dd>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
          <xref target="RFC6585"/> naming the missing evidence), so a
          refusal is itself evidence, not silence.</dd>
          <dt>Dependency:</dt>
          <dd>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.</dd>
          <dt>Evidence:</dt>
          <dd>public vectors, positive and negative (receipt and quorum
          suites in the EP reference repository), reproducible with the
          ep-verify tool.</dd>
        </dl>
        <t>One asymmetry, stated rather than papered over: the chain row
        of <xref target="chain-row"/> 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.</t>
      </section>

      <section anchor="possession-row">
        <name>The Possession Row, Stated by Its Supplier</name>
        <t>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.</t>
        <dl spacing="normal" newline="false">
          <dt>Claim:</dt>
          <dd>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."</dd>
          <dt>Carrier:</dt>
          <dd>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.)</dd>
          <dt>Verifier and rule:</dt>
          <dd>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.</dd>
          <dt>Binding and freshness:</dt>
          <dd>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.</dd>
          <dt>Failure behavior:</dt>
          <dd>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.</dd>
          <dt>Dependency:</dt>
          <dd>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.</dd>
          <dt>Evidence:</dt>
          <dd>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.</dd>
        </dl>
        <t>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.</t>
      </section>

      <section anchor="template">
        <name>Template Compatibility</name>
        <t>Each row of <xref target="combined-table"/> and each input
        class above is kept expressible in the mapping-table template
        of
        <xref target="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.</t>
      </section>
    </section>

    <section anchor="security">
      <name>Security Considerations</name>
      <t>This document defines no protocol elements and introduces no
      new attack surface. Its risks are risks of misreading:</t>
      <ul spacing="normal">
        <li>A conditional verdict read as unconditional. Every "met" in
        <xref target="combined-table"/> 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.</li>
        <li>Implicit inheritance across layers. The layers compose by
        digest and by conjunction; neither inherits the other's
        guarantees, and <xref target="composition"/> 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.</li>
        <li>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.</li>
      </ul>
    </section>

    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>

  </middle>

  <back>
    <references>
      <name>Informative References</name>

      <reference anchor="I-D.reece-wimse-cross-org-delegation">
        <front>
          <title>Requirements for Cross-Organization Delegation of
          Authority to AI Agents</title>
          <author initials="M." surname="Reece" fullname="Morgan Reece">
          </author>
          <date year="2026" month="June"/>
        </front>
        <seriesInfo name="Internet-Draft"
            value="draft-reece-wimse-cross-org-delegation-00"/>
      </reference>

      <reference anchor="I-D.rampalli-pedigree">
        <front>
          <title>PEDIGREE: Per-Agent Delegation Identity with
          Governance-Enforced Execution</title>
          <author initials="K." surname="Rampalli"
              fullname="Karthik Rampalli">
          </author>
          <date year="2026" month="July"/>
        </front>
        <seriesInfo name="Internet-Draft"
            value="draft-rampalli-pedigree-01"/>
      </reference>

      <reference anchor="I-D.rampalli-scitt-capsule-provenance-binding">
        <front>
          <title>Binding Delegation Authorization and Provenance
          References into SCITT Agent Action Capsules</title>
          <author initials="K." surname="Rampalli"
              fullname="Karthik Rampalli">
          </author>
          <date year="2026" month="July"/>
        </front>
        <seriesInfo name="Internet-Draft"
            value="draft-rampalli-scitt-capsule-provenance-binding-00"/>
      </reference>

      <reference anchor="I-D.schrock-human-authorization-binding">
        <front>
          <title>Binding Named-Human Authorization Evidence into
          Agent-Action Records</title>
          <author initials="I." surname="Schrock"
              fullname="Iman Schrock">
          </author>
          <date year="2026" month="July"/>
        </front>
        <seriesInfo name="Internet-Draft"
            value="draft-schrock-human-authorization-binding-00"/>
      </reference>

      <reference anchor="I-D.schrock-ep-authority-introduction">
        <front>
          <title>Authority Documents and Graded Introduction: Trust
          Establishment for Agent-Action Evidence Without Prior
          Federation</title>
          <author initials="I." surname="Schrock"
              fullname="Iman Schrock">
          </author>
          <date year="2026" month="July"/>
        </front>
        <seriesInfo name="Internet-Draft"
            value="draft-schrock-ep-authority-introduction-00"/>
      </reference>

      <reference anchor="I-D.schrock-ep-action-evidence-graph">
        <front>
          <title>Action Evidence Graphs and Evidence Policy Replay for
          High-Risk Agent Actions (EP-AEG)</title>
          <author initials="I." surname="Schrock"
              fullname="Iman Schrock">
          </author>
          <date year="2026" month="July"/>
        </front>
        <seriesInfo name="Internet-Draft"
            value="draft-schrock-ep-action-evidence-graph-00"/>
      </reference>

      <reference anchor="I-D.bu-agentproto-security-principal-binding">
        <front>
          <title>Security Principal and Verifier Binding for Agent
          Communication Protocols</title>
          <author initials="S." surname="Bu" fullname="Songbo Bu">
          </author>
          <date year="2026" month="June"/>
        </front>
        <seriesInfo name="Internet-Draft"
            value="draft-bu-agentproto-security-principal-binding-01"/>
      </reference>

      <reference anchor="I-D.ietf-wimse-s2s-protocol">
        <front>
          <title>WIMSE Workload-to-Workload Authentication</title>
          <author>
            <organization>IETF WIMSE Working Group</organization>
          </author>
          <date year="2026"/>
        </front>
        <seriesInfo name="Internet-Draft"
            value="draft-ietf-wimse-s2s-protocol"/>
      </reference>

      <reference anchor="RFC8785"
          target="https://www.rfc-editor.org/info/rfc8785">
        <front>
          <title>JSON Canonicalization Scheme (JCS)</title>
          <author initials="A." surname="Rundgren">
          </author>
          <author initials="B." surname="Jordan">
          </author>
          <author initials="S." surname="Erdtman">
          </author>
          <date year="2020" month="June"/>
        </front>
        <seriesInfo name="RFC" value="8785"/>
        <seriesInfo name="DOI" value="10.17487/RFC8785"/>
      </reference>

      <reference anchor="RFC6585"
          target="https://www.rfc-editor.org/info/rfc6585">
        <front>
          <title>Additional HTTP Status Codes</title>
          <author initials="M." surname="Nottingham">
          </author>
          <author initials="R." surname="Fielding">
          </author>
          <date year="2012" month="April"/>
        </front>
        <seriesInfo name="RFC" value="6585"/>
        <seriesInfo name="DOI" value="10.17487/RFC6585"/>
      </reference>

      <reference anchor="RFC9421"
          target="https://www.rfc-editor.org/info/rfc9421">
        <front>
          <title>HTTP Message Signatures</title>
          <author initials="A." surname="Backman" role="editor">
          </author>
          <author initials="J." surname="Richer" role="editor">
          </author>
          <author initials="M." surname="Sporny">
          </author>
          <date year="2024" month="February"/>
        </front>
        <seriesInfo name="RFC" value="9421"/>
        <seriesInfo name="DOI" value="10.17487/RFC9421"/>
      </reference>

    </references>

    <section anchor="changes-03" numbered="false">
      <name>Changes Since -03</name>
      <ul spacing="normal">
        <li>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.</li>
        <li>The R4 composition cell now points to the supplied
        possession row.</li>
      </ul>
    </section>

    <section anchor="changes-02" numbered="false">
      <name>Changes Since -02</name>
      <ul spacing="normal">
        <li>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.</li>
      </ul>
    </section>

    <section anchor="changes-01" numbered="false">
      <name>Changes Since -01</name>
      <ul spacing="normal">
        <li>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.</li>
      </ul>
    </section>

    <section anchor="changes-00" numbered="false">
      <name>Changes Since -00</name>
      <ul spacing="normal">
        <li>Added Section 3.2: the human-authorization row as contributed
        on-list by Iman Schrock, in the same template terms as the chain
        row.</li>
        <li>Stated the open evidence entry on the chain row explicitly.</li>
        <li>Added informative references for JCS and HTTP status code
        428.</li>
      </ul>
    </section>

    <section anchor="acks" numbered="false">
      <name>Acknowledgments</name>
      <t>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 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 supplied 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.</t>
    </section>
  </back>
</rfc>
