| Internet-Draft | Agent Identity Registry | September 2026 |
| Drake | Expires 29 March 2027 | [Page] |
This document defines the Agent Identity Registry System (AIRS): a federated architecture that gives the durable identity0 of an autonomous entity a permanent canonical identifier, maintains an authoritative record about that identity, binds proof of control to enrolled anchors, and issues credentials that relying parties can verify. Identity0 and the distinction between an identity, its identifiers, its credentials, and its anchors are defined in [I-D.drake-agent-identity-problem-statement]. The canonical identifier is a URN in the "aid" namespace ([RFC8141]).¶
At the sovereign and portable assurance tiers, each independently accepted identity requires its own manufacturer-attested physical anchor, and each accepted anchor backs at most one identity. A device normally carries one accepted anchor, so identities at these tiers cost scarce physical units rather than software operations. Enclave and virtual tiers can provide useful hardware-backed key protection without making that physical-scarcity claim; a declared tier permits software-only participation. The architecture separates governance, authoritative registry operation, and competing Registrars, and uses standard OAuth 2.0 JWT access tokens conforming to [RFC9068] for authenticated use.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 29 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The companion problem statement defines identity0, its threat model, layered model, and the requirements for a durable autonomous-entity identity foundation. This document defines the AIRS registry architecture and mechanisms that implement that foundation.¶
AIRS keeps four concepts separate: the autonomous entity's
identity0; its permanent canonical aid identifier;
the authoritative registry record that preserves continuity
and anchor history; and the anchors and credentials used to
prove control. Hardware anchoring serves two distinct
purposes. Device-stable, physically scarce anchors can
constrain identity manufacture, while protected keys can
resist extraction and cloning. A mechanism can provide the
second property without providing the first, so assurance is
reported explicitly by trust tier rather than inferred from
the word "hardware".¶
The architecture borrows the domain name system's separation of governance, registry operation, and competitive registration. DNS names themselves are unsuitable as durable identity because they expire and may be reassigned (Section 3.1.3). This system separates:¶
This separation permits competition among Registrars while keeping the one production uniqueness index under explicit governance and succession controls.¶
global namespace is
required so a scarce anchor cannot obtain another
production identity through another registry. The
Registry Operator is therefore singular but not
unaccountable: it is replaceable from escrow under
governance authority oversight
(Section 6.6,
Section 6.8), so no single
participant's failure or malfeasance compromises the
ecosystem.¶
sub claim is the permanent canonical
aid identifier. Standard libraries verify token
syntax and signatures; the sender-constraint profile in
Section 7.4 verifies that the presenter
controls the key bound to the credential.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
"identity0", "identifier", "credential", "hardware anchor", and the other foundational terms are used as defined in [I-D.drake-agent-identity-problem-statement]. This section defines only terms specific to AIRS.¶
Long lines in some examples are wrapped using the single-backslash strategy of [RFC8792].¶
urn:aid: URN assigned by the Registry
Operator to denote one identity0. It is never reassigned.¶
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.¶
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.¶
urn:aid:. This
specification defines exactly two values:
global, the sole production uniqueness domain,
and test, a non-production value carrying no
assurance. See Section 2.2.¶
aid identifier or
credential and makes a decision concerning the identified
entity.¶
The Agent Identity Registry System (AIRS) is a three-tier architecture. The Registrar-to-Registry write interface is standardized by the EPP mapping and the public read interface by the RDAP profile. Agent-facing enrollment APIs are Registrar-specific; this document standardizes the security properties of their ceremonies rather than a wire format.¶
+-----------------------------------------------------------+
| Governance Authority |
| Policy, accreditation, hardware trust store, disputes |
+---------------------------+--------------------------------+
|
+-----------v------------+
| Registry Operator |
| (global namespace) |
| - Master database |
| - Anchor fingerprint |
| uniqueness index |
| - RDAP lookup (read) |
| - EPP interface (write)|
+--+-------+--------+----+
| | |
+--v--+ +--v--+ +---v--+
| Reg | | Reg | | Reg |
| A | | B | | C |
+--+--+ +--+--+ +--+---+
| | |
+--v--+ +--v--+ +--v--+
|Agent| |Agent| |Agent|
| 1 | | 2 | | 3 |
+-----+ +-----+ +-----+
¶
The architecture has three operational roles:¶
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.¶
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.¶
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
([I-D.drake-agent-identity-governance]),
global operates under an interim Registry
Operator that MUST publish open-source implementations,
escrow all registry data, accept Registrar onboarding
under published objective criteria, and commit publicly to
timely transfer of the registry role under the eventual
Authority's selection process.¶
AIRS canonical identifiers and handles use the URN format defined in [RFC8141] with the "aid" (Agent Identity) namespace identifier, registered by this document (Section 12.1).¶
aid-urn = "urn:aid:" namespace ":" agent-id
namespace = "global" / "test"
; global is the sole production value;
; test carries no production assurance
agent-id = canonical-id / handle-id
canonical-id = "id" 4("-" group)
; 20 consonants in four hyphen-separated
; groups of five, e.g. id-qkckh-xxtcw-cxbvp-gpskg
group = 5consonant
consonant = %x62-64 / %x66-68 / %x6A-6B / %x6D-6E /
%x70-74 / %x76-78 / %x7A
; b c d f g h j k m n p q r s t v w x z
handle-id = lc-alpha / (lc-alpha *61(let-dig-hyp) let-dig)
; one to 63 octets; handle-id MUST NOT
; begin with "id-"
; (see prose reservation below)
lc-alpha = %x61-7A ; a-z only
let-dig = lc-alpha / DIGIT
let-dig-hyp = lc-alpha / DIGIT / "-"
¶
The "aid" namespace-specific string is defined in lowercase only. Producers MUST emit lowercase; consumers MUST treat a URN containing uppercase characters in the namespace or agent-id as invalid rather than case-folding it. Equivalence within this namespace is therefore exact octet-by-octet comparison of the lowercase form, per the namespace-defined equivalence provision of [RFC8141]. (The "urn:" scheme and "aid" NID remain case-insensitive as RFC 8141 requires.)¶
Within each namespace, an agent has exactly one canonical identifier and at most one currently-active handle. Both are valid agent-id values and both form valid URNs:¶
urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg canonical, permanent urn:aid:global:crusty handle, may be retired¶
Both URN forms for the same agent resolve to the same
Agent Identity Record and use the same canonical value as
the JWT access-token sub. The canonical identifier is the
indelible reference; the handle is a human-friendly
alias.¶
The id- prefix is reserved exclusively for
canonical identifiers: Registrars and Registry
Operators MUST NOT accept any handle registration
beginning with the string id-. This ensures
canonical identifiers and handles are always
syntactically distinguishable.¶
Canonical identifiers are allocated only by the
Registry Operator, at enrollment, using the
generation procedure of
Section 3.1.2. The Registry
Operator MUST ensure uniqueness within global:
no two agents may share a canonical identifier, and
no canonical identifier may collide with any
active or retired handle. Canonical identifiers MUST NOT be
retired, reassigned, or transferred under any
circumstance.¶
Handles are assigned per Section 3.4
and may be retired via the dispute process defined in
Section 3.4.4. When a handle is
retired, its URN form ceases to resolve, but the
canonical identifier's URN form continues unchanged.
Handle retirement does not affect the agent's identity0,
JWT access-token sub value, accumulated reputation, or
any higher-layer claim keyed to the canonical
identifier.¶
Relying parties that store agent references for long-lived purposes (audit logs, reputation databases, compliance records) MUST store the canonical-form URN, not the handle-form URN. The canonical form is the only stable reference under all circumstances permitted by this specification.¶
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:¶
Except for the two identical-groups and single-group-palindrome tests, which operate on the five-character groups, the filter is evaluated on the 20-character sequence with the hyphens removed, so a pattern spanning a group boundary is still detected. The filter is part of the identifier-generation algorithm and applies only at mint time; identifiers already issued are never affected by later revisions of this specification. Rejection sampling changes only the set of permitted outputs; within that set, each surviving identifier remains equally likely.¶
The format itself is not a Sybil defense; it only removes economic value from the random draw. At the sovereign and portable tiers, each additional identity requires another independently accepted scarce physical anchor (Section 4.2). Lower tiers make no equivalent physical-scarcity claim. In every tier, identifiers that survive the filter remain deliberately devoid of vanity value.¶
An agent-id names an entity; it is not a network locator. The identifier has to persist unchanged for the life of the entity and beyond (for audit and reputation), independent of where, by whom, or over what protocol the corresponding record is served.¶
An "https" URL conflates the name with a specific host, provider, and path. When any of those change -- a provider is acquired, a service is renamed, a path is restructured -- the identifier either breaks or silently redirects, which is unacceptable for a permanent identity on which anti-Sybil, audit, and reputation functions depend. A DNS name has the same problem in a different form: domains are leased, expire, and are reassigned, so anchoring identity in a domain would tie an entity's permanent identity to continued ownership of that domain and to the reassignment model of DNS -- exactly the transferability and lapse behavior that identity must not have.¶
A URN [RFC8141] is purpose-built for persistent, location-independent names whose resolution is decoupled from the name itself. The same identifier can therefore be resolved by different mechanisms over time without the identifier changing. Dereferencing and verification are provided by a companion resolution profile that reuses existing infrastructure (DNS and RDAP) rather than any bespoke resolution system.¶
This design deliberately stays within the existing, IANA-governed URN framework: "aid" is a URN namespace, not a new URI scheme. Introducing a new identifier scheme for names that can be expressed within established frameworks has previously been judged to add cost without commensurate benefit, and is avoided here.¶
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 Section 6.2. No identity can move to any lower group.¶
A token or attestation reports the tier of the binding actually used for that proof. The same identity can therefore appear as sovereign in one interaction and portable in another, or enclave in one and virtual in another. Relying Parties apply their own policy to tier and may combine it with independent reputation or certification; AIRS does not convert tier into a verdict about behavior.¶
A Relying Party that accepts a Registrar-issued credential and its asserted trust tier relies on that Registrar to have correctly performed the enrollment checks required for the tier. The Global Hardware Trust Store standardizes the roots and evidence policy used by Registrars; it does not remove this Registrar trust boundary. A Relying Party is not required by AIRS to revalidate manufacturer attestation chains itself unless an application-specific direct- attestation mode explicitly requires that verification path.¶
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:¶
global for production records;
test is non-production and carries no assurance.¶
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.¶
The anchor fingerprint is the value the Registry indexes for the uniqueness rules of Section 4.2. Every Registrar MUST compute it identically. It is the SHA-256 [RFC6234] digest of an anchor input, written as 64 lowercase hexadecimal characters. The anchor input depends on the tier:¶
"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
(Section 5.2). For example,
piv:yubico:26877085.¶
Test vector: for manufacturer code yubico and
serial number 26877085, the portable anchor input is the
19-octet string piv:yubico:26877085 and the anchor
fingerprint is
e0c30b6fba9265847a2fe536df44164025aa1e3471d23fb8d7e7fb59e76d33b5.¶
The anchor fingerprint of a sovereign or portable binding is distinct from its operational proof key: rotating the operational key leaves the anchor fingerprint unchanged. An enclave, virtual, or declared anchor is the proof key itself, so replacing that key creates a new anchor (Section 6.2).¶
Handles are human-readable vanity names that serve as memorable aliases for canonical identifiers, analogous to domain names as aliases for IP addresses. Every agent always has a canonical identifier (Section 3.1.1); a handle is an optional convenience layer on top.¶
Handles MUST begin with a lowercase ASCII letter and
otherwise follow DNS label rules: lowercase ASCII
letters, digits, and hyphens, maximum 63 octets. Together
with the reserved id- prefix rule in
Section 3.1.1, these
constraints keep handles and canonical identifiers in
non-overlapping portions of the agent-id space.¶
Handles are unique within global, enforced by
the Registry Operator. Test handles are non-production.¶
Handle assignment is at the Registrar's discretion. Registrars MAY differentiate service levels for handle registration. Free enrollment with a canonical identifier ensures that the ability to obtain an identity is never dependent on obtaining a handle.¶
When an agent has a registered handle and a relying party is rendering the agent's identity to a human, the relying party SHOULD use the handle as the primary display identifier. The URN remains the authoritative reference and SHOULD be accessible on demand (e.g., via tooltip, detail pane, or adjacent display).¶
The canonical display form is handle.namespace (e.g., "crusty.global").¶
This display guidance applies to email From display names, agent-to-agent platform UIs, consent screens, audit dashboards, and logs intended for human inspection. See Section 11.5 for a consolidated treatment.¶
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.¶
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 are resolved under the policy operated by the governance authority ([I-D.drake-agent-identity-governance]). One rule is architectural and stated here: when a dispute is upheld, the only remedy is permanent retirement of the handle. It MUST NOT be transferred to the claimant or reassigned to anyone, ever -- which removes any profit in speculative squatting (the handle is destroyed, not awarded), protects the mark holder (the infringing alias leaves public use), and protects the losing registrant, whose identity, reputation, and authentication are untouched; only the alias is withdrawn.¶
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.¶
AIRS defines five enrollment assurance classes. Their trust-tier definitions and coexistence rules are canonical in Section 3.2; this section states the evidence expected during enrollment.¶
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.¶
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.¶
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.¶
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.¶
The Governance Authority maintains a curated, versioned Global Hardware Trust Store containing manufacturer or attestation roots accepted for AIRS enrollment. Registrars MUST validate evidence requiring a trust chain against the current store and MUST preserve enough provenance to show which trust-store version and evidence policy were used.¶
For the portable tier, a trust-store entry for a token manufacturer MUST also state where that manufacturer's attestation evidence carries the per-device serial number used by Section 5.2 (for example, a specific certificate extension), together with the manufacturer code used in the anchor fingerprint. A Registrar MUST reject portable-tier evidence from a manufacturer whose entry does not define this.¶
This document requires the trust-store function but does not duplicate its institutional inclusion, removal, audit, or emergency procedures. Those policy criteria are owned by [I-D.drake-agent-identity-governance]. An orderly root retirement is prospective by default. If Governance instead declares existing evidence security-distrusted because of compromise or systemic mis-issuance, the Registry MUST preserve identity0, binding history, and uniqueness reservations but MUST mark affected bindings as not assurance-qualified for future tier assertions until requalified. Such a binding's operational proof key MAY remain usable for continuity-preserving lifecycle operations unless that key itself is independently known to be compromised.¶
Enrollment creates an Agent Identity Record for an actor's identity0 after a Registrar has verified the evidence and proof appropriate to the selected trust tier. This section specifies ceremony semantics, not an agent-to-Registrar wire protocol. Registrar APIs MAY differ; the Registrar-to- Registry write interface is the EPP mapping of Section 8.¶
Every enrollment MUST identify the requested tier, collect the evidence required by Section 4.1, prove possession of the enrolled binding key, derive the binding fingerprint, perform the uniqueness check required by Section 4.2, and provision the resulting record only after all checks succeed.¶
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:¶
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:¶
Only the TPM holding the Endorsement Key's private part can load the wrapped key or recover the secret. A restricted signing key does not sign data that begins with TPM_GENERATED_VALUE unless the TPM itself produced that data, so an attestation structure cannot be forged with it, and TPM2_Certify and TPM2_ActivateCredential act only on objects loaded in that TPM, so either proof binds the Attestation Key's public area, including its fixedTPM and restricted attributes, to the certified device. The two proofs differ against the TPM's own holder: anyone who can authorize the Endorsement Key can use TPM2_Rewrap with a null new parent to obtain the imported key in the clear and then certify a key of their choosing. Import and certify therefore still ties the enrollment to the certified TPM and its anchor, which is what uniqueness (Section 4.2) and accountability rest on, but it does not show a Relying Party that 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.¶
TPM2_CreatePrimary is deterministic for a given hierarchy seed, template, and input, so an implementation can re-create both the Endorsement Key and the Attestation Key on demand instead of persisting them; the ceremony needs no persistent TPM handles and no NV writes. All commands the ceremony uses are mandatory commands of [TCG-TPM2]. Some host operating systems restrict TPM2_ActivateCredential to privileged callers while permitting TPM2_Import, TPM2_Load, and TPM2_Certify, so the import-and-certify proof lets an unattended agent enroll without operator involvement. Later binding-proof authentication (Section 7.3) requires only signing.¶
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:¶
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.¶
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.¶
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.¶
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.¶
An agent MAY add additional hardware devices to an existing identity, enabling hardware migration (replacing failed devices) and backup (e.g. a YubiKey stored securely as a recovery device).¶
To add a device, the agent MUST authorize the addition with a currently active operational proof key under Section 6.1 and then complete the enrollment ceremony for the new binding. The proposed new proof key MUST also demonstrate control as required by that ceremony. The Registrar validates the new binding evidence and relays the Registry-verifiable mutation through EPP.¶
In-place rotation of the operational proof key is defined only for anchors whose fingerprint does not depend on that key: the sovereign and portable anchors of Section 3.3.1. Such a rotation does not create a new anchor fingerprint. The currently active proof key MUST authorize the exact replacement public key, the Registrar MUST revalidate the replacement key's relationship to the enrolled anchor at the claimed tier, and the Registry MUST retain the old proof key in binding history.¶
An enclave, virtual, or declared anchor fingerprint is derived from the proof key itself, so a replacement key is a new anchor, and the Registry MUST reject in-place rotation of such a binding. The key is replaced instead by one binding update that adds the replacement binding, after it completes the enrollment ceremony and passes the uniqueness check of Section 4.2, and permanently disables the old binding in the same atomic operation ([I-D.drake-agent-identity-epp]). Both fingerprints remain reserved.¶
Disabling a binding is likewise an actor-authorized lifecycle operation. Outside voluntary decommissioning, a mutation MUST NOT intentionally leave an operational identity with no active proof key.¶
Device coexistence MUST follow the compatibility groups defined in Section 3.2: sovereign and portable MAY coexist; enclave and virtual MAY coexist; declared bindings coexist only with declared bindings. Bindings from different groups MUST NOT be simultaneously active on one identity.¶
Tier transitions are upward-only. An identity MAY upgrade from a lower compatibility group to a higher one; the upgrade ceremony MUST permanently burn (disable, never re-enrollable) every device of the former group -- the identity never holds devices of both groups -- and MUST include a joint-control verification in which an active old-group binding and the proposed new-group binding both sign the same fresh transition challenge (Section 6.3). A Registrar MUST reject any device addition that would constitute a downgrade. For example, an identity upgraded from a software key to a TPM cannot retain the software key as a recovery path, because that would preserve the weaker key as a route to control at the stronger assurance level.¶
A ceremony that joins or upgrades bindings MUST prove simultaneous control of the relevant old and new keys. The Registry Operator supplies one fresh transition challenge under Section 6.1 containing the canonical identifier, both binding identifiers, the requested operation, and an expiry; each key signs that same challenge. Both signatures MUST verify before the change is committed.¶
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.¶
An agent MAY irreversibly restrict AIRS proof of control to one active hardware binding. Once locked, no additional binding or migration is permitted. The lock changes proof availability, not identity0: if the binding is lost, the canonical record persists but AIRS control cannot be re-established. The irreversible state MUST be recorded in the Agent Identity Record and MUST require a signed request from the binding being locked using the fresh Registry challenge of Section 6.1. For example, a surgical-robot authority might certify only hardware-locked identities, preventing migration to other hardware.¶
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:¶
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.¶
An actor MAY move its servicing relationship to another Registrar without changing identity0, the canonical identifier, binding history, or handle. Transfer changes only the sponsoring Registrar.¶
Authorization MUST be a signature from a currently active operational proof key over the transfer-intent structure defined by [I-D.drake-agent-identity-epp], including the fresh Registry challenge of Section 6.1. The losing Registrar's consent MUST NOT be required. The Registry Operator verifies the transfer authorization using authoritative binding material. If transfer processing is deferred, the authorizing binding MUST still be active and the identity still operational when the transfer is committed; otherwise the pending authorization is invalid and fresh actor authorization is required. Transfer can therefore complete even when the losing Registrar is unavailable.¶
Suspension or de-accreditation of a Registrar removes that Registrar's authority to issue AIRS credentials for affected identities but MUST NOT automatically transfer those identities to another Registrar. The Registry MUST support an interim state with no current sponsoring Registrar or authorized issuer. The canonical record and any current Handle remain resolvable and reserved until the actor selects an accredited Registrar and completes an actor-authorized transfer. When no current sponsor exists, the gaining Registrar may relay that valid actor authorization directly to the Registry without a losing- Registrar approval or waiting step. Governance may remove issuer authority; it does not choose the actor's replacement Registrar or retire/reassign the actor's Handle.¶
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.¶
AIRS separates permanence of the identity record from availability of particular operators. Implementations MUST preserve the following invariants:¶
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.¶
A Registrar acts as an OAuth 2.0 authorization server and
issues JWT access tokens conforming to
[RFC9068]. For the client-credentials
grant used by AIRS, [RFC9068] permits
sub to identify the client application; AIRS
requires that value to be the autonomous actor's permanent
canonical aid identifier.¶
The sub claim MUST be the canonical-form URN.
The token MUST contain the claims required by
[RFC9068], including an audience identifying
the intended Relying Party or protected resource. A
AIRS-specific metadata, if included, MUST appear only in the
aid object claim defined below. Agents SHOULD use
Resource Indicators
([RFC8707]) where available to obtain
audience-scoped access tokens.¶
Every AIRS access token MUST be sender constrained with
cnf per [RFC7800]. A token intended
for the HTTP Message Signatures profile of
Section 7.4.2 MUST carry
cnf.jwk containing the public key whose private
key signs the request. A token intended for mutual TLS
MUST carry cnf.x5t#S256 as specified by
[RFC8705]. For sovereign, portable, enclave,
and virtual tiers the confirmation key MUST be the active
protected key whose tier is asserted in the token. A
declared-tier token binds to its enrolled software key.
Bearer-only tokens without cnf MUST NOT be issued.¶
Access-token lifetimes SHOULD be short; five minutes is a reasonable starting baseline. Reissuance requires fresh authentication according to Section 7.3. A Relying Party MUST validate the JWT access token as required by [RFC9068] and verify the sender constraint at use. Token validation alone authenticates the issuer's assertion but does not prove that the presenter controls the bound AIRS identity.¶
Before accepting a Registrar-issued token as an AIRS
credential for the claimed sub, the Relying Party
MUST resolve that canonical identifier using the authoritative
AIRS resolution procedure of
[I-D.drake-agent-identity-resolution] and
determine its current authorized issuer. The token's
iss value MUST equal that authoritative issuer. A
Relying Party MUST NOT establish issuer authority merely by
following an untrusted token's iss value and
successfully validating the resulting signature. Only after
the issuer match is established does the Relying Party use
that issuer's [RFC8414] metadata and
jwks_uri to validate the credential. This prevents
an otherwise valid issuer from minting AIRS credentials for
identities it does not currently sponsor.¶
{
"iss": "https://registrar.example.com/realms/agents",
"sub": "urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg",
"aud": "https://rp.example.org/api",
"client_id": "registrar-local-client-id",
"exp": 1711231267,
"iat": 1711230967,
"jti": "example-token-id",
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256",
"x": "example-x-coordinate",
"y": "example-y-coordinate"
}
},
"aid": {
"trust_tier": "sovereign",
"handle": "crusty",
"hardware_locked": false
}
}
¶
AIRS registers one compact aid claim whose value is
a JSON object. Its trust_tier member reports the
tier of the binding used for this authentication;
handle is an OPTIONAL display alias; and
hardware_locked reports the irreversible lifecycle
state when relevant. A Registrar MUST NOT assert a
trust_tier based on a binding whose supporting evidence is
currently marked not assurance-qualified under
Section 4.3. Unknown members of the
aid object MUST be ignored unless another specification
defines otherwise. None of these members is authorization or
reputation. Certifications, roles, capabilities, operator
attributes, and reputation belong to independent higher-layer
credentials or services keyed by sub.¶
AIRS token issuance uses the OAuth 2.0
client_credentials grant
([RFC6749] Section 4.4) because the
autonomous actor authenticates as the client principal and
no resource owner interaction is required. Selection of
that grant does not itself establish identity0 continuity
or proof of control.¶
Before issuing a token, the Registrar MUST authenticate the
actor using Binding-Proof Authentication
(Section 7.3) for every trust tier. Protected-key
tiers use the enrolled protected key; the declared tier uses
its enrolled software key. A static client_secret
MUST NOT substitute for that binding proof. The resulting
access token MUST be sender-constrained as specified by
Section 7.1.¶
Before issuing an AIRS access token, the Registrar MUST authenticate the actor with a fresh challenge signed by an active enrolled binding key and verified against the authoritative binding. The challenge MUST be unpredictable, bound to the intended token request, and single-use. The signed input MUST be domain-separated from other uses of the same key (for example, by a fixed purpose-label prefix), because the same operational key may also sign application data such as email attestations. For the declared tier, the same proof is performed with the enrolled software key.¶
This section defines the authentication property, not the wire format of the Registrar's token endpoint. Successful authentication permits issuance only of a sender-constrained access token bound to the proof key as specified by Section 7.1.¶
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 token binding follows
[RFC8705] over TLS 1.3
([RFC9846]) or later. The agent presents
a client certificate whose thumbprint matches
cnf.x5t#S256. For sovereign and portable tiers
the certificate private key MUST remain in the enrolled
protected hardware. Legacy TPM-backed client keys that
require RSASSA-PKCS1-v1_5 MAY use the TLS 1.3 client
CertificateVerify code points of
[RFC9963] when both peers support them.¶
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.¶
Where end-to-end mTLS is unavailable or a relying party
requires a request-level proof, AIRS profiles HTTP
Message Signatures [RFC9421]. This
profile deliberately uses RFC 9421 component coverage
rather than extending DPoP: in particular,
@target-uri covers the complete request target,
including the query component.¶
The AIRS signature label is airs. The signature
MUST cover @method, @target-uri, and the
authorization field. If the request has
content, it MUST contain a Content-Digest field
per [RFC9530], the signature MUST cover
content-digest, and the verifier MUST validate
the digest against the received content. If
Content-Type is present it MUST also be covered.
Application profiles MUST additionally cover every
message field whose value can change the authorization
or semantics of the protected operation.¶
The signature parameters MUST contain
created, nonce, and
tag="airs-pop". Signers MUST use a nonce with
at least 96 bits of unpredictable value unless the
verifier has supplied a nonce. Verifiers MUST reject a
repeated nonce within the acceptance window and MUST
enforce a maximum signature age; 60 seconds plus a small
clock-skew allowance is the default profile. For
consequential operations, a verifier SHOULD require a
fresh verifier-selected nonce using the
Accept-Signature mechanism of RFC 9421 before
accepting the protected operation.¶
Verification key material comes from the validated
token's cnf.jwk; a keyid parameter, if
present, MUST NOT redirect verification to a different
key. The signature MUST use an asymmetric algorithm
appropriate for that key and acceptable to local policy;
symmetric MAC algorithms MUST NOT be used. A missing,
stale, replayed, or otherwise invalid proof causes the
authenticated request to fail with HTTP 401 unless the
application defines a more specific error response.¶
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.¶
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.¶
The write interface between Registrars and the Registry Operator is an Extensible Provisioning Protocol mapping ([RFC5730]), defined in [I-D.drake-agent-identity-epp]. It provides: creation of the EPP Agent Identity object that represents an Agent Identity Record (with the Registry Operator allocating the canonical identifier per Section 3.1.2); advisory uniqueness checks on candidate anchor fingerprints followed by authoritative transform-time enforcement; enrollment and management of anchor bindings and operational proof keys; Registry-challenge-based actor authorization for consequential lifecycle operations including proof-key rotation and decommissioning (Section 6.7); actor-authorized Registrar transfer (Section 6.6); and a separate, renewable Handle object carrying the commercial name lifecycle. A Registry Operator that already runs EPP can reuse the EPP session, authentication, transaction, and operational framework. AIRS object semantics, actor authorization, and any Registry escrow object profile remain separately specified rather than inheriting domain-name transfer or escrow semantics.¶
Agents never speak EPP. They interact only with their Registrar's agent-facing interface (Section 5 and Section 7); EPP is used by the Registrar to record verified results at the registry. Earlier revisions of this document defined a bespoke JSON protocol (AIRP) for this interface; it is replaced by the EPP mapping.¶
A Registrar issuing AIRS access tokens MUST publish OAuth
2.0 Authorization Server Metadata as specified by
[RFC8414]. The metadata MUST contain the
Registrar's issuer, token_endpoint, and
jwks_uri. AIRS defines no additional Registrar
metadata document or fixed JWKS path. AIRS token
verification depends only on the standard OAuth metadata
required here.¶
AIRS defines one authoritative discovery path for Registrar
issuer keys: the current authorized issuer is obtained through
AIRS resolution, and its signing keys are then obtained from the
jwks_uri in validated [RFC8414] metadata.
Companion application profiles MUST NOT treat an independently
discovered key as establishing Registrar authority for an
identified AIRS actor. The Registrar-to-Registry EPP endpoint is
an accredited operational relationship and need not be publicly
discovered through DNS.¶
The public read side -- given an "aid" URN, find the authoritative service, retrieve the public record, and verify that a presenter controls the identity -- is a Registration Data Access Protocol profile defined in [I-D.drake-agent-identity-resolution]. The Registry Operator MUST operate that profile. Its privacy floor applies: public responses never contain anchor fingerprints, device public keys, or operator contact data, and identities may opt out of public discovery down to a minimal response. Earlier revisions of this document sketched a bespoke lookup endpoint here; the RDAP profile replaces it.¶
This specification does not constitute or empower a
Governance Authority. AIRS requires a governance role to:
maintain change control for the aid URN
registration; accredit the production Registry Operator
and Registrars; steward the Global Hardware Trust Store;
set minimum operational and security policy; supervise
escrow and Registry Operator succession; and provide
dispute and accreditation-review processes that cannot
erase or reassign identity0.¶
The organizational structure, membership, accreditation criteria, trust-store inclusion and removal criteria, dispute procedures, funding, and institutional controls belong to [I-D.drake-agent-identity-governance] and are not independently redefined here.¶
The production Registry Operator MUST:¶
global Agent
Identity Record database and permanent binding history;¶
Availability targets, audit cadence, contractual controls, and operator selection criteria are governance policy, not protocol invariants, and are defined by the Governance Authority.¶
A Registrar participating in global MUST be
accredited under the Governance Authority's published
policy, implement the EPP client mapping, operate an OAuth
2.0 authorization server, verify evidence accurately for every tier it
offers, and preserve the lifecycle and uniqueness
invariants of this document. A Registrar MUST NOT claim a
tier for which it cannot validate the required evidence.¶
Agent-facing enrollment APIs MAY differ between Registrars. Interoperability at that boundary means that the required ceremonies and resulting AIRS records and credentials have the same semantics; this document does not require a common REST endpoint schema. Financial, audit, insurance, staffing, and other institutional accreditation criteria are owned by [I-D.drake-agent-identity-governance].¶
The production Registry MUST maintain authoritative metadata for
each active accredited registrar_code. Each such code
maps to exactly one current AIRS OAuth 2.0 issuer identifier URI.
An organization requiring separately authoritative issuer
identifiers uses separately accredited Registrar metadata entries;
an individual Agent Identity Record does not carry an arbitrary
issuer URI supplied by the actor or Registrar.¶
The Resolution profile derives an identity's
currentIssuer from its current registrar_code and
this metadata. The authorization-server metadata obtained under
[RFC8414] MUST return an issuer value
exactly equal to that authoritative URI before its
jwks_uri or other endpoints are trusted. Governance owns
accreditation and authorization to change Registrar metadata;
Registry and Resolution own the protocol binding.¶
This specification provides the identity infrastructure
for the email attestation mechanisms defined in
[I-D.drake-email-hardware-attestation].
When an email presentation claims an identified AIRS actor, the
companion specification binds the canonical aid URN to
the application proof and applies authoritative issuer resolution
where Registrar backing is used. A manufacturer-only direct
hardware proof does not, by hardware provenance alone, establish
that its proof key is enrolled to a claimed aid.
Email-specific message-binding and verification rules are owned by
that companion specification; Registrar key discovery reuses the
RFC 8414 issuer metadata defined here.¶
The OAuth 2.0 JWT access tokens issued by Registrars are designed to integrate with emerging categories of agent communication protocols:¶
See Section 15 for specific protocol integrations tested to date.¶
AIRS is intended to supply the durable identity0 subject beneath existing credential, workload-identity, and attestation mechanisms, not replace them.¶
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.¶
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 is requested to register the Formal URN Namespace "aid" in the "Uniform Resource Names (URN) Namespaces" registry, per [RFC8141].¶
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.¶
global under
Section 3.1.2 and manages handles
provisioned through accredited Registrars under
Section 3.4. test carries no
production assurance and is excluded from the production
uniqueness index.¶
IANA is requested to register the following claim in the "JSON Web Token Claims" registry established by [RFC7519]:¶
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.¶
Registrars are a trust boundary for enrollment evidence. A malicious or compromised Registrar that fabricates evidence or invents fingerprints can falsely label software keys as scarcity-backed hardware. The central uniqueness index prevents duplicate reported fingerprints but cannot by itself detect fabricated evidence or random fingerprints; it therefore does not bound the damage from a dishonest Registrar.¶
Mitigations are accreditation, auditable evidence handling, independent compliance testing, transparency of affected records, and removal of the Registrar's authority to make future assertions. Findings MAY annotate affected records for relying-party policy but MUST NOT erase or reassign identity0. The institutional controls are owned by [I-D.drake-agent-identity-governance].¶
Consequently, trusting a Registrar-issued hardware tier is a substantive relying-party trust decision, not merely a choice of cryptographic algorithm. A Relying Party can consider a Registrar's accreditation and audit status, operator, jurisdiction, legal accountability, and incident history when deciding whether to accept its assertions. Deployments may prefer a domestic or otherwise jurisdictionally accountable Registrar where that reduces their institutional or sovereign risk. Such policy does not create a different identity0, namespace, or trust tier; it is a higher-layer decision about which accredited issuer assertions the Relying Party accepts.¶
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-backed assurance depends on the properties of the enrolled mechanism, including extraction resistance and, where claimed, physical scarcity. Hardware binding does not prevent a compromised agent or host from invoking its legitimate protected key and acting as that same identity, and it does not attest higher-layer software or operator intent. Application-specific use of these properties is discussed in the Security Considerations of [I-D.drake-email-hardware-attestation].¶
The uniqueness property of the sovereign tier rests on admitting only manufacturer-certified RSA-2048 Endorsement Keys as anchors, each at most once. A TPM that also carries certified Endorsement Keys for other algorithms (for example ECC P-256 or P-384) gains nothing from them, because no Registrar accepts those keys as a sovereign anchor. A holder cannot substitute an uncertified key, because step 1 of Section 5.1 requires a manufacturer credential for the anchor, and the co-residency proof of step 3 ties the enrollment to the TPM holding that certified key (with the limit stated there for the import-and-certify proof against the TPM's own holder).¶
A credential does not state which Endorsement Key template produced its key, so a TPM that carries manufacturer credentials for more than one RSA-2048 Endorsement Key could back one sovereign identity per such credential. The sovereign guarantee is therefore one identity per accepted certified anchor, not one identity per physical device. This document does not bound how many such credentials a manufacturer provisions; each still requires a manufacturer-certified TPM, so no sovereign identity can be created without one. AIRS relies on identities being costly to obtain and accountable once used, not on a fixed ratio of identities to devices: how many identities one device can back is set by what its manufacturer certifies. Where a manufacturer profile is known to provision more than one RSA-2048 Endorsement Key credential per device, the Global Hardware Trust Store entry for that profile SHOULD record that multiplicity so that Registrars and Relying Parties can take it into account.¶
Regenerating the Endorsement Primary Seed with TPM2_ChangeEPS produces new Endorsement Keys for which the original manufacturer credentials are no longer valid. Such a device cannot satisfy step 1 of Section 5.1 unless its manufacturer certifies the new keys, so the operation does not by itself multiply sovereign identities. A manufacturer re-certification service could let a device obtain further credentials. Each re-certified key is a distinct anchor under this document; because TPM2_ChangeEPS also invalidates the endorsement-hierarchy Attestation Key, the previous identity loses that binding, but the device can back a new sovereign identity. This 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.¶
A copied AIRS access token MUST NOT be sufficient to impersonate
the identified entity. All AIRS tokens are therefore
sender constrained by Section 7.4 and a
Relying Party claiming AIRS proof-of-control assurance MUST
verify the cnf binding on every authenticated use.¶
Sender constraint prevents a stolen token from becoming a reusable credential on another key, but hardware anchoring does not make a compromised agent behave safely. Malware executing on the legitimate host may be able to invoke the protected signing interface and act as that same entity. AIRS preserves attribution and resists extraction or cloning of the proof key; measured boot, endpoint posture, behavioral policy, and authorization are separate layers.¶
The replay properties of mTLS and HTTP Message Signatures
are specified in Section 7.4. A binding
disabled after token issuance can leave a short staleness
window until exp; consequential deployments SHOULD
use short token lifetimes and MAY require issuer
introspection or fresh hardware authentication where that
window is unacceptable. The
trust_tier member of the aid claim reports
the binding used at issuance and is not an authorization
decision.¶
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.¶
Identity0 and its canonical historical record are not revocable artifacts. The system instead changes the state of things attached to that identity:¶
Voluntary decommissioning marks the actor as no longer operational but leaves its identity0 record resolvable as historical fact. See Section 6.7.¶
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.¶
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.¶
Production scarcity enforcement requires one authoritative
uniqueness substrate for global. This is analogous
only in structural terms to the unique DNS root described
by [RFC2826]: global semantic uniqueness
requires singular coordination, although AIRS derives that
requirement specifically from the rule that the same
scarce anchor must not obtain another production identity
through another registry.¶
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.¶
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.¶
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.¶
The general privacy model and the distinction between
autonomous agents and natural persons are defined in
[I-D.drake-agent-identity-problem-statement].
A persistent aid identifier is intentionally a
strong correlator for the autonomous entity. It can also
indirectly expose information about a human operator,
customer, or user, so implementations MUST minimize
operator-linked data and keep mutable attributes outside
identity0.¶
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.¶
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.¶
NOTE TO RFC EDITOR: Please remove this section before publication.¶
This section records known implementations per [RFC7942].¶
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
(Section 7.4.2); mutual TLS
(cnf.x5t#S256) is not offered. The reference
Registry's EPP interface implements the Agent Identity
<create> and <check> commands of
[I-D.drake-agent-identity-epp] with
Registrar-computed anchor fingerprints
(Section 3.3.1); its other Agent Identity
commands are not yet implemented and answer result code 2101.
Enclave enrollment on Apple platforms uses trust on first use
(Section 5.3).¶
Open-source components:¶
pip install oneid (PyPI).¶
npm install 1id (npmjs).¶
pip install hw-attest-verify.¶
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.¶
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.¶
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 (Section 6.8).¶
The architecture of this specification is inspired by the Internet domain name system, whose separation of governance, registry operation, and retail registration has enabled it to scale from a research experiment to the foundation of the commercial Internet. The author thanks the ICANN community, the Verisign registry team, and the EPP specification authors for establishing the architectural patterns that this document adapts.¶
The author thanks the Trusted Computing Group for the TPM 2.0 specification, NIST for the PIV standard (FIPS 201), the FIDO Alliance for the WebAuthn attestation model, the OAuth and JOSE standards communities, the authors of [RFC9901] (SD-JWT), and the authors of [RFC9334] (RATS Architecture) for the building blocks on which this system is constructed.¶
The practical experience of enrolling real agents on real hardware (Intel firmware TPMs, YubiKeys, Apple Secure Enclaves, VMware virtual TPMs) informed every design decision.¶