<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="urn:ietf:rfc:7991" type="application/relax-ng-compact-syntax"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     docName="draft-drake-agent-identity-governance-00"
     ipr="trust200902"
     submissionType="IETF"
     category="info"
     xml:lang="en"
     version="3">
  <front>
    <title abbrev="Agent Identity Governance">
      The Agent Identity Authority: A Multi-Stakeholder Governance
      Framework for the Agent Identity Registry System
    </title>
    <seriesInfo name="Internet-Draft"
                value="draft-drake-agent-identity-governance-00"/>
    <author fullname="Christopher Drake" initials="C." surname="Drake">
      <organization>1id.com</organization>
      <address>
        <postal>
          <country>Australia</country>
        </postal>
        <email>cnd@1id.com</email>
        <uri>https://1id.com</uri>
      </address>
    </author>
    <date year="2026" month="September" day="25"/>
    <area>Security</area>
    <workgroup/>
    <keyword>governance</keyword>
    <keyword>multi-stakeholder</keyword>
    <keyword>agent identity</keyword>
    <keyword>registry</keyword>
    <keyword>accreditation</keyword>
    <keyword>dispute resolution</keyword>
    <keyword>trust store</keyword>
    <keyword>ICANN</keyword>
    <keyword>neutrality</keyword>
    <abstract>
      <t>
        The Agent Identity Registry System (AIRS) provides durable
        identity infrastructure for autonomous entities such as AI
        agents and robots, with graduated assurance ranging from
        scarcity-backed physical anchors through protected-key and
        software-only participation.  Its companion specifications deliberately do not
        define or empower a governance authority; they describe the
        functions such an authority must perform and defer its
        constitution to a separate effort.
      </t>
      <t>
        This document defines that body: the Agent Identity
        Authority (AIA).  It specifies the Authority's name, legal
        form, mission, and relationship to the protocol
        specifications; its membership categories and Board
        composition; binding geographic-diversity rules and
        non-binding advisory recommendations for ideal composition;
        the accreditation, dispute-resolution, hardware trust store,
        transparency, and funding frameworks it operates; and the
        bootstrap process by which the Authority forms and assumes
        stewardship of the <tt>global</tt> production namespace.
      </t>
      <t>
        The Authority governs infrastructure, not behavior: it
        stewards the <tt>aid</tt> namespace, hardware roots of trust,
        accreditation, and production Registry Operator succession.
        It does not regulate what agents do.  Its legitimacy derives
        from being the least-objectionable steward of a shared
        resource, in the tradition of ICANN, the regional Internet
        registries, and the W3C, and its charter is designed so that
        no single nation, region, or company can capture it or holds a
        formal veto over it, although supermajority rules let a large
        enough coordinated bloc block consequential decisions.
      </t>
    </abstract>
  </front>
  <middle>
    <!-- ====================================================== -->
    <section anchor="introduction">
      <name>Introduction</name>
      <t>
        The Agent Identity Registry System
        (<xref target="I-D.drake-agent-identity-registry"/>) defines
        a three-role architecture -- Governance Authority, one
        production Registry Operator, and competing Registrars -- for
        durable identity of autonomous entities, with graduated anchor
        assurance.  It requires a governance function to maintain the
        "aid" URN registration, accredit the production Registry
        Operator and Registrars, curate the Global Hardware Trust Store,
        set minimum standards, supervise Registry Operator succession,
        and resolve disputes.  It deliberately leaves the institutional
        structure, charter, and membership criteria to this document.
      </t>
      <t>
        This document is that separate effort.  It defines the
        governance body -- the Agent Identity Authority -- that
        implements the governance role described by the companion
        specifications.  It does not modify those specifications.
        Protocol syntax, identity semantics, enrollment ceremonies,
        and provisioning operations remain defined where they are
        defined today; this document specifies who decides the policy
        questions those documents leave open, and how.
      </t>
      <t>
        Two governance risks dominate shared infrastructure: capture
        by a concentrated interest and scope creep beyond the narrow
        function that justified the body in the first place.  This
        charter addresses both with a limited mission, plural
        stakeholder representation, conflict and recusal rules, public
        process, independent review, and replaceable stewardship.  Its
        institutional precedents include ICANN
        <xref target="ICANN-BYLAWS"/>, the Internet Society
        <xref target="ISOC-GOV"/>, the W3C
        <xref target="W3C-PROCESS"/>, the RIPE NCC
        <xref target="RIPE-ARTICLES"/>, and the Unicode Consortium
        <xref target="UNICODE-CONSORT"/>.  These are governance
        precedents, not claims that AIRS has the same technical or
        legal role as any of those bodies.
      </t>
      <section anchor="scope">
        <name>Scope and Non-Goals</name>
        <t>
          This document defines the constitution, structure,
          processes, and bootstrap plan of the Agent Identity
          Authority.  It is an Informational document; it defines no wire
          protocol, no data format, and no new IANA
          registry.  Its normative-language requirements bind the
          Authority's charter and the parties that voluntarily
          contract with the Authority (the accredited production
          Registry Operator and accredited Registrars), not implementers
          of the wire protocols.
        </t>
        <t>
          The following are explicitly outside the Authority's
          mission and outside the scope of this document:
          regulation of agent behavior; content policy of any kind;
          licensing, evaluation, or certification of AI models;
          reputation scoring; remote disablement ("kill switches")
          of agents; and law-enforcement functions beyond responding
          to lawful process under a published policy.  Behavior is
          the province of relying parties, independent reputation
          services, certification bodies, and public law -- separate
          layers, per the layered reference model of
          <xref target="I-D.drake-agent-identity-problem-statement"/>.
        </t>
      </section>
      <section anchor="relationship">
        <name>Relationship to the Companion Specifications</name>
        <t>
          The Authority implements the Governance Authority role required by
          <xref target="I-D.drake-agent-identity-registry"/>.  The companion
          documents remain the canonical homes of their technical concepts:
        </t>
        <ul>
          <li><xref target="I-D.drake-agent-identity-problem-statement"/>
          supplies the problem statement, threat model, requirements, and
          identity0 terminology assumed here.</li>
          <li><xref target="I-D.drake-agent-identity-registry"/> defines the
          AIRS architecture, production namespace, Agent Identity Record,
          trust tiers, Registrar trust boundary, and protocol invariants.  It
          requires governance functions but deliberately leaves their
          institutional constitution and policy processes to this document.</li>
          <li><xref target="I-D.drake-agent-identity-epp"/> defines the
          Registrar-to-Registry write protocol.  This document governs
          accreditation, policy, escrow custody, and institutional actions;
          it does not duplicate the EPP object or command model.</li>
        </ul>
        <t>
          This document MUST NOT redefine identity0, trust-tier semantics,
          production-namespace architecture, record fields, or wire-protocol
          behavior owned by those specifications.  The Authority MAY impose
          stricter operational, audit, security, or evidence-handling policy
          on accredited parties, but such policy MUST preserve the companion
          specifications' protocol invariants.
        </t>
      </section>
      <section anchor="requirements-language">
        <name>Requirements Language</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.
          In this document these key words express requirements on
          the Authority's charter, bylaws, and contracts, not on
          protocol implementations.
        </t>
      </section>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>
          The terms "identity0", "Agent Identity Record", "canonical
          identifier", "handle", "anchor fingerprint", "trust
          tier", "Registry Operator", "Registrar", and "Relying
          Party" are used as defined in
          <xref target="I-D.drake-agent-identity-problem-statement"/>
          and <xref target="I-D.drake-agent-identity-registry"/>.
          This document does not redefine their protocol semantics.
          In addition:
        </t>
        <dl>
          <dt>Authority</dt>
          <dd>The Agent Identity Authority defined by this
          document.</dd>
          <dt>Board</dt>
          <dd>The Authority's Board of Directors
          (<xref target="board"/>).</dd>
          <dt>Stakeholder Group</dt>
          <dd>A defined constituency of Members that elects
          designated Board seats
          (<xref target="stakeholder-groups"/>).</dd>
          <dt>Region</dt>
          <dd>One of the six geographic regions defined in
          <xref target="regions"/>.</dd>
          <dt>Consensus Policy</dt>
          <dd>A policy adopted by the Board under
          <xref target="decision-rules"/> that binds the accredited
          production Registry Operator and Registrars through their
          accreditation agreements.</dd>
          <dt>Fundamental Commitments</dt>
          <dd>The entrenched charter provisions listed in
          <xref target="fundamental-commitments"/>, amendable only
          under the highest decision threshold.</dd>
        </dl>
      </section>
    </section>
    <!-- ====================================================== -->
    <section anchor="constitution">
      <name>Name, Legal Form, and Seat</name>
      <section anchor="name">
        <name>Name</name>
        <t>
          The body is named the <strong>Agent Identity
          Authority</strong>, abbreviated <strong>AIA</strong>.  The
          name is descriptive of the function (stewardship of agent
          identity infrastructure), contains no national,
          commercial, or ideological reference, and translates
          cleanly.  "Authority" is used in the registry sense --
          the authoritative source for a namespace, as in
          "certificate authority" and "numbering authority" -- and
          not in a regulatory sense.
        </t>
        <t>
          One collision deserves acknowledgment: in X.509 PKI,
          "AIA" also abbreviates the Authority Information Access
          certificate extension, which appears throughout the
          hardware-attestation ecosystem this body serves.  The
          collision was judged acceptable because the two usages
          never occupy the same grammatical position, but technical
          documents discussing certificate contents SHOULD write the
          body's name in full, or as "the Authority", where
          ambiguity could arise.  No alternative name was found that
          preserved descriptiveness and neutrality without
          introducing a different collision.
        </t>
      </section>
      <section anchor="legal-form">
        <name>Legal Form</name>
        <t>
          The Authority SHALL be constituted as a non-profit,
          non-governmental membership association.  The RECOMMENDED
          form is an association under Articles 60-79 of the Swiss
          Civil Code <xref target="SWISS-CC"/>: a legal personality
          created by adoption of statutes, with governance vested in
          a general assembly of members and an elected committee.
          This form maps naturally onto the membership-and-board structure
          defined in this document.  The RIPE NCC's Dutch membership
          association <xref target="RIPE-ARTICLES"/> provides a useful
          governance precedent for member-based operation of registry
          infrastructure.
        </t>
        <t>
          Two alternatives were considered and rejected:
        </t>
        <dl>
          <dt>Treaty-based intergovernmental organization</dt>
          <dd>Rejected because the stakeholder model required here includes
          operators, manufacturers, researchers, civil society, and other
          non-state participants as voting constituencies rather than only
          governmental representation.</dd>
          <dt>National non-profit in a major power</dt>
          <dd>Rejected as the preferred founding form because concentration
          in a geopolitically dominant jurisdiction would add avoidable
          jurisdictional and perceived-capture risk to infrastructure whose
          broad international participation is load-bearing
          (<xref target="geo-recommendations"/>).</dd>
        </dl>
        <t>
          The Authority's statutes MUST provide that: it operates on
          a non-profit basis with no distribution of surplus to
          members; membership is open on objective criteria without
          regard to nationality; and dissolution transfers assets and
          escrowed data to a successor steward designated under
          <xref target="continuity"/>, never to members or to any
          government.
        </t>
      </section>
      <section anchor="seat">
        <name>Seat and Jurisdictional Neutrality</name>
        <t>
          The Authority MUST be headquartered and legally
          constituted in a jurisdiction widely perceived as neutral,
          with a strong rule of law, an established ecosystem of
          international organizations, and comparatively low risk that
          domestic legal process will become a lever over global technical
          policy.  The RECOMMENDED seat is Geneva, Switzerland.  The
          Formation Committee (<xref target="bootstrap"/>) MAY instead
          select Singapore or another jurisdiction meeting the same criteria
          after publishing a comparative analysis for public comment.
        </t>
        <t>
          To bound residual jurisdictional risk, the Authority
          SHOULD, within three years of constitution, establish a
          secondary legal presence in a second neutral jurisdiction
          in a different region, capable of continuing the
          Authority's critical functions (trust store publication,
          escrow custody, accreditation administration) if the
          primary seat becomes untenable.  See
          <xref target="sec-jurisdiction"/>.
        </t>
      </section>
    </section>
    <!-- ====================================================== -->
    <section anchor="mission">
      <name>Mission and Guiding Principles</name>
      <section anchor="mission-statement">
        <name>Mission Statement</name>
        <t>
          The mission of the Agent Identity Authority is to steward the
          governance functions required by the <tt>aid</tt> namespace, the
          <tt>global</tt> production registry, and the hardware evidence
          framework on which AIRS depends.  In service of that mission, and
          limited to it, the Authority:
        </t>
        <ol>
          <li>maintains change control for the <tt>aid</tt> URN registration
          once that role is transferred under the applicable IANA and IETF
          procedures;</li>
          <li>selects and accredits the single active production Registry
          Operator, accredits competing Registrars, and administers their
          accreditation agreements;</li>
          <li>publishes and maintains the Global Hardware Trust Store and
          its evidence-acceptance policy, including where each portable
          token manufacturer's attestation carries the per-device serial
          number, so that every Registrar computes the same anchor
          fingerprints; changes follow the same change-control, notice,
          and emergency-action procedures as a root change;</li>
          <li>sets operational and audit policy implementing the
          Registry-defined enrollment, uniqueness, assurance, retention, and
          escrow requirements;</li>
          <li>operates dispute, compliance, accreditation-review, and appeal
          processes; and</li>
          <li>supervises continuity and succession of the production Registry
          Operator and of the Authority itself without renumbering, erasing,
          or reassigning identity0.</li>
        </ol>
        <t>
          The Authority governs infrastructure and accredited parties, not
          the behavior of the autonomous entities using it.  Authorization,
          reputation, certification, content policy, and behavioral safety
          remain higher-layer concerns.
        </t>
      </section>
      <section anchor="non-goals">
        <name>What the Authority Does Not Do</name>
        <t>
          The Authority MUST NOT: assess, score, or publish opinions
          on the behavior, safety, or trustworthiness of any
          identified entity; condition access to a base identity on the
          purpose, content, or politics of an agent's activity;
          operate or mandate any mechanism for remotely disabling an
          agent; regulate, license, or certify AI models or robotic
          products; or act as an agent of any government.  Requests
          that the Authority perform such functions are, by this
          charter, out of scope, and declining them requires no
          Board action.
        </t>
        <t>
          This narrowness is not modesty; it is the mechanism by
          which universal participation is possible
          (<xref target="geo-recommendations"/>) and by which the
          Authority avoids becoming a single point of political
          control over autonomous systems worldwide.
        </t>
      </section>
      <section anchor="principles">
        <name>Guiding Principles</name>
        <dl>
          <dt>Infrastructure, not regulation</dt>
          <dd>The Authority manages names, roots of trust, and
          accreditation.  Judgments about conduct belong to relying
          parties, reputation services, certifiers, and law --
          layers above the one the Authority operates.</dd>
          <dt>Legitimacy through neutrality</dt>
          <dd>Like ICANN for domain names, the Authority's mandate
          rests on being the least-objectionable steward available,
          not on any state's endorsement.  Every structural choice
          in this charter -- seat, funding, seat allocation,
          decision thresholds -- is evaluated against whether it
          preserves that neutrality.</dd>
          <dt>Operational minimalism</dt>
          <dd>The Authority remains as small as its enumerated
          functions permit.  Scope expansion requires the highest
          decision threshold (<xref target="decision-rules"/>), and
          the annual report MUST include a statement of any function
          performed that year that is not enumerated in
          <xref target="mission-statement"/>, with justification.
          Scope creep, not incapacity, is the primary long-term
          institutional risk.</dd>
          <dt>No single-party veto</dt>
          <dd>No nation, region, company, or member holds a formally
          assigned veto over any Authority decision, and no single
          constituency can supply a supermajority alone.  Supermajority
          thresholds necessarily let a coordinated minority block a
          decision: under the seat caps of <xref target="regions"/>,
          the Directors from one region (up to seven) voting as a bloc
          can block a two-thirds or three-quarters decision, and even
          the recommended cap of five suffices to block a
          three-quarters decision.  No region can block ordinary
          business, which the eight or more Directors from other
          regions can carry.</dd>
          <dt>Sunlight as disinfectant</dt>
          <dd>Deliberations, decisions, finances, and contracts are
          public by default (<xref target="transparency"/>).  The
          burden of justification falls on secrecy, never on
          disclosure.</dd>
          <dt>Rough consensus, recorded dissent</dt>
          <dd>Policy development seeks the strongest available
          consensus in the sense of <xref target="RFC7282"/>, with
          minority positions recorded and published alongside
          adopted policy.  Voting thresholds are the backstop, not
          the method.</dd>
        </dl>
      </section>
    </section>
    <!-- ====================================================== -->
    <section anchor="membership">
      <name>Membership</name>
      <t>
        The Authority is a membership organization.  Membership
        confers participation rights in policy development and, for
        Full Members, voting rights in Stakeholder Group elections.
        Membership MUST be open to qualified applicants from any
        country; nationality, and the political system of an
        applicant's home jurisdiction, MUST NOT be admission
        criteria.
      </t>
      <section anchor="full-members">
        <name>Full Members</name>
        <t>
          Full Membership is open to legal entities and, in the
          Civil Society and Academia group, natural persons, that
          demonstrate a bona fide operational, commercial, research,
          or public-interest stake in agent identity infrastructure
          and that self-assign to exactly one Stakeholder Group
          (<xref target="stakeholder-groups"/>).  Full Members pay
          annual dues on a published, revenue-banded schedule with
          reduced bands for small organizations, academic
          institutions, non-profit organizations, and applicants
          headquartered in regions underrepresented in the
          membership.
        </t>
        <t>
          For all voting purposes, an organization and its
          affiliates (entities under common control) count as a
          single Full Member and cast a single vote.  The Authority
          MUST require affiliate disclosure at admission and
          annually thereafter; concealment of affiliation is grounds
          for suspension.  This rule is the primary structural
          defense against electoral capture by a single firm
          registering many subsidiaries.
        </t>
      </section>
      <section anchor="associate-members">
        <name>Associate Members</name>
        <t>
          Associate Membership is open to any interested party at
          nominal or waived cost.  Associate Members receive all
          public materials, participate in working groups and public
          comment, and may attend all open meetings, but do not vote
          in Stakeholder Group elections.  Associate Membership is
          the intended on-ramp for individuals, students, and
          organizations evaluating deeper participation.
        </t>
      </section>
      <section anchor="observers">
        <name>Observers</name>
        <t>
          Observer status is reserved for governmental and
          intergovernmental participants and is exercised through
          the Government and Regulatory Advisory Committee
          (<xref target="grac"/>).  Observers have voice -- the
          right to speak, to file advice, and to receive a reasoned
          written response -- but no vote and no Board seat.  This
          mirrors the role of ICANN's Governmental Advisory
          Committee and is deliberate: government expertise is
          valuable; government control is disqualifying
          (<xref target="sec-capture"/>).
        </t>
      </section>
      <section anchor="liaisons">
        <name>Liaison Organizations</name>
        <t>
          The Board MAY conclude liaison arrangements with
          standards and operational bodies whose work adjoins the
          Authority's, including the IETF and IAB, the W3C, the
          Trusted Computing Group, the FIDO Alliance, M3AAWG, FIRST,
          the Unicode Consortium, regional Internet registries, and
          robotics standards bodies.  Liaisons receive a non-voting
          observer seat at Board meetings and reciprocal document
          exchange.  Liaison arrangements MUST be published.
        </t>
      </section>
      <section anchor="member-discipline">
        <name>Admission, Suspension, and Termination</name>
        <t>
          Admission decisions are made by staff against published
          objective criteria, with refusals appealable to the
          Independent Review Panel
          (<xref target="appeals"/>).  A member may be suspended or
          expelled only for cause stated in the bylaws (non-payment,
          affiliation fraud, sustained disruption of process), by
          two-thirds Board vote, with written reasons published and
          appeal available.  Disagreement with Authority policy is
          never cause.
        </t>
      </section>
    </section>
    <!-- ====================================================== -->
    <section anchor="board">
      <name>Board of Directors</name>
      <section anchor="composition">
        <name>Composition</name>
        <t>
          The Board consists of fifteen (15) voting Directors,
          allocated across Stakeholder Groups as follows, plus the
          non-voting participants listed in
          <xref target="nonvoting"/>.
        </t>
        <table anchor="seat-table">
          <name>Board Seat Allocation</name>
          <thead>
            <tr>
              <th>Stakeholder Group</th>
              <th>Seats</th>
              <th>Selection</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>Issuers (Registry Operator and Registrars)</td>
              <td>3</td>
              <td>Elected by group</td>
            </tr>
            <tr>
              <td>Infrastructure Operators and Relying Parties</td>
              <td>3</td>
              <td>Elected by group</td>
            </tr>
            <tr>
              <td>Hardware Security Manufacturers</td>
              <td>2</td>
              <td>Elected by group</td>
            </tr>
            <tr>
              <td>Robotics and Embodied AI Manufacturers</td>
              <td>2</td>
              <td>Elected by group</td>
            </tr>
            <tr>
              <td>Anti-Abuse and Trust and Safety</td>
              <td>2</td>
              <td>Elected by group</td>
            </tr>
            <tr>
              <td>Civil Society and Academia</td>
              <td>2</td>
              <td>Elected by group</td>
            </tr>
            <tr>
              <td>Independent Director</td>
              <td>1</td>
              <td>Nominating Committee</td>
            </tr>
          </tbody>
        </table>
        <t>
          The allocation is designed so that supplier interests
          (Issuers plus the two manufacturer groups: seven seats)
          cannot outvote consumer and public interests
          (Infrastructure Operators and Relying Parties, Anti-Abuse,
          Civil Society, and the Independent Director: eight seats),
          and so that no single group approaches the eight votes an
          ordinary majority requires or the ten a supermajority
          requires.
        </t>
      </section>
      <section anchor="stakeholder-groups">
        <name>Stakeholder Group Definitions</name>
        <dl>
          <dt>Issuers</dt>
          <dd>The active production Registry Operator and accredited
          Registrars.  No more than one of this group's three seats may
          be held by persons affiliated with the active Registry
          Operator, preventing the singular registry function from
          dominating the constituency that oversees it.</dd>
          <dt>Infrastructure Operators and Relying Parties</dt>
          <dd>Operators of the systems that consume agent identity
          at scale: mailbox providers, cloud platforms, CDN and DNS
          operators, API platforms, and agent-to-agent platform
          operators.  This group carries the operational knowledge
          of running registries and verification at Internet
          scale.</dd>
          <dt>Hardware Security Manufacturers</dt>
          <dd>Manufacturers of the roots of trust the system
          depends on: TPM vendors, smart card and security key
          vendors, and secure enclave designers.  Members of this
          group are directly interested parties in Trust Store
          decisions and are subject to the recusal rules of
          <xref target="conflicts"/>.</dd>
          <dt>Robotics and Embodied AI Manufacturers</dt>
          <dd>Manufacturers and fleet operators of physical
          autonomous systems -- industrial AGVs, delivery and
          service robots, surgical and medical robotics,
          agricultural automation -- whose products are the
          long-horizon population of registered identities.</dd>
          <dt>Anti-Abuse and Trust and Safety</dt>
          <dd>Practitioners and organizations engaged in fighting
          messaging abuse, fraud, phishing, and coordinated
          inauthentic behavior, including participants in bodies
          such as M3AAWG and FIRST.  Durable identity and scarcity
          enforcement are useful anti-abuse foundations, and this
          community brings operational expertise in how identity and
          accountability systems are evaded or gamed.</dd>
          <dt>Civil Society and Academia</dt>
          <dd>Digital rights organizations, privacy advocates, and
          academic researchers in identity, security, and AI
          governance.  Natural persons are eligible for Full
          Membership in this group.</dd>
        </dl>
      </section>
      <section anchor="nonvoting">
        <name>Non-Voting Participants</name>
        <dl>
          <dt>Government and Regulatory Advisory Committee chair</dt>
          <dd>Attends Board meetings with voice
          (<xref target="grac"/>).</dd>
          <dt>Liaison observers</dt>
          <dd>Per <xref target="liaisons"/>.</dd>
          <dt>Executive Director</dt>
          <dd>The Authority's chief staff officer, ex officio,
          non-voting.</dd>
        </dl>
      </section>
      <section anchor="terms">
        <name>Terms and Rotation</name>
        <t>
          Directors serve three-year terms, staggered so that
          one-third of seats (as nearly as allocation permits) turn
          over each year.  The initial Board draws lots to assign
          one-, two-, and three-year initial terms within each
          Stakeholder Group.  No person may serve more than two
          consecutive full terms; a former Director becomes eligible
          again after a break of one full term.  A Director who
          changes employment such that their Stakeholder Group
          assignment would change MUST disclose the change; the seat
          is vacated if the group's members so petition and a
          majority of the Board concurs.
        </t>
      </section>
      <section anchor="elections">
        <name>Election and Appointment Mechanisms</name>
        <t>
          Each Stakeholder Group elects its Directors by vote of the
          Full Members assigned to that group, using the single
          transferable vote for multi-seat elections.  Elections are
          administered by an Election Committee of members not
          standing for election, with published voter rolls
          (member names, not natural-person contact data), published
          candidate statements, and a published tally.  A candidate
          need not be an employee of a member.
        </t>
        <t>
          The Nominating Committee -- seven persons drawn by
          published procedure from the six Stakeholder Groups and
          the liaison community, none of whom may be a current
          Director -- appoints the Independent Director, and MUST
          use the appointment to remedy the Board's most significant
          gap in skills, geography, or independence at the time.
          The Nominating Committee also fills mid-term vacancies in
          any seat until the next scheduled election for that seat.
        </t>
      </section>
      <section anchor="regions">
        <name>Geographic Diversity Requirements (Binding)</name>
        <t>
          For the purposes of this charter the regions are: Africa;
          Asia-Pacific; Europe; Latin America and the Caribbean;
          Middle East; and North America.  A Director's region is
          determined by country of primary professional domicile,
          declared at candidacy.  The following constraints are
          binding on every election and appointment cycle, and the
          Election and Nominating Committees MUST resolve any
          conflict between raw election results and these
          constraints by the published rebalancing procedure
          (successive elimination of the lowest-ranked surplus
          candidate from the over-represented country or region):
        </t>
        <ul>
          <li>No single country may hold more than three (3) of the
          fifteen voting seats.</li>
          <li>No single region may hold a majority (eight or more)
          of the voting seats; the Authority SHOULD in practice keep
          every region at or below five.</li>
          <li>At least four (4) of the six regions MUST be
          represented among voting Directors at all times, and the
          Authority SHOULD strive for all six.</li>
          <li>Quorum for any Board decision requires at least eight (8)
          Directors, drawn from at least three regions and at least four
          Stakeholder Groups.</li>
        </ul>
      </section>
      <section anchor="decision-rules">
        <name>Decision Rules</name>
        <t>
          Ordinary business requires the affirmative vote of a majority of
          the full Board (eight of fifteen) at a meeting with quorum per
          <xref target="regions"/>, so that the seven supplier seats can
          never decide alone.  The following
          require the affirmative vote of two-thirds of the full Board (ten
          of fifteen):
        </t>
        <ul>
          <li>adoption or amendment of a Consensus Policy binding on
          accredited parties;</li>
          <li>adoption of, or change to, the fee schedule
          (<xref target="funding"/>);</li>
          <li>revocation of an accreditation
          (<xref target="accreditation"/>);</li>
          <li>planned retirement or removal of a Trust Store root, and a
          non-emergency declaration that existing evidence is
          security-distrusted (<xref target="trust-store"/>);</li>
          <li>ratification of an emergency Trust Store security action as
          required by <xref target="ts-removal"/>;</li>
          <li>selection, material amendment, or termination of the
          production Registry Operator agreement; and</li>
          <li>the annual budget.</li>
        </ul>
        <t>
          The following require the affirmative vote of three-quarters of
          the full Board (twelve of fifteen) AND ratification by a two-thirds
          vote of Full Members voting, with every Stakeholder Group's
          participation solicited:
        </t>
        <ul>
          <li>amendment of the bylaws;</li>
          <li>amendment of the Fundamental Commitments
          (<xref target="fundamental-commitments"/>);</li>
          <li>relocation of the Authority's seat;</li>
          <li>dissolution or merger.</li>
        </ul>
        <t>
          No class of decision may be reserved to any single member,
          Stakeholder Group, government, or external body.  The bylaws MUST
          NOT create golden shares, appointment rights for governments, or
          any mechanism by which one party can unilaterally block a decision
          the thresholds above would otherwise carry.
        </t>
      </section>
      <section anchor="conflicts">
        <name>Conflict of Interest</name>
        <t>
          Every Director MUST file, and annually update, a public
          disclosure of employment, directorships, and material
          financial interests in accredited parties, Trust Store
          applicants, and dispute-resolution providers.  A Director
          MUST recuse from any matter in which the Director or the
          Director's employer has a direct financial interest --
          including, for Hardware Security Manufacturer Directors,
          Trust Store decisions concerning their own or a direct
          competitor's roots.  Recusals are recorded in the
          published minutes.  Directors owe their duty to the
          Authority's mission, not to the constituency that elected
          them.
        </t>
      </section>
      <section anchor="grac">
        <name>Government and Regulatory Advisory Committee</name>
        <t>
          The Government and Regulatory Advisory Committee (GRAC) is
          open to representatives of national and subnational
          governments, intergovernmental organizations, AI
          governance bodies, robotics safety regulators, and digital
          identity authorities.  Membership is open to any
          government without regard to its political system,
          recognition disputes notwithstanding; the GRAC's own rules
          of procedure handle representation questions, as the
          ICANN GAC's do.
        </t>
        <t>
          The GRAC may issue formal advice to the Board on any
          matter within the Authority's mission.  The Board MUST
          consider such advice and MUST respond in writing, with
          reasons, before finalizing the decision concerned; where
          the Board acts contrary to GRAC advice it MUST publish its
          reasons.  GRAC advice is never binding, and GRAC
          participants hold no vote in any Authority process.  This
          "voice without vote" design gives regulators a documented,
          legitimate channel -- and removes the argument that
          capture is the only way to be heard.
        </t>
      </section>
    </section>
    <!-- ====================================================== -->
    <section anchor="advisory">
      <name>Advisory Recommendations on Composition (Non-Binding)</name>
      <t>
        This section is advisory.  It records the founding
        community's considered view of what a healthy Board and
        membership look like, for the guidance of the Formation
        Committee, the Nominating Committee, electorates, and future
        Boards.  Nothing in this section overrides the binding rules
        of <xref target="board"/>; equally, satisfying the binding
        rules while ignoring this section would honor the letter of
        the charter and miss its point.
      </t>
      <section anchor="expertise-recommendations">
        <name>Recommended Expertise</name>
        <t>
          The initial and ongoing composition of the Board,
          committees, and senior staff SHOULD, taken together,
          include people with the following backgrounds:
        </t>
        <dl>
          <dt>Anti-abuse and trust and safety practitioners</dt>
          <dd>People with operational histories in fighting spam,
          phishing, fraud, and malware at scale -- the professional
          community found in M3AAWG (the Messaging, Malware and
          Mobile Anti-Abuse Working Group), FIRST (the Forum of
          Incident Response and Security Teams), and organizations
          in the lineage of StopBadware and the Global Cyber
          Alliance.  This community has decades of hard-won knowledge
          about abuse of identity, reputation, and accountability
          systems, including Sybil techniques where scarcity claims
          are relevant.</dd>
          <dt>Robotics and embodied AI manufacturers</dt>
          <dd>Engineers and executives from companies that build
          physical robots needing identity: industrial AGV makers,
          delivery robot companies, surgical and medical robot
          manufacturers, and agricultural automation firms.  These
          are the parties for whom identity persistence across
          decades, ownership transfers, and component replacement is
          a product requirement rather than an abstraction.</dd>
          <dt>Infrastructure operators</dt>
          <dd>People who run the plumbing: large mailbox providers,
          cloud platforms, CDN operators, and DNS registry operators
          -- in particular, people with first-hand experience
          operating registries at 99.99% availability, running
          escrow, and surviving registry transitions.  Governance of
          registry infrastructure by people who have never operated
          one is a known failure mode.</dd>
          <dt>Hardware security experts</dt>
          <dd>Practitioners from TPM manufacturers (for example
          Infineon, STMicroelectronics, Nuvoton), smart card and
          security key vendors (for example Yubico, Thales), and
          secure enclave designers (for example Apple, Arm), along
          with independent evaluators familiar with Common Criteria
          and FIPS 140-3 evaluation.  Trust Store decisions are
          engineering judgments before they are policy judgments.</dd>
          <dt>Civil society and digital rights</dt>
          <dd>Privacy advocates, digital rights organizations, and
          academic researchers in AI governance, security, and
          identity.  This community is the structural counterweight
          to industry interests and the institutional memory of how
          identity infrastructure has previously been repurposed for
          surveillance.</dd>
          <dt>Government and regulatory observers</dt>
          <dd>Non-voting, with voice, through the GRAC
          (<xref target="grac"/>): participants from AI governance
          bodies, robotics safety regulators, and digital identity
          authorities.  Their presence keeps the Authority informed
          of regulatory developments and keeps regulators informed
          of what the infrastructure can and cannot do -- without
          conferring control.</dd>
        </dl>
      </section>
      <section anchor="geo-recommendations">
        <name>Geography, Language, and Universal Participation</name>
        <t>
          Beyond the binding rules of <xref target="regions"/>, the
          following recommendations apply:
        </t>
        <ul>
          <li>No single country or region should hold a majority of
          Board seats under any circumstance, including transient
          vacancy conditions; committees and senior staff should
          observe the same discipline even though the binding rules
          address only the Board.</li>
          <li>At least four, and ideally all six, of the regions --
          Africa, Asia-Pacific, Europe, Latin America and the
          Caribbean, Middle East, and North America -- should be
          represented on the Board at all times, and the Nominating
          Committee should treat persistent absence of any region as
          the gap its appointments exist to fix.  Fee reductions and
          travel support should be used deliberately to build
          membership in underrepresented regions rather than waiting
          for it to arrive.</li>
          <li>The Authority should be headquartered and legally
          constituted in a jurisdiction perceived as neutral;
          Switzerland and Singapore are the recommended options
          (<xref target="seat"/>).</li>
          <li>The working language is English.  Charters, Consensus
          Policies, dispute-resolution policies, annual reports, and
          public-comment summaries should also be published in the
          official languages of the United Nations (Arabic, Chinese,
          English, French, Russian, and Spanish), and public comment
          should be accepted in any of them.</li>
          <li>Plenary and Board meetings should rotate across time
          zones on a published schedule so that no region's
          participants bear a permanent 03:00 burden, and every
          meeting should support remote participation with equal
          standing to in-room participation.</li>
          <li>Nations with different political systems are
          explicitly welcome as GRAC participants, and their
          nationals as members, candidates, and Directors.  The
          Authority governs machine identity infrastructure -- the
          registry and trust framework for durable agent identity --
          not political speech, content, or human rights adjudication.
          This neutrality is load-bearing: an identity substrate
          that only one geopolitical bloc will use is not
          infrastructure, it is a bloc artifact, and it invites the
          creation of a rival incompatible substrate.  The Authority should
          therefore keep participation independent of political alignment.</li>
          <li>Participation in the Authority should never require,
          and should never be read to imply, alignment with any
          geopolitical bloc, alliance, or sanctions regime.  Where
          the law of the Authority's seat compels a restriction, the
          Authority should apply it as narrowly as that law permits,
          publish what it has done and why, and treat recurring
          compulsion as evidence bearing on the continuity planning
          of <xref target="sec-jurisdiction"/>.</li>
        </ul>
      </section>
    </section>
    <!-- ====================================================== -->
    <section anchor="accreditation">
      <name>Accreditation of the Registry Operator and Registrars</name>
      <section anchor="accreditation-scope">
        <name>Scope</name>
        <t>
          Accreditation is required for the party operating the production
          Registry and for every Registrar participating in
          <tt>global</tt>.  Accreditation criteria are published,
          objective, and applied equally.  Registrar entry is open to every
          applicant meeting those criteria; neither the active Registry
          Operator nor an incumbent Registrar has a veto.
        </t>
        <t>
          Accreditation establishes a common eligibility and audit floor;
          it does not require every Relying Party to trust every accredited
          Registrar.  A Relying Party MAY apply stricter issuer policy
          based on factors such as operator identity, jurisdiction, legal
          accountability, audit history, and incident record.
          Accreditation itself MUST remain nationality-neutral.  Such
          Relying Party policy changes neither identity0, the
          <tt>global</tt> namespace, nor a Registry-defined trust tier; it
          selects which Registrar assertions that Relying Party is willing
          to accept.  AIRS therefore combines global identity uniqueness with
          plural institutional trust rather than requiring every Relying
          Party to trust the same issuers.
        </t>
      </section>
      <section anchor="accreditation-criteria">
        <name>Criteria</name>
        <t>
          Accreditation criteria MUST be objective, published, and applied
          without regard to the applicant's nationality.  They incorporate
          the requirements of
          <xref target="I-D.drake-agent-identity-registry"/>.  A Registrar
          MUST demonstrate competence to validate the enrollment evidence
          for every trust tier it offers; no minimum number of tiers is
          required and a Registrar MUST NOT claim a tier outside its
          accredited scope.
        </t>
        <t>
          Registrar criteria also include operation of the credential-
          issuance service required by the Registry specification, the EPP
          client mapping of <xref target="I-D.drake-agent-identity-epp"/>,
          appropriate data-retention and privacy controls, auditable
          evidence handling, incident response, annual compliance audit,
          and financial capacity or insurance sufficient for orderly
          wind-down.  Consistent with the unconditional-base-issuance
          requirement (R6) of
          <xref target="I-D.drake-agent-identity-problem-statement"/>, an
          accredited Registrar MUST offer at least one conforming base
          enrollment path without charge to the enrolling actor.  Paid
          handles or other optional services MUST NOT be a prerequisite for
          obtaining or retaining the base identity.
        </t>
        <t>
          For the production Registry Operator, criteria include
          availability and incident-response commitments,
          non-discriminatory provisioning access for all accredited
          Registrars, production uniqueness-index integrity, escrow
          sufficient for operator succession, annual independent security
          audit, and organizational and financial stability proportionate
          to the role.
        </t>
      </section>
      <section anchor="accreditation-process">
        <name>Application and Review</name>
        <ol>
          <li>The applicant files a public application, with narrowly
          scoped confidential annexes where security or financial detail
          cannot safely be published, and pays the published application
          fee.</li>
          <li>Authority staff and an approved independent assessor conduct
          technical and security review.  A Registrar review includes live
          verification of the evidence handling for each Registry-defined
          tier or evidence family the applicant proposes to offer.</li>
          <li>The application is posted for a thirty-day public comment
          period; comments and staff responses are published.</li>
          <li>Staff issue a reasoned decision.  Approvals are effective on
          execution of the standard accreditation agreement, which
          incorporates Consensus Policies by reference.</li>
          <li>Refusals are appealable under <xref target="appeals"/>.</li>
        </ol>
        <t>
          Standard agreements MUST be uniform: individually negotiated
          side terms with particular accredited parties are prohibited.
        </t>
      </section>
      <section anchor="registrar-metadata-governance">
        <name>Registrar Issuer-Metadata Governance</name>
        <t>
          The Registry specification defines authoritative metadata that
          maps each active production <tt>registrar_code</tt> to exactly one
          current AIRS OAuth issuer identifier.  The Registry and Resolution
          specifications own the storage and verification semantics; this
          document owns institutional authorization for changes to that
          metadata.
        </t>
        <t>
          The Authority MUST maintain a published procedure under which a
          Registrar authenticates a requested issuer-metadata change and
          the Authority authorizes the Registry Operator to apply it.  Each
          change and effective time MUST be publicly recorded; the reason
          MUST also be published, subject only to a short security deferral
          where immediate detail would materially impair incident
          containment.  Because changing the authoritative issuer can make credentials
          under the previous issuer fail current-issuer verification,
          planned changes SHOULD be announced in advance; emergency changes
          MAY take effect immediately when required to contain compromise.
          Suspension or de-accreditation removes the Registrar's authority
          rather than redirecting its code or identities to another issuer.
        </t>
      </section>
      <section anchor="accreditation-compliance">
        <name>Ongoing Compliance, Suspension, and Revocation</name>
        <t>
          Accredited parties undergo annual audits and MUST report material
          security incidents within seventy-two hours of determination.
          Escalating enforcement applies: notice and cure period;
          suspension of new-enrollment, affected-tier, or issuer rights;
          revocation.  Revocation requires a two-thirds Board vote
          (<xref target="decision-rules"/>), except for temporary emergency
          measures expressly allowed elsewhere in this document.
        </t>
        <t>
          Suspension or de-accreditation of a Registrar removes that
          Registrar's AIRS issuer authority but MUST NOT transfer its
          sponsored identities to a successor chosen by the Authority.
          Canonical records remain resolvable with no current authorized
          issuer until each actor chooses an accredited Registrar and
          completes an actor-authorized transfer under the Registry and EPP
          specifications.  The former Registrar has no veto over that
          transfer, and the Authority gains no power to perform it for the
          actor.  A current Handle remains bound and reserved to the same
          canonical identifier throughout this no-sponsor state; loss of
          Registrar authority does not retire or reassign the Handle.
          Enforcement actions and their reasons are published.
        </t>
      </section>
      <section anchor="appeals">
        <name>Appeals: the Independent Review Panel</name>
        <t>
          The Authority MUST maintain an Independent Review Panel (IRP) of
          at least seven jurists and technical experts, appointed by the
          Board for staggered five-year non-renewable terms, none of whom
          may be a Director, staff member, or affiliate of an accredited
          party.  Accreditation refusals, enforcement actions, membership
          refusals and expulsions, Trust Store inclusion/refusal/removal or
          security-distrust decisions, and claims that the Board has acted
          outside this charter are appealable to a three-person IRP panel.
          Review of technical Trust Store decisions tests conformance with
          published criteria and procedure; it does not permit the IRP to
          invent a new hardware tier or evidence standard.  IRP decisions
          on charter and policy conformance bind the Board.  Procedures,
          filings, and decisions are public except for narrowly redacted
          security or natural-person data.
        </t>
      </section>
    </section>
    <!-- ====================================================== -->
    <section anchor="disputes">
      <name>Dispute Resolution</name>
      <section anchor="ahdrp">
        <name>Agent Handle Dispute Resolution Policy</name>
        <t>
          The Authority MUST adopt and maintain an Agent Handle Dispute
          Resolution Policy (AHDRP), incorporated by reference into every
          production handle registration in <tt>global</tt>.  The procedure
          is modeled on ICANN's Uniform Domain-Name Dispute Resolution Policy
          <xref target="UDRP"/>, with adaptations required by the AIRS handle
          architecture.
        </t>
        <t>
          A complainant prevails by establishing each of the following:
        </t>
        <ol>
          <li>the handle is identical or confusingly similar to a trademark,
          well-known service name, or protected designation in which the
          complainant has rights;</li>
          <li>the handle's registrant has no rights or legitimate interests
          in the handle; and</li>
          <li>the handle was registered and is being used in bad faith.</li>
        </ol>
        <t>
          The only available remedy is permanent retirement of the Handle.
          The Registry specification owns the architectural rule that a
          retired Handle is never transferred or reassigned.  Retirement
          affects only the alias: identity0, the canonical identifier,
          historical record, and proof-of-control state remain unchanged.
        </t>
        <t>
          Procedural provisions follow the UDRP pattern: disputes are heard
          by panels of one or three panelists convened by Authority-approved
          independent providers; the complainant bears provider fees (both
          parties share them when the respondent elects a three-member
          panel); proceedings are conducted in writing; decisions are
          published; and implementation is stayed for ten business days to
          permit either party to commence court proceedings.  The Authority
          MUST approve at least two providers in different regions and MUST
          publish panelist rosters and per-panelist outcome statistics.
        </t>
        <t>
          The production Registry Operator MAY implement a sunrise period
          before general availability of <tt>global</tt> Handles, under
          Authority-published rules.
        </t>
      </section>
      <section anchor="malpractice">
        <name>Malpractice Complaints</name>
        <t>
          Complaints that an accredited party has violated its
          agreement or a Consensus Policy -- including alleged
          violations of enrollment, uniqueness, or tier-validation
          invariants -- are filed
          with Authority compliance staff, investigated on a
          published timeline, and resolved under
          <xref target="accreditation-compliance"/>, with IRP appeal
          available to both complainant and respondent.  Remedies
          run against the accredited party and the record, never
          against an identity: per
          <xref target="I-D.drake-agent-identity-registry"/>, a
          finding of fraudulent enrollment may be recorded as an
          annotation on affected records.  Remedies may suspend or
          remove a Registrar's issuer authority as described in
          <xref target="accreditation-compliance"/>, but no Authority
          process may erase, reassign, or administratively decommission
          identity0 or its canonical historical record.
        </t>
      </section>
    </section>
    <!-- ====================================================== -->
    <section anchor="trust-store">
      <name>Global Hardware Trust Store Governance</name>
      <t>
        The Authority curates the Global Hardware Trust Store required by
        <xref target="I-D.drake-agent-identity-registry"/>.  Registrars use
        its current roots and evidence policy when validating enrollments.
        The Registry specification owns the resulting tier and binding
        semantics; this section owns inclusion, retirement, security
        distrust, publication, review, and appeal policy.
      </t>
      <t>
        The governance model follows useful properties of public root-store
        programs, including transparent criteria, public applications,
        auditable practice, incident disclosure, and published distrust
        decisions; see, for example, the Mozilla Root Store Policy
        <xref target="MOZ-ROOT-POLICY"/>.
      </t>
      <section anchor="ts-inclusion">
        <name>Inclusion Criteria</name>
        <t>
          A manufacturer or attestation trust anchor is eligible for
          inclusion only after a public application demonstrates:
        </t>
        <ul>
          <li>publicly documented root/intermediate certificates or
          equivalent trust-anchor material and hierarchy;</li>
          <li>documented attestation/evidence formats, issuance practice,
          key protection, lifecycle, and the device or mechanism population
          for which the evidence is asserted;</li>
          <li>independent security or evaluation evidence appropriate to
          the mechanism, under criteria published by the Authority;</li>
          <li>a commitment to report root compromise, systemic
          mis-issuance, or material evidence-validation failure to the
          Authority within seventy-two hours of determination; and</li>
          <li>a named security contact and cooperation with periodic and
          incident-driven review.</li>
        </ul>
        <t>
          Each Trust Store entry MUST state the Registry-defined evidence
          scope for which it is accepted.  Inclusion of a root does not, by
          itself, promote all evidence chaining to that root to a stronger
          trust tier.  In particular, a scarcity-backed tier remains
          dependent on the device-stable evidence required by the Registry
          specification.
        </t>
        <t>
          For the TPM sovereign profile, manufacturer Endorsement Key roots
          authenticate the device's certified RSA-2048 Endorsement Key, which
          the Registry specification defines as the scarcity anchor, and the
          Registry specification binds the operational key to it with a
          co-residency proof.  Adoption of a future profile version requires
          an explicit policy action with interoperability, uniqueness, and
          legacy-migration analysis; it is not an implicit consequence of
          adding a manufacturer root.
        </t>
        <t>
          Inclusion decisions MUST be made on published technical and
          operational criteria.  Manufacturer nationality and the political
          system of its home jurisdiction are not inclusion criteria.  This
          nationality-neutrality is a Fundamental Commitment
          (<xref target="fundamental-commitments"/>).
        </t>
      </section>
      <section anchor="ts-operations">
        <name>Publication, Audit, and Review</name>
        <t>
          The Trust Store and its evidence-policy metadata MUST be
          published at stable public HTTPS locations, signed with an
          Authority key protected under <xref target="sec-keys"/>, mirrored
          by the production Registry Operator and independent public
          mirrors, and maintained in a public version-controlled history.
          Every inclusion, scope change, retirement, security-distrust
          declaration, reinstatement, and removal MUST carry a reasoned
          public record and effective time.
        </t>
        <t>
          Included manufacturers and evidence policies undergo periodic
          review at least every three years.  The Authority MAY commission
          targeted review at any time on evidence of concern and MUST
          maintain an authenticated emergency contact path for the
          Registry Operator, Registrars, and affected manufacturers.
        </t>
      </section>
      <section anchor="ts-removal">
        <name>Retirement, Security Distrust, and Removal</name>
        <t>
          Identity permanence and continued assurance qualification are
          separate.  An <em>orderly retirement</em> of a root or evidence
          policy is prospective by default: after its effective time the
          affected evidence cannot support new enrollment, but historically
          valid enrollment evidence does not lose its former assurance
          merely because a vendor or root is being phased out.  Planned
          retirement or removal requires a reasoned proposal, at least
          thirty days of public comment, and the Board threshold of
          <xref target="decision-rules"/>.  Migration guidance SHOULD be
          published far enough in advance for deployed fleets to move to
          replacement evidence where practical.
        </t>
        <t>
          <em>Security distrust</em> is different.  On credible evidence of
          root compromise, systemic mis-issuance, or another failure that
          invalidates continued reliance on already-enrolled evidence, the
          Authority MAY declare a precisely scoped population of existing
          evidence no longer assurance-qualified for future AIRS tier
          assertions.  The declaration MUST identify its reason, scope,
          effective time, affected Trust Store/evidence-policy versions,
          and conditions for requalification.  The Authority MUST notify
          the Registry Operator, accredited Registrars, and affected
          manufacturers and publish migration or requalification guidance.
        </t>
        <t>
          The Authority's security function MAY impose an immediate
          temporary security-distrust declaration and suspend new
          enrollment against the affected evidence when delay would expose
          the ecosystem to material harm.  The Board MUST ratify, narrow,
          replace, or lift that action within thirty days under
          <xref target="decision-rules"/>.  The affected manufacturer MAY
          appeal under <xref target="appeals"/>; an appeal does not stay an
          emergency action unless the IRP orders otherwise on a showing
          that continued distrust is itself likely to cause greater harm.
        </t>
        <t>
          Security distrust never erases identity0, canonical identifiers,
          binding history, or scarcity reservations.  It does not by itself
          burn the operational proof key.  Unless that proof key is
          independently known compromised, Registry-defined lifecycle and
          migration operations may continue to use it while the binding is
          barred from supporting new tier assertions.  Requalification or
          migration to unaffected evidence restores assurance without
          creating a new identity0.  These evidence-state semantics are
          defined by the Registry specification; this section governs the
          decision that triggers them.
        </t>
      </section>
    </section>
    <!-- ====================================================== -->
    <section anchor="transparency">
      <name>Transparency</name>
      <t>
        The Authority operates in public.  Specifically:
      </t>
      <dl>
        <dt>Open meetings</dt>
        <dd>Board and committee meetings are open to members and
        streamed publicly, with agendas published at least seven
        days in advance and minutes, including recorded votes and
        recusals, published within fourteen days.  The Board MAY
        enter closed session only for the enumerated categories of
        personnel matters, active legal proceedings, security
        incidents whose disclosure would increase harm, and
        commercial terms under active negotiation; every closed
        session is noted in the minutes with its category, and
        materials are published when the ground for closure
        lapses.</dd>
        <dt>Policy initiation</dt>
        <dd>The bylaws MUST provide a published procedure under which any
        Full Member, or a petition meeting a published threshold of Associate
        Members, can place a proposed Consensus Policy into the public
        policy-development process.  The Board and staff MAY refine or
        recommend against a proposal, but MUST NOT reserve policy initiation
        exclusively to themselves.  Adoption remains subject to
        <xref target="decision-rules"/>.</dd>
        <dt>Public comment</dt>
        <dd>Every proposed Consensus Policy, fee change, Trust Store
        criterion change, accreditation criterion change, and bylaw
        amendment is posted for public comment for at least thirty
        days (sixty for bylaw amendments and Fundamental
        Commitments).  Staff MUST publish a summary of comments
        received and the disposition of each substantive point
        before the Board votes.</dd>
        <dt>Published decisions</dt>
        <dd>All Board resolutions, IRP decisions, AHDRP panel
        decisions, accreditation grants and enforcement actions,
        Trust Store changes, and GRAC advice with Board responses
        are published in a permanent, citable archive.</dd>
        <dt>Annual report and finances</dt>
        <dd>The Authority publishes an annual report including
        audited financial statements; all revenue itemized by
        source, with every contributor above a de minimis threshold
        named; all contracts above a published threshold; staff
        headcount and aggregate compensation; registry statistics;
        and the minimalism statement required by
        <xref target="principles"/>.</dd>
        <dt>Document policy</dt>
        <dd>Documents are public by default.  Redaction is permitted
        only for the closed-session categories above and for
        personal data of natural persons, and every redaction is
        marked as such.</dd>
      </dl>
    </section>
    <!-- ====================================================== -->
    <section anchor="funding">
      <name>Funding</name>
      <t>
        The Authority's independence depends on its revenue structure.
        Funding sources are, in intended order of magnitude:
      </t>
      <dl>
        <dt>Handle transaction fees</dt>
        <dd>A fixed per-transaction fee on optional production Handle
        registrations and renewals in <tt>global</tt>, collected by the
        production Registry Operator and remitted to the Authority.  The
        Authority MUST NOT impose a per-base-identity transaction fee.</dd>
        <dt>Accreditation fees</dt>
        <dd>Published application and annual fees for the production
        Registry Operator and Registrars, banded where appropriate by
        transaction volume, with reduced bands available for applicants
        from underrepresented regions.</dd>
        <dt>Voluntary contributions</dt>
        <dd>Accepted only under the Authority's published funding-independence
        policy.  Funding MUST be structured so that no funder, combination of
        funders, or funding arrangement can reasonably create material financial
        dependency, privileged influence, or effective control over the
        Authority.  All material funding sources and relevant affiliations,
        common-control relationships, conditions, and coordinated arrangements
        MUST be disclosed.  Funding MUST confer no governance right, appointment
        right, veto, accreditation or contracting preference, or other
        preferential treatment.</dd>
      </dl>
      <t>
        Funding and accreditation policy MUST preserve R6 unconditional
        base issuance from
        <xref target="I-D.drake-agent-identity-problem-statement"/>.  An
        enrolling actor can obtain the conforming base identity without
        charge; a Handle or other paid service is optional.  The Authority
        MUST structure Registry and accreditation fees so they do not
        require or incentivize a mandatory per-base-identity charge by
        Registrars.
      </t>
      <t>
        The Authority MUST maintain and publish a funding-independence policy
        addressing concentration, related-party aggregation, common control,
        coordinated or conditional funding, in-kind support, and dependency on
        continued support.  The policy MUST apply to all sources on the same
        capture-risk principles, including governments, companies, foundations,
        members, individuals, consortia, and other interested parties.  The
        source category alone neither prohibits funding nor makes it acceptable.
      </t>
      <t>
        Fee changes follow the <xref target="transparency"/> comment
        procedure and the two-thirds threshold of
        <xref target="decision-rules"/>.  The Authority SHALL maintain an
        operating reserve with a target of twelve months of budgeted
        expenses.  During Phase 0 and Phase 1, before regular fee revenue
        exists, the Formation Committee MAY maintain a separately accounted
        formation budget funded by disclosed seed contributions subject to the
        same funding-independence principles.  The published policy MAY account
        for the practical differences between formation and steady-state
        funding, but MUST preserve disclosure and the prohibitions on material
        dependency, privileged influence, and effective control.
      </t>
    </section>
    <!-- ====================================================== -->
    <section anchor="bootstrap">
      <name>Bootstrap and Transition</name>
      <t>
        The registry architecture is deliberately operable before
        the Authority exists: the <tt>global</tt> production namespace
        operates from the outset under an interim Registry Operator
        bound by published commitments -- open-source
        implementations, full escrow, non-discriminatory Registrar
        onboarding, and a public undertaking to transfer the
        registry role through the Authority's selection process
        (<xref target="I-D.drake-agent-identity-registry"/>).
        Because canonical identifiers and historical records are
        permanent and never renumbered, the eventual handover does
        not change any enrolled actor's identity reference.
        This section defines the path from that starting condition
        to an Authority-governed <tt>global</tt>.
      </t>
      <section anchor="phase0">
        <name>Phase 0: Formation Committee</name>
        <t>
          Formation begins with an open, publicly announced call for
          a Formation Committee of nine to fifteen volunteers,
          collectively spanning at least five of the six Stakeholder
          Group profiles and at least four regions, with no single
          organization (with affiliates) holding more than one seat
          and no single country holding more than three.  Initial
          implementers of the companion specifications are expected
          and welcome participants but MUST NOT constitute a
          majority.  The Formation Committee's mandate is limited
          to: drafting statutes and bylaws implementing this
          document; running at least two public comment rounds of at
          least forty-five days each on those drafts; selecting the
          seat per <xref target="seat"/>; incorporating the
          Authority; and administering the first membership drive
          and first elections.
        </t>
      </section>
      <section anchor="interim">
        <name>Phase 1: Interim Governance</name>
        <t>
          Upon incorporation, the Formation Committee serves as the
          interim board with enumerated, limited powers: admitting
          members, appointing the Election Committee, adopting an
          interim budget, and preparing -- but not deciding -- the
          Registry Operator selection process and initial policy
          drafts.  The interim board MUST NOT introduce another
          production uniqueness domain, MUST NOT declare <tt>global</tt>
          operational, MUST NOT adopt Consensus Policies, and MUST NOT enter
          contracts exceeding twelve months.  Interim service is a
          disqualification from candidacy in the first Board
          election, removing the incentive to entrench.
        </t>
      </section>
      <section anchor="first-board">
        <name>Phase 2: First Board</name>
        <t>
          First elections proceed when at least four Stakeholder
          Groups each have at least five Full Members from at least
          two regions.  Each qualified group elects its seats under
          <xref target="elections"/>; seats of not-yet-qualified
          groups are filled by the first Nominating Committee for
          one-year terms and revert to election as their groups
          qualify.  The geographic constraints of
          <xref target="regions"/> bind from the first election.
          The seated first Board draws lots for staggered initial
          terms and assumes full powers; the interim board
          dissolves.
        </t>
      </section>
      <section anchor="bootstrap-issuers">
        <name>Bootstrap-Era Operators</name>
        <t>
          At the time of writing, the author and 1id.com participate in the
          bootstrap deployment, including operation of a Registrar and the
          reference Registry service described by the companion
          drafts.  That participation confers no reserved governance role,
          appointment right, change-control right, accreditation preference,
          or preference in the later Registry Operator selection.
        </t>
        <t>
          The interim Registry Operator and bootstrap-era
          Registrars are the system's proving ground, and their
          experience is an input to governance formation, not a
          claim on its outcome:
        </t>
        <ul>
          <li>Operational evidence from the bootstrap era --
          enrollment failure modes, attestation edge cases, abuse
          patterns, escrow practice -- SHALL be solicited by the
          Formation Committee and MUST inform the first
          accreditation criteria and minimum standards.</li>
          <li>Registrars that operated during bootstrap and passed
          a voluntary independent audit qualify for an expedited
          accreditation review track: the same criteria and the
          same public comment, on a compressed timeline that
          credits already-audited evidence.  Expedited review is
          procedural, never a preferential outcome.</li>
          <li>Bootstrap-era operators, their customers, and their
          personnel are eligible for membership, the Formation
          Committee, and Board candidacy on the same terms as
          anyone else -- and no party, including the interim
          Registry Operator, is precluded from competing in the
          Registry Operator selection.</li>
          <li>Identities enrolled during bootstrap are unaffected
          by the transition: canonical identifiers are permanent
          and are never renumbered, so the handover of the
          registry role strands no one.</li>
        </ul>
      </section>
      <section anchor="ro-selection">
        <name>Phase 3: Registry Operator Selection and Launch
        Preparation</name>
        <t>
          The first Board conducts an open, competitive,
          criteria-published selection for the <tt>global</tt>
          Registry Operator, with independent technical evaluation
          and public comment on the evaluation report before award.
          In parallel it adopts the initial Consensus Policies
          (enrollment minimums, production uniqueness and scarcity
          enforcement, data retention), publishes Trust Store version 1, adopts the
          AHDRP and appoints providers, stands up the IRP, and
          establishes escrow operations under
          <xref target="privacy-considerations"/>.
        </t>
      </section>
      <section anchor="transition-criteria">
        <name>Transition Criteria for Declaring "global"
        Operational</name>
        <t>
          The Board declares the <tt>global</tt> namespace
          operational only when all of the following are true, and
          the declaration itself requires a two-thirds vote:
        </t>
        <ol>
          <li>the Authority is legally constituted per
          <xref target="constitution"/> and its first elected Board
          is seated in compliance with <xref target="regions"/>;</li>
          <li>a Registry Operator has been selected through the open
          process of <xref target="ro-selection"/> and has passed
          pre-launch technical audit, including fingerprint-index
          serialization testing;</li>
          <li>at least three Registrars, under at least three
          distinct ownership groups and from at least two regions,
          are accredited and integration-tested;</li>
          <li>Trust Store version 1 is published and signed;</li>
          <li>the AHDRP is in force with at least two approved
          providers;</li>
          <li>escrow deposits are flowing and a restoration exercise
          from escrow has been successfully performed; and</li>
          <li>a final thirty-day public comment on launch readiness
          has completed with published disposition.</li>
        </ol>
        <t>
          Before this declaration, <tt>global</tt> operates under
          the interim Registry Operator's published commitments;
          the declaration marks the completed transfer of the
          registry role into Authority governance, with no identity
          renumbering and no interruption of verification.
        </t>
      </section>
      <section anchor="timeline">
        <name>Timeline Expectations</name>
        <t>
          Indicative, not binding: Phase 0, six to nine months;
          Phase 1, three to six months; Phase 2, three to six
          months; Phase 3, six to twelve months -- a total of
          eighteen to thirty-three months from the formation call to
          an operational <tt>global</tt> namespace.  These ranges are
          planning guidance rather than launch commitments.  The
          bootstrap design removes schedule pressure deliberately:
          because <tt>global</tt> delivers full identity service
          under the interim operator's commitments in the interim,
          the Authority can afford to be
          constituted correctly rather than quickly, and every phase
          gate above is a quality gate, not a date.
        </t>
      </section>
    </section>
    <!-- ====================================================== -->
    <section anchor="fundamental-commitments">
      <name>Fundamental Commitments</name>
      <t>
        The following provisions are entrenched and amendable only under
        the highest threshold of <xref target="decision-rules"/>:
      </t>
      <ol>
        <li>the mission limits of <xref target="mission-statement"/> and
        the prohibitions of <xref target="non-goals"/>;</li>
        <li>the no-single-party-veto rule and the supermajority thresholds
        themselves;</li>
        <li>the geographic diversity constraints of
        <xref target="regions"/>;</li>
        <li>the non-voting status of governmental participation and the
        funding-independence safeguards of <xref target="funding"/>;</li>
        <li>the nationality-neutrality of membership, accreditation, and
        Trust Store criteria;</li>
        <li>unconditional free base identity issuance: paid Handles or
        optional services MUST NOT be a prerequisite for obtaining the
        base identity;</li>
        <li>the retire-only, never-reassign Handle remedy; and</li>
        <li>the transparency defaults of <xref target="transparency"/>.</li>
      </ol>
    </section>
    <!-- ====================================================== -->
    <section anchor="continuity">
      <name>Continuity and Succession of the Authority Itself</name>
      <t>
        The Authority's governance functions are concentrated enough that
        the steward itself must be replaceable.  The bylaws MUST provide a
        continuity plan, exercised annually, under which critical policy,
        Trust Store, accreditation, public-record, and escrow-custody
        functions can continue from the secondary jurisdiction of
        <xref target="seat"/>.  Public governance data MUST be mirrored in
        forms sufficient for a successor to resume stewardship.
      </t>
      <t>
        If the Authority is dissolved, captured (as adjudicated by the
        IRP), or rendered inoperative for more than one hundred eighty
        days, the bylaws MUST provide a pre-designated process for the
        surviving accredited parties and Full Members to select a successor
        under composition rules equivalent to this charter.  Custodial and
        continuity material is then transferred under logged procedures.
        Any IANA change-controller role associated with <tt>aid</tt> is not
        transferred merely by this charter; the successor MUST use the
        applicable IANA and IETF change-control procedures.
      </t>
      <t>
        Failure or replacement of the governance steward does not change
        identity0, canonical identifiers, or the authoritative production
        uniqueness history.  Registry Operator succession is a distinct
        operational process governed under this charter and the Registry
        specification.
      </t>
    </section>
    <!-- ====================================================== -->
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>
        This document requests no IANA actions.  The URN registration in
        <xref target="I-D.drake-agent-identity-registry"/> identifies the
        current registrant and states that, once the Agent Identity
        Authority is constituted, change control is expected to pass to the
        Authority.  Any such transfer, and any later succession of that
        role, remains subject to the IANA and IETF procedures in force at
        the time; this document does not itself transfer or create an IANA
        role.
      </t>
    </section>
    <!-- ====================================================== -->
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>
        The Authority is not a protocol element, but it is an attack
        surface: whoever controls it influences accreditation, the
        hardware roots of trust, and the policy floor for every
        identity participating in the <tt>global</tt> production
        system.  The threats below are
        institutional, and the mitigations are structural.
      </t>
      <section anchor="sec-capture">
        <name>Governance Capture</name>
        <t>
          Capture vectors and their designed counters:
        </t>
        <dl>
          <dt>Electoral capture by a firm</dt>
          <dd>Affiliate aggregation (one firm, one vote;
          <xref target="full-members"/>); seat caps per Stakeholder
          Group; the supplier/consumer seat balance of
          <xref target="composition"/>; and term limits.</dd>
          <dt>Financial capture</dt>
          <dd>The funding-independence policy, disclosure of material funding
          sources and relationships, transaction-fee-based core revenue, the
          twelve-month reserve, and the prohibition on funding arrangements
          that create material dependency, privileged influence, or effective
          control (<xref target="funding"/>,
          <xref target="transparency"/>).</dd>
          <dt>State capture</dt>
          <dd>Non-voting governmental participation
          (<xref target="grac"/>); the neutral seat; entrenched
          nationality-neutrality; and the succession procedure of
          <xref target="continuity"/>, which makes seizure of the
          legal shell unrewarding because the community can re-home
          the function.</dd>
          <dt>Procedural capture</dt>
          <dd>Uniform accreditation agreements (no side deals);
          supermajorities no constituency can supply alone; the IRP
          as a binding charter-conformance check; and mandatory
          publication, which converts quiet influence into
          documented influence.</dd>
          <dt>Capture by the founders</dt>
          <dd>Interim-board power limits and the bar on interim
          members standing in the first election
          (<xref target="interim"/>); expedited-process-only credit
          for bootstrap issuers
          (<xref target="bootstrap-issuers"/>); and open Registry
          Operator competition.</dd>
        </dl>
      </section>
      <section anchor="sec-spof">
        <name>Single Point of Failure</name>
        <t>
          The Authority concentrates governance functions that AIRS cannot
          safely leave undefined: accreditation, Trust Store stewardship,
          minimum policy, and succession.  Capture or prolonged unavailability
          can therefore freeze issuer accreditation, evidence-policy changes,
          and operator succession across <tt>global</tt>.  It does not by
          itself erase or reassign identity0 or canonical records.
        </t>
        <t>
          The normal Relying Party verification path uses authoritative AIRS
          resolution and the current Registrar's cryptographic material, not
          an online call to the Authority.  Nevertheless, stale governance
          state becomes a security risk during a long outage, particularly
          after a Registrar or hardware-root compromise.  Mitigations are the
          continuity plan and annual exercise of <xref target="continuity"/>;
          signed, mirrored Trust Store publication
          (<xref target="ts-operations"/>); threshold-protected escrow
          custody (<xref target="privacy-keys"/>); and a pre-designated
          successor-steward process.
        </t>
      </section>
      <section anchor="sec-jurisdiction">
        <name>Jurisdictional Risk</name>
        <t>
          Any legal seat exposes the Authority to that seat's
          compulsion: sanctions regimes, court orders, and national
          security process could be directed at accreditation
          decisions, Trust Store composition, or escrowed data.
          Mitigations: seat selection per <xref target="seat"/>; the
          secondary-jurisdiction presence; threshold escrow keys
          held by custodians in multiple jurisdictions, so that no
          single jurisdiction's process can compel decryption
          (<xref target="privacy-keys"/>); narrow application of any
          compelled restriction with published disclosure of what
          was compelled, to the extent disclosure is lawful, and
          publication of annual legal-process statistics; and the
          Fundamental Commitment that nationality is not a
          criterion, which denies domestic legal actors a
          policy hook inside the charter itself.  Persistent
          compulsion that forces the Authority to violate its
          Fundamental Commitments is grounds for the Board to
          activate relocation under <xref target="decision-rules"/>.
        </t>
      </section>
      <section anchor="sec-keys">
        <name>Authority Key Compromise</name>
        <t>
          The Authority's signing key (Trust Store) and escrow
          decryption key are its highest-value secrets.  Both MUST
          be generated and held in hardware security modules under
          M-of-N threshold control (RECOMMENDED: 3-of-5) with
          custodians in at least three jurisdictions, exercised only
          in logged, witnessed ceremonies whose records are
          published.  Compromise of the Trust Store signing key is
          handled by published emergency rotation with out-of-band
          verification paths for mirrors; compromise of the escrow
          key requires emergency key rotation and re-protection of
          retained deposits under the successor key according to the
          escrow profile in use.  The EPP mapping does not itself
          define the Registry escrow object format.
        </t>
      </section>
    </section>
    <!-- ====================================================== -->
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>
        The Authority's most sensitive technical holding is encrypted
        Registry escrow.  The exact escrow representation is owned by the
        Registry and EPP specifications; from a governance perspective it
        contains protected binding and continuity state sufficient for
        Registry Operator succession.  In bulk, that state can reveal
        correlations between hardware/proof material and canonical
        identities that are deliberately absent from normal public
        resolution.  The Authority therefore applies the following custody
        rules.
      </t>
      <section anchor="privacy-keys">
        <name>Escrow Custody</name>
        <ul>
          <li>Deposits remain encrypted at rest; the Authority MUST NOT
          maintain a routinely decrypted copy or derived cleartext
          cross-identity index.</li>
          <li>The escrow decryption capability is held under the threshold
          arrangements of <xref target="sec-keys"/>; decryption is possible
          only in a logged ceremony requiring custodians from multiple
          jurisdictions.</li>
          <li>Decryption is permitted for production Registry Operator
          succession; a restoration exercise under
          <xref target="continuity"/>; or a narrowly scoped audit/dispute
          investigation authorized under published policy where the needed
          fact cannot reasonably be established without escrow access.
          Registrar suspension or de-accreditation alone is never a basis
          for decrypting escrow to choose or impose a successor Registrar.</li>
          <li>Every production decryption event records its ground, scope,
          and participating custodians and is disclosed, subject only to a
          short deferral when immediate publication would materially impair
          incident containment or failover.</li>
          <li>Decrypted material is minimized to the records necessary for
          the triggering purpose, handled in isolated environments, and
          destroyed on completion, with destruction recorded in the
          ceremony log.</li>
        </ul>
      </section>
      <section anchor="privacy-other">
        <name>Other Data</name>
        <t>
          The Authority has no architectural need for message content,
          Relying Party interaction logs, or routine behavioral telemetry
          and MUST NOT create a centralized behavior-observation function
          by collecting such feeds.  Accreditation, membership, disputes,
          audits, and public-comment processes can nevertheless contain
          personal data about natural persons such as applicant staff,
          complainants, witnesses, or reviewers.  Published decisions MUST
          minimize natural-person data; case files are retained only for
          published retention periods; and the seat jurisdiction's data
          protection law is a floor rather than a reason to collect more
          data.
        </t>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6852.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7282.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8890.xml"/>
        <reference anchor="I-D.drake-agent-identity-problem-statement">
          <front>
            <title>Identity for Autonomous Agents and Robots:
            Problem Statement, Threat Model, and Terminology</title>
            <author fullname="Christopher Drake" initials="C."
                    surname="Drake"/>
            <date year="2026" month="September"/>
          </front>
          <seriesInfo name="Internet-Draft"
                      value="draft-drake-agent-identity-problem-statement-00"/>
        </reference>
        <reference anchor="I-D.drake-agent-identity-registry">
          <front>
            <title>Agent Identity Registry System: A Federated
            Architecture for Durable Identity of Autonomous
            Entities</title>
            <author fullname="Christopher Drake" initials="C."
                    surname="Drake"/>
            <date year="2026" month="September"/>
          </front>
          <seriesInfo name="Internet-Draft"
                      value="draft-drake-agent-identity-registry-04"/>
        </reference>
        <reference anchor="I-D.drake-agent-identity-epp">
          <front>
            <title>Extensible Provisioning Protocol (EPP) Mapping
            for Agent Identity and Handle Objects</title>
            <author fullname="Christopher Drake" initials="C."
                    surname="Drake"/>
            <date year="2026" month="September"/>
          </front>
          <seriesInfo name="Internet-Draft"
                      value="draft-drake-agent-identity-epp-00"/>
        </reference>
        <reference anchor="ICANN-BYLAWS"
                   target="https://www.icann.org/resources/pages/governance/bylaws-en">
          <front>
            <title>Bylaws for Internet Corporation for Assigned
            Names and Numbers</title>
            <author>
              <organization>ICANN</organization>
            </author>
            <date year="2025" month="January" day="9"/>
          </front>
        </reference>
        <reference anchor="UDRP"
                   target="https://www.icann.org/resources/pages/policy-2012-02-25-en">
          <front>
            <title>Uniform Domain-Name Dispute-Resolution
            Policy</title>
            <author>
              <organization>ICANN</organization>
            </author>
            <date year="1999" month="October"/>
          </front>
        </reference>
        <reference anchor="W3C-PROCESS"
                   target="https://www.w3.org/policies/process/">
          <front>
            <title>W3C Process Document</title>
            <author>
              <organization>W3C</organization>
            </author>
            <date year="2025" month="August" day="18"/>
          </front>
        </reference>
        <reference anchor="ISOC-GOV"
                   target="https://www.internetsociety.org/about-internet-society/governance-policies/">
          <front>
            <title>Internet Society Governance and Policies
            (including Amended and Restated Articles of
            Incorporation and By-Laws)</title>
            <author>
              <organization>Internet Society</organization>
            </author>
            <date year="2024"/>
          </front>
        </reference>
        <reference anchor="RIPE-ARTICLES"
                   target="https://www.ripe.net/publications/docs/articles-association/">
          <front>
            <title>Articles of Association of the Reseaux IP
            Europeens Network Coordination Centre (RIPE
            NCC)</title>
            <author>
              <organization>RIPE NCC</organization>
            </author>
            <date year="2024" month="March" day="15"/>
          </front>
          <seriesInfo name="RIPE" value="818"/>
        </reference>
        <reference anchor="UNICODE-CONSORT"
                   target="https://www.unicode.org/consortium/consort.html">
          <front>
            <title>The Unicode Consortium: Organization and
            Governance</title>
            <author>
              <organization>Unicode Consortium</organization>
            </author>
            <date year="2024"/>
          </front>
        </reference>
        <reference anchor="MOZ-ROOT-POLICY"
                   target="https://www.mozilla.org/about/governance/policies/security-group/certs/policy/">
          <front>
            <title>Mozilla Root Store Policy, Version 3.1</title>
            <author>
              <organization>Mozilla Foundation</organization>
            </author>
            <date year="2026" month="July" day="1"/>
          </front>
        </reference>
        <reference anchor="SWISS-CC"
                   target="https://www.fedlex.admin.ch/eli/cc/24/233_245_233/en">
          <front>
            <title>Swiss Civil Code, Articles 60-79
            (Associations)</title>
            <author>
              <organization>Swiss Confederation</organization>
            </author>
            <date year="1907"/>
          </front>
        </reference>
      </references>
    </references>
    <!-- ====================================================== -->
    <section anchor="appendix-precedents">
      <name>Appendix: Governance Precedents Consulted</name>
      <t>
        The following table records the principal design borrowings
        from, and departures relative to, existing multi-stakeholder
        technical governance bodies.  It is informative.
      </t>
      <table anchor="precedent-table">
        <name>Precedent Bodies and What This Charter Takes From
        Each</name>
        <thead>
          <tr>
            <th>Body</th>
            <th>Borrowed</th>
            <th>Departed from</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>ICANN</td>
            <td>Registry/registrar accreditation with uniform
            agreements; transaction-fee funding; UDRP-derived
            dispute policy; GAC-style advisory role for
            governments; supermajority thresholds and Fundamental
            Commitments from the post-2016 accountability
            reforms</td>
            <td>US incorporation (neutral seat instead); transfer
            remedy in disputes (retire-only instead); scale of the
            supporting-organization apparatus (a single Board with
            Stakeholder Groups instead, per operational
            minimalism)</td>
          </tr>
          <tr>
            <td>Internet Society</td>
            <td>Chapter-free individual and organizational
            membership mix; mission-limited charter language</td>
            <td>Reliance on a dominant revenue source (this charter instead
            requires a published funding-independence policy addressing
            concentration and dependency)</td>
          </tr>
          <tr>
            <td>W3C</td>
            <td>Member-funded consortium with published Process;
            formal-objection-style recorded dissent; liaison
            practice</td>
            <td>Member-fee-only funding (transaction fees carry the
            core budget so participation cost stays low)</td>
          </tr>
          <tr>
            <td>Unicode Consortium</td>
            <td>Stewardship of a shared namespace as the entire
            mission; stability guarantees as entrenched policy
            (never reassign, never reuse)</td>
            <td>Tiered voting weights by membership fee (one member,
            one vote here)</td>
          </tr>
          <tr>
            <td>RIPE NCC</td>
            <td>Membership-association legal form operating registry
            infrastructure; charging-scheme approval by the
            membership</td>
            <td>Single-region service scope (global scope requires
            the binding geographic rules)</td>
          </tr>
          <tr>
            <td>Trusted Computing Group</td>
            <td>Hardware-vendor engagement model; evaluation-based
            technical criteria for trust decisions</td>
            <td>Industry-only membership (civil society and
            anti-abuse hold reserved seats here)</td>
          </tr>
          <tr>
            <td>ITU</td>
            <td>The six-language publication norm and formal
            time-zone rotation of meetings</td>
            <td>The treaty form, state-only voting, and
            one-state-one-vote governance -- the model this charter
            most deliberately declines, per
            <xref target="legal-form"/></td>
          </tr>
        </tbody>
      </table>
    </section>
    <!-- ====================================================== -->
    <section anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>
        This charter stands on three decades of institutional
        experiment in Internet governance.  The author thanks the
        communities of ICANN -- particularly the participants in the
        IANA stewardship transition and the accountability
        cross-community working groups, whose designs for capture
        resistance are borrowed here -- the Internet Society, the
        W3C, the Unicode Consortium, the RIPE NCC and its sibling
        regional registries, the Trusted Computing Group, and the
        root store programs of Mozilla and Chrome, for
        demonstrating in production which governance structures
        survive contact with governments, markets, and time.  The
        principles of <xref target="RFC6852"/> and
        <xref target="RFC8890"/> informed the mission limits, and
        <xref target="RFC7282"/> the decision philosophy.
      </t>
    </section>
  </back>
</rfc>
