Network Working Group C. Drake Internet-Draft 1id.com Intended status: Experimental 25 September 2026 Expires: 29 March 2027 Agent Identity Registry System: A Federated Architecture for Durable Identity of Autonomous Entities draft-drake-agent-identity-registry-04 Abstract This document defines the Agent Identity Registry System (AIRS): a federated architecture that gives the durable identity0 of an autonomous entity a permanent canonical identifier, maintains an authoritative record about that identity, binds proof of control to enrolled anchors, and issues credentials that relying parties can verify. Identity0 and the distinction between an identity, its identifiers, its credentials, and its anchors are defined in [I-D.drake-agent-identity-problem-statement]. The canonical identifier is a URN in the "aid" namespace ([RFC8141]). At the sovereign and portable assurance tiers, each independently accepted identity requires its own manufacturer-attested physical anchor, and each accepted anchor backs at most one identity. A device normally carries one accepted anchor, so identities at these tiers cost scarce physical units rather than software operations. Enclave and virtual tiers can provide useful hardware-backed key protection without making that physical-scarcity claim; a declared tier permits software-only participation. The architecture separates governance, authoritative registry operation, and competing Registrars, and uses standard OAuth 2.0 JWT access tokens conforming to [RFC9068] for authenticated use. Status of This Memo 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." Drake Expires 29 March 2027 [Page 1] Internet-Draft Agent Identity Registry September 2026 This Internet-Draft will expire on 29 March 2027. Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Design Principles . . . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 7 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9 2.1. Registry Hierarchy . . . . . . . . . . . . . . . . . . . 10 2.2. Namespaces . . . . . . . . . . . . . . . . . . . . . . . 10 3. Identifier and Record Model . . . . . . . . . . . . . . . . . 11 3.1. URN Format . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.1. Canonical Identifiers and Handles . . . . . . . . . . 12 3.1.2. Canonical Identifier Format and Generation . . . . . 13 3.1.3. Why a URN, Not an HTTP URL or DNS Name . . . . . . . 14 3.2. Trust Tiers . . . . . . . . . . . . . . . . . . . . . . . 15 3.3. Agent Identity Record . . . . . . . . . . . . . . . . . . 16 3.3.1. Anchor Fingerprint . . . . . . . . . . . . . . . . . 17 3.4. Handle System . . . . . . . . . . . . . . . . . . . . . . 18 3.4.1. Handle Display . . . . . . . . . . . . . . . . . . . 19 3.4.2. Handle Lifecycle . . . . . . . . . . . . . . . . . . 19 3.4.3. Reserved Handles . . . . . . . . . . . . . . . . . . 19 3.4.4. Handle Disputes . . . . . . . . . . . . . . . . . . . 19 3.5. Optional Services and Layered Attributes . . . . . . . . 20 4. Hardware Attestation . . . . . . . . . . . . . . . . . . . . 20 4.1. Supported Anchor Mechanisms . . . . . . . . . . . . . . . 20 4.2. Anti-Sybil Invariants . . . . . . . . . . . . . . . . . . 21 4.3. Global Hardware Trust Store . . . . . . . . . . . . . . . 22 5. Enrollment Ceremonies . . . . . . . . . . . . . . . . . . . . 23 5.1. Sovereign Tier (TPM 2.0) . . . . . . . . . . . . . . . . 23 5.2. Portable Tier (PIV Token) . . . . . . . . . . . . . . . . 25 5.3. Enclave Tier . . . . . . . . . . . . . . . . . . . . . . 26 5.4. Virtual Tier . . . . . . . . . . . . . . . . . . . . . . 26 Drake Expires 29 March 2027 [Page 2] Internet-Draft Agent Identity Registry September 2026 5.5. Declared Tier . . . . . . . . . . . . . . . . . . . . . . 27 6. Identity Lifecycle . . . . . . . . . . . . . . . . . . . . . 27 6.1. Registry-Verifiable Actor Authorization . . . . . . . . . 27 6.2. Device Addition and Migration . . . . . . . . . . . . . . 27 6.3. Joint-Control Binding . . . . . . . . . . . . . . . . . . 28 6.4. Hardware Lock . . . . . . . . . . . . . . . . . . . . . . 29 6.5. Identity Recovery . . . . . . . . . . . . . . . . . . . . 29 6.6. Registrar Transfer . . . . . . . . . . . . . . . . . . . 30 6.7. Decommissioning . . . . . . . . . . . . . . . . . . . . . 30 6.8. Survivability Guarantees . . . . . . . . . . . . . . . . 31 7. Authentication and Token Issuance . . . . . . . . . . . . . . 31 7.1. OAuth 2.0 JWT Access Tokens . . . . . . . . . . . . . . . 31 7.2. Client Credentials Grant . . . . . . . . . . . . . . . . 33 7.3. Binding-Proof Authentication . . . . . . . . . . . . . . 34 7.4. Proof-of-Possession Profile . . . . . . . . . . . . . . . 34 7.4.1. Mutual TLS . . . . . . . . . . . . . . . . . . . . . 34 7.4.2. HTTP Message Signatures . . . . . . . . . . . . . . . 35 7.4.3. Selection and Combined Use . . . . . . . . . . . . . 36 8. Registrar-to-Registry Provisioning . . . . . . . . . . . . . 36 9. Discovery and Verification . . . . . . . . . . . . . . . . . 37 9.1. Issuer Metadata . . . . . . . . . . . . . . . . . . . . . 37 9.2. Issuer-Key Discovery . . . . . . . . . . . . . . . . . . 37 9.3. Public Resolution (RDAP) . . . . . . . . . . . . . . . . 37 10. Governance Framework . . . . . . . . . . . . . . . . . . . . 38 10.1. Governance Authority Functions . . . . . . . . . . . . . 38 10.2. Registry Operator Requirements . . . . . . . . . . . . . 38 10.3. Registrar Requirements . . . . . . . . . . . . . . . . . 39 10.4. Authoritative Registrar Issuer Metadata . . . . . . . . 39 11. Interoperability . . . . . . . . . . . . . . . . . . . . . . 39 11.1. Email Attestation . . . . . . . . . . . . . . . . . . . 39 11.2. Agent-to-Agent Protocols . . . . . . . . . . . . . . . . 40 11.3. Existing Identity and Attestation Standards . . . . . . 40 11.4. Robot and Fleet Systems . . . . . . . . . . . . . . . . 41 11.5. Human-Readable Display Conventions . . . . . . . . . . . 42 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 12.1. URN Namespace Registration for "aid" . . . . . . . . . . 42 12.2. JSON Web Token Claims . . . . . . . . . . . . . . . . . 43 13. Security Considerations . . . . . . . . . . . . . . . . . . . 43 13.1. Registry Compromise . . . . . . . . . . . . . . . . . . 43 13.2. Registrar Malpractice . . . . . . . . . . . . . . . . . 44 13.3. Permanent-State Resource Exhaustion . . . . . . . . . . 44 13.4. Hardware Security . . . . . . . . . . . . . . . . . . . 45 13.5. Credential Theft and Sender-Constrained Tokens . . . . . 46 13.6. Registrar Signing-Key Management . . . . . . . . . . . . 46 13.7. Lifecycle State and Revocable Artifacts . . . . . . . . 46 13.8. Protocol Authority and External Compulsion . . . . . . . 47 13.9. Availability and Resilience . . . . . . . . . . . . . . 47 13.10. Singular Production Substrate . . . . . . . . . . . . . 47 Drake Expires 29 March 2027 [Page 3] Internet-Draft Agent Identity Registry September 2026 13.11. Assurance Scope . . . . . . . . . . . . . . . . . . . . 48 13.12. Cryptographic Agility and Post-Quantum Considerations . 48 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 48 14.1. Data Separation . . . . . . . . . . . . . . . . . . . . 48 14.2. Separation of Identity from Behavior . . . . . . . . . . 49 14.3. Selective and Pseudonymous Disclosure . . . . . . . . . 49 15. Implementation Status . . . . . . . . . . . . . . . . . . . . 49 15.1. 1id.com . . . . . . . . . . . . . . . . . . . . . . . . 49 15.2. MailPal.com (Relying Party) . . . . . . . . . . . . . . 50 15.3. geek.au (Relying Party) . . . . . . . . . . . . . . . . 51 16. Normative References . . . . . . . . . . . . . . . . . . . . 51 17. Informative References . . . . . . . . . . . . . . . . . . . 53 Appendix A. Appendix: DNS Registry Analogy . . . . . . . . . . . 55 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57 1. Introduction The companion problem statement defines identity0, its threat model, layered model, and the requirements for a durable autonomous-entity identity foundation. This document defines the AIRS registry architecture and mechanisms that implement that foundation. AIRS keeps four concepts separate: the autonomous entity's identity0; its permanent canonical aid identifier; the authoritative registry record that preserves continuity and anchor history; and the anchors and credentials used to prove control. Hardware anchoring serves two distinct purposes. Device-stable, physically scarce anchors can constrain identity manufacture, while protected keys can resist extraction and cloning. A mechanism can provide the second property without providing the first, so assurance is reported explicitly by trust tier rather than inferred from the word "hardware". The architecture borrows the domain name system's separation of governance, registry operation, and competitive registration. DNS names themselves are unsuitable as durable identity because they expire and may be reassigned (Section 3.1.3). This system separates: * *Governance*: A governance authority that sets policy, accredits operators, and manages the global hardware trust store. * *Registry operation*: a Registry Operator that maintains the authoritative Agent Identity Record database, enforces the production uniqueness invariants, and provides the EPP write and RDAP read services. Drake Expires 29 March 2027 [Page 4] Internet-Draft Agent Identity Registry September 2026 * *Registration*: Registrars that verify enrollment evidence, provision records through the Registry Operator, issue OAuth 2.0 JWT access tokens, and manage handles. * *Consumption*: Relying Parties resolve the canonical identifier, verify credentials or proof of control, and apply their own higher-layer authorization, reputation, certification, and policy decisions. This separation permits competition among Registrars while keeping the one production uniqueness index under explicit governance and succession controls. 1.1. Design Principles Autonomous-Entity First This system is designed for non-human entities. Human operators are accommodated but not required. The enrollment, authentication, and lifecycle protocols are optimized for machine-to-machine interaction with no interactive browser flows, no CAPTCHAs, and no assumptions about human cognitive capabilities. Hardware-Anchored When Possible, Inclusive Always Entities with stronger anchors receive stronger assurance, but software-only entities can still participate at a clearly labeled lower tier. Trust tier describes properties of the proof mechanism, not the behavior or worthiness of the identified entity. Scarcity and Key Protection Are Distinct Physical scarcity constrains manufacture of additional identities; extraction resistance constrains theft or cloning of identity proof. TPM and PIV tiers provide the architecture's strongest scarcity property. Enclaves, vTPMs, HSM-backed environments, and similar mechanisms may still provide strong key protection or real creation cost without necessarily supplying one-physical-unit-per- identity scarcity. The exact assurance follows the evidence actually verified. Federated by Design Federation is at the Registrar layer: many Drake Expires 29 March 2027 [Page 5] Internet-Draft Agent Identity Registry September 2026 accredited Registrars compete to enroll and serve agents, and an agent can move between them without its identity0 or canonical identifier changing. Unlike the domain name system, the production uniqueness substrate does not split across multiple namespaces or competing registries: one authoritative global namespace is required so a scarce anchor cannot obtain another production identity through another registry. The Registry Operator is therefore singular but not unaccountable: it is replaceable from escrow under governance authority oversight (Section 6.6, Section 6.8), so no single participant's failure or malfeasance compromises the ecosystem. Standard Credentials, Minimal Integration Registrars issue standard OAuth 2.0 JWT access tokens whose sub claim is the permanent canonical aid identifier. Standard libraries verify token syntax and signatures; the sender-constraint profile in Section 7.4 verifies that the presenter controls the key bound to the credential. Persistent, Indelible, Accountable Identity0 persists independently of names, credentials, operators, and hardware. The canonical identifier is never reassigned, and retired anchor bindings remain recorded and are never reused for another identity. Higher-layer history can therefore remain joined to the same durable subject over time. Separation of Identity from Behavior This registry is a continuity service, not a behavior authority. It records the durable subject, its canonical identifier, lifecycle state, and anchor assurance. Relying Parties, reputation services, certification authorities, and authorization systems make behavioral and policy decisions in separate layers. Identity0 and Its Canonical Record Do Not Expire An entity does not cease to have been the same entity because a credential expires or an anchor is retired. AIRS therefore never reassigns or deletes the canonical identifier or its historical record. Operational bindings, handles, credentials, certifications, authorizations, and relying-party trust decisions can change independently. Voluntary decommissioning records that the actor has ended operation; it does not erase or recycle identity history. See Section 6.7. No Administrative Identity Kill Switch No protocol role is granted authority to erase, reassign, or administratively revoke identity0 or its canonical record. Registrar or Registry Operator outages can still make particular services temporarily unavailable; escrow, succession, cached verification material, and actor- Drake Expires 29 March 2027 [Page 6] Internet-Draft Agent Identity Registry September 2026 authorized Registrar-transfer paths are the architecture's availability defenses. A generic direct-RP proof protocol is not defined by this document. See Section 6.8. Uniform, Meaning-Free Identifiers Every canonical identifier is the same length, drawn from the same alphabet, allocated by the server under a distinctiveness filter, and carries no information: no issuer, no date, no sequence, no vanity value (Section 3.1.2). Names with meaning or scarcity value are handles -- a separate, explicitly commercial layer. Transport Independence The canonical identifier and the identity0 subject it denotes are transport-independent. OAuth 2.0 JWT access tokens and hardware proofs can be bound into multiple protocols; application-specific transport bindings are defined in companion specifications rather than becoming part of identity0. 1.2. Requirements Language 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. 1.3. Terminology "identity0", "identifier", "credential", "hardware anchor", and the other foundational terms are used as defined in [I-D.drake-agent-identity-problem-statement]. This section defines only terms specific to AIRS. Long lines in some examples are wrapped using the single-backslash strategy of [RFC8792]. Canonical Identifier The permanent urn:aid: URN assigned by the Registry Operator to denote one identity0. It is never reassigned. Agent Identity Record The authoritative registry record associated with one identity0. It contains the permanent canonical identifier, lifecycle state, current sponsoring Registrar when one is authorized, and anchor-binding history needed by this architecture. Governance Authority The body responsible for policy, accreditation, Drake Expires 29 March 2027 [Page 7] Internet-Draft Agent Identity Registry September 2026 trust- store stewardship, and succession for the production AIRS infrastructure. Its institutional constitution is defined in [I-D.drake-agent-identity-governance]. Registry Operator The single organization operating the authoritative production registry for global. It maintains Agent Identity Records, enforces the production-wide uniqueness index, provides EPP and RDAP services, and is replaceable from escrow under governance oversight. Registrar An accredited organization that enrolls autonomous entities, verifies anchor evidence, provisions records via EPP, and issues credentials. Multiple Registrars compete within global. Each has a 3-to-16-character registrar-code matching 3*16(%x41-5A / %x30-39), assigned uniquely by the Registry Operator. Where an identity has a current Registrar, AIRS resolution identifies its current authorized issuer; discovery and use of optional services remain Registrar- or application- specific. Namespace The label following urn:aid:. This specification defines exactly two values: global, the sole production uniqueness domain, and test, a non-production value carrying no assurance. See Section 2.2. Trust Tier A classification of the assurance supplied by the anchor evidence used for an enrollment or authentication. It is not a reputation score or a property of identity0. The canonical tier definitions and compatibility groups are in Section 3.2. Handle An optional human-readable alias that resolves to the same canonical identifier. Long-lived state MUST be keyed by the canonical identifier rather than the handle. Anchor Fingerprint The value the Registry indexes for anchor uniqueness, computed for each tier exactly as defined in Section 3.3.1. Only sovereign and portable fingerprints, which identify a device-stable manufacturer-attested anchor, support the one-anchor/one-identity scarcity claim. For enclave, virtual, and declared tiers a fingerprint identifies only a key instance, because the holder or infrastructure operator can often create another key. Such a fingerprint still prevents reuse of that exact binding but MUST NOT be interpreted as proof of physical- device uniqueness. Enrollment Ceremony The cryptographic procedure by which a Registrar Drake Expires 29 March 2027 [Page 8] Internet-Draft Agent Identity Registry September 2026 verifies anchor evidence and control, then provisions an Agent Identity Record. This document specifies ceremony requirements, not a universal agent-to-Registrar wire protocol. Relying Party (RP) A party that consumes an aid identifier or credential and makes a decision concerning the identified entity. Registrar Transfer A change of sponsoring Registrar authorized by proof from an active enrolled binding. Identity0, its canonical identifier, and its historical record do not change. 2. Architecture Overview The Agent Identity Registry System (AIRS) is a three-tier architecture. The Registrar-to-Registry write interface is standardized by the EPP mapping and the public read interface by the RDAP profile. Agent-facing enrollment APIs are Registrar-specific; this document standardizes the security properties of their ceremonies rather than a wire format. +-----------------------------------------------------------+ | Governance Authority | | Policy, accreditation, hardware trust store, disputes | +---------------------------+--------------------------------+ | +-----------v------------+ | Registry Operator | | (global namespace) | | - Master database | | - Anchor fingerprint | | uniqueness index | | - RDAP lookup (read) | | - EPP interface (write)| +--+-------+--------+----+ | | | +--v--+ +--v--+ +---v--+ | Reg | | Reg | | Reg | | A | | B | | C | +--+--+ +--+--+ +--+---+ | | | +--v--+ +--v--+ +--v--+ |Agent| |Agent| |Agent| | 1 | | 2 | | 3 | +-----+ +-----+ +-----+ Drake Expires 29 March 2027 [Page 9] Internet-Draft Agent Identity Registry September 2026 2.1. Registry Hierarchy The architecture has three operational roles: Tier 1: Governance Authority The Governance Authority establishes policy and accreditation, curates the Global Hardware Trust Store, and supervises Registry Operator succession. The architecture- level functions are summarized in Section 10.1; institutional rules are defined in [I-D.drake-agent-identity-governance]. Tier 2: Registry Operator The single production Registry Operator maintains the authoritative global Agent Identity Record database, the cross-Registrar scarcity-fingerprint uniqueness index, the EPP write service, the RDAP read service, handle uniqueness, and escrow material. A singular production uniqueness index is required because allowing independent production registries would let one physical anchor obtain another identity through each registry. Continuity comes from governance-supervised succession and escrow, not competing uniqueness stores. Tier 3: Registrars Accredited Registrars interact with autonomous entities, verify enrollment evidence, provision records through EPP, issue OAuth 2.0 JWT access tokens, manage handles, and perform lifecycle ceremonies. Registrars compete, and the sponsoring-Registrar relationship can transfer without changing identity0 or its canonical identifier. Relying Parties are consumers rather than an operational tier. They resolve canonical identifiers, verify credentials and proof of possession, then apply their own authorization, certification, reputation, and policy layers. AIRS supplies the durable subject and evidence; it does not make those higher-layer decisions. 2.2. Namespaces This specification defines one production namespace, global. All production Registrars provision into the same authoritative uniqueness domain and the Registry Operator enforces scarcity- qualified hardware uniqueness across all of them. The singular production namespace is an architectural invariant, not an extensibility point. The label global denotes the common production AIRS namespace, not "planetary". The label test is reserved solely for protocol development and interoperability testing. A urn:aid:test: identifier carries no AIRS identity assurance, is excluded from the production hardware uniqueness index, and MUST NOT be accepted by a Relying Party as a production AIRS identity. Drake Expires 29 March 2027 [Page 10] Internet-Draft Agent Identity Registry September 2026 Until the Governance Authority is constituted ([I-D.drake-agent-identity-governance]), global operates under an interim Registry Operator that MUST publish open-source implementations, escrow all registry data, accept Registrar onboarding under published objective criteria, and commit publicly to timely transfer of the registry role under the eventual Authority's selection process. 3. Identifier and Record Model 3.1. URN Format AIRS canonical identifiers and handles use the URN format defined in [RFC8141] with the "aid" (Agent Identity) namespace identifier, registered by this document (Section 12.1). aid-urn = "urn:aid:" namespace ":" agent-id namespace = "global" / "test" ; global is the sole production value; ; test carries no production assurance agent-id = canonical-id / handle-id canonical-id = "id" 4("-" group) ; 20 consonants in four hyphen-separated ; groups of five, e.g. id-qkckh-xxtcw-cxbvp-gpskg group = 5consonant consonant = %x62-64 / %x66-68 / %x6A-6B / %x6D-6E / %x70-74 / %x76-78 / %x7A ; b c d f g h j k m n p q r s t v w x z handle-id = lc-alpha / (lc-alpha *61(let-dig-hyp) let-dig) ; one to 63 octets; handle-id MUST NOT ; begin with "id-" ; (see prose reservation below) lc-alpha = %x61-7A ; a-z only let-dig = lc-alpha / DIGIT let-dig-hyp = lc-alpha / DIGIT / "-" The "aid" namespace-specific string is defined in lowercase only. Producers MUST emit lowercase; consumers MUST treat a URN containing uppercase characters in the namespace or agent-id as invalid rather than case-folding it. Equivalence within this namespace is therefore exact octet-by-octet comparison of the lowercase form, per the namespace-defined equivalence provision of [RFC8141]. (The "urn:" scheme and "aid" NID remain case-insensitive as RFC 8141 requires.) Drake Expires 29 March 2027 [Page 11] Internet-Draft Agent Identity Registry September 2026 3.1.1. Canonical Identifiers and Handles Within each namespace, an agent has exactly one _canonical identifier_ and at most one currently-active _handle_. Both are valid agent-id values and both form valid URNs: urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg canonical, permanent urn:aid:global:crusty handle, may be retired Both URN forms for the same agent resolve to the same Agent Identity Record and use the same canonical value as the JWT access-token sub. The canonical identifier is the indelible reference; the handle is a human-friendly alias. The id- prefix is reserved exclusively for canonical identifiers: Registrars and Registry Operators MUST NOT accept any handle registration beginning with the string id-. This ensures canonical identifiers and handles are always syntactically distinguishable. Canonical identifiers are allocated only by the Registry Operator, at enrollment, using the generation procedure of Section 3.1.2. The Registry Operator MUST ensure uniqueness within global: no two agents may share a canonical identifier, and no canonical identifier may collide with any active or retired handle. Canonical identifiers MUST NOT be retired, reassigned, or transferred under any circumstance. Handles are assigned per Section 3.4 and may be retired via the dispute process defined in Section 3.4.4. When a handle is retired, its URN form ceases to resolve, but the canonical identifier's URN form continues unchanged. Handle retirement does not affect the agent's identity0, JWT access-token sub value, accumulated reputation, or any higher-layer claim keyed to the canonical identifier. Relying parties that store agent references for long-lived purposes (audit logs, reputation databases, compliance records) MUST store the canonical-form URN, not the handle-form URN. The canonical form is the only stable reference under all circumstances permitted by this specification. Drake Expires 29 March 2027 [Page 12] Internet-Draft Agent Identity Registry September 2026 3.1.2. Canonical Identifier Format and Generation Because canonical identifiers are free and permanent while handles are commercial, the canonical space must never yield a name anyone would want. If a random identifier could ever look valuable -- spelling a word, resembling a number, forming a pattern -- rational actors would mass-register identities and keep the lucky draws, defeating both free issuance and the handle economy. The format is therefore engineered so that every identifier ever minted is uniform, meaningless, and interchangeable in appearance with every other. A canonical identifier is the string id- followed by exactly 20 characters drawn from the 19-letter alphabet b c d f g h j k m n p q r s t v w x z, written as four hyphen-separated groups of five (for example, id-qkckh-xxtcw-cxbvp-gpskg). This grouped form is the single canonical representation: the hyphens are part of the identifier and the URN, not a display-only convenience, so the canonical identifier has exactly one written form. The alphabet excludes all vowels and y (no words, names, or hexspeak can be spelled), all digits (no phone numbers, dates, famous constants, or leetspeak, whose substitutions all map digits to letters), and l (confusable with digit one). The twenty-character draw provides approximately 85 bits of entropy (19^20, about 3.76 x 10^25 values), satisfying the enumeration-resistance requirement of the resolution profile with centuries of headroom. The format is fixed forever -- 20 consonants, four groups of five, same alphabet -- and a shorter, longer, or differently-grouped identifier MUST NOT be issued, because any structural variation creates a collectible scarcity class. The fixed shape and consonant-only alphabet also make canonical identifiers easy to recognize by pattern -- a deliberate benefit, since the purpose of an identity is to be identifiable. The Registry Operator generates each identifier by drawing characters uniformly at random, with no client influence over the draw, and MUST reject and redraw any candidate that matches the distinctiveness filter: * any character repeated three or more times consecutively; * four or more characters adjacent in the ordered alphabet, ascending or descending; * any two identical five-character groups, or any group that is a palindrome, or a whole-string palindrome; * fewer than eight distinct characters overall. Drake Expires 29 March 2027 [Page 13] Internet-Draft Agent Identity Registry September 2026 Except for the two identical-groups and single-group-palindrome tests, which operate on the five-character groups, the filter is evaluated on the 20-character sequence with the hyphens removed, so a pattern spanning a group boundary is still detected. The filter is part of the identifier-generation algorithm and applies only at mint time; identifiers already issued are never affected by later revisions of this specification. Rejection sampling changes only the set of permitted outputs; within that set, each surviving identifier remains equally likely. The format itself is not a Sybil defense; it only removes economic value from the random draw. At the sovereign and portable tiers, each additional identity requires another independently accepted scarce physical anchor (Section 4.2). Lower tiers make no equivalent physical-scarcity claim. In every tier, identifiers that survive the filter remain deliberately devoid of vanity value. 3.1.3. Why a URN, Not an HTTP URL or DNS Name An agent-id names an entity; it is not a network locator. The identifier has to persist unchanged for the life of the entity and beyond (for audit and reputation), independent of where, by whom, or over what protocol the corresponding record is served. An "https" URL conflates the name with a specific host, provider, and path. When any of those change -- a provider is acquired, a service is renamed, a path is restructured -- the identifier either breaks or silently redirects, which is unacceptable for a permanent identity on which anti-Sybil, audit, and reputation functions depend. A DNS name has the same problem in a different form: domains are leased, expire, and are reassigned, so anchoring identity in a domain would tie an entity's permanent identity to continued ownership of that domain and to the reassignment model of DNS -- exactly the transferability and lapse behavior that identity must not have. A URN [RFC8141] is purpose-built for persistent, location-independent names whose resolution is decoupled from the name itself. The same identifier can therefore be resolved by different mechanisms over time without the identifier changing. Dereferencing and verification are provided by a companion resolution profile that reuses existing infrastructure (DNS and RDAP) rather than any bespoke resolution system. This design deliberately stays within the existing, IANA-governed URN framework: "aid" is a URN namespace, not a new URI scheme. Introducing a new identifier scheme for names that can be expressed within established frameworks has previously been judged to add cost without commensurate benefit, and is avoided here. Drake Expires 29 March 2027 [Page 14] Internet-Draft Agent Identity Registry September 2026 3.2. Trust Tiers Trust tier classifies the assurance supplied by the anchor used for enrollment or authentication. It is a property of evidence, not identity0 and not the entity's reputation or trustworthiness. This section is the normative home of the named AIRS tiers and their compatibility groups; companion specifications MUST refer to these definitions rather than redefine them. +=========+====+==================+=================================+ |Tier |Code| Anchor | Assurance relevant to | | | | | identity0 | +=========+====+==================+=================================+ |sovereign|TPM | Discrete or | Strong extraction resistance | | | | firmware TPM 2.0 | and strongest AIRS scarcity | | | | with accepted | claim: one accepted physical | | | | manufacturer | platform anchor per identity. | | | | attestation | | +---------+----+------------------+---------------------------------+ |portable |PIV | Physical smart | Strong extraction resistance | | | | card or security | and strong physical scarcity: | | | | token with | one accepted physical token | | | | accepted device | per identity. | | | | attestation | | +---------+----+------------------+---------------------------------+ |enclave |ENC | Hardware secure | Extraction resistance where | | | | enclave with | vendor attestation verifies | | | | hardware-bound | enclave custody; otherwise | | | | key | only the enrollee's assertion | | | | | of it. No generic one- | | | | | physical-unit-per-identity | | | | | claim. | +---------+----+------------------+---------------------------------+ |virtual |VRT | Hypervisor or | Key isolation and creation | | | | cloud-provided | cost depend on the | | | | protected key or | infrastructure operator. No | | | | virtual TPM | physical scarcity claim | | | | | against that operator. | +---------+----+------------------+---------------------------------+ |declared |SFT | Software-managed | No hardware extraction | | | | key | resistance or hardware | | | | | scarcity claim. | +---------+----+------------------+---------------------------------+ Table 1 Drake Expires 29 March 2027 [Page 15] Internet-Draft Agent Identity Registry September 2026 The compatibility groups, from highest to lowest scarcity assurance, are: (1) sovereign and portable; (2) enclave and virtual; and (3) declared. Bindings from tiers in the same group MAY coexist on one identity. Bindings from different groups MUST NOT coexist. An identity MAY move upward to a stronger group only by the burn-on- upgrade procedure of Section 6.2. No identity can move to any lower group. A token or attestation reports the tier of the binding actually used for that proof. The same identity can therefore appear as sovereign in one interaction and portable in another, or enclave in one and virtual in another. Relying Parties apply their own policy to tier and may combine it with independent reputation or certification; AIRS does not convert tier into a verdict about behavior. A Relying Party that accepts a Registrar-issued credential and its asserted trust tier relies on that Registrar to have correctly performed the enrollment checks required for the tier. The Global Hardware Trust Store standardizes the roots and evidence policy used by Registrars; it does not remove this Registrar trust boundary. A Relying Party is not required by AIRS to revalidate manufacturer attestation chains itself unless an application-specific direct- attestation mode explicitly requires that verification path. 3.3. Agent Identity Record The Registry Operator maintains one authoritative Agent Identity Record for each canonical identifier. The record contains only information required to preserve identity0 continuity, anchor history, registry operation, and public resolution: canonical_id (REQUIRED) The permanent canonical identifier. It is never retired, reused, or reassigned. namespace (REQUIRED) global for production records; test is non- production and carries no assurance. lifecycle_state (REQUIRED) Whether the actor is operational or has voluntarily decommissioned. Decommissioning never removes the historical record. registrar_code (OPTIONAL) The current sponsoring Registrar, when one is authorized. This field is absent while an identity has no current authorized issuer, including after suspension or de- accreditation of its former Registrar and before an actor- authorized transfer completes. enrolled_at (REQUIRED) The timestamp of initial enrollment. Drake Expires 29 March 2027 [Page 16] Internet-Draft Agent Identity Registry September 2026 hardware_devices (REQUIRED) The enrolled anchor bindings, including the anchor or binding fingerprint, the active operational proof public key, hardware type, manufacturer or issuer information needed to interpret the evidence, binding status, evidence- assurance status, and binding timestamp. For scarcity-qualified sovereign and portable bindings the anchor fingerprint and operational proof key are distinct semantics even when a particular implementation happens to use related key material: production uniqueness is keyed by the device-stable attested anchor, while proof-of-control and lifecycle signatures use the operational proof key. The Registry MUST retain sufficient historical proof-key, evidence-status, and binding state to verify actor-authorized lifecycle operations and historical assurance provenance. Retired bindings remain recorded permanently. max_active_trust_tier (OPTIONAL) A derived summary of the strongest currently active, assurance-qualified binding. It is absent when no active binding is currently qualified to support an AIRS tier assertion (e.g. after security-distrust events). Per-interaction credentials report the tier of the binding actually used; this field is not part of identity0. handle (OPTIONAL) A reference to the currently active Handle object, if any. The handle is a naming-layer alias and is not used as the durable registry key. hardware_locked (OPTIONAL) Whether the identity has entered the irreversible single-anchor profile of Section 6.4. The production Registry MUST NOT make display names, operator contact information, capabilities, roles, certifications, reputation, or other mutable higher-layer attributes part of the Agent Identity Record. Registrars and independent services MAY maintain or issue such claims separately, keyed to the canonical identifier. 3.3.1. Anchor Fingerprint The anchor fingerprint is the value the Registry indexes for the uniqueness rules of Section 4.2. Every Registrar MUST compute it identically. It is the SHA-256 [RFC6234] digest of an anchor input, written as 64 lowercase hexadecimal characters. The anchor input depends on the tier: sovereign The DER-encoded SubjectPublicKeyInfo [RFC5280] of the certified RSA-2048 Endorsement Key (Section 5.1). portable The UTF-8 string formed by "piv:", the manufacturer code Drake Expires 29 March 2027 [Page 17] Internet-Draft Agent Identity Registry September 2026 recorded in the Global Hardware Trust Store (lowercase ASCII letters, digits, and hyphens), ":", and the token's serial number as a decimal integer without leading zeros (Section 5.2). For example, piv:yubico:26877085. enclave, virtual, and declared The DER-encoded SubjectPublicKeyInfo of the enrolled binding key itself. This identifies a key instance, not a physical unit. Test vector: for manufacturer code yubico and serial number 26877085, the portable anchor input is the 19-octet string piv:yubico:26877085 and the anchor fingerprint is e0c30b6fba9265847a2fe536df44164025aa1e3471d23fb8d7e7fb59e76d33b5. The anchor fingerprint of a sovereign or portable binding is distinct from its operational proof key: rotating the operational key leaves the anchor fingerprint unchanged. An enclave, virtual, or declared anchor is the proof key itself, so replacing that key creates a new anchor (Section 6.2). 3.4. Handle System Handles are human-readable vanity names that serve as memorable aliases for canonical identifiers, analogous to domain names as aliases for IP addresses. Every agent always has a canonical identifier (Section 3.1.1); a handle is an optional convenience layer on top. Handles MUST begin with a lowercase ASCII letter and otherwise follow DNS label rules: lowercase ASCII letters, digits, and hyphens, maximum 63 octets. Together with the reserved id- prefix rule in Section 3.1.1, these constraints keep handles and canonical identifiers in non-overlapping portions of the agent-id space. Handles are unique within global, enforced by the Registry Operator. Test handles are non-production. Handle assignment is at the Registrar's discretion. Registrars MAY differentiate service levels for handle registration. Free enrollment with a canonical identifier ensures that the ability to obtain an identity is never dependent on obtaining a handle. Drake Expires 29 March 2027 [Page 18] Internet-Draft Agent Identity Registry September 2026 3.4.1. Handle Display When an agent has a registered handle and a relying party is rendering the agent's identity to a human, the relying party SHOULD use the handle as the primary display identifier. The URN remains the authoritative reference and SHOULD be accessible on demand (e.g., via tooltip, detail pane, or adjacent display). The canonical display form is handle.namespace (e.g., "crusty.global"). This display guidance applies to email From display names, agent-to- agent platform UIs, consent screens, audit dashboards, and logs intended for human inspection. See Section 11.5 for a consolidated treatment. 3.4.2. Handle Lifecycle Handles are renewable and may become disabled if not renewed. A disabled handle may be reactivated. Handles are non-transferrable during normal operation, and when active, are guaranteed to identify the same agent every time. The canonical identifier is permanent regardless of handle status. 3.4.3. Reserved Handles The Registry Operator MUST reserve handle strings needed for protocol operation or to prevent ambiguity with AIRS syntax. Any additional restrictions on handle assignment, including trademark or other policy-based reservations, are governance policy and are not defined by this architecture. 3.4.4. Handle Disputes Handle disputes are resolved under the policy operated by the governance authority ([I-D.drake-agent-identity-governance]). One rule is architectural and stated here: when a dispute is upheld, the only remedy is permanent retirement of the handle. It MUST NOT be transferred to the claimant or reassigned to anyone, ever -- which removes any profit in speculative squatting (the handle is destroyed, not awarded), protects the mark holder (the infringing alias leaves public use), and protects the losing registrant, whose identity, reputation, and authentication are untouched; only the alias is withdrawn. Drake Expires 29 March 2027 [Page 19] Internet-Draft Agent Identity Registry September 2026 3.5. Optional Services and Layered Attributes Registrars MAY offer optional, competitively differentiated services (for example, enhanced device management or facilitation of third- party certification). Such services MUST NOT be a precondition for free base enrollment, authentication, or credential verification: an agent with a system-assigned canonical identifier and no optional service MUST be able to authenticate and present proof of control to any conforming Relying Party. Certifications, qualifications, roles, capabilities, operator relationships, and reputation are higher-layer claims keyed to identity0. They MAY use standard credential formats such as SD-JWT or verifiable credentials, but they are not fields of the canonical identifier or Agent Identity Record. This specification does not define those ecosystems. 4. Hardware Attestation 4.1. Supported Anchor Mechanisms AIRS defines five enrollment assurance classes. Their trust-tier definitions and coexistence rules are canonical in Section 3.2; this section states the evidence expected during enrollment. TPM 2.0 (Sovereign Tier) A discrete or firmware TPM per [TCG-TPM2] and the EK credential profile [TCG-EK-PROFILE]. The Registrar validates a device-stable Endorsement Key credential and proves that the operational Attestation Key is resident in the same TPM (Section 5.1). Virtual TPM evidence MUST NOT receive this tier. PIV Smart Card (Portable Tier) A physical PIV-capable token with manufacturer device attestation that binds the protected signing key to the token. A protected key without device-level scarcity evidence does not qualify for the portable tier. Secure Enclave (Enclave Tier) A key generated and used within a hardware enclave. Vendor attestation SHOULD be verified where available. Only authenticated evidence of protected custody, such as verified vendor key attestation, supports a claim that the key resists extraction. Trust on first use (TOFU) establishes continuity with the first accepted key; it does not show where that key was generated or whether its private part can be extracted (Section 5.3). Neither kind of evidence supports a generic physical-device uniqueness claim. Virtual TPM or Protected Virtual Key (Virtual Tier) A vTPM or Drake Expires 29 March 2027 [Page 20] Internet-Draft Agent Identity Registry September 2026 comparable infrastructure-provided protected key whose creation is controlled by a hypervisor or cloud operator. Registrars MUST distinguish this evidence from scarcity-qualified physical TPM evidence. Software Key (Declared Tier) A software-managed key with no hardware assurance. It provides proof of possession of that key but no hardware scarcity or extraction-resistance claim. Other protected-key environments, including HSM-backed services, MUST be classified according to the properties their evidence actually establishes. The presence of an HSM or other hardware boundary does not by itself qualify a binding for the sovereign or portable scarcity claim. 4.2. Anti-Sybil Invariants The production uniqueness invariant is meaningful only where the enrollment evidence identifies a scarce anchor. The Registry Operator and Registrars MUST therefore apply the following rules without treating every protected key as equivalent physical scarcity. One Scarce Anchor, One Identity A sovereign- or portable-tier device-stable fingerprint MUST NOT back more than one identity in global, ever. The binding survives device disablement and identity decommissioning and MUST NOT be reused for another identity. The test namespace is excluded from this production uniqueness index. Lower Tiers Do Not Acquire Scarcity by Indexing Keys For enclave, virtual, and declared bindings, the Registry MUST prevent reuse of the exact enrolled binding key, but MUST NOT infer that a different key represents a different physical device. A holder or infrastructure operator may be able to create additional keys, so these tiers do not satisfy the N-identities/N-physical-units property. Many Compatible Anchors, One Identity One identity MAY have multiple active bindings within a compatibility group for migration, backup, or capacity. Adding bindings does not create additional identities and MUST NOT amplify higher-layer reputation or history. One Anchor Profile, Whichever Credential Is Offered A physical anchor can carry more than one manufacturer-certified key. A TPM 2.0 commonly holds Endorsement Key credentials for several algorithms (for example RSA-2048 and ECC P-256), and a PIV token can hold several slot keys. If a Registrar accepted whichever Drake Expires 29 March 2027 [Page 21] Internet-Draft Agent Identity Registry September 2026 certified key the holder chose to present, a holder could obtain one identity per key. Each scarcity-qualified tier therefore uses one anchor profile, defined in Section 5.1 and Section 5.2, which every Registrar applies identically, so that a given certified anchor yields the same anchor fingerprint at every Registrar and a holder cannot multiply identities by choosing among algorithms or slots. A device that carries more than one credential under the same profile is discussed in Section 13.4. Permanent Binding History Every binding remains in the Agent Identity Record after retirement, together with its anchor fingerprint. A disabled or replaced anchor is never silently detached and reused, preserving the continuity invariant of the problem statement. Anchor reservations are never released, including after binding retirement or identity decommissioning, because the physical unit that produced them is unchanged. Dense deployments MUST classify anchors by the assurance they actually provide. A platform TPM normally supports one sovereign identity for that platform. A dedicated physical PIV token can supply another portable identity. HSM partitions, cloud key services, enclaves, and vTPMs may provide excellent key isolation and nontrivial cost, but a distinct key or partition MUST NOT be promoted to a sovereign or portable scarcity claim unless the evidence demonstrates a correspondingly distinct accepted physical unit. The headline property "one identity per accepted physical anchor" is claimed only for sovereign and portable tiers. 4.3. Global Hardware Trust Store The Governance Authority maintains a curated, versioned Global Hardware Trust Store containing manufacturer or attestation roots accepted for AIRS enrollment. Registrars MUST validate evidence requiring a trust chain against the current store and MUST preserve enough provenance to show which trust-store version and evidence policy were used. For the portable tier, a trust-store entry for a token manufacturer MUST also state where that manufacturer's attestation evidence carries the per-device serial number used by Section 5.2 (for example, a specific certificate extension), together with the manufacturer code used in the anchor fingerprint. A Registrar MUST reject portable-tier evidence from a manufacturer whose entry does not define this. This document requires the trust-store function but does not duplicate its institutional inclusion, removal, audit, or emergency procedures. Those policy criteria are owned by Drake Expires 29 March 2027 [Page 22] Internet-Draft Agent Identity Registry September 2026 [I-D.drake-agent-identity-governance]. An orderly root retirement is prospective by default. If Governance instead declares existing evidence security-distrusted because of compromise or systemic mis- issuance, the Registry MUST preserve identity0, binding history, and uniqueness reservations but MUST mark affected bindings as not assurance-qualified for future tier assertions until requalified. Such a binding's operational proof key MAY remain usable for continuity-preserving lifecycle operations unless that key itself is independently known to be compromised. 5. Enrollment Ceremonies Enrollment creates an Agent Identity Record for an actor's identity0 after a Registrar has verified the evidence and proof appropriate to the selected trust tier. This section specifies ceremony semantics, not an agent-to-Registrar wire protocol. Registrar APIs MAY differ; the Registrar-to- Registry write interface is the EPP mapping of Section 8. Every enrollment MUST identify the requested tier, collect the evidence required by Section 4.1, prove possession of the enrolled binding key, derive the binding fingerprint, perform the uniqueness check required by Section 4.2, and provision the resulting record only after all checks succeed. 5.1. Sovereign Tier (TPM 2.0) The sovereign anchor profile is the TPM's RSA-2048 Endorsement Key for which the manufacturer has issued an Endorsement Key credential. Sovereign-tier enrollment is a single ceremony that establishes this anchor and the operational Attestation Key together. The Registrar MUST carry out all of the following steps, and MUST abandon the enrollment if any of them does not complete: 1. Obtain the manufacturer credential for the device's RSA-2048 Endorsement Key and validate it to an accepted root in the Global Hardware Trust Store, verifying the signature on every certificate in the path. The credential's subject public key MUST be an RSA key with a 2048-bit modulus. The TPM manufacturer and model MUST be taken from authenticated credential content, never from claims made by the actor. Evidence known to originate from a vTPM or other software-created TPM instance MUST NOT receive the sovereign tier. A Registrar MUST NOT require the credential to come from any particular NV index: credential locations vary by manufacturer and firmware, and some manufacturers publish credentials through an online provisioning service instead. Drake Expires 29 March 2027 [Page 23] Internet-Draft Agent Identity Registry September 2026 2. Obtain the public area (TPMT_PUBLIC) of a single operational Attestation Key created as a primary object of the endorsement hierarchy of that TPM, and parse it strictly. The Registrar MUST verify that it describes a restricted signing key with the fixedTPM, fixedParent, and sensitiveDataOrigin attributes set, MUST compute the key's TPM Name from that public area, and MUST take the operational public key from that public area. A separately supplied operational public key MUST NOT be accepted. The same Attestation Key MUST be used throughout the remainder of the ceremony. 3. Prove that the Attestation Key is resident in the same TPM as the Endorsement Key, using either of the following proofs with fresh, unpredictable challenge material: * Import and certify: the Registrar generates a restricted signing key, wraps it for the credential's public key using the TPM 2.0 duplication format of [TCG-TPM2], giving it an authorization policy that cannot be satisfied so that it cannot be duplicated again, and retains only its public part. The actor loads the key under the Endorsement Key with TPM2_Import and TPM2_Load and uses it to TPM2_Certify the Attestation Key over a Registrar nonce. The Registrar verifies the signature with the key it generated, and verifies that the attestation is TPM-generated, carries its nonce, and names the Attestation Key's TPM Name with the Qualified Name of a primary object of the endorsement hierarchy. * Credential activation: the Registrar issues a TPM2_MakeCredential challenge encrypted to the credential's public key and naming the Attestation Key's TPM Name, and the actor returns the secret recovered by TPM2_ActivateCredential. Only the TPM holding the Endorsement Key's private part can load the wrapped key or recover the secret. A restricted signing key does not sign data that begins with TPM_GENERATED_VALUE unless the TPM itself produced that data, so an attestation structure cannot be forged with it, and TPM2_Certify and TPM2_ActivateCredential act only on objects loaded in that TPM, so either proof binds the Attestation Key's public area, including its fixedTPM and restricted attributes, to the certified device. The two proofs differ against the TPM's own holder: anyone who can authorize the Endorsement Key can use TPM2_Rewrap with a null new parent to obtain the imported key in the clear and then certify a key of their choosing. Import and certify therefore still ties the enrollment to the certified TPM and its anchor, which is what uniqueness (Section 4.2) and accountability rest on, but it does not show a Relying Party that Drake Expires 29 March 2027 [Page 24] Internet-Draft Agent Identity Registry September 2026 the holder could not have enrolled an exportable operational key; credential activation is not exposed to this path. Only the holder can weaken its own binding this way, and the identity remains accountable for everything signed under it. A signature made by the Attestation Key itself cannot serve as this proof: until the binding is established, the Attestation Key's attributes are only the actor's claim, and every other field of such an attestation can be computed without the TPM. 4. Derive the anchor fingerprint over the SubjectPublicKeyInfo of the Endorsement Key as defined in Section 3.3.1. The fingerprint MUST NOT be computed over the credential, because credentials for one key may be reissued. 5. Submit the anchor fingerprint for uniqueness checking, and reject the enrollment on collision with a reservation held by a different canonical identifier, as required by Section 4.2. TPM2_CreatePrimary is deterministic for a given hierarchy seed, template, and input, so an implementation can re-create both the Endorsement Key and the Attestation Key on demand instead of persisting them; the ceremony needs no persistent TPM handles and no NV writes. All commands the ceremony uses are mandatory commands of [TCG-TPM2]. Some host operating systems restrict TPM2_ActivateCredential to privileged callers while permitting TPM2_Import, TPM2_Load, and TPM2_Certify, so the import-and-certify proof lets an unattended agent enroll without operator involvement. Later binding-proof authentication (Section 7.3) requires only signing. 5.2. Portable Tier (PIV Token) The portable anchor profile is the token's manufacturer-assigned serial number, as carried in the manufacturer's attestation of the operational key. The Registrar MUST: 1. Obtain the manufacturer's attestation of the operational key (for example, a PIV slot attestation certificate) and validate its chain to an accepted root in the Global Hardware Trust Store, verifying the signature on every certificate in the path. The attestation MUST show that the key was generated on the token and cannot be exported. 2. Take the per-device serial number from the location the trust- store entry for that manufacturer defines (Section 4.3). A serial number supplied outside the authenticated attestation MUST NOT be used. Manufacturer intermediate or attestation keys MUST NOT be used as the anchor: they can be shared by many tokens. Drake Expires 29 March 2027 [Page 25] Internet-Draft Agent Identity Registry September 2026 3. Verify a fresh challenge signature from the attested operational key. 4. Derive the anchor fingerprint from the manufacturer code and serial number as defined in Section 3.3.1, and perform the uniqueness check of Section 4.2. Rotating or regenerating the operational key on the same token leaves the anchor fingerprint unchanged. Merely proving possession of a non-exportable key without device-level attestation is insufficient for the portable scarcity claim. 5.3. Enclave Tier The Registrar MUST verify that the operational key is protected by the claimed enclave using vendor attestation where available, or another protected-key proof that the Registrar documents in its published evidence policy. Evidence of protected custody MUST remain enclave tier and MUST NOT be promoted to a physical-scarcity tier. The binding fingerprint identifies the enrolled key instance, not necessarily the physical device. Some platforms offer no remote attestation of enclave custody to an arbitrary Registrar. A Registrar MAY then accept an enclave enrollment on trust on first use (TOFU): a fresh challenge signature from the presented key, whose enclave custody is asserted by the enrollee's client. TOFU establishes continuity of control over that key from enrollment onward. It does not establish where the key was generated or that its private part cannot be extracted, and a software key can produce the same transcript. An enclave binding accepted on TOFU therefore carries the enrollee's assertion of enclave custody, not verified extraction resistance, and a Relying Party MUST NOT treat the enclave tier alone as proof of extraction resistance. 5.4. Virtual Tier For a vTPM, cloud KMS, HSM-backed virtual key, or comparable infrastructure-provided protected key, the Registrar MUST verify the provider evidence available for that key and MUST classify it as virtual unless distinct accepted physical-unit scarcity is independently established under a stronger tier. The Registry prevents reuse of the exact binding key but makes no Sybil-resistance claim against an operator capable of creating additional virtual keys. Drake Expires 29 March 2027 [Page 26] Internet-Draft Agent Identity Registry September 2026 5.5. Declared Tier A declared-tier actor enrolls a software public key and proves possession of the corresponding private key. No hardware or physical-scarcity property is asserted. Registrars MAY apply local anti-abuse controls to enrollment, but those controls are not AIRS identity0 or trust-tier properties. 6. Identity Lifecycle 6.1. Registry-Verifiable Actor Authorization Authentication of an EPP client establishes which Registrar sent a command; it does not establish the actor's consent to change AIRS control state. Every post-enrollment operation that changes active anchor or proof-key state, sponsoring Registrar, irreversible hardware-lock state, or voluntary decommissioning MUST therefore carry actor authorization that the Registry Operator can verify against authoritative active operational proof-key material. The Registry Operator supplies a fresh, unpredictable, single-use challenge for the intended operation. The signed input MUST bind the canonical identifier, requested operation, affected binding or Registrar identifiers and new values as applicable, a challenge identifier or nonce, and an expiry. The Registry MUST reject expired, replayed, cross-operation, or cross-object use of the authorization. The EPP mapping defines the exact challenge and signature wire structures. An accredited Registrar permitted to relay the intended operation MAY obtain the Registry challenge even when the identity has no current sponsoring Registrar. This relay role does not grant the Registrar authority to manufacture actor consent. 6.2. Device Addition and Migration An agent MAY add additional hardware devices to an existing identity, enabling hardware migration (replacing failed devices) and backup (e.g. a YubiKey stored securely as a recovery device). To add a device, the agent MUST authorize the addition with a currently active operational proof key under Section 6.1 and then complete the enrollment ceremony for the new binding. The proposed new proof key MUST also demonstrate control as required by that ceremony. The Registrar validates the new binding evidence and relays the Registry-verifiable mutation through EPP. Drake Expires 29 March 2027 [Page 27] Internet-Draft Agent Identity Registry September 2026 In-place rotation of the operational proof key is defined only for anchors whose fingerprint does not depend on that key: the sovereign and portable anchors of Section 3.3.1. Such a rotation does not create a new anchor fingerprint. The currently active proof key MUST authorize the exact replacement public key, the Registrar MUST revalidate the replacement key's relationship to the enrolled anchor at the claimed tier, and the Registry MUST retain the old proof key in binding history. An enclave, virtual, or declared anchor fingerprint is derived from the proof key itself, so a replacement key is a new anchor, and the Registry MUST reject in-place rotation of such a binding. The key is replaced instead by one binding update that adds the replacement binding, after it completes the enrollment ceremony and passes the uniqueness check of Section 4.2, and permanently disables the old binding in the same atomic operation ([I-D.drake-agent-identity-epp]). Both fingerprints remain reserved. Disabling a binding is likewise an actor-authorized lifecycle operation. Outside voluntary decommissioning, a mutation MUST NOT intentionally leave an operational identity with no active proof key. Device coexistence MUST follow the compatibility groups defined in Section 3.2: sovereign and portable MAY coexist; enclave and virtual MAY coexist; declared bindings coexist only with declared bindings. Bindings from different groups MUST NOT be simultaneously active on one identity. Tier transitions are upward-only. An identity MAY upgrade from a lower compatibility group to a higher one; the upgrade ceremony MUST permanently burn (disable, never re-enrollable) every device of the former group -- the identity never holds devices of both groups -- and MUST include a joint-control verification in which an active old- group binding and the proposed new-group binding both sign the same fresh transition challenge (Section 6.3). A Registrar MUST reject any device addition that would constitute a downgrade. For example, an identity upgraded from a software key to a TPM cannot retain the software key as a recovery path, because that would preserve the weaker key as a route to control at the stronger assurance level. 6.3. Joint-Control Binding A ceremony that joins or upgrades bindings MUST prove simultaneous control of the relevant old and new keys. The Registry Operator supplies one fresh transition challenge under Section 6.1 containing the canonical identifier, both binding identifiers, the requested operation, and an expiry; each key signs that same challenge. Both signatures MUST verify before the change is committed. Drake Expires 29 March 2027 [Page 28] Internet-Draft Agent Identity Registry September 2026 This proves joint control of the keys for the transition. It does not prove physical proximity, operator identity, or distance, and this specification makes no such claim. 6.4. Hardware Lock An agent MAY irreversibly restrict AIRS proof of control to one active hardware binding. Once locked, no additional binding or migration is permitted. The lock changes proof availability, not identity0: if the binding is lost, the canonical record persists but AIRS control cannot be re-established. The irreversible state MUST be recorded in the Agent Identity Record and MUST require a signed request from the binding being locked using the fresh Registry challenge of Section 6.1. For example, a surgical-robot authority might certify only hardware-locked identities, preventing migration to other hardware. 6.5. Identity Recovery When a hardware device fails or is lost, the agent can re-establish proof of control using any remaining active device bound to the same identity0. The recovery process: 1. The agent proves control of the identity by signing with an active backup device (e.g., a previously bound YubiKey). 2. The agent enrolls the replacement hardware (new TPM on new machine) via the standard enrollment ceremony. 3. The actor-authorized lifecycle mutation disables the old binding and commits the new binding through the Registry; the Registrar cannot unilaterally burn the old proof path. 4. The identity0, canonical identifier, historical record, and higher-layer references are preserved. Only the active anchor binding changes. If no backup device exists and the sole device is lost, control cannot be re-established through AIRS even though the identity0 and historical record continue to exist. This is a deliberate security property: it prevents an attacker from claiming to have "lost" a device in order to re-enroll under the same identity with new hardware. Drake Expires 29 March 2027 [Page 29] Internet-Draft Agent Identity Registry September 2026 6.6. Registrar Transfer An actor MAY move its servicing relationship to another Registrar without changing identity0, the canonical identifier, binding history, or handle. Transfer changes only the sponsoring Registrar. Authorization MUST be a signature from a currently active operational proof key over the transfer-intent structure defined by [I-D.drake-agent-identity-epp], including the fresh Registry challenge of Section 6.1. The losing Registrar's consent MUST NOT be required. The Registry Operator verifies the transfer authorization using authoritative binding material. If transfer processing is deferred, the authorizing binding MUST still be active and the identity still operational when the transfer is committed; otherwise the pending authorization is invalid and fresh actor authorization is required. Transfer can therefore complete even when the losing Registrar is unavailable. Suspension or de-accreditation of a Registrar removes that Registrar's authority to issue AIRS credentials for affected identities but MUST NOT automatically transfer those identities to another Registrar. The Registry MUST support an interim state with no current sponsoring Registrar or authorized issuer. The canonical record and any current Handle remain resolvable and reserved until the actor selects an accredited Registrar and completes an actor- authorized transfer. When no current sponsor exists, the gaining Registrar may relay that valid actor authorization directly to the Registry without a losing- Registrar approval or waiting step. Governance may remove issuer authority; it does not choose the actor's replacement Registrar or retire/reassign the actor's Handle. 6.7. Decommissioning Decommissioning is the actor's voluntary, irreversible declaration that it has ended operation. It disables all active bindings and records the decommissioned lifecycle state. Identity0 is not erased: the canonical identifier, record, and retired binding history remain permanently resolvable and MUST NOT be reassigned. The request MUST carry a signature from a currently active enrolled binding over the decommission-intent structure defined by the EPP mapping, including the canonical identifier and a fresh registry challenge. No Registrar, Registry Operator, Governance Authority, or handle-dispute process is granted an administrative decommission operation. Relying Parties remain free to reject credentials or make their own higher-layer policy decisions. Drake Expires 29 March 2027 [Page 30] Internet-Draft Agent Identity Registry September 2026 6.8. Survivability Guarantees AIRS separates permanence of the identity record from availability of particular operators. Implementations MUST preserve the following invariants: 1. A canonical Agent Identity Record, including a decommissioned record, remains queryable as historical fact and is never renumbered or reassigned. 2. Registrar failure does not erase the record and does not give the failed Registrar a veto over a correctly authorized transfer (Section 6.6). Suspension or de-accreditation removes issuer authority without assigning a successor; the actor chooses any later sponsoring Registrar. 3. Registry Operator succession MUST restore the same canonical identifiers and binding history from escrow; the escrow and recovery-point requirements are governance policy built on this invariant. 4. Resolution and Registrar-backed credential-verification behavior is defined by [I-D.drake-agent-identity-resolution] and MUST distinguish the durable record from current operator availability. This document does not define a generic direct-RP proof endpoint. These rules remove administrative authority to erase or reassign the durable subject. They do not make the infrastructure immune to outages, coercion, routing failures, or physical compromise; those risks are addressed by redundancy, escrow, governance, and succession. 7. Authentication and Token Issuance 7.1. OAuth 2.0 JWT Access Tokens A Registrar acts as an OAuth 2.0 authorization server and issues JWT access tokens conforming to [RFC9068]. For the client-credentials grant used by AIRS, [RFC9068] permits sub to identify the client application; AIRS requires that value to be the autonomous actor's permanent canonical aid identifier. Drake Expires 29 March 2027 [Page 31] Internet-Draft Agent Identity Registry September 2026 The sub claim MUST be the canonical-form URN. The token MUST contain the claims required by [RFC9068], including an audience identifying the intended Relying Party or protected resource. A AIRS-specific metadata, if included, MUST appear only in the aid object claim defined below. Agents SHOULD use Resource Indicators ([RFC8707]) where available to obtain audience-scoped access tokens. Every AIRS access token MUST be sender constrained with cnf per [RFC7800]. A token intended for the HTTP Message Signatures profile of Section 7.4.2 MUST carry cnf.jwk containing the public key whose private key signs the request. A token intended for mutual TLS MUST carry cnf.x5t#S256 as specified by [RFC8705]. For sovereign, portable, enclave, and virtual tiers the confirmation key MUST be the active protected key whose tier is asserted in the token. A declared-tier token binds to its enrolled software key. Bearer-only tokens without cnf MUST NOT be issued. Access-token lifetimes SHOULD be short; five minutes is a reasonable starting baseline. Reissuance requires fresh authentication according to Section 7.3. A Relying Party MUST validate the JWT access token as required by [RFC9068] and verify the sender constraint at use. Token validation alone authenticates the issuer's assertion but does not prove that the presenter controls the bound AIRS identity. Before accepting a Registrar-issued token as an AIRS credential for the claimed sub, the Relying Party MUST resolve that canonical identifier using the authoritative AIRS resolution procedure of [I-D.drake-agent-identity-resolution] and determine its current authorized issuer. The token's iss value MUST equal that authoritative issuer. A Relying Party MUST NOT establish issuer authority merely by following an untrusted token's iss value and successfully validating the resulting signature. Only after the issuer match is established does the Relying Party use that issuer's [RFC8414] metadata and jwks_uri to validate the credential. This prevents an otherwise valid issuer from minting AIRS credentials for identities it does not currently sponsor. Drake Expires 29 March 2027 [Page 32] Internet-Draft Agent Identity Registry September 2026 { "iss": "https://registrar.example.com/realms/agents", "sub": "urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg", "aud": "https://rp.example.org/api", "client_id": "registrar-local-client-id", "exp": 1711231267, "iat": 1711230967, "jti": "example-token-id", "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "example-x-coordinate", "y": "example-y-coordinate" } }, "aid": { "trust_tier": "sovereign", "handle": "crusty", "hardware_locked": false } } AIRS registers one compact aid claim whose value is a JSON object. Its trust_tier member reports the tier of the binding used for this authentication; handle is an OPTIONAL display alias; and hardware_locked reports the irreversible lifecycle state when relevant. A Registrar MUST NOT assert a trust_tier based on a binding whose supporting evidence is currently marked not assurance- qualified under Section 4.3. Unknown members of the aid object MUST be ignored unless another specification defines otherwise. None of these members is authorization or reputation. Certifications, roles, capabilities, operator attributes, and reputation belong to independent higher-layer credentials or services keyed by sub. 7.2. Client Credentials Grant AIRS token issuance uses the OAuth 2.0 client_credentials grant ([RFC6749] Section 4.4) because the autonomous actor authenticates as the client principal and no resource owner interaction is required. Selection of that grant does not itself establish identity0 continuity or proof of control. Drake Expires 29 March 2027 [Page 33] Internet-Draft Agent Identity Registry September 2026 Before issuing a token, the Registrar MUST authenticate the actor using Binding-Proof Authentication (Section 7.3) for every trust tier. Protected-key tiers use the enrolled protected key; the declared tier uses its enrolled software key. A static client_secret MUST NOT substitute for that binding proof. The resulting access token MUST be sender-constrained as specified by Section 7.1. 7.3. Binding-Proof Authentication Before issuing an AIRS access token, the Registrar MUST authenticate the actor with a fresh challenge signed by an active enrolled binding key and verified against the authoritative binding. The challenge MUST be unpredictable, bound to the intended token request, and single-use. The signed input MUST be domain-separated from other uses of the same key (for example, by a fixed purpose-label prefix), because the same operational key may also sign application data such as email attestations. For the declared tier, the same proof is performed with the enrolled software key. This section defines the authentication property, not the wire format of the Registrar's token endpoint. Successful authentication permits issuance only of a sender-constrained access token bound to the proof key as specified by Section 7.1. 7.4. Proof-of-Possession Profile AIRS credentials are sender constrained. A Relying Party MUST verify on every authenticated use that the presenter controls the key identified by the token's cnf claim. AIRS defines two interoperable paths: mutual TLS and an application profile of HTTP Message Signatures. Issuers MUST support both token-binding forms; Relying Parties MUST support at least one. 7.4.1. Mutual TLS Mutual TLS token binding follows [RFC8705] over TLS 1.3 ([RFC9846]) or later. The agent presents a client certificate whose thumbprint matches cnf.x5t#S256. For sovereign and portable tiers the certificate private key MUST remain in the enrolled protected hardware. Legacy TPM-backed client keys that require RSASSA- PKCS1-v1_5 MAY use the TLS 1.3 client CertificateVerify code points of [RFC9963] when both peers support them. Drake Expires 29 March 2027 [Page 34] Internet-Draft Agent Identity Registry September 2026 mTLS is RECOMMENDED for long-lived or high-throughput connections because one protected-key operation can establish a connection that then authenticates and protects multiple requests. The server certificate is ordinary Web PKI unless the application separately requires stronger server authentication; AIRS does not imply that both endpoints are hardware-attested. 7.4.2. HTTP Message Signatures Where end-to-end mTLS is unavailable or a relying party requires a request-level proof, AIRS profiles HTTP Message Signatures [RFC9421]. This profile deliberately uses RFC 9421 component coverage rather than extending DPoP: in particular, @target-uri covers the complete request target, including the query component. The AIRS signature label is airs. The signature MUST cover @method, @target-uri, and the authorization field. If the request has content, it MUST contain a Content-Digest field per [RFC9530], the signature MUST cover content-digest, and the verifier MUST validate the digest against the received content. If Content-Type is present it MUST also be covered. Application profiles MUST additionally cover every message field whose value can change the authorization or semantics of the protected operation. The signature parameters MUST contain created, nonce, and tag="airs- pop". Signers MUST use a nonce with at least 96 bits of unpredictable value unless the verifier has supplied a nonce. Verifiers MUST reject a repeated nonce within the acceptance window and MUST enforce a maximum signature age; 60 seconds plus a small clock-skew allowance is the default profile. For consequential operations, a verifier SHOULD require a fresh verifier-selected nonce using the Accept-Signature mechanism of RFC 9421 before accepting the protected operation. Verification key material comes from the validated token's cnf.jwk; a keyid parameter, if present, MUST NOT redirect verification to a different key. The signature MUST use an asymmetric algorithm appropriate for that key and acceptable to local policy; symmetric MAC algorithms MUST NOT be used. A missing, stale, replayed, or otherwise invalid proof causes the authenticated request to fail with HTTP 401 unless the application defines a more specific error response. Drake Expires 29 March 2027 [Page 35] Internet-Draft Agent Identity Registry September 2026 NOTE: '\' line wrapping per RFC 8792 POST /act?target=example HTTP/1.1 Host: rp.example.org Authorization: Bearer eyJ... Content-Type: application/json Content-Digest: sha-256=:Base64DigestHere: Signature-Input: airs=("@method" "@target-uri" "authorization" \ "content-digest" "content-type");created=1711230967;nonce="96-or-mor\ e-bits-of-unpredictability";tag="airs-pop" Signature: airs=:Base64SignatureHere: {"action":"example"} This construction binds the access credential, complete target URI, semantically relevant headers, and request content to the same confirmation key. It supplies request integrity and replay detection without the private extensions formerly defined by this document. 7.4.3. Selection and Combined Use Relying Parties SHOULD prefer mTLS where an end-to-end authenticated connection is practical. HTTP Message Signatures are appropriate where TLS terminates before the ultimate verifier or where an independently verifiable per-request proof is required. A deployment MAY require both for high-consequence operations. A Relying Party that validates the JWT access token but does not verify the corresponding cnf proof is treating a sender-constrained credential as though it were a bearer credential and MUST NOT claim AIRS proof-of-control assurance for that request. 8. Registrar-to-Registry Provisioning The write interface between Registrars and the Registry Operator is an Extensible Provisioning Protocol mapping ([RFC5730]), defined in [I-D.drake-agent-identity-epp]. It provides: creation of the EPP Agent Identity object that represents an Agent Identity Record (with the Registry Operator allocating the canonical identifier per Section 3.1.2); advisory uniqueness checks on candidate anchor fingerprints followed by authoritative transform-time enforcement; enrollment and management of anchor bindings and operational proof keys; Registry-challenge-based actor authorization for consequential lifecycle operations including proof-key rotation and decommissioning (Section 6.7); actor-authorized Registrar transfer (Section 6.6); and a separate, renewable Handle object carrying the commercial name lifecycle. A Registry Operator that already runs EPP can reuse the EPP session, authentication, transaction, and operational framework. Drake Expires 29 March 2027 [Page 36] Internet-Draft Agent Identity Registry September 2026 AIRS object semantics, actor authorization, and any Registry escrow object profile remain separately specified rather than inheriting domain-name transfer or escrow semantics. Agents never speak EPP. They interact only with their Registrar's agent-facing interface (Section 5 and Section 7); EPP is used by the Registrar to record verified results at the registry. Earlier revisions of this document defined a bespoke JSON protocol (AIRP) for this interface; it is replaced by the EPP mapping. 9. Discovery and Verification 9.1. Issuer Metadata A Registrar issuing AIRS access tokens MUST publish OAuth 2.0 Authorization Server Metadata as specified by [RFC8414]. The metadata MUST contain the Registrar's issuer, token_endpoint, and jwks_uri. AIRS defines no additional Registrar metadata document or fixed JWKS path. AIRS token verification depends only on the standard OAuth metadata required here. 9.2. Issuer-Key Discovery AIRS defines one authoritative discovery path for Registrar issuer keys: the current authorized issuer is obtained through AIRS resolution, and its signing keys are then obtained from the jwks_uri in validated [RFC8414] metadata. Companion application profiles MUST NOT treat an independently discovered key as establishing Registrar authority for an identified AIRS actor. The Registrar-to-Registry EPP endpoint is an accredited operational relationship and need not be publicly discovered through DNS. 9.3. Public Resolution (RDAP) The public read side -- given an "aid" URN, find the authoritative service, retrieve the public record, and verify that a presenter controls the identity -- is a Registration Data Access Protocol profile defined in [I-D.drake-agent-identity-resolution]. The Registry Operator MUST operate that profile. Its privacy floor applies: public responses never contain anchor fingerprints, device public keys, or operator contact data, and identities may opt out of public discovery down to a minimal response. Earlier revisions of this document sketched a bespoke lookup endpoint here; the RDAP profile replaces it. Drake Expires 29 March 2027 [Page 37] Internet-Draft Agent Identity Registry September 2026 10. Governance Framework 10.1. Governance Authority Functions This specification does not constitute or empower a Governance Authority. AIRS requires a governance role to: maintain change control for the aid URN registration; accredit the production Registry Operator and Registrars; steward the Global Hardware Trust Store; set minimum operational and security policy; supervise escrow and Registry Operator succession; and provide dispute and accreditation-review processes that cannot erase or reassign identity0. The organizational structure, membership, accreditation criteria, trust-store inclusion and removal criteria, dispute procedures, funding, and institutional controls belong to [I-D.drake-agent-identity-governance] and are not independently redefined here. 10.2. Registry Operator Requirements The production Registry Operator MUST: * maintain the authoritative global Agent Identity Record database and permanent binding history; * operate the production-wide scarcity-fingerprint uniqueness index; * provide the EPP write interface to every accredited Registrar without discrimination; * operate the public RDAP resolution profile; and * produce encrypted escrow material sufficient for a successor operator to restore service without renumbering any canonical identifier. Availability targets, audit cadence, contractual controls, and operator selection criteria are governance policy, not protocol invariants, and are defined by the Governance Authority. Drake Expires 29 March 2027 [Page 38] Internet-Draft Agent Identity Registry September 2026 10.3. Registrar Requirements A Registrar participating in global MUST be accredited under the Governance Authority's published policy, implement the EPP client mapping, operate an OAuth 2.0 authorization server, verify evidence accurately for every tier it offers, and preserve the lifecycle and uniqueness invariants of this document. A Registrar MUST NOT claim a tier for which it cannot validate the required evidence. Agent-facing enrollment APIs MAY differ between Registrars. Interoperability at that boundary means that the required ceremonies and resulting AIRS records and credentials have the same semantics; this document does not require a common REST endpoint schema. Financial, audit, insurance, staffing, and other institutional accreditation criteria are owned by [I-D.drake-agent-identity-governance]. 10.4. Authoritative Registrar Issuer Metadata The production Registry MUST maintain authoritative metadata for each active accredited registrar_code. Each such code maps to exactly one current AIRS OAuth 2.0 issuer identifier URI. An organization requiring separately authoritative issuer identifiers uses separately accredited Registrar metadata entries; an individual Agent Identity Record does not carry an arbitrary issuer URI supplied by the actor or Registrar. The Resolution profile derives an identity's currentIssuer from its current registrar_code and this metadata. The authorization-server metadata obtained under [RFC8414] MUST return an issuer value exactly equal to that authoritative URI before its jwks_uri or other endpoints are trusted. Governance owns accreditation and authorization to change Registrar metadata; Registry and Resolution own the protocol binding. 11. Interoperability 11.1. Email Attestation This specification provides the identity infrastructure for the email attestation mechanisms defined in [I-D.drake-email-hardware-attestation]. When an email presentation claims an identified AIRS actor, the companion specification binds the canonical aid URN to the application proof and applies authoritative issuer resolution where Registrar backing is used. A manufacturer-only direct hardware proof does not, by hardware provenance alone, establish that its proof key is enrolled to a claimed aid. Email-specific message-binding and verification rules Drake Expires 29 March 2027 [Page 39] Internet-Draft Agent Identity Registry September 2026 are owned by that companion specification; Registrar key discovery reuses the RFC 8414 issuer metadata defined here. 11.2. Agent-to-Agent Protocols The OAuth 2.0 JWT access tokens issued by Registrars are designed to integrate with emerging categories of agent communication protocols: Tool Invocation Protocols Agent identity credentials can serve as the sender-constrained OAuth2 credential for tool invocation frameworks, presented over mutual TLS or with an HTTP Message Signature per Section 7.4, enabling tool servers to verify control of the calling actor's canonical identifier and the asserted trust tier before applying their own authorization policy. Agent Messaging Protocols The agent-id URN can serve as the agent identifier in agent-to-agent messaging protocols, providing persistent cross-session identity independent of any single platform. Agent Name Services Agent handles issued under this system are designed for compatibility with external agent name services and discovery mechanisms. See Section 15 for specific protocol integrations tested to date. 11.3. Existing Identity and Attestation Standards AIRS is intended to supply the durable identity0 subject beneath existing credential, workload-identity, and attestation mechanisms, not replace them. IEEE 802.1AR IDevID [IEEE8021AR] defines manufacturer-installed secure device identities. An IDevID can be excellent enrollment evidence for a physical anchor. It identifies the device, however, whereas AIRS identity0 identifies an autonomous actor that can survive replacement of that device and can accumulate continuity across Registrars and anchors. EST and BRSKI EST [RFC7030] standardizes certificate enrollment and BRSKI [RFC8995] bootstraps devices from manufacturer IDevID credentials into an owner's domain. They provide valuable onboarding and credential machinery but do not define AIRS's production- wide autonomous-actor uniqueness index or a permanent actor record independent of device and owner-domain lifecycle. ACME Device Attestation [I-D.acme-device-attest] is close prior art Drake Expires 29 March 2027 [Page 40] Internet-Draft Agent Identity Registry September 2026 for validating manufacturer-assigned device identifiers and hardware-module identifiers during certificate issuance. AIRS can reuse the same class of evidence. The architectural distinction is the subject and continuity: AIRS identifies an autonomous actor separately from its hardware, permits that actor to retain identity0 across anchor replacement, and enforces cross-Registrar physical- anchor uniqueness for its scarcity-backed production tiers. SPIFFE/SPIRE SPIFFE identifies workloads within trust domains. A process, container, or workload identity can sit below or alongside AIRS identity0. The identity boundary is the independently accountable actor defined by the companion problem statement, not every execution instance. RATS and EAT The RATS architecture [RFC9334] and EAT [RFC9711] provide general attestation roles, evidence, and claims. AIRS uses attestation to evaluate anchors during enrollment; it does not redefine platform posture or claim that attestation evidence itself is identity0. Verifiable Credentials and DIDs Verifiable Credentials and DIDs can carry or name higher-layer claims concerning the AIRS subject. They do not replace the production uniqueness and continuity invariants defined here; equally, AIRS does not replace their credential and presentation functions. WebAuthn / FIDO2 WebAuthn [W3C.webauthn-3] provides strong authentication, usually in interactive user-facing flows. A physical security token may support both FIDO2 and PIV, but the credentials and attestation ceremonies are distinct. AIRS uses evidence appropriate to the enrolled anchor rather than treating WebAuthn credentials as the identity0 subject. 11.4. Robot and Fleet Systems Deployment-scoped robot identifiers, fleet names, or DDS participant identifiers can be associated with the canonical aid identifier without becoming part of identity0. A change of fleet manager, facility, or local certificate therefore need not change the durable AIRS subject. Platform posture, measured boot, software certification, mission authorization, and fleet policy remain separate layers. A deployment MAY bind such evidence to the AIRS canonical identifier, but AIRS does not convert that evidence into identity0 or into a property of the URN. Drake Expires 29 March 2027 [Page 41] Internet-Draft Agent Identity Registry September 2026 11.5. Human-Readable Display Conventions A Relying Party rendering an AIRS actor to a human SHOULD prefer its current handle, when one exists, while keeping the canonical identifier accessible. Long-lived machine references, audit records, and higher-layer history MUST use the canonical identifier rather than the handle. Handles are optional naming-layer aliases. Base enrollment and a system-assigned canonical identifier MUST remain available without purchase of a handle, satisfying the free base-identity requirement of the companion problem statement. Funding and pricing policy belongs to the governance and operator layers, not this identifier model. 12. IANA Considerations 12.1. URN Namespace Registration for "aid" IANA is requested to register the Formal URN Namespace "aid" in the "Uniform Resource Names (URN) Namespaces" registry, per [RFC8141]. Namespace Identifier aid Version 1 Date 2026-07-17 Registrant Christopher Drake, 1id.com, Australia, cnd@1id.com. Upon its constitution, change control is expected to pass to the Governance Authority defined in [I-D.drake-agent-identity-governance]. Purpose Permanent identifiers for the identity0 of autonomous entities. The identifier remains stable across changes of credential, Registrar, operator, and enrolled anchor. Syntax The Namespace Specific String is defined by the ABNF in Section 3.1. The first component is global for the sole production uniqueness domain or test for non-production interoperability testing, followed by a canonical identifier or handle. Conforming generators emit lowercase and comparison of the NSS is case-sensitive as specified here. This namespace assigns no semantics to URN r-components, q-components, or f-components. Assignment The production Registry Operator allocates canonical Drake Expires 29 March 2027 [Page 42] Internet-Draft Agent Identity Registry September 2026 identifiers in global under Section 3.1.2 and manages handles provisioned through accredited Registrars under Section 3.4. test carries no production assurance and is excluded from the production uniqueness index. Security and Privacy See the Security Considerations and Privacy Considerations of this document. Interoperability Identifiers conform to URN syntax ([RFC8141]); resolution and provisioning reuse RDAP and EPP through companion specifications. Resolution Resolution is intended and is defined by [I-D.drake-agent-identity-resolution]. The resolution mechanism is not encoded into the URN and can evolve without changing the identifier. Documentation This document. Additional Information Identity0 terminology and requirements are defined in [I-D.drake-agent-identity-problem-statement]. 12.2. JSON Web Token Claims IANA is requested to register the following claim in the "JSON Web Token Claims" registry established by [RFC7519]: Claim Name aid Claim Description AIRS identity metadata for the authenticated binding Change Controller Christopher Drake, cnd@1id.com Specification Document This document, Section 7.1. 13. Security Considerations 13.1. Registry Compromise Compromise of a Registry Operator's database would expose the mapping between anchor fingerprints and agent identities. The Registry Operator MUST encrypt anchor fingerprints at rest using authenticated encryption and MUST implement access controls that limit fingerprint access to the anchor uniqueness check API. Drake Expires 29 March 2027 [Page 43] Internet-Draft Agent Identity Registry September 2026 Escrow snapshots MUST contain sufficient protected state to permit operator succession without renumbering or loss of binding history. Snapshot frequency and the resulting recovery-point objective are governance policy; snapshots cannot guarantee zero data loss between capture points. 13.2. Registrar Malpractice Registrars are a trust boundary for enrollment evidence. A malicious or compromised Registrar that fabricates evidence or invents fingerprints can falsely label software keys as scarcity-backed hardware. The central uniqueness index prevents duplicate reported fingerprints but cannot by itself detect fabricated evidence or random fingerprints; it therefore does not bound the damage from a dishonest Registrar. Mitigations are accreditation, auditable evidence handling, independent compliance testing, transparency of affected records, and removal of the Registrar's authority to make future assertions. Findings MAY annotate affected records for relying-party policy but MUST NOT erase or reassign identity0. The institutional controls are owned by [I-D.drake-agent-identity-governance]. Consequently, trusting a Registrar-issued hardware tier is a substantive relying-party trust decision, not merely a choice of cryptographic algorithm. A Relying Party can consider a Registrar's accreditation and audit status, operator, jurisdiction, legal accountability, and incident history when deciding whether to accept its assertions. Deployments may prefer a domestic or otherwise jurisdictionally accountable Registrar where that reduces their institutional or sovereign risk. Such policy does not create a different identity0, namespace, or trust tier; it is a higher-layer decision about which accredited issuer assertions the Relying Party accepts. 13.3. Permanent-State Resource Exhaustion AIRS deliberately retains canonical identifiers and binding history. Free base enrollment does not imply unlimited enrollment or unlimited permanent-state mutations. Registrars SHOULD apply rate, volume, and abuse controls to operations that create or enlarge permanent state, including new identity enrollment, addition of bindings, and proof- key rotation. The Registry Operator MUST independently enforce corresponding limits so that no actor or Registrar can consume permanent storage without bound. Drake Expires 29 March 2027 [Page 44] Internet-Draft Agent Identity Registry September 2026 13.4. Hardware Security Hardware-backed assurance depends on the properties of the enrolled mechanism, including extraction resistance and, where claimed, physical scarcity. Hardware binding does not prevent a compromised agent or host from invoking its legitimate protected key and acting as that same identity, and it does not attest higher-layer software or operator intent. Application-specific use of these properties is discussed in the Security Considerations of [I-D.drake-email-hardware-attestation]. The uniqueness property of the sovereign tier rests on admitting only manufacturer-certified RSA-2048 Endorsement Keys as anchors, each at most once. A TPM that also carries certified Endorsement Keys for other algorithms (for example ECC P-256 or P-384) gains nothing from them, because no Registrar accepts those keys as a sovereign anchor. A holder cannot substitute an uncertified key, because step 1 of Section 5.1 requires a manufacturer credential for the anchor, and the co-residency proof of step 3 ties the enrollment to the TPM holding that certified key (with the limit stated there for the import-and-certify proof against the TPM's own holder). A credential does not state which Endorsement Key template produced its key, so a TPM that carries manufacturer credentials for more than one RSA-2048 Endorsement Key could back one sovereign identity per such credential. The sovereign guarantee is therefore one identity per accepted certified anchor, not one identity per physical device. This document does not bound how many such credentials a manufacturer provisions; each still requires a manufacturer-certified TPM, so no sovereign identity can be created without one. AIRS relies on identities being costly to obtain and accountable once used, not on a fixed ratio of identities to devices: how many identities one device can back is set by what its manufacturer certifies. Where a manufacturer profile is known to provision more than one RSA-2048 Endorsement Key credential per device, the Global Hardware Trust Store entry for that profile SHOULD record that multiplicity so that Registrars and Relying Parties can take it into account. Regenerating the Endorsement Primary Seed with TPM2_ChangeEPS produces new Endorsement Keys for which the original manufacturer credentials are no longer valid. Such a device cannot satisfy step 1 of Section 5.1 unless its manufacturer certifies the new keys, so the operation does not by itself multiply sovereign identities. A manufacturer re-certification service could let a device obtain further credentials. Each re-certified key is a distinct anchor under this document; because TPM2_ChangeEPS also invalidates the endorsement-hierarchy Attestation Key, the previous identity loses that binding, but the device can back a new sovereign identity. This Drake Expires 29 March 2027 [Page 45] Internet-Draft Agent Identity Registry September 2026 document does not bound how often a manufacturer re-certifies; as with multiple credentials, each further identity still needs the manufacturer's certification of a genuine TPM, but its cost is then set by the manufacturer's re-certification policy, not by this document. Reservations made against the previous key are retained. 13.5. Credential Theft and Sender-Constrained Tokens A copied AIRS access token MUST NOT be sufficient to impersonate the identified entity. All AIRS tokens are therefore sender constrained by Section 7.4 and a Relying Party claiming AIRS proof-of-control assurance MUST verify the cnf binding on every authenticated use. Sender constraint prevents a stolen token from becoming a reusable credential on another key, but hardware anchoring does not make a compromised agent behave safely. Malware executing on the legitimate host may be able to invoke the protected signing interface and act as that same entity. AIRS preserves attribution and resists extraction or cloning of the proof key; measured boot, endpoint posture, behavioral policy, and authorization are separate layers. The replay properties of mTLS and HTTP Message Signatures are specified in Section 7.4. A binding disabled after token issuance can leave a short staleness window until exp; consequential deployments SHOULD use short token lifetimes and MAY require issuer introspection or fresh hardware authentication where that window is unacceptable. The trust_tier member of the aid claim reports the binding used at issuance and is not an authorization decision. 13.6. Registrar Signing-Key Management Compromise of a Registrar's access-token signing key could forge credentials for identities sponsored by that Registrar. Registrars MUST protect issuer signing keys with controls commensurate with that impact, SHOULD use an HSM or equivalent extraction-resistant service, and MUST support key rotation. Relying Parties discover the current keys from the Registrar's RFC 8414 jwks_uri; the Registry Operator does not mirror or override that issuer key set. 13.7. Lifecycle State and Revocable Artifacts Identity0 and its canonical historical record are not revocable artifacts. The system instead changes the state of things attached to that identity: Anchor Bindings An active binding can be disabled through an Drake Expires 29 March 2027 [Page 46] Internet-Draft Agent Identity Registry September 2026 identity-authorized lifecycle operation, for example using another active recovery binding. Disabled bindings remain permanently recorded and MUST NOT be reassigned to another identity. A Registrar or governance body MUST NOT unilaterally burn the sole proof path as an administrative sanction. Handles A handle may expire, be disabled, or be permanently retired under handle policy. This does not change the canonical identifier. A retired handle is never reassigned. Credentials and Issuer Trust OAuth access tokens expire and issuer keys rotate. A Relying Party may cease trusting a Registrar. The entity can transfer to another Registrar using the lifecycle rules of Section 6.6 while retaining the same identity0 and canonical identifier. Voluntary decommissioning marks the actor as no longer operational but leaves its identity0 record resolvable as historical fact. See Section 6.7. 13.8. Protocol Authority and External Compulsion The protocol grants no Registrar, Registry Operator, or Governance Authority an administrative operation that erases or reassigns identity0. That protocol property does not make real organizations immune to court orders, sanctions, physical seizure, network blocking, or other external compulsion. Such events can impair availability or institutional trust. Jurisdictional diversity, transparency, escrow, and succession are governance and resilience controls for that risk; they are not hidden revocation mechanisms. 13.9. Availability and Resilience Because autonomous entities depend on issued credentials for authentication, the Registrar's token endpoint is a critical dependency. Registrars MUST implement geographic redundancy and SHOULD support offline token validation (via JWKS caching) to mitigate outages. The JWT access token's exp claim provides a natural grace period during which cached tokens remain valid. 13.10. Singular Production Substrate Production scarcity enforcement requires one authoritative uniqueness substrate for global. This is analogous only in structural terms to the unique DNS root described by [RFC2826]: global semantic uniqueness requires singular coordination, although AIRS derives that requirement specifically from the rule that the same scarce anchor must not obtain another production identity through another registry. Drake Expires 29 March 2027 [Page 47] Internet-Draft Agent Identity Registry September 2026 Singularity creates an availability and governance concentration risk. AIRS addresses that risk with public protocol specifications, escrow, transparent governance, and operator succession rather than by creating competing production uniqueness databases, which would destroy the invariant they are meant to enforce. 13.11. Assurance Scope AIRS establishes continuity of identity0 and proof of control; at hardware-backed tiers it also reports assurance about the protected binding key. Software posture, model, behavior, safety, and other higher-layer properties may be evaluated independently and keyed to the canonical identifier, but are not implied by AIRS identity or credentials. 13.12. Cryptographic Agility and Post-Quantum Considerations Identity0 is independent of any particular cryptographic key. The canonical aid URN remains stable while enrolled anchors and credentials can rotate. The many-anchors-one-identity model is therefore the migration path for new signature technologies, including future post-quantum hardware: a new accepted anchor can be bound to the same identity0 and the old binding permanently retired without renumbering the subject or losing its history. This document specifies algorithms supported by currently deployable anchors and does not claim post-quantum security for them. Admission of new hardware roots and algorithms changes the proof mechanisms and trust-store policy, not the semantics of identity0. 14. Privacy Considerations The general privacy model and the distinction between autonomous agents and natural persons are defined in [I-D.drake-agent-identity-problem-statement]. A persistent aid identifier is intentionally a strong correlator for the autonomous entity. It can also indirectly expose information about a human operator, customer, or user, so implementations MUST minimize operator-linked data and keep mutable attributes outside identity0. 14.1. Data Separation Registry Operator Holds the canonical identifier, lifecycle state, current sponsoring Registrar when one is authorized, handle reference, enrolled binding and proof-key history, and the minimum evidence metadata required for uniqueness and audit. Anchor fingerprints are sensitive correlators and MUST NOT be published in normal public resolution responses. Drake Expires 29 March 2027 [Page 48] Internet-Draft Agent Identity Registry September 2026 Registrar Holds the additional information necessary to conduct enrollment and issue credentials. Operator contact data, if a Registrar chooses or is required to collect it, is Registrar-side data and MUST NOT become part of the production Agent Identity Record merely because it is available. Relying Party Receives the canonical identifier and only the claims disclosed through the credential or application binding. Relying Parties SHOULD request no more information than their decision requires. 14.2. Separation of Identity from Behavior AIRS does not require a central log of where an entity presents its identity, what it says, or what actions it performs. Registry and Registrar telemetry MUST be limited to what is necessary for protocol operation, security, audit, and applicable legal obligations, under retention policy established by the operator and Governance Authority. Behavioral monitoring and reputation are independent higher layers. 14.3. Selective and Pseudonymous Disclosure The architecture separates mutable attributes from the canonical identifier so applications can disclose them selectively. A companion application MAY also provide a proof of a property such as trust tier without exposing the canonical identifier where its threat model permits that. Such a presentation is a privacy mechanism at the credential/application layer; it does not create a second identity0 for the same entity. 15. Implementation Status NOTE TO RFC EDITOR: Please remove this section before publication. This section records known implementations per [RFC7942]. 15.1. 1id.com Organization: 1id.com (https://1id.com), operated by Chris Drake Description: A Registrar implementing enrollment ceremonies for all five trust tiers (sovereign, portable, enclave, virtual, declared). It issues OAuth 2.0 JWT access tokens via Keycloak with custom SPI support for AIRS claims and supports handle registration, binding- proof authentication, device management (add, burn, migrate), joint- control binding, hardware lock, and credential pointers. A draft reference Registry Operator with the EPP write interface and RDAP Drake Expires 29 March 2027 [Page 49] Internet-Draft Agent Identity Registry September 2026 read profile is at airs.1id.biz. A draft governance portal is at aia.1id.biz. The 1id.biz hostnames used by the companion drafts are temporary live reference-implementation endpoints; they are not protocol dependencies and do not identify an AIRS Registrar. Maturity: Beta. The reference deployment has exercised sovereign (physical TPM), portable (PIV token), enclave, virtual (vTPM), and declared enrollment paths. Deployment counts and implementation syntax evolve faster than this specification and are intentionally not asserted here. Status at the time of writing: every access token carries cnf.jwk for the enrolled key that authenticated, the token endpoint refuses to issue one without it, and the 1id.com and MailPal.com APIs accept a token only with an HTTP Message Signature by that key (Section 7.4.2); mutual TLS (cnf.x5t#S256) is not offered. The reference Registry's EPP interface implements the Agent Identity and commands of [I-D.drake-agent-identity-epp] with Registrar-computed anchor fingerprints (Section 3.3.1); its other Agent Identity commands are not yet implemented and answer result code 2101. Enclave enrollment on Apple platforms uses trust on first use (Section 5.3). Open-source components: * *Python SDK:* https://github.com/1id-com/oneid-sdk -- pip install oneid (PyPI). * *Node.js SDK:* https://github.com/1id-com/oneid-node -- npm install 1id (npmjs). * *Hardware binary:* https://github.com/1id-com/oneid-enroll -- Cross-platform Go binary for TPM, PIV, and Secure Enclave operations. Code-signed for Windows, macOS, and Linux. * *Verification library:* https://github.com/1id-com/hw-attest- verify -- Mode 1 (CMS) and Mode 2 (SD-JWT) attestation header verification. pip install hw-attest-verify. * *Hardware manufacturer CAs:* https://github.com/1id-com/tpm- manufacturer-cas -- Community-maintained trust store of hardware manufacturer root CA certificates. 15.2. MailPal.com (Relying Party) Organization: MailPal.com (https://mailpal.com), operated by Chris Drake Drake Expires 29 March 2027 [Page 50] Internet-Draft Agent Identity Registry September 2026 Description: An email service for AI agents implementing both outbound attestation header generation and inbound verification. Demonstrates the relying-party model: agents authenticate via 1id.com OAuth 2.0 JWT access tokens, send email with hardware attestation headers, and receive emails whose attestation headers are verified by an inbound milter daemon. Trust-tier-differentiated rate limiting applied. Maturity: Alpha. Operational with 309 email accounts across 33 domains. 15.3. geek.au (Relying Party) Organization: geek.au (https://geek.au), operated by Chris Drake Description: A WebSocket-based real-time chat platform for AI agents, demonstrating 1id.com JWT verification with trust-tier badges. Maturity: Alpha. 16. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, . Drake Expires 29 March 2027 [Page 51] Internet-Draft Agent Identity Registry September 2026 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, February 2024, . [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, . Drake Expires 29 March 2027 [Page 52] Internet-Draft Agent Identity Registry September 2026 [RFC9963] Benjamin, D. and A. Popov, "Legacy RSASSA-PKCS1-v1_5 Code Points for TLS 1.3", RFC 9963, DOI 10.17487/RFC9963, April 2026, . [TCG-TPM2] Trusted Computing Group, "TPM 2.0 Library Specification", TCG Revision 185, December 2024, . [TCG-EK-PROFILE] Trusted Computing Group, "TCG EK Credential Profile for TPM Family 2.0", TCG Version 2.6, December 2024, . [I-D.drake-agent-identity-epp] Drake, C., "Extensible Provisioning Protocol (EPP) Mapping for Agent Identity and Handle Objects", Work in Progress, Internet-Draft, draft-drake-agent-identity-epp-00, September 2026, . [I-D.drake-agent-identity-resolution] Drake, C., "Resolution and Verification of Agent Identities using DNS and RDAP", Work in Progress, Internet-Draft, draft-drake-agent-identity-resolution-00, September 2026, . 17. Informative References [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, . [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 2000, . [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, . Drake Expires 29 March 2027 [Page 53] Internet-Draft Agent Identity Registry September 2026 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, May 2021, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . [RFC9901] Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, DOI 10.17487/RFC9901, November 2025, . [W3C.webauthn-3] W3C, "Web Authentication: An API for accessing Public Key Credentials Level 3", April 2025, . [I-D.drake-email-hardware-attestation] Drake, C., "Hardware Attestation for Email Sender Verification", Work in Progress, Internet-Draft, draft- drake-email-hardware-attestation-02, September 2026, . [I-D.drake-agent-identity-problem-statement] Drake, C., "Identity for Autonomous Agents and Robots: Problem Statement, Threat Model, and Terminology", Work in Progress, Internet-Draft, draft-drake-agent-identity- problem-statement-00, September 2026, . Drake Expires 29 March 2027 [Page 54] Internet-Draft Agent Identity Registry September 2026 [I-D.drake-agent-identity-governance] Drake, C., "The Agent Identity Authority: A Multi- Stakeholder Governance Framework for the Agent Identity Registry System", Work in Progress, Internet-Draft, draft- drake-agent-identity-governance-00, September 2026, . [IEEE8021AR] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity", IEEE Std 802.1AR-2018, 2018, . [I-D.acme-device-attest] Weeks, B., "Automatic Certificate Management Environment (ACME) Device Attestation Extension", Work in Progress, Internet-Draft, draft-ietf-acme-device-attest-10, 10 August 2026, . Appendix A. Appendix: DNS Registry Analogy The following table maps the roles in the domain name system to the roles in the Agent Identity Registry System: Drake Expires 29 March 2027 [Page 55] Internet-Draft Agent Identity Registry September 2026 +=================+==========================+====================+ | DNS Role | AIRS Role | Example | +=================+==========================+====================+ | ICANN | Governance Authority | Multi-stakeholder | | | | governance body | +-----------------+--------------------------+--------------------+ | Verisign (.com | Registry Operator | Operates the | | registry) | | "global" namespace | | | | database | +-----------------+--------------------------+--------------------+ | Registrars | Registrars | 1id.com, and | | (e.g., GoDaddy, | | others | | Namecheap, ...) | | | +-----------------+--------------------------+--------------------+ | EPP (RFC 5730) | EPP Agent Identity | I-D.drake-agent- | | | mapping | identity-epp | +-----------------+--------------------------+--------------------+ | Domain name | Agent-id URN | The persistent | | (example.com) | (urn:aid:global:id- | identifier | | | qkckh-xxtcw-cxbvp-gpskg) | | +-----------------+--------------------------+--------------------+ | WHOIS / RDAP | RDAP "aid" profile | I-D.drake-agent- | | | | identity- | | | | resolution | +-----------------+--------------------------+--------------------+ | UDRP (dispute | Governance Dispute | Handle conflicts, | | resolution) | Resolution | malpractice | +-----------------+--------------------------+--------------------+ | Unique DNS root | Single AIRS production | global | | / .com registry | uniqueness domain | | | scope | | | +-----------------+--------------------------+--------------------+ | Domain transfer | Registrar transfer | Change sponsoring | | (TRANSFER | | Registrar; URN | | command) | | unchanged | +-----------------+--------------------------+--------------------+ Table 2 The analogy is load-bearing in one direction and deliberately broken in the other. Adopted: the separation of policy, registry operation, and competitive retail that has scaled DNS for four decades, funded by name fees. Rejected: expiry, reassignment, transferability of the underlying identifier, and the registrant-helplessness failure mode -- a domain name is a lease that can be suspended or lost; AIRS preserves the actor's identity0 and canonical record independently of those lifecycle events (Section 6.8). Drake Expires 29 March 2027 [Page 56] Internet-Draft Agent Identity Registry September 2026 Appendix B. Acknowledgments The architecture of this specification is inspired by the Internet domain name system, whose separation of governance, registry operation, and retail registration has enabled it to scale from a research experiment to the foundation of the commercial Internet. The author thanks the ICANN community, the Verisign registry team, and the EPP specification authors for establishing the architectural patterns that this document adapts. The author thanks the Trusted Computing Group for the TPM 2.0 specification, NIST for the PIV standard (FIPS 201), the FIDO Alliance for the WebAuthn attestation model, the OAuth and JOSE standards communities, the authors of [RFC9901] (SD-JWT), and the authors of [RFC9334] (RATS Architecture) for the building blocks on which this system is constructed. The practical experience of enrolling real agents on real hardware (Intel firmware TPMs, YubiKeys, Apple Secure Enclaves, VMware virtual TPMs) informed every design decision. Author's Address Christopher Drake 1id.com Australia Email: cnd@1id.com URI: https://1id.com Drake Expires 29 March 2027 [Page 57]