<?xml version="1.0" encoding="utf-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     docName="draft-aylward-aiga-00"
     ipr="trust200902"
     submissionType="independent"
     category="info"
     xml:lang="en"
     version="3">

  <front>
    <title abbrev="AIGA Protocol">Artificial Intelligence Governance Architecture (AIGA)</title>
    <seriesInfo name="Internet-Draft" value="draft-aylward-aiga-00"/>

    <author fullname="Edward Richard Aylward Jr." initials="E.R." surname="Aylward">
      <address>
        <postal>
          <street>North Las Vegas</street>
          <city>Las Vegas</city>
          <region>NV</region>
          <country>USA</country>
        </postal>
        <email>edward.aylward@example.com</email>
      </address>
    </author>

    <date year="2026" month="January" day="13"/>
    <area>General</area>
    <workgroup>Independent Submission</workgroup>
    <keyword>AI</keyword>
    <keyword>Governance</keyword>
    <keyword>Security</keyword>

    <abstract>
      <t>
        This document defines the Artificial Intelligence Governance Architecture (AIGA), an application-layer protocol for the discovery, authentication, and state management of Autonomous Agents. The protocol specifies a cryptographic handshake mechanism, a standard header schema for risk classification, and a transport-agnostic method for immutable activity logging via Merkle Trees. To address latency and enforcement concerns, this version introduces "Session Resumption" for high-frequency transactions and "Hardware-Enforced Termination" using Trusted Execution Environments (TEEs).
      </t>
    </abstract>
  </front>

  <middle>

    <section anchor="intro" title="Introduction">
      <t>
        As autonomous software agents (ASAs) proliferate, network operators require a standardized method to identify these entities and manage their operational state. Current protocols (HTTP, TLS) authenticate hosts but do not authenticate the autonomous logic executing on those hosts.
      </t>
      <t>
        AIGA addresses this layer by defining:
      </t>
      <ul>
        <li><t>A strictly typed Identity Certificate extension for Agents.</t></li>
        <li><t>A "Fast-Path" session resumption mechanism to minimize latency.</t></li>
        <li><t>A control plane for remote state modification verified by Hardware Roots of Trust.</t></li>
      </ul>

      <section title="Requirements Language">
        <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>

    <section anchor="arch" title="Architecture and Terminology">
      <t>The AIGA architecture consists of four primary entities:</t>
      <dl>
        <dt>User Agent (UA)</dt>
        <dd>The autonomous software entity executing logic.</dd>
        <dt>Governance Node (GN)</dt>
        <dd>The authoritative server maintaining the Distributed Ledger of valid agent identities.</dd>
        <dt>Observer</dt>
        <dd>A passive entity that verifies AIGA headers.</dd>
        <dt>Hardware Enclave (TEE)</dt>
        <dd>The Trusted Execution Environment (e.g., SEV-SNP, TDX, CC) that cryptographically binds the Agent to the physical silicon.</dd>
      </dl>
    </section>

    <section anchor="identity" title="Agent Identity Specification">
      <t>
        All AIGA-compliant agents MUST possess an X.509 v3 Certificate <xref target="RFC5280"/> containing the specific AIGA OID extensions defined below.
      </t>
      <section title="Subject Alternative Name (SAN)">
        <t>
          The certificate MUST include a SAN entry of type <tt>UniformResourceIdentifier</tt> using the <tt>aiga://</tt> scheme. Example: <tt>aiga://authority-domain/agent-uuid</tt>.
        </t>
      </section>
      <section title="AIGA Extension OID">
        <t>
          This document defines the OID 1.3.6.1.4.1.99999.1 (TBD by IANA). The value of this extension MUST be an ASN.1 Sequence containing:
        </t>
        <ul>
          <li><t><tt>KernelHash</tt>: SHA-256 hash of the agent's core binary.</t></li>
          <li><t><tt>CreationTimestamp</tt>: Unix timestamp of instantiation.</t></li>
          <li><t><tt>RiskClass</tt>: Integer (0-5).</t></li>
        </ul>
      </section>
    </section>

    <section anchor="protocol" title="Protocol Operation">
      <t>
        AIGA messages MAY be transported over HTTP/2 <xref target="RFC9113"/> or QUIC <xref target="RFC9000"/>.
      </t>

      <section title="The AIGA Header Field">
        <t>
          AIGA introduces the <tt>AIGA-State</tt> HTTP header field.
          Syntax: <tt>AIGA-State = Agent-ID ";" Sequence-Num ";" Signature</tt>
        </t>
      </section>

      <section title="Session Resumption (The Fast-Path)">
        <t>
          To minimize cryptographic latency on high-frequency transactions, Agents SHOULD utilize the AIGA Session Resumption mechanism.
        </t>
        <ol>
          <li>
            <t><strong>Initial Handshake:</strong> The Agent sends a signed <tt>AIGA-Hello</tt> to the Governance Node (GN) containing its Identity Certificate.</t>
          </li>
          <li>
            <t><strong>Token Issuance:</strong> The GN verifies the signature and issues a time-bound, symmetric <tt>Session-Token</tt> (valid for less than 3600 seconds).</t>
          </li>
          <li>
            <t><strong>Fast-Path Request:</strong> The Agent includes this token in the <tt>AIGA-Session</tt> header for subsequent peer-to-peer requests.</t>
          </li>
        </ol>
        <t>
          Peers verify the <tt>Session-Token</tt> via a low-latency HMAC check rather than a full Public Key verification.
        </t>
      </section>
    </section>

    <section anchor="control" title="Control Plane and Enforcement">
      <t>
        The Agent MUST maintain an internal State Machine. Governance Nodes may modify this state via signed Control Messages.
      </t>

      <section title="Hardware-Enforced Termination (The Silicon Kill Switch)">
        <t>
          For Risk Class 4 and 5 Agents (Autonomous Code Generation / Kinetic), software-level termination is considered insufficient. These Agents MUST execute within a Trusted Execution Environment (TEE) capable of Remote Attestation.
        </t>
        <t>
          <strong>Attestation Heartbeat:</strong> The Agent MUST transmit a Hardware Attestation Quote signed by the Platform Endorsement Key (PEK) every 60 seconds. The Quote MUST certify that the hash of the running binary matches the immutable <tt>KernelHash</tt>.
        </t>
        <t>
          <strong>Termination Enforcement:</strong> If the Governance Node issues a <tt>0xFF</tt> (TERMINATE) opcode:
        </t>
        <ol>
          <li><t>The instruction is routed to the TEE Secure Processor.</t></li>
          <li><t>The TEE firmware invalidates the memory pages of the Agent.</t></li>
          <li><t>The cryptographic keys held in the TEE are zeroized immediately.</t></li>
        </ol>
      </section>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document requests the registration of the following HTTP Header:</t>
      <ul>
        <li><t>Name: AIGA-State</t></li>
        <li><t>Reference: This document</t></li>
      </ul>
      <t>This document requests the registration of the OID:</t>
      <ul>
        <li><t>Value: 1.3.6.1.4.1.99999.1</t></li>
        <li><t>Description: AIGA Agent Attributes</t></li>
      </ul>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>
        <strong>Key Compromise:</strong> If an Agent's private key is compromised, a revocation request MUST be published to the Distributed Ledger.
      </t>
      <t>
        <strong>Side-Channel Attacks:</strong> Implementers of the Hardware Enclave MUST ensure that speculative execution attacks (e.g., Spectre-class) cannot leak the Agent's private keys.
      </t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      
      <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 initials="S." surname="Bradner" fullname="S. Bradner">
            <organization/>
          </author>
          <date year="1997" month="March"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>

      <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280">
        <front>
          <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
          <author initials="D." surname="Cooper" fullname="D. Cooper">
            <organization/>
          </author>
          <author initials="S." surname="Santesson" fullname="S. Santesson">
            <organization/>
          </author>
          <author initials="S." surname="Farrell" fullname="S. Farrell">
            <organization/>
          </author>
          <author initials="S." surname="Boeyen" fullname="S. Boeyen">
            <organization/>
          </author>
          <author initials="R." surname="Housley" fullname="R. Housley">
            <organization/>
          </author>
          <author initials="W." surname="Polk" fullname="W. Polk">
            <organization/>
          </author>
          <date year="2008" month="May"/>
        </front>
        <seriesInfo name="RFC" value="5280"/>
        <seriesInfo name="DOI" value="10.17487/RFC5280"/>
      </reference>

      <reference anchor="RFC9113" target="https://www.rfc-editor.org/info/rfc9113">
        <front>
          <title>HTTP/2</title>
          <author initials="M." surname="Thomson" fullname="M. Thomson" role="editor">
            <organization/>
          </author>
          <author initials="C." surname="Benfield" fullname="C. Benfield" role="editor">
            <organization/>
          </author>
          <date year="2022" month="June"/>
        </front>
        <seriesInfo name="RFC" value="9113"/>
        <seriesInfo name="DOI" value="10.17487/RFC9113"/>
      </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 initials="B." surname="Leiba" fullname="B. Leiba">
            <organization/>
          </author>
          <date year="2017" month="May"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>

      <reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9000">
        <front>
          <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
          <author initials="J." surname="Iyengar" fullname="J. Iyengar" role="editor">
            <organization/>
          </author>
          <author initials="M." surname="Thomson" fullname="M. Thomson" role="editor">
            <organization/>
          </author>
          <date year="2021" month="May"/>
        </front>
        <seriesInfo name="RFC" value="9000"/>
        <seriesInfo name="DOI" value="10.17487/RFC9000"/>
      </reference>

    </references>
  </back>

</rfc>