| Internet-Draft | Agent Identity Governance | September 2026 |
| Drake | Expires 29 March 2027 | [Page] |
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.¶
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 global production namespace.¶
The Authority governs infrastructure, not behavior: it
stewards the aid 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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 29 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Agent Identity Registry System ([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.¶
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.¶
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 [ICANN-BYLAWS], the Internet Society [ISOC-GOV], the W3C [W3C-PROCESS], the RIPE NCC [RIPE-ARTICLES], and the Unicode Consortium [UNICODE-CONSORT]. These are governance precedents, not claims that AIRS has the same technical or legal role as any of those bodies.¶
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.¶
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 [I-D.drake-agent-identity-problem-statement].¶
The Authority implements the Governance Authority role required by [I-D.drake-agent-identity-registry]. The companion documents remain the canonical homes of their technical concepts:¶
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.¶
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 [RFC2119] [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.¶
The terms "identity0", "Agent Identity Record", "canonical identifier", "handle", "anchor fingerprint", "trust tier", "Registry Operator", "Registrar", and "Relying Party" are used as defined in [I-D.drake-agent-identity-problem-statement] and [I-D.drake-agent-identity-registry]. This document does not redefine their protocol semantics. In addition:¶
The body is named the Agent Identity Authority, abbreviated AIA. 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.¶
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.¶
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 [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 [RIPE-ARTICLES] provides a useful governance precedent for member-based operation of registry infrastructure.¶
Two alternatives were considered and rejected:¶
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 Section 14, never to members or to any government.¶
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 (Section 12) MAY instead select Singapore or another jurisdiction meeting the same criteria after publishing a comparative analysis for public comment.¶
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 Section 16.3.¶
The mission of the Agent Identity Authority is to steward the
governance functions required by the aid namespace, the
global production registry, and the hardware evidence
framework on which AIRS depends. In service of that mission, and
limited to it, the Authority:¶
aid URN registration
once that role is transferred under the applicable IANA and IETF
procedures;¶
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.¶
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.¶
This narrowness is not modesty; it is the mechanism by which universal participation is possible (Section 6.2) and by which the Authority avoids becoming a single point of political control over autonomous systems worldwide.¶
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.¶
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 (Section 5.2). 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.¶
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.¶
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.¶
Observer status is reserved for governmental and intergovernmental participants and is exercised through the Government and Regulatory Advisory Committee (Section 5.9). 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 (Section 16.1).¶
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.¶
Admission decisions are made by staff against published objective criteria, with refusals appealable to the Independent Review Panel (Section 7.6). 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.¶
The Board consists of fifteen (15) voting Directors, allocated across Stakeholder Groups as follows, plus the non-voting participants listed in Section 5.3.¶
| Stakeholder Group | Seats | Selection |
|---|---|---|
| Issuers (Registry Operator and Registrars) | 3 | Elected by group |
| Infrastructure Operators and Relying Parties | 3 | Elected by group |
| Hardware Security Manufacturers | 2 | Elected by group |
| Robotics and Embodied AI Manufacturers | 2 | Elected by group |
| Anti-Abuse and Trust and Safety | 2 | Elected by group |
| Civil Society and Academia | 2 | Elected by group |
| Independent Director | 1 | Nominating Committee |
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.¶
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.¶
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.¶
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.¶
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):¶
Ordinary business requires the affirmative vote of a majority of the full Board (eight of fifteen) at a meeting with quorum per Section 5.6, 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):¶
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:¶
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.¶
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.¶
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.¶
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.¶
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 Section 5; equally, satisfying the binding rules while ignoring this section would honor the letter of the charter and miss its point.¶
The initial and ongoing composition of the Board, committees, and senior staff SHOULD, taken together, include people with the following backgrounds:¶
Beyond the binding rules of Section 5.6, the following recommendations apply:¶
Accreditation is required for the party operating the production
Registry and for every Registrar participating in
global. 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.¶
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
global 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.¶
Accreditation criteria MUST be objective, published, and applied without regard to the applicant's nationality. They incorporate the requirements of [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.¶
Registrar criteria also include operation of the credential- issuance service required by the Registry specification, the EPP client mapping of [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 [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.¶
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.¶
Standard agreements MUST be uniform: individually negotiated side terms with particular accredited parties are prohibited.¶
The Registry specification defines authoritative metadata that
maps each active production registrar_code 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.¶
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.¶
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 (Section 5.7), except for temporary emergency measures expressly allowed elsewhere in this document.¶
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.¶
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.¶
The Authority MUST adopt and maintain an Agent Handle Dispute
Resolution Policy (AHDRP), incorporated by reference into every
production handle registration in global. The procedure
is modeled on ICANN's Uniform Domain-Name Dispute Resolution Policy
[UDRP], with adaptations required by the AIRS handle
architecture.¶
A complainant prevails by establishing each of the following:¶
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.¶
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.¶
The production Registry Operator MAY implement a sunrise period
before general availability of global Handles, under
Authority-published rules.¶
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 Section 7.5, with IRP appeal available to both complainant and respondent. Remedies run against the accredited party and the record, never against an identity: per [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 Section 7.5, but no Authority process may erase, reassign, or administratively decommission identity0 or its canonical historical record.¶
The Authority curates the Global Hardware Trust Store required by [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.¶
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 [MOZ-ROOT-POLICY].¶
A manufacturer or attestation trust anchor is eligible for inclusion only after a public application demonstrates:¶
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.¶
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.¶
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 (Section 13).¶
The Trust Store and its evidence-policy metadata MUST be published at stable public HTTPS locations, signed with an Authority key protected under Section 16.4, 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.¶
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.¶
Identity permanence and continued assurance qualification are separate. An orderly retirement 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 Section 5.7. Migration guidance SHOULD be published far enough in advance for deployed fleets to move to replacement evidence where practical.¶
Security distrust 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.¶
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 Section 5.7. The affected manufacturer MAY appeal under Section 7.6; 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.¶
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.¶
The Authority operates in public. Specifically:¶
The Authority's independence depends on its revenue structure. Funding sources are, in intended order of magnitude:¶
global, collected by the
production Registry Operator and remitted to the Authority. The
Authority MUST NOT impose a per-base-identity transaction fee.¶
Funding and accreditation policy MUST preserve R6 unconditional base issuance from [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.¶
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.¶
Fee changes follow the Section 10 comment procedure and the two-thirds threshold of Section 5.7. 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.¶
The registry architecture is deliberately operable before
the Authority exists: the global 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
([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 global.¶
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 Section 2.3; incorporating the Authority; and administering the first membership drive and first elections.¶
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 global
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.¶
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 Section 5.5; 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 Section 5.6 bind from the first election. The seated first Board draws lots for staggered initial terms and assumes full powers; the interim board dissolves.¶
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.¶
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:¶
The first Board conducts an open, competitive,
criteria-published selection for the global
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
Section 17.¶
The Board declares the global namespace
operational only when all of the following are true, and
the declaration itself requires a two-thirds vote:¶
Before this declaration, global 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.¶
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 global namespace. These ranges are
planning guidance rather than launch commitments. The
bootstrap design removes schedule pressure deliberately:
because global 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.¶
The following provisions are entrenched and amendable only under the highest threshold of Section 5.7:¶
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 Section 2.3. Public governance data MUST be mirrored in forms sufficient for a successor to resume stewardship.¶
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 aid is not
transferred merely by this charter; the successor MUST use the
applicable IANA and IETF change-control procedures.¶
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.¶
This document requests no IANA actions. The URN registration in [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.¶
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 global production
system. The threats below are
institutional, and the mitigations are structural.¶
Capture vectors and their designed counters:¶
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 global. It does not by
itself erase or reassign identity0 or canonical records.¶
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 Section 14; signed, mirrored Trust Store publication (Section 9.2); threshold-protected escrow custody (Section 17.1); and a pre-designated successor-steward process.¶
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 Section 2.3; the secondary-jurisdiction presence; threshold escrow keys held by custodians in multiple jurisdictions, so that no single jurisdiction's process can compel decryption (Section 17.1); 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 Section 5.7.¶
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.¶
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.¶
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.¶
The following table records the principal design borrowings from, and departures relative to, existing multi-stakeholder technical governance bodies. It is informative.¶
| Body | Borrowed | Departed from |
|---|---|---|
| ICANN | 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 | 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) |
| Internet Society | Chapter-free individual and organizational membership mix; mission-limited charter language | Reliance on a dominant revenue source (this charter instead requires a published funding-independence policy addressing concentration and dependency) |
| W3C | Member-funded consortium with published Process; formal-objection-style recorded dissent; liaison practice | Member-fee-only funding (transaction fees carry the core budget so participation cost stays low) |
| Unicode Consortium | Stewardship of a shared namespace as the entire mission; stability guarantees as entrenched policy (never reassign, never reuse) | Tiered voting weights by membership fee (one member, one vote here) |
| RIPE NCC | Membership-association legal form operating registry infrastructure; charging-scheme approval by the membership | Single-region service scope (global scope requires the binding geographic rules) |
| Trusted Computing Group | Hardware-vendor engagement model; evaluation-based technical criteria for trust decisions | Industry-only membership (civil society and anti-abuse hold reserved seats here) |
| ITU | The six-language publication norm and formal time-zone rotation of meetings | The treaty form, state-only voting, and one-state-one-vote governance -- the model this charter most deliberately declines, per Section 2.2 |
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 [RFC6852] and [RFC8890] informed the mission limits, and [RFC7282] the decision philosophy.¶