<?xml version="1.0" encoding="UTF-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     category="info"
     docName="draft-durga-agenttrust-trace-verification-00"
     ipr="trust200902"
     submissionType="independent"
     version="3">

  <front>
    <title abbrev="AgentTrust Trace Verification">Cryptographic Execution-Trace Verification, JCS Canonicalization, and Fail-Closed Delegation Attestation for Autonomous AI Agents</title>

    <author fullname="Raghuvar Karthik Durga" initials="R. K." surname="Durga">
      <organization>Microsoft Corporation</organization>
      <address>
        <postal>
          <city>Chicago</city>
          <region>IL</region>
          <country>US</country>
        </postal>
        <email>rdurga@microsoft.com</email>
        <uri>https://orcid.org/0009-0003-7014-355X</uri>
      </address>
    </author>

    <date year="2026" month="October" day="29"/>
    <area>Security</area>
    <workgroup>Network Working Group</workgroup>
    <keyword>AI Agents</keyword>
    <keyword>Model Context Protocol</keyword>
    <keyword>RFC 8785</keyword>
    <keyword>JCS</keyword>
    <keyword>Zero Trust</keyword>

    <abstract>
      <t>
        This document specifies a deterministic cryptographic verification
        profile for execution traces, delegation chains, and weight-custody
        manifests generated by autonomous artificial intelligence (AI) agents
        operating across Model Context Protocol (MCP), Agent-to-Agent (A2A),
        and enterprise system-of-record boundaries. The profile binds JSON
        Canonicalization Scheme (JCS, RFC 8785) pre-image serialization,
        Ed25519 (RFC 8032) and ECDSA P-256/P-384 signatures, JSON Web Key
        (JWK, RFC 7517) thumbprint pinning, and fail-closed revocation and
        freshness checks so that relying parties can independently verify
        whether an agent action was authorized prior to commit.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro">
      <name>Introduction</name>
      <t>
        Autonomous AI agents increasingly invoke external tools, modify
        enterprise state, and delegate subtasks across multi-agent boundaries
        using protocols such as the Model Context Protocol (MCP) and
        Agent-to-Agent (A2A) transport envelopes. Without a deterministic,
        cryptographically verifiable execution receipt, a relying party
        cannot distinguish between a self-reported agent log and an
        independently verifiable commitment record.
      </t>
      <t>
        This specification formalizes the fail-closed verification invariants
        implemented in the open-source AgentTrust ("agentrust-io/trace-spec",
        "agentrust-io/agent-manifest", and "agentrust-io/weight-custody-manifest")
        conformance suites and empirically evaluated in <xref target="TR-2026-01"/>,
        <xref target="TR-2026-02"/>, and <xref target="TR-2026-03"/>.
      </t>
    </section>

    <section anchor="conventions">
      <name>Conventions and Terminology</name>
      <t>
        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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.
      </t>
    </section>

    <section anchor="jcs">
      <name>Deterministic Pre-Image Canonicalization (RFC 8785 JCS)</name>
      <t>
        To prevent cross-language signature verification drift between
        Python, TypeScript/JavaScript, and Rust verifiers, every execution
        trace envelope MUST be serialized according to the JSON
        Canonicalization Scheme <xref target="RFC8785"/> prior to digest
        calculation or signature verification:
      </t>
      <ul>
        <li>
          Non-string dictionary keys MUST be rejected with a deterministic
          type error rather than silently coerced.
        </li>
        <li>
          Lone UTF-16 surrogates (U+D800 through U+DFFF) and non-finite
          IEEE 754 floating-point values (NaN, +Infinity, -Infinity) MUST
          cause canonicalization to fail closed.
        </li>
        <li>
          Duplicate JSON object member names within signed payloads MUST be
          rejected during parsing before signature appraisal.
        </li>
      </ul>
    </section>

    <section anchor="b64url-jwk">
      <name>Strict Base64url and JWK Public-Key Hygiene</name>
      <t>
        Verifiers evaluating detached signatures, witness receipts, or JWK
        bundles <xref target="RFC7517"/> MUST enforce canonical unpadded
        base64url encoding (Section 5 of <xref target="RFC4648"/>):
      </t>
      <ul>
        <li>
          Padding characters ("="), non-alphabet whitespace, or non-zero
          trailing pad bits MUST be rejected.
        </li>
        <li>
          Verification bundles MUST NOT contain private JWK parameters
          ("d", "p", "q", "dp", "dq", "qi", "oth"). Any trust bundle
          containing a private key parameter MUST be rejected immediately.
        </li>
        <li>
          JWK thumbprints <xref target="RFC7638"/> and confirmation claims
          ("cnf.jwk") MUST be validated against the pinned trust store
          prior to revocation list evaluation.
        </li>
      </ul>
    </section>

    <section anchor="delegation">
      <name>Parent-Linked Delegation Chain Verification</name>
      <t>
        When an orchestrator agent delegates authority to a sub-agent, each
        hop record MUST include a "parent_record_hash" field containing the
        lowercase hexadecimal SHA-256 digest of the canonicalized parent
        record. A verifier evaluating an N-hop delegation chain MUST verify:
      </t>
      <ol>
        <li>Cryptographic signature validity of every hop i in 0..N-1.</li>
        <li>Hash continuity: hop[i].parent_record_hash == SHA256(JCS(hop[i-1])).</li>
        <li>Scope attenuation: hop[i].granted_scopes is a strict subset of or equal to hop[i-1].granted_scopes.</li>
        <li>Temporal monotonicity: hop[i].issued_at &gt;= hop[i-1].issued_at and hop[i].expires_at &lt;= hop[i-1].expires_at.</li>
      </ol>
    </section>

    <section anchor="security">
      <name>Security Considerations</name>
      <t>
        Verifiers that accept boolean literals as integer timestamps (for
        example, in runtimes where boolean is a subclass of integer) or that
        silently truncate recursive argument walks without flagging depth
        exhaustion introduce fail-open bypass vectors. Implementations MUST
        validate exact integer types for sequence numbers, epochs, and
        clock-skew bounds, and MUST fail closed when structural nesting
        bounds are exceeded.
      </t>
    </section>

    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
        </reference>
        <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648">
          <front>
            <title>The Base16, Base32, and Base64 Data Encodings</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <date month="October" year="2006"/>
          </front>
          <seriesInfo name="RFC" value="4648"/>
        </reference>
        <reference anchor="RFC7517" target="https://www.rfc-editor.org/info/rfc7517">
          <front>
            <title>JSON Web Key (JWK)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <date month="May" year="2015"/>
          </front>
          <seriesInfo name="RFC" value="7517"/>
        </reference>
        <reference anchor="RFC7638" target="https://www.rfc-editor.org/info/rfc7638">
          <front>
            <title>JSON Web Key (JWK) Thumbprint</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
            <date month="September" year="2015"/>
          </front>
          <seriesInfo name="RFC" value="7638"/>
        </reference>
        <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032">
          <front>
            <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <author fullname="I. Liusvaara" initials="I." surname="Liusvaara"/>
            <date month="January" year="2017"/>
          </front>
          <seriesInfo name="RFC" value="8032"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
        </reference>
        <reference anchor="RFC8785" target="https://www.rfc-editor.org/info/rfc8785">
          <front>
            <title>JSON Canonicalization Scheme (JCS)</title>
            <author fullname="A. Rundgren" initials="A." surname="Rundgren"/>
            <author fullname="B. Jordan" initials="B." surname="Jordan"/>
            <author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
            <date month="June" year="2020"/>
          </front>
          <seriesInfo name="RFC" value="8785"/>
        </reference>
      </references>

      <references>
        <name>Informative References</name>
        <reference anchor="TR-2026-01" target="https://doi.org/10.5281/zenodo.23735274">
          <front>
            <title>Deterministic Control-Plane Governance and Lease-Bounded Recovery for Enterprise Agentic AI Systems</title>
            <author fullname="Raghuvar Karthik Durga" initials="R. K." surname="Durga"/>
            <date month="October" year="2026"/>
          </front>
          <seriesInfo name="DOI" value="10.5281/zenodo.23735274"/>
        </reference>
        <reference anchor="TR-2026-02" target="https://doi.org/10.5281/zenodo.23735497">
          <front>
            <title>Adversarial Regression Benchmarking for Agentic AI Security Controls Across OWASP ASI01-ASI10</title>
            <author fullname="Raghuvar Karthik Durga" initials="R. K." surname="Durga"/>
            <date month="October" year="2026"/>
          </front>
          <seriesInfo name="DOI" value="10.5281/zenodo.23735497"/>
        </reference>
        <reference anchor="TR-2026-03" target="https://doi.org/10.5281/zenodo.23775009">
          <front>
            <title>Cryptographic Weight-Custody Manifests, JCS Canonicalization, and Two-Plane Edge Fleet Verification for Autonomous AI Systems</title>
            <author fullname="Raghuvar Karthik Durga" initials="R. K." surname="Durga"/>
            <date month="October" year="2026"/>
          </front>
          <seriesInfo name="DOI" value="10.5281/zenodo.23775009"/>
        </reference>
      </references>
    </references>
  </back>
</rfc>
