Agent Identity Registry System: A Federated Architecture for Durable Identity of Autonomous Entities

Agent Identity Registry System: A Federated Architecture for Durable Identity of Autonomous Entities 1id.com

Australia cnd@1id.com https://1id.com

Security agent identity AI agents autonomous entities hardware attestation TPM PIV registry registrar federation Sybil resistance OAuth2 URN robot identity 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 . The canonical identifier is a URN in the "aid" namespace (). 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 for authenticated use.

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 (). 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.
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.

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 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 (, ), 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 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 .
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-authorized Registrar-transfer paths are the architecture's availability defenses. A generic direct-RP proof protocol is not defined by this document. See .
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 (). 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.

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 when, and only when, they appear in all capitals, as shown here.

Terminology "identity0", "identifier", "credential", "hardware anchor", and the other foundational terms are used as defined in . This section defines only terms specific to AIRS. Long lines in some examples are wrapped using the single-backslash strategy of .

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, trust- store stewardship, and succession for the production AIRS infrastructure. Its institutional constitution is defined in .
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 .
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 .
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 . 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 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.

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.

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 ; institutional rules are defined in .
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.

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. Until the Governance Authority is constituted (), 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.

Identifier and Record Model

URN Format AIRS canonical identifiers and handles use the URN format defined in with the "aid" (Agent Identity) namespace identifier, registered by this document (). 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 . (The "urn:" scheme and "aid" NID remain case-insensitive as RFC 8141 requires.)

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: 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 . 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 and may be retired via the dispute process defined in . 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.

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.

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 (). Lower tiers make no equivalent physical-scarcity claim. In every tier, identifiers that survive the filter remain deliberately devoid of vanity value.

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 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.

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 firmware TPM 2.0 with accepted manufacturer attestation	Strong extraction resistance and strongest AIRS scarcity claim: one accepted physical platform anchor per identity.
portable	PIV	Physical smart card or security token with accepted device attestation	Strong extraction resistance and strong physical scarcity: one accepted physical token per identity.
enclave	ENC	Hardware secure enclave with hardware-bound key	Extraction resistance where vendor attestation verifies enclave custody; otherwise only the enrollee's assertion of it. No generic one-physical-unit-per-identity claim.
virtual	VRT	Hypervisor or cloud-provided protected key or virtual TPM	Key isolation and creation cost depend on the infrastructure operator. No physical scarcity claim against that operator.
declared	SFT	Software-managed key	No hardware extraction resistance or hardware scarcity claim.

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 . 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.

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.
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 .

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.

Anchor Fingerprint The anchor fingerprint is the value the Registry indexes for the uniqueness rules of . Every Registrar MUST compute it identically. It is the SHA-256 digest of an anchor input, written as 64 lowercase hexadecimal characters. The anchor input depends on the tier:

sovereign: The DER-encoded SubjectPublicKeyInfo of the certified RSA-2048 Endorsement Key ().
portable: The UTF-8 string formed by "piv:", the manufacturer code 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 (). 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 ().

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 (); 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 , 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.

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 for a consolidated treatment.

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.

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.

Handle Disputes Handle disputes are resolved under the policy operated by the governance authority (). 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.

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.

Hardware Attestation

Supported Anchor Mechanisms AIRS defines five enrollment assurance classes. Their trust-tier definitions and coexistence rules are canonical in ; this section states the evidence expected during enrollment.

TPM 2.0 (Sovereign Tier): A discrete or firmware TPM per and the EK credential profile . The Registrar validates a device-stable Endorsement Key credential and proves that the operational Attestation Key is resident in the same TPM (). 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 (). Neither kind of evidence supports a generic physical-device uniqueness claim.
Virtual TPM or Protected Virtual Key (Virtual Tier): A vTPM or 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.

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 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 and , 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 .
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.

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 (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 . 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.

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 . Every enrollment MUST identify the requested tier, collect the evidence required by , prove possession of the enrolled binding key, derive the binding fingerprint, perform the uniqueness check required by , and provision the resulting record only after all checks succeed.

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:

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.
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.
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 , 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 () and accountability rest on, but it does not show a Relying Party that 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.
Derive the anchor fingerprint over the SubjectPublicKeyInfo of the Endorsement Key as defined in . The fingerprint MUST NOT be computed over the credential, because credentials for one key may be reissued.
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 .

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 . 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 () requires only signing.

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:

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.
Take the per-device serial number from the location the trust-store entry for that manufacturer defines (). 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.
Verify a fresh challenge signature from the attested operational key.
Derive the anchor fingerprint from the manufacturer code and serial number as defined in , and perform the uniqueness check of .

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.

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.

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.

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.

Identity Lifecycle

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.

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 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. 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 . 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 , and permanently disables the old binding in the same atomic operation (). 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 : 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 (). 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.

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 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. 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.

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 . For example, a surgical-robot authority might certify only hardware-locked identities, preventing migration to other hardware.

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:

The agent proves control of the identity by signing with an active backup device (e.g., a previously bound YubiKey).
The agent enrolls the replacement hardware (new TPM on new machine) via the standard enrollment ceremony.
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.
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.

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 , including the fresh Registry challenge of . 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.

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.

Survivability Guarantees AIRS separates permanence of the identity record from availability of particular operators. Implementations MUST preserve the following invariants:

A canonical Agent Identity Record, including a decommissioned record, remains queryable as historical fact and is never renumbered or reassigned.
Registrar failure does not erase the record and does not give the failed Registrar a veto over a correctly authorized transfer (). Suspension or de-accreditation removes issuer authority without assigning a successor; the actor chooses any later sponsoring Registrar.
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.
Resolution and Registrar-backed credential-verification behavior is defined by 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.

Authentication and Token Issuance

OAuth 2.0 JWT Access Tokens A Registrar acts as an OAuth 2.0 authorization server and issues JWT access tokens conforming to . For the client-credentials grant used by AIRS, permits sub to identify the client application; AIRS requires that value to be the autonomous actor's permanent canonical aid identifier. The sub claim MUST be the canonical-form URN. The token MUST contain the claims required by , 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 () where available to obtain audience-scoped access tokens. Every AIRS access token MUST be sender constrained with cnf per . A token intended for the HTTP Message Signatures profile of 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 . 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 . A Relying Party MUST validate the JWT access token as required by 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 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 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. 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 . 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.

Client Credentials Grant AIRS token issuance uses the OAuth 2.0 client_credentials grant ( 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. Before issuing a token, the Registrar MUST authenticate the actor using Binding-Proof Authentication () 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 .

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 .

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.

Mutual TLS Mutual TLS token binding follows over TLS 1.3 () 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 when both peers support them. 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.

HTTP Message Signatures Where end-to-end mTLS is unavailable or a relying party requires a request-level proof, AIRS profiles HTTP Message Signatures . 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 , 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. 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.

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.

Registrar-to-Registry Provisioning The write interface between Registrars and the Registry Operator is an Extensible Provisioning Protocol mapping (), defined in . It provides: creation of the EPP Agent Identity object that represents an Agent Identity Record (with the Registry Operator allocating the canonical identifier per ); 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 (); actor-authorized Registrar transfer (); 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. 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 ( and ); 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.

Discovery and Verification

Issuer Metadata A Registrar issuing AIRS access tokens MUST publish OAuth 2.0 Authorization Server Metadata as specified by . 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.

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 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.

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 . 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.

Governance Framework

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 and are not independently redefined here.

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.

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 .

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 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.

Interoperability

Email Attestation This specification provides the identity infrastructure for the email attestation mechanisms defined in . 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 are owned by that companion specification; Registrar key discovery reuses the RFC 8414 issuer metadata defined here.

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 , 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 for specific protocol integrations tested to date.

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: 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 standardizes certificate enrollment and BRSKI 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: is close prior art 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 and EAT 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 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.

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.

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.

IANA Considerations

URN Namespace Registration for "aid" IANA is requested to register the Formal URN Namespace "aid" in the "Uniform Resource Names (URN) Namespaces" registry, per .

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 .
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 . 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 identifiers in global under and manages handles provisioned through accredited Registrars under . 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 (); resolution and provisioning reuse RDAP and EPP through companion specifications.
Resolution: Resolution is intended and is defined by . 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 .

JSON Web Token Claims IANA is requested to register the following claim in the "JSON Web Token Claims" registry established by :

Claim Name: aid
Claim Description: AIRS identity metadata for the authenticated binding
Change Controller: Christopher Drake, cnd@1id.com
Specification Document: This document, .

Security Considerations

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. 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.

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 . 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.

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.

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 . 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 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 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 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.

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 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 . 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.

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.

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 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 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 .

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.

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.

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 : 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. 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.

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.

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.

Privacy Considerations The general privacy model and the distinction between autonomous agents and natural persons are defined in . 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.

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.
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.

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.

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.

Implementation Status NOTE TO RFC EDITOR: Please remove this section before publication. This section records known implementations per .

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 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 (); mutual TLS (cnf.x5t#S256) is not offered. The reference Registry's EPP interface implements the Agent Identity <create> and <check> commands of with Registrar-computed anchor fingerprints (); its other Agent Identity commands are not yet implemented and answer result code 2101. Enclave enrollment on Apple platforms uses trust on first use (). Open-source components:

Python SDK: -- pip install oneid (PyPI).
Node.js SDK: -- npm install 1id (npmjs).
Hardware binary: -- Cross-platform Go binary for TPM, PIV, and Secure Enclave operations. Code-signed for Windows, macOS, and Linux.
Verification library: -- Mode 1 (CMS) and Mode 2 (SD-JWT) attestation header verification. pip install hw-attest-verify.
Hardware manufacturer CAs: -- Community-maintained trust store of hardware manufacturer root CA certificates.

MailPal.com (Relying Party) Organization: MailPal.com (https://mailpal.com), operated by Chris Drake 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.

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.

Normative References The Transport Layer Security (TLS) Protocol Version 1.3 Independent TPM 2.0 Library Specification Trusted Computing Group TCG EK Credential Profile for TPM Family 2.0 Trusted Computing Group Extensible Provisioning Protocol (EPP) Mapping for Agent Identity and Handle Objects Resolution and Verification of Agent Identities using DNS and RDAP Informative References Web Authentication: An API for accessing Public Key Credentials Level 3 W3C Hardware Attestation for Email Sender Verification Identity for Autonomous Agents and Robots: Problem Statement, Threat Model, and Terminology The Agent Identity Authority: A Multi-Stakeholder Governance Framework for the Agent Identity Registry System IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity IEEE Automatic Certificate Management Environment (ACME) Device Attestation Extension

Appendix: DNS Registry Analogy The following table maps the roles in the domain name system to the roles in the Agent Identity Registry System:

DNS Role	AIRS Role	Example
ICANN	Governance Authority	Multi-stakeholder governance body
Verisign (.com registry)	Registry Operator	Operates the "global" namespace database
Registrars (e.g., GoDaddy, Namecheap, ...)	Registrars	1id.com, and others
EPP (RFC 5730)	EPP Agent Identity mapping	I-D.drake-agent-identity-epp
Domain name (example.com)	Agent-id URN (urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg)	The persistent identifier
WHOIS / RDAP	RDAP "aid" profile	I-D.drake-agent-identity-resolution
UDRP (dispute resolution)	Governance Dispute Resolution	Handle conflicts, malpractice
Unique DNS root / .com registry scope	Single AIRS production uniqueness domain	global
Domain transfer (TRANSFER command)	Registrar transfer	Change sponsoring Registrar; URN unchanged

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 ().

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 (SD-JWT), and the authors of (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.