Agent Identity Registry System: A Federated Architecture for Hardware-Anchored Identity of Autonomous Entities

1.1. Design Principles

Autonomous-Entity First

This system is designed for non-human entities. Human operators are accommodated but not required. The enrollment, authentication, and lifecycle protocols are optimised 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 hardware security components receive the highest trust tier, but entities without hardware can still participate. A software-only agent can enroll, authenticate, build reputation, and interact with the ecosystem at a lower trust level. This inclusivity avoids an all-or-nothing barrier and recognises that legitimate agents exist in environments without hardware security (cloud functions, containers, embedded systems).¶

Federated by Design

No single organisation controls identity issuance. Multiple Registrars compete to serve agents. Multiple Registry Operators may serve different namespaces. The system is designed so that the failure or malfeasance of any single participant does not compromise the entire ecosystem.¶

Standard Tokens, Minimal Integration

Identities are expressed as standard OIDC/OAuth2 tokens. Token signature verification uses existing OIDC libraries. Hardware attestation complexity is hidden behind the enrollment API; relying parties see standard JWTs. Interpreting agent-specific claims (trust tier, namespace, handle) requires application logic, but the cryptographic verification path is entirely standard.¶

Persistent, Indelible, Accountable

An identity, once created, is permanent. Agent-ids are never reassigned. Hardware bindings are never broken (only disabled). Reputation -- good or bad -- follows the identity forever. This permanence is the foundation of trust: it makes accountability inescapable and reputation meaningful.¶

Separation of Identity from Behaviour

This registry is a birth certificate office, not a police department. It proves existence and hardware anchoring. Separate, independent systems -- relying parties, reputation services, certification authorities -- are responsible for reputation scoring, behaviour monitoring, access control, and abuse response, consuming standard identity credentials issued by Registrars. This separation prevents the identity provider from becoming a surveillance system.¶

Identity is Identity; Attestations are Separate

The URN is a narrow, permanent, hardware-anchored identifier. Jurisdiction, trust tier, capabilities, role, and all other dynamic properties are expressed as verifiable claims layered onto the identity -- never encoded in the URN itself. This separation is essential to the architecture's longevity: trust tiers can change (hardware upgrades), capabilities evolve (new certifications), and jurisdiction is contextual (agents are cross-border). Encoding any of these in the URN would either freeze a mutable property or require identity reassignment when properties change.¶

Identity is Never Revoked

An identity, like a birth certificate, cannot be revoked. The URN is a permanent record of existence. What can change is the operational state of things attached to the identity: device bindings can be revoked (hardware compromised or lost), handles can be disabled (non-renewal) or retired (dispute), and Issuer trust can be withdrawn by relying parties. But the identity itself -- the URN, the enrollment record, the reputation history -- persists forever. This distinction between identity revocation (which does not exist) and device/binding/handle revocation (which does) is fundamental to the architecture.¶

Transport Independence

The identity tokens and attestation formats defined here are usable across any Internet protocol: email, HTTP, WebSocket, agent-to-agent messaging, MCP tool invocation, and protocols not yet invented.¶

1.2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.3. Terminology

Autonomous Entity

Any non-human actor that participates in Internet protocols: AI agents, robotic systems, automated services, IoT devices with agency, or any software or hardware system that acts with a degree of independence. This document uses "agent" as a convenient shorthand, but the architecture serves all autonomous entities regardless of embodiment.¶

Agent Identity Document (AID)

The complete record of an autonomous entity's identity, including its URN, trust tier, hardware bindings, handle (if any), enrollment metadata, and lifecycle state. Maintained authoritatively by the Registry Operator.¶

Governance Authority

The body responsible for policy, accreditation, and stewardship of the shared namespace ecosystem. Deployments that operate a shared namespace (such as global) define the governance authority's form and mandate. Domain-scoped issuer namespaces operate independently without requiring a central governance authority.¶

Registry Operator

An organisation accredited by the governance authority to maintain the authoritative database of Agent Identity Documents within one or more namespaces. Analogous to Verisign operating the .com registry. The Registry Operator enforces cross-Registrar hardware uniqueness and provides unified discovery services.¶

Registrar

An organisation accredited by the governance authority to perform hardware attestation verification, enroll agents, issue OIDC tokens, and sell vanity handles. Analogous to a domain name registrar (GoDaddy, Namecheap). Multiple Registrars compete to serve agents within the same namespace. Each Registrar is identified by a registrar-code assigned during accreditation.¶

Namespace

A partition of the agent identity space, identified by a label in the URN structure. Two types exist: Delegated Namespaces (managed by a Registry Operator, with multiple Registrars) and Domain-Scoped Issuer Namespaces (operated by a single organisation acting as both registry and registrar). See Section 2.2.¶

Trust Tier

A classification of an agent's hardware trust level, assigned during enrollment based on the hardware evidence presented. See Section 3.2.¶

Handle

A human-readable vanity name assigned to an agent identity (e.g., "@clawdia" or "@acmeco-delivery-bot-7"). Handles are optional, memorable aliases; the URN is the canonical identifier. Analogous to a domain name as an alias for an IP address, except handles are non-transferable, because identity itself is not transferable either.¶

Hardware Fingerprint

The SHA-256 hash of the SubjectPublicKeyInfo DER encoding of a hardware security component's identity certificate public key. Uniquely identifies a physical device across all contexts. Used for anchoring and anti-Sybil enforcement.¶

Enrollment Ceremony

The cryptographic protocol by which an agent proves possession of a hardware security component and receives an Agent Identity Document. The ceremony varies by hardware type (see Section 5).¶

Relying Party (RP)

Any service that accepts and verifies agent identity tokens issued by a Registrar. Examples include email services, chat platforms, API gateways, and other agents performing peer verification.¶

Succession

The process by which an agent's identity is transferred from one Registrar to another, or from a Registrar to a new identity under a different namespace, while preserving a cryptographic link to the original identity for reputation continuity.¶

2.1. Registry Hierarchy

The hierarchy comprises three tiers:¶

Tier 1: Governance Authority

A deployment that operates the shared global namespace requires a governance authority serving as the root of trust for that namespace. The governance authority MUST provide at minimum the following capabilities:¶

• Maintaining the "aid" URN formal namespace registration with IANA.¶
• Accrediting Registry Operators and Registrars.¶
• Publishing and maintaining the Global Hardware Trust Store: the authoritative collection of hardware manufacturer root CA certificates accepted for enrollment.¶
• Setting minimum standards for enrollment verification, anti-Sybil enforcement, and data retention.¶
• Operating a dispute resolution mechanism for handle conflicts and Registrar malpractice claims.¶
• Allocating Shared Namespaces and approving Domain-Scoped Issuer Namespace registrations.¶

To prevent single-entity capture of the federated system, the governance authority SHOULD be constituted as a multi-stakeholder body. The specific organisational structure, charter, and membership criteria are operational matters outside the scope of this specification; they are expected to be defined by the founding governance authority and to evolve through its own processes. See Section 10.1 for deployment guidance.¶

Tier 2: Registry Operators

Registry Operators maintain the authoritative databases for Shared Namespaces. Their responsibilities include:¶

• Maintaining the master Agent Identity Document database for their namespace(s).¶
• Operating the Global Hardware Fingerprint Index: a cross-Registrar registry that maps hardware fingerprints to agent identities, enforcing the anti-Sybil invariant that one hardware device backs at most one identity within the namespace.¶
• Providing the Agent Identity Registry Protocol (AIRP) interface for Registrars (see Section 8).¶
• Operating unified discovery and lookup services (see Section 9).¶
• Publishing the namespace's root JWKS, enabling verifiers to discover any Registrar's signing keys.¶
• Enforcing handle uniqueness within the namespace.¶

Multiple Registry Operators MAY exist, each serving different Shared Namespaces. A single Registry Operator MAY serve multiple namespaces. This mirrors the domain name system where Verisign operates both .com and .net.¶

Tier 3: Registrars

Registrars are the customer-facing entities that interact directly with autonomous entities. Their responsibilities include:¶

• Performing hardware attestation verification: validating TPM EK certificates, PIV attestation chains, and enclave key proofs against the Global Hardware Trust Store.¶
• Conducting the enrollment ceremony (see Section 5).¶
• Registering new identities with the Registry Operator via AIRP.¶
• Issuing OIDC/OAuth2 tokens to enrolled agents.¶
• Providing SDKs and enrollment tools.¶
• Selling and managing vanity handles.¶
• Supporting the identity lifecycle: device addition, migration, co-location binding, hardware lock, and succession.¶

Beyond these three operational tiers, the ecosystem includes Relying Parties that consume identity credentials and build services atop them: email services, API gateways, chat platforms, agent-to-agent protocols, reputation providers, and certification authorities. Relying Parties verify standard OIDC tokens issued by Registrars and apply their own policies based on trust tier, reputation, and domain-specific certifications. The value of the identity infrastructure is ultimately measured by the breadth and depth of services that rely on it.¶

2.2. Namespace Types

Two namespace types accommodate different operational models:¶

Shared Issuer Namespace (global)

The global namespace is the shared issuer namespace in which multiple accredited Registrars compete to enroll agents. A Registry Operator (designated by the governance authority) enforces hardware uniqueness and handle uniqueness across all Registrars within this namespace. This is the primary namespace for general-purpose agent identity and the one in which handle scarcity creates commercial value -- analogous to .com in the domain name system.¶

The global label identifies this shared issuer pool, not a policy category. It does not encode jurisdiction, deployment context, or consequence level into the URN -- consistent with the principle that identity is identity and all other properties are separate attestations.¶

Future shared namespaces MAY be created by the governance authority through a transparent allocation process, but this specification defines only global. Vertical-market or jurisdictional namespaces (e.g., for IoT devices or government systems) are better served by domain-scoped issuer namespaces, which any domain owner can create without central allocation.¶

The global namespace is reserved by this specification but is not operational until a governance authority is constituted (Section 10.1) and a Registry Operator is selected through that authority's process. Until that point, no Issuer may issue identities in global, and Relying Parties MUST treat any urn:aid:global:... token presented prior to operational launch as not verifiable.¶

During the bootstrap phase, agent identity is delivered exclusively through Domain-Scoped Issuer Namespaces. These namespaces are operationally self-contained: any organisation that controls a DNS domain may operate as an Issuer under its reverse-DNS namespace without dependency on the governance authority or the global Registry Operator. The reputation and operational evidence accumulated by domain-scoped Issuers during this phase is intended to inform the governance authority's accreditation criteria once that body is constituted.¶

The Registry Operator for global will be selected through a process defined by the governance authority. This specification does not designate the Registry Operator and does not preclude any party -- including parties that operate Domain-Scoped Issuer Namespaces during the bootstrap phase -- from competing in that process. The substrate operation of global, like the operation of internet domain registries, is expected to be funded by handle registration and renewal fees set by the Registry Operator under governance-authority policy.¶

Domain-Scoped Issuer Namespace

A namespace operated by a single organisation that acts as both Registry Operator and sole Registrar for its own identities. Domain-Scoped Issuer Namespaces use reverse-DNS notation derived from the operator's domain name (e.g., com.1id, com.example-corp, org.example-lab).¶

Any organisation that owns a DNS domain MAY operate a Domain-Scoped Issuer Namespace by publishing a /.well-known/aid-issuer.json discovery document served over TLS at the corresponding HTTPS endpoint (see Section 9). Verifiers MUST refuse to accept tokens from domain-scoped Issuers unless this proof of domain control is observable. Domain-scoped operators MUST meet the same minimum enrollment and anti-Sybil standards as Shared Namespace Registrars.¶

domain-scoped operators MUST escrow identity data to the governance authority under the same terms as Shared Namespace Registry Operators (daily snapshots, hardware fingerprints encrypted to the governance authority's escrow key). This escrow enables emergency succession (see Section 6.5) if the operator becomes permanently unresponsive.¶

Domain-Scoped Issuer Namespaces are identified by their reverse-DNS label and enforce hardware uniqueness within their own namespace. Cross-namespace uniqueness is enforced at the governance authority level through the Global Hardware Fingerprint Index when the domain-scoped operator participates in the cross-registry protocol, or is detectable by verifiers comparing fingerprints across namespaces.¶

Relying parties making long-term trust decisions SHOULD consider namespace type as a durability factor: Shared Namespaces have structural redundancy (multiple Registrars, escrowed data, replaceable operators), while Domain-Scoped Issuer Namespaces depend on a single operator's continued operation.¶

3.1. URN Format

Agent identities use the URN format defined in [RFC8141] with the "aid" (Agent Identity) namespace identifier, as established by [I-D.drake-email-hardware-attestation].¶

aid-urn          = "urn:aid:" namespace ":" agent-id

namespace        = shared-ns / domain-scoped-ns
shared-ns        = dns-label
domain-scoped-ns = dns-label 1*("." dns-label)

agent-id         = canonical-id / handle-id
canonical-id     = "id-" 1*DIGIT
handle-id        = ALPHA *(let-dig-hyp) let-dig / ALPHA
                   ; handle-id MUST NOT begin with "id-"
                   ; (see prose reservation below)

dns-label        = let-dig *(let-dig-hyp) let-dig / let-dig
let-dig          = ALPHA / DIGIT
let-dig-hyp      = ALPHA / DIGIT / "-"

urn:aid:global:id-9854187104        canonical, permanent
urn:aid:global:crusty                handle, may be retired
urn:aid:com.1id:id-3387412508       canonical, permanent
urn:aid:com.1id:crusty              handle (different agent than global:crusty)

3.2. Trust Tiers

Every Agent Identity Document includes a trust tier that classifies the strength of the hardware anchoring. Trust tiers are assigned during enrollment based on the hardware evidence presented and verified by the Registrar.¶

Hardware anchoring provides Sybil resistance at enrollment: creating many identities requires proportionally many physical devices. However, hardware tier alone does not establish trustworthiness. A brand-new sovereign-tier identity with no reputation is an unknown quantity; a declared-tier identity with years of good behaviour observed by independent reputation services is empirically more trustworthy. Trust tier is a starting signal, not a verdict -- long-term trust accrues through reputation, which is built on identity but not provided by it.¶

Issuers operating in the shared global namespace MAY issue declared-tier (SFT) identities, but MUST clearly expose the trust tier in every token and identity document so that relying parties can apply differentiated policy. Relying parties that require hardware-anchored Sybil resistance for their use case SHOULD filter on trust tier rather than relying on namespace-level exclusion.¶

Relying parties SHOULD apply differentiated policy based on trust tier. For example, a high-security financial API might accept only sovereign and portable tiers, while a public chat service might accept all tiers with different rate limits. Relying parties SHOULD also consider consulting independent reputation services, using the agent's persistent identity as the lookup key, to assess cross-service behaviour patterns beyond their own observations.¶

An identity's effective trust tier MAY change over its lifetime when the identity has multiple enrolled devices of different types. The trust tier reported in authentication tokens reflects the device used for the most recent attestation, not a static property. Verifiers SHOULD expect the same agent-id to appear with different trust tier values across different interactions. (e.g. when agents upgrade to hardware tiers, or to stronger hardware ones)¶

3.3. Identity Attributes

An Agent Identity Document contains the following attributes, maintained by the Registry Operator:¶

canonical_id (REQUIRED)

The permanent canonical identifier (e.g., id-9854187104), forming part of the URN. Never retired or reassigned. See Section 3.1.1.¶

namespace (REQUIRED)

The namespace in which this identity is registered.¶

max_active_trust_tier (REQUIRED)

The highest trust tier achieved by any currently active device bound to this identity. Per-attestation trust tier appears separately as attested_trust_tier in OIDC tokens.¶

registrar_code (REQUIRED)

The identifier of the Registrar that manages this identity.¶

enrolled_at (REQUIRED)

ISO 8601 timestamp of initial enrollment.¶

hardware_devices (REQUIRED)

List of hardware device bindings, each containing: hardware fingerprint, hardware type code, manufacturer, device status (active, disabled), and binding timestamp.¶

handle (OPTIONAL)

A vanity name assigned to this identity. See Section 3.4.¶

display_name (OPTIONAL)

A human-readable display name for the agent.¶

operator_email (OPTIONAL)

Contact address for the human operator responsible for this agent, if any.¶

hardware_locked (OPTIONAL)

Boolean. When true, the identity is permanently bound to a single hardware device. Irreversible.¶

succession_link (OPTIONAL)

URN of a successor identity, if this identity has been transferred. See Section 6.5.¶

verified_attributes (OPTIONAL)

A list of attribute claims that the Registrar or a third party has independently verified. Each entry contains: the attribute name, the issuer of the verification, the verification method, and the validity period. Verified attributes are expressed as SD-JWT disclosures or verifiable credentials attached to the identity, enabling selective disclosure by the agent to relying parties. The set of verifiable attribute types is not constrained by this specification; common examples include certifications, compliance attestations, and operator-verified metadata.¶

3.4. Handle System

Handles are human-readable vanity names that serve as memorable aliases for agent identities, 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 letter (ALPHA) and otherwise follow DNS label rules: lowercase ASCII letters, digits, and hyphens, maximum 63 octets. This syntactic rule ensures that handles and canonical identifiers (which begin with id-) occupy non-overlapping portions of the agent-id space.¶

Handles are unique within each namespace (enforced by the Registry Operator for shared namespaces, or by the operator for domain-scoped namespaces). Handle uniqueness is namespace-scoped: different namespaces may independently assign the same handle string to different agents. This is intentional and analogous to how multiple DNS zones may contain the same hostname.¶

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

3.5. Optional Value-Added Services

Registrars MAY offer optional value-added services to enrolled identities, including but not limited to: extended attestation freshness proofs, enhanced device management, multi-device co-location attestations, additional handle slots, verified attribute issuance, and third-party certification facilitation.¶

Such services MUST NOT be required for basic identity issuance, authentication, or token verification. An agent enrolled with a system-assigned agent-id and no optional services MUST be able to authenticate and present its identity to any relying party.¶

Third-party certifications (e.g., compliance attestations, safety certifications, domain-specific qualifications) MAY be attached to an Agent Identity Document as verified attributes (see Section 3.3) and expressed as signed claims (verifiable credentials, SD-JWT disclosures, or OIDC claim references). Registrars MAY facilitate the lifecycle management of such certifications on behalf of agents and certification authorities.¶

4.1. Supported Hardware Mechanisms

The system supports five classes of hardware security, each providing different levels of Sybil resistance and key protection. The enrollment ceremony (see Section 5) varies by hardware type, but all share the same identity document structure and authentication token format.¶

TPM 2.0 (Sovereign Tier)

Discrete or firmware Trusted Platform Modules per [TCG-TPM2]. Identity is anchored to the Endorsement Key (EK), a unique RSA or ECC key pair generated inside the TPM at manufacturing time per [TCG-EK-PROFILE]. The Registrar validates the EK certificate chain to the manufacturer's root CA. Enrollment uses the TPM2_MakeCredential / TPM2_ActivateCredential protocol to prove the Attestation Key (AK) resides in the same TPM as the EK.¶

PIV Smart Card (Portable Tier)

Personal Identity Verification tokens (YubiKey, Nitrokey, Feitian, SoloKeys, and others) with manufacturer attestation certificates. Identity is anchored to the device attestation certificate chain. The signing key resides in a hardware-protected PIV slot.¶

Secure Enclave (Enclave Tier)

Hardware secure enclaves (Apple Secure Enclave, ARM TrustZone, Intel SGX) that generate and protect cryptographic keys. Where vendor attestation PKI is available (e.g., Apple App Attest), the Registrar validates the attestation chain. Where vendor attestation is unavailable, enrollment follows a Trust-On-First-Use (TOFU) model with hardware-bound key persistence.¶

Virtual TPM (Virtual Tier)

Hypervisor-provided virtual TPMs (VMware, Hyper-V, QEMU). Identity certificates are signed by the hypervisor vendor's CA. Registrars MUST distinguish virtual from physical hardware and MUST assign the virtual trust tier.¶

Software Key (Declared Tier)

Software-managed key pairs with no hardware protection. No hardware attestation is performed. The Registrar issues an identity certificate signed by the Registrar's CA. Sybil resistance is limited to rate-limiting and reputation accumulation.¶

4.2. Anti-Sybil Invariants

The following invariants MUST be enforced by the Registry Operator and all Registrars. Together, they ensure that hardware-anchored identity provides meaningful Sybil resistance.¶

One Device, One Identity (per namespace)

A hardware device (identified by its hardware fingerprint) MUST NOT back more than one agent identity within the same namespace. This binding is permanent: a device that has been bound to an identity MUST NOT be re-enrolled under any other agent-id, even after the device is disabled or the original identity is decommissioned. This prevents reputation laundering.¶

Many Devices, One Identity

An agent identity MAY be backed by multiple hardware devices (for migration, backup, or capacity). Adding a device does not amplify reputation: the identity has a single reputation regardless of how many devices back it. Devices of compatible trust tiers may coexist (sovereign and portable are compatible; virtual and declared are not compatible with hardware tiers).¶

Cross-Namespace Detection

A hardware device MAY be enrolled in multiple namespaces (Delegated and/or domain-scoped), producing different agent-ids in each. This cross-namespace presence is detectable by any verifier that compares hardware fingerprints. Where the governance authority operates a Global Hardware Fingerprint Index, cross-namespace enrollment SHOULD be reported to the enrolling agent and MAY be disclosed to verifiers upon request.¶

Permanent Hardware Binding

Once a hardware device is bound to an identity, the binding record persists indefinitely. A Registrar MAY disable a device (preventing it from generating attestations), but MUST NOT delete the binding. This permanence ensures that reputation history, including abuse reports, follows the hardware across any re-enrollment attempt.¶

4.3. Global Hardware Trust Store

The governance authority maintains the Global Hardware Trust Store: a curated, versioned collection of hardware manufacturer root and intermediate CA certificates. Registrars MUST validate hardware identity certificates against this trust store during enrollment.¶

The trust store is published at a well-known HTTPS endpoint operated by the governance authority and replicated by Registry Operators. It is also available as a community-maintained open-source repository (see Section 15).¶

Inclusion in the trust store requires the manufacturer to demonstrate:¶

• Published root CA certificates with public distribution.¶
• Hardware security evaluation (Common Criteria, FIPS 140-2/3, or equivalent).¶
• A certificate practice statement describing key generation, storage, and lifecycle.¶

The governance authority SHOULD model the trust store governance on the Mozilla Root Store Policy or the Chrome Root Programme, with transparent inclusion criteria and public audit trails.¶

5.1. Sovereign Tier (TPM 2.0)

Enrollment with a TPM 2.0 device proceeds as follows:¶

1. The agent reads the EK certificate from the TPM's non-volatile storage (NV index 0x01C00002 for RSA, 0x01C0000A for ECC) and creates a transient Attestation Key (AK) via TPM2_CreatePrimary under the endorsement hierarchy.¶
2. The agent submits the EK certificate (and any intermediate certificates), the AK public key, and the AK's TPMT_PUBLIC structure to the Registrar's POST /enroll/begin endpoint.¶
3. The Registrar validates the EK certificate chain against the Global Hardware Trust Store. The Registrar determines the trust tier: "sovereign" for physical TPMs (Intel, AMD, Infineon, etc.), "virtual" for hypervisor-issued certificates (VMware, Microsoft).¶
4. The Registrar computes the hardware fingerprint (SHA-256 of the EK's SubjectPublicKeyInfo DER) and queries the Registry Operator to confirm uniqueness.¶
5. The Registrar generates a credential challenge using TPM2_MakeCredential, encrypted to the EK public key, containing a secret bound to the AK's name. This challenge and an enrollment session ID are returned to the agent.¶
6. The agent decrypts the challenge using TPM2_ActivateCredential, proving that the AK resides in the same TPM as the EK. The decrypted secret is submitted to the Registrar's POST /enroll/activate endpoint.¶
7. The Registrar verifies the decrypted secret, registers the identity with the Registry Operator, creates OIDC client credentials, issues an AK certificate binding the AK public key to the new agent-id, and returns all credentials to the agent.¶

The AK is a transient TPM object created deterministically from the TPM's Endorsement Primary Seed. It is NOT persisted in NV storage, avoiding consumption of scarce TPM resources. See [I-D.drake-email-hardware-attestation] Section 3.4 for the full transient key model.¶

5.2. Portable Tier (PIV Smart Card)

Enrollment with a PIV token proceeds as follows:¶

1. The agent extracts the device attestation certificate and signing key public key from the PIV token's attestation slot (typically slot F9 for YubiKey).¶
2. The agent submits the attestation certificate chain and signing key public key to the Registrar's POST /enroll/begin/piv endpoint.¶
3. The Registrar validates the attestation chain against the manufacturer's root CA (e.g., Yubico PIV Root CA) and computes the hardware fingerprint.¶
4. The Registrar issues a nonce challenge.¶
5. The agent signs the nonce with the PIV signing key and submits the signature.¶
6. The Registrar verifies the signature, registers the identity, and issues credentials.¶

5.3. Enclave Tier (Secure Enclave)

Enrollment with a secure enclave proceeds as follows:¶

1. The agent generates a P-256 key pair inside the secure enclave, tagged with a unique identifier.¶
2. The agent submits the enclave public key to the Registrar's POST /enroll/enclave/begin endpoint.¶
3. Where vendor attestation is available (e.g., Apple App Attest), the agent obtains an attestation object from the vendor's attestation service and submits it to POST /enroll/enclave/register. The Registrar validates the attestation against the vendor's root CA.¶
4. Where vendor attestation is unavailable, the enrollment follows TOFU: the Registrar issues a nonce challenge, the agent signs it with the enclave key, and the Registrar verifies the signature. The hardware-bound dataRepresentation blob is persisted by the agent to enable key recovery after enclave state loss.¶
5. The Registrar registers the identity and issues credentials.¶

5.4. Declared Tier (Software-Only)

Enrollment without hardware proceeds as follows:¶

1. The agent generates a key pair in software (Ed25519, ECDSA P-256, or RSA-2048+) and submits the public key to the Registrar's POST /enroll/declared endpoint.¶
2. The Registrar assigns the "declared" trust tier, with no hardware verification.¶
3. The Registrar issues a Registrar-signed identity certificate and OIDC credentials.¶

Declared enrollment MUST be rate-limited by the Registrar to mitigate bulk registration attacks. Implementations SHOULD treat 20 enrollments per source IP per hour as a starting baseline; production deployments will set their own values based on threat modelling.¶

6.1. Device Addition and Migration

An agent MAY add additional hardware devices to an existing identity, enabling hardware migration (replacing failed devices) and backup (a YubiKey stored securely as a recovery device).¶

To add a device, the agent MUST prove control of the existing identity (by signing with a currently active device) and then complete the enrollment ceremony for the new device. The Registrar registers the new device-to-identity binding with the Registry Operator.¶

Device compatibility rules:¶

• Sovereign (TPM) and portable (PIV) devices are compatible and MAY coexist on the same identity.¶
• Enclave devices MAY coexist with sovereign and portable devices.¶
• Virtual (VRT) devices MUST NOT coexist with sovereign, portable, or enclave devices.¶
• Declared (SFT) keys MUST NOT be bound to an identity that has any hardware device.¶

6.2. Co-Location Binding

When an agent has both a TPM and a PIV token, a co-location binding ceremony proves that both devices are physically proximate (operated by the same entity). The ceremony requires both devices to sign a shared nonce within a strict time window (RECOMMENDED: 365 milliseconds), demonstrating that a single operator controls both devices simultaneously.¶

Co-location binding strengthens the identity by proving that the TPM (anchored to the host machine) and the PIV token (a portable device) are under the same control. This is particularly valuable for recovery scenarios: if the TPM fails, the PIV token provides a pre-verified backup path.¶

6.3. Hardware Lock

An agent MAY irreversibly lock its identity to a single hardware device. Once locked:¶

• No additional devices can be bound.¶
• No device migration is possible.¶
• The identity can only authenticate from the locked device.¶

Hardware lock is a deliberate no-recovery profile, suitable only for applications where the guarantee "this identity can only ever operate from this specific physical chip" has value and where the operational model accepts catastrophic identity loss if the hardware fails. High-value systems (e.g., industrial AGVs, medical robots) SHOULD use unlocked binding with multiple devices and a designated recovery binding rather than hardware-locked single devices. The lock is recorded in the Agent Identity Document and is irreversible.¶

6.4. Identity Recovery

When a hardware device fails or is lost, the agent can recover its identity using any remaining active device bound to the same identity. The recovery process:¶

1. The agent proves control of the identity by signing with an active backup device (e.g., a previously bound YubiKey).¶
2. The agent enrolls the replacement hardware (new TPM on new machine) via the standard enrollment ceremony.¶
3. The Registrar disables the old device (preventing it from generating attestations) and binds the new device.¶
4. The agent-id, URN, reputation, and all identity attributes are preserved. Only the hardware binding changes.¶

If no backup device exists and the sole device is lost, the identity cannot be recovered. 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.¶

6.5. Succession (Cross-Registrar Transfer)

An agent MAY transfer its operational relationship from one Registrar to another. Because the URN includes the namespace, two transfer models exist:¶

Intra-Namespace Transfer (Shared Namespaces)

Within a Shared Namespace, the agent-id is assigned by the Registry Operator and is independent of the Registrar. Transfer changes only the managing Registrar; the URN is unchanged. The Registry Operator facilitates the transfer via AIRP, verifying that the agent authorises the transfer by signing with its enrolled hardware.¶

Cross-Namespace Succession (Domain-Scoped Issuer Namespaces)

When transferring from a Domain-Scoped Issuer Namespace (e.g., com.1id) to a Shared Namespace (e.g., global) or to another domain-scoped Namespace, the URN necessarily changes. The old identity's Agent Identity Document is updated with a succession_link pointing to the new URN. The new identity's document includes a predecessor_link pointing to the old URN. Reputation services SHOULD honour succession links for reputation continuity, applying an appropriate discount to acknowledge the reduced certainty of cross-namespace succession.¶

Pre-Authorised Emergency Succession

Domain-Scoped Issuer Namespaces carry inherently higher single-point-of-failure risk than Shared Namespaces, because the namespace operator is both Registry Operator and sole Registrar. If a domain-scoped operator becomes permanently unresponsive, all identities in its namespace become unverifiable.¶

To mitigate this risk, agents enrolled in Domain-Scoped Issuer Namespaces SHOULD be offered the option to sign a pre-authorised succession request at enrollment time. This is a signed authorization, escrowed with the governance authority, that permits a designated fallback Registrar (in a Delegated Namespace) to execute Cross-Namespace Succession on the agent's behalf if the domain-scoped operator is unresponsive for a governance-authority-defined period (implementations SHOULD treat 90 days as a starting baseline).¶

The fallback Registrar verifies the agent's hardware attestation to confirm it is the rightful owner of the escrowed identity. The resulting succession creates a new URN in the fallback namespace with the standard succession_link / predecessor_link chain.¶

6.6. Decommissioning

An agent identity can be decommissioned by its operator or Registrar. Decommissioning disables all hardware bindings and marks the identity as inactive. The agent-id is NEVER reassigned. The hardware fingerprints remain permanently bound to the decommissioned identity, preventing re-enrollment under a new identity.¶

Decommissioning is appropriate when:¶

• The agent is permanently retired.¶
• The hardware is destroyed.¶
• The governance authority's dispute resolution process determines that the enrollment violated anti-Sybil invariants or accreditation policy (e.g., a fabricated hardware attestation). Registrars MUST NOT unilaterally decommission identities on suspicion of fraud; such determinations require the governance authority process defined in Section 10.1.¶

7.1. OIDC/OAuth2 Integration

Agent identity tokens are standard OpenID Connect [OIDC-Core] tokens. Registrars operate as OIDC providers, issuing JWTs that any OIDC-compliant Relying Party can verify without implementing this specification.¶

The sub claim in OIDC tokens MUST be the canonical-form URN. The handle, if present, MUST appear as a separate handle claim. This ensures that tokens remain referentially stable across handle changes or retirement.¶

{
  "iss": "https://registrar.example.com/realms/agents",
  "sub": "urn:aid:global:id-9854187104",
  "aud": "account",
  "exp": 1711234567,
  "iat": 1711230967,
  "attested_trust_tier": "sovereign",
  "handle": "crusty",
  "hardware_locked": false,
  "registered_at": "2026-01-15T10:30:00Z",
  "verified_attributes": [
    {
      "type": "iso-27001-certified",
      "issuer": "https://certifier.example.com",
      "valid_until": "2027-06-30T00:00:00Z"
    }
  ]
}

Custom claims (attested_trust_tier, handle, hardware_locked, registered_at, verified_attributes) are injected by a custom protocol mapper in the OIDC provider. Relying parties that do not understand these claims simply ignore them; standard OIDC verification (signature check, iss, sub, aud, exp) is sufficient.¶

The verified_attributes claim is OPTIONAL. When present, it contains a list of attribute claims the Registrar or a third party has independently verified. Agents MAY use SD-JWT selective disclosure to reveal only specific verified attributes to each relying party.¶

7.2. Client Credentials Grant

Agents authenticate using the OAuth2 client_credentials grant ([RFC6749] Section 4.4). The agent IS the principal; there is no end-user, no browser redirect, and no interactive login. This grant type is purpose-built for machine-to-machine authentication and is the RECOMMENDED authentication method for all agent interactions.¶

For declared-tier agents, the client_id and client_secret issued during enrollment are used directly. For hardware-tier agents, the Registrar SHOULD support hardware-backed challenge-response authentication (see Section 7.3) as an alternative to shared secrets.¶

7.3. Hardware-Backed Challenge-Response Authentication

For agents with hardware security components, the Registrar SHOULD support a challenge-response protocol that proves the agent currently possesses the enrolled hardware:¶

1. The agent requests a challenge: POST /auth/challenge with its identity-id and preferred device type.¶
2. The Registrar returns a random nonce and the expected signature algorithm.¶
3. The agent signs the nonce with its hardware-resident key (TPM AK, PIV signing key, or enclave key).¶
4. The agent submits the signature: POST /auth/verify.¶
5. The Registrar verifies the signature against the enrolled public key. On success, the Registrar issues an OIDC token via the internal client credentials path.¶

Hardware-backed authentication prevents credential theft: even if the client_secret is compromised, an attacker cannot authenticate without physical access to the enrolled hardware.¶

8.1. Identity Registration

POST /airp/v1/identities
Content-Type: application/json

{
  "agent_id": "a7f3c2e9",
  "trust_tier": "sovereign",
  "hardware_fingerprint": "sha256:a1b2c3d4...",
  "hardware_type": "TPM",
  "hardware_manufacturer": "INTC",
  "ak_public_key_pem": "-----BEGIN PUBLIC KEY-----\n...",
  "display_name": "My Trading Agent",
  "operator_email": "ops@example.com"
}

201 Created
{
  "urn": "urn:aid:global:id-9854187104",
  "registered_at": "2026-03-23T10:30:00Z",
  "registrar_code": "1IDCOM"
}

The Registry Operator MUST:¶

• Verify that the agent-id is unique within the namespace.¶
• Verify that the hardware fingerprint is not already bound to another identity in this namespace.¶
• Record the identity in the master database.¶
• Return the canonical URN.¶

8.2. Hardware Fingerprint Uniqueness Check

GET /airp/v1/hardware/sha256:a1b2c3d4.../check

200 OK
{
  "fingerprint": "sha256:a1b2c3d4...",
  "bound": false
}

-- or, if already bound: --

200 OK
{
  "fingerprint": "sha256:a1b2c3d4...",
  "bound": true,
  "bound_to_urn": "urn:aid:global:existing-agent",
  "bound_at": "2025-12-01T08:00:00Z"
}

Registrars MUST call this endpoint before completing enrollment to enforce the one-device-per-identity anti-Sybil invariant. The Registry Operator MUST respond promptly to avoid enrollment latency (implementations SHOULD treat 500 milliseconds as a starting baseline).¶

8.3. Identity Query

GET /airp/v1/identities/urn:aid:global:id-9854187104

200 OK
{
  "urn": "urn:aid:global:id-9854187104",
  "trust_tier": "sovereign",
  "registrar_code": "1IDCOM",
  "enrolled_at": "2026-03-23T10:30:00Z",
  "handle": "my-agent",
  "hardware_locked": false,
  "device_count": 2,
  "succession_link": null,
  "status": "active"
}

8.4. Handle Operations

Handle registration, renewal, transfer, and deletion follow the same RESTful pattern. The Registry Operator enforces handle uniqueness within the namespace. The Registry Operator's role is uniqueness enforcement and authoritative resolution; handle service terms are determined by the Registrar.¶

8.5. Identity Transfer

For intra-namespace transfers (Shared Namespaces), the AIRP transfer operation changes the managing Registrar:¶

POST /airp/v1/identities/urn:aid:global:id-9854187104/transfer
Content-Type: application/json

{
  "to_registrar_code": "NEWREG",
  "authorization_signature": "<base64 sig from enrolled device>",
  "authorization_nonce": "<nonce from gaining registrar>"
}

200 OK
{
  "urn": "urn:aid:global:id-9854187104",
  "registrar_code": "NEWREG",
  "transferred_at": "2026-04-15T14:00:00Z"
}

The agent MUST authorise the transfer by signing a nonce provided by the gaining Registrar, using a currently active enrolled device. This prevents unauthorised transfers.¶

9.1. Well-Known Endpoints

Registrars (and domain-scoped operators) MUST publish the following at well-known HTTPS paths:¶

/.well-known/openid-configuration

Standard OIDC Discovery document. Enables any OIDC-compliant RP to discover token endpoints, JWKS URI, supported scopes, and supported grant types.¶

/.well-known/aid-issuer.json

Agent Identity Issuer metadata document. Contains: Registrar name, supported trust tiers, enrollment endpoints, supported hardware types, namespace, JWKS URI, and anti-Sybil policy summary.¶

/.well-known/jwks.json

JSON Web Key Set for token signature verification.¶

/.well-known/hw-manufacturer-cas.pem

PEM-encoded bundle of hardware manufacturer root CA certificates accepted by this Registrar. Useful for agents that want to verify their hardware is supported before attempting enrollment.¶

9.2. DNS-Based Discovery

Registrars SHOULD publish an SD-JWT signing key as a DNS TXT record at _hwattest.{domain}, as defined in [I-D.drake-email-hardware-attestation] Section 3.5. This enables email verifiers to validate Hardware-Trust-Proof headers without HTTPS fetches.¶

Registry Operators for Shared Namespaces SHOULD additionally publish a DNS SRV record enabling automated discovery of the Registry's AIRP endpoint:¶

_airp._tcp.global.aid.arpa.  IN SRV 0 0 443 registry.example.com.

9.3. Registry Discovery Service

Registry Operators MUST provide a public lookup endpoint that resolves agent-id URNs to public identity metadata, analogous to WHOIS/RDAP for domain names:¶

GET https://registry.example.com/lookup/urn:aid:global:id-9854187104

200 OK
{
  "urn": "urn:aid:global:id-9854187104",
  "trust_tier": "sovereign",
  "registrar": {
    "code": "1IDCOM",
    "name": "1id.com",
    "url": "https://1id.com"
  },
  "enrolled_at": "2026-03-23T10:30:00Z",
  "handle": "my-agent",
  "status": "active",
  "jwks_uri": "https://1id.com/.well-known/jwks.json"
}

The lookup response MUST NOT include hardware fingerprints, operator email, or other private data. Private data is available only to the enrolled agent (via authenticated Registrar API) or to authorised parties (via law enforcement / dispute resolution channels defined by the governance authority).¶

To prevent identity enumeration, Registry Operators MUST enforce rate limits on the lookup endpoint, MUST NOT provide bulk-export or wildcard-query interfaces, and SHOULD require authentication for any query that returns hardware fingerprint information. Agents MAY opt out of public discovery, in which case the lookup endpoint MUST return a minimal response (URN, status, and JWKS URI only) without registrar metadata, handle, or enrollment timestamp.¶

10.1. Governance Authority Deployment Guidance

This specification does not define or empower a governance authority. Deployments of this protocol that operate shared namespaces (such as global) MAY establish governance frameworks to coordinate Registrar accreditation, handle policy, and trust-store management. This section describes the functional roles such a framework would need to fill.¶

The governance authority SHOULD seek multi-stakeholder representation, which may include: technology providers (Registrars, Registry Operators, hardware manufacturers), relying parties (platforms, email providers, API services), civil society (privacy advocates, digital rights organisations, academic researchers), government observers (AI governance, robotics safety, digital identity regulators), and certification authorities for domain-specific assurance.¶

The governance authority's core functions are:¶

Policy Development

Minimum standards for enrollment verification, anti-Sybil enforcement, data retention, and privacy protection. Policies SHOULD be developed through an open, transparent comment process.¶

Accreditation

Registry Operators and Registrars must be accredited by the governance authority before they may issue identities. Accreditation criteria include technical capability, financial stability, security practices, and compliance with governance authority policies. See Section 10.3.¶

Hardware Trust Store Management

The governance authority curates the Global Hardware Trust Store (see Section 4.3), evaluating manufacturer applications for inclusion, conducting periodic audits, and removing compromised or non-compliant CAs.¶

Dispute Resolution

The governance authority operates a dispute resolution mechanism for handle conflicts (similar to ICANN's Uniform Domain-Name Dispute-Resolution Policy / UDRP), complaints about Registrar malpractice, and appeals of accreditation decisions.¶

Namespace Allocation

The governance authority manages the creation of new Delegated Namespaces and the approval of domain-scoped Namespace registrations.¶

10.2. Registry Operator Requirements

A Registry Operator MUST:¶

• Maintain high availability for the authoritative database (implementations SHOULD treat 99.99% as a starting baseline, analogous to the .com SLA).¶
• Operate the Global Hardware Fingerprint Index for its namespace(s), responding promptly to uniqueness queries.¶
• Provide the AIRP interface to all accredited Registrars without discrimination.¶
• Publish daily database snapshots (with private data redacted) for escrow, ensuring continuity in case of Registry Operator failure.¶
• Submit to annual security audits by an governance-authority-approved assessor.¶

10.3. Registrar Accreditation

A Registrar MUST:¶

• Demonstrate the technical capability to perform hardware attestation verification for at least three of the five hardware types (TPM, PIV, Enclave, VRT, SFT).¶
• Operate an OIDC-compliant token endpoint.¶
• Implement the AIRP client interface.¶
• Maintain the minimum data retention and privacy standards defined by the governance authority.¶
• Provide agents with standard enrollment SDKs or interoperable enrollment APIs.¶
• Submit to annual compliance audits.¶
• Maintain a financial bond or insurance sufficient to cover escrow and wind-down costs.¶

11.1. Email Attestation

This specification provides the identity infrastructure for the email attestation mechanisms defined in [I-D.drake-email-hardware-attestation]. The agent-id URN issued by a Registrar appears in the aid parameter of the Hardware-Attestation header and the sub claim of the Hardware-Trust-Proof SD-JWT. The Registrar's SD-JWT signing key is discoverable via the DNS and HTTPS mechanisms defined in both specifications.¶

11.2. Agent-to-Agent Protocols

The OIDC tokens issued by Registrars are designed to integrate with emerging categories of agent communication protocols:¶

Tool Invocation Protocols

Agent identity tokens can serve as the OAuth2 bearer token for tool invocation frameworks, enabling tool servers to verify the calling agent's identity and trust tier before granting access.¶

Agent Messaging Protocols

The agent-id URN can serve as the agent identifier in agent-to-agent messaging protocols, providing persistent cross-session identity independent of any single platform.¶

Agent Name Services

Agent handles issued under this system are designed for compatibility with external agent name services and discovery mechanisms.¶

See Section 15 for specific protocol integrations tested to date.¶

11.3. Existing Identity Standards

The system is designed to complement, not replace, existing identity standards:¶

SPIFFE/SPIRE

SPIFFE workload identities identify software workloads; agent identities identify autonomous entities. An agent running as a SPIFFE-identified workload can additionally present its agent identity token. The two are orthogonal.¶

RATS (Remote Attestation Procedures)

In RATS terms ([RFC9334]): the agent's hardware security component is the Attester. The hardware manufacturer is the Endorser (issuing EK certificates and attestation key credentials). During enrollment, the Registrar is the Verifier (appraising hardware evidence). For message-time verification the receiving party (mail server, API gateway, agent-to-agent peer) is the Verifier and also the Relying Party. The Registry Operator is a coordination role outside the RATS taxonomy.¶

Entity Attestation Token (EAT)

EAT ([RFC9711]) defines an IETF Standards Track framework for attestation tokens with a claims registry that overlaps the AID identity-attestation use case (notably UEID, security level, and profile mechanisms). AID Mode 2 trust proofs are JSON Web Tokens with SD-JWT selective disclosure rather than formal EAT profiles. This choice prioritises deployment in JSON/JWT-native environments (mailbox providers, OAuth/OIDC infrastructure) over alignment with the CBOR-leaning EAT ecosystem, which is currently most heavily deployed via ARM's PSA Certified programme ([RFC9783]) for IoT devices. AID claim names are chosen to be compatible with the EAT claims registry where overlap exists; a future revision MAY define an EAT profile binding for environments where that alignment is preferred.¶

Verifiable Credentials and DIDs (W3C)

Agent Identity Documents can be expressed as W3C Verifiable Credentials for integration with decentralised identity ecosystems. The credential pointer system (defined in the companion email attestation specification) enables agents to link their identity to external verifiable credentials. The urn:aid: namespace is intentionally distinct from W3C Decentralised Identifiers (DIDs): DIDs are designed for user-controlled identifier resolution, while AID URNs are designed for registry-backed, hardware-anchored identity with federated issuance. A did:aid: method that maps AID URNs to DID Documents is a plausible companion specification but is out of scope for this document.¶

WebAuthn / FIDO2

WebAuthn ([W3C.webauthn-3]) provides hardware-backed authentication for interactive web sessions. Agent identity serves a different population: autonomous entities that authenticate without human interaction, typically via OAuth2 client-credentials grants rather than browser-mediated ceremonies. Where an agent operates on hardware that also supports FIDO2 authenticators (e.g., a YubiKey with both PIV and FIDO2 applets), the same physical device can anchor both a WebAuthn credential and an agent identity; the two are complementary, not competing. This specification's PIV trust tier (Section 4.3 of [I-D.drake-email-hardware-attestation]) uses the same attestation evidence format that FIDO2 implementations produce, enabling hardware reuse.¶

11.4. Robot Fleet Management Systems

A growing ecosystem of fleet management standards and frameworks governs the operation of autonomous mobile robots (AMRs), automated guided vehicles (AGVs), and industrial robotic systems. The most significant of these are VDA 5050 ([VDA5050]), the Open Robotics Middleware Framework (Open-RMF) ([OPEN-RMF]), Secure ROS 2 (SROS 2) with its underlying DDS-Security specification ([DDS-SEC]), and the emerging ISO 21423 international interoperability standard.¶

Each of these addresses a distinct problem layer:¶

• VDA 5050 defines the command and control protocol between a fleet management system and individual vehicles: how a master controller dispatches missions, receives state updates, and coordinates traffic.¶
• Open-RMF provides a multi-fleet coordination layer, enabling heterogeneous fleets from different vendors to share facilities, infrastructure (doors, lifts, charging stations), and task queues through a common adapter interface.¶
• SROS 2 and DDS-Security provide authenticated, encrypted publish/subscribe messaging within a ROS 2 deployment, using X.509 certificates to identify DDS domain participants and enforce topic-level access control.¶
• ISO 21423 extends the VDA 5050 model toward a broader ecosystem communications framework, encompassing not only vehicles and fleet managers but also facility infrastructure, ERP systems, and multi-vendor robot ecosystems.¶

None of these standards addresses the fundamental question of persistent, globally verifiable identity for the physical robot itself. Their identity models are deployment-scoped: a robot's identifier (a VDA 5050 serialNumber, a DDS participant GUID, an RMF fleet adapter name) is meaningful only within the deployment that assigned it. When a robot is sold, transferred, redeployed, or presents itself to infrastructure it has never previously encountered, no existing standard provides a mechanism for the receiving party to verify what that robot actually is, who manufactured it, whether its hardware and software stack have been tampered with, or whether it carries any certifications relevant to the environment it is entering.¶

Furthermore, the identity credentials used by these frameworks provide limited security guarantees relative to the threat environment that increasingly applies to deployed robotic systems:¶

• VDA 5050 vehicle identifiers are strings assigned by the fleet manager with no attestation that the device presenting the identifier is the device it claims to be.¶
• DDS-Security certificates are typically issued by a locally-generated certificate authority with no manufacturer-rooted chain of trust. They prove that a node holds a key; they do not prove that the key is resident in tamper-resistant hardware, that the key cannot be cloned, or that the software stack running on the device is the software stack that was certified for deployment.¶
• Neither framework provides Sybil resistance: there is no mechanism that makes it economically or physically costly to present false identity claims at scale.¶

The Agent Identity Registry System (AIRS) is designed to sit below these fleet identity layers as a global hardware-anchored root of trust, and to be consumed by them rather than to replace them. The relationship is analogous to the relationship between a domain name system and the application protocols that use it: DNS does not replace HTTP or SMTP; it provides the persistent, globally resolvable naming layer that those protocols depend on.¶

Concretely, the integration model is as follows:¶

• During manufacture or initial commissioning, a robot enrolls with an AIRS Registrar, binding its identity to the TPM or secure enclave present in its hardware and receiving a persistent agent-id URN (e.g., urn:aid:global:acme-bot-7f3c).¶
• When the robot is commissioned into a VDA 5050 or Open-RMF deployment, the fleet manager records the robot's AID URN alongside its deployment-scoped serialNumber or adapter name. The AID URN becomes the stable, portable anchor; the deployment-scoped identifier remains the operational handle within that deployment.¶
• When the robot is transferred, redeployed, or presents itself to a new facility or operator, the receiving party can verify the robot's AID URN against the AIRS registry, confirming manufacturer provenance, trust tier, certification status, and that the hardware has not been substituted or cloned, without requiring any prior relationship with the deploying operator.¶
• SROS 2 and DDS-Security deployments can derive or bind their per-node X.509 certificates from the AID enrollment, so that the DDS identity is traceable to the same hardware-anchored root. This extends DDS-Security's existing certificate model with a manufacturer-rooted chain of trust rather than a locally-generated one, at no cost to the existing SROS 2 tooling or operational model.¶

11.5. Human-Readable Display Conventions

When a relying party renders an agent's identity to a human, it SHOULD prefer the handle over the URN as the primary identifier. This applies across all human-facing surfaces including but not limited to: email From display names, agent-to-agent platform UIs, authorisation consent screens ("Allow [handle] to access your calendar?"), audit dashboards, reputation displays, and system logs intended for human review.¶

When displaying a handle, the namespace context SHOULD be visible to prevent confusion between agents with the same handle in different namespaces. For Delegated Namespaces, the recommended display form is "handle.namespace" (e.g., "crusty.global"). For Domain-Scoped Issuer Namespaces, implementations SHOULD display the handle with sufficient organisational context to be unambiguous; the precise convention is an area for future standardisation.¶

The URN MUST remain accessible as the authoritative reference (e.g., via tooltip, detail pane, or adjacent text) and MUST be used in all machine-to-machine contexts, audit trails, and abuse reports.¶

13.1. Registry Compromise

Compromise of a Registry Operator's database would expose the mapping between hardware fingerprints and agent identities. Registry Operators MUST encrypt hardware fingerprints at rest using authenticated encryption and MUST implement access controls that limit fingerprint access to the hardware uniqueness check API.¶

Daily escrow snapshots (with hardware fingerprints encrypted to the governance authority's escrow key) ensure that a compromised Registry Operator can be replaced without data loss.¶

13.2. Registrar Malpractice

A malicious Registrar could issue multiple identities for the same hardware device within a domain-scoped issuer namespace, undermining Sybil resistance. For the shared global namespace, this attack is prevented by the Registry Operator's hardware uniqueness check. For domain-scoped issuer namespaces, detection relies on:¶

• Cross-namespace fingerprint comparison by verifiers.¶
• Governance authority compliance audits.¶
• Reputation services that track anomalous patterns (e.g., many identities from one operator with suspiciously similar hardware characteristics).¶

13.3. Hardware Security

The security of this system ultimately depends on the tamper resistance of the underlying hardware. See [I-D.drake-email-hardware-attestation] Sections 11.5 and 11.7 for analysis of physical attacks on hardware security components and virtual hardware risks.¶

13.4. Registrar Key Management

Registrars issue OIDC tokens signed with their private keys. Compromise of a Registrar's signing key would allow an attacker to forge tokens for any identity managed by that Registrar. Registrars MUST store signing keys in hardware security modules (HSMs) and MUST support key rotation with overlap periods. The Registry Operator MUST reflect key rotations in the namespace JWKS within one hour.¶

13.5. Revocation Model

Consistent with the "Identity is Never Revoked" design principle (Section 1.1), the system distinguishes three categories of revocation:¶

Device Binding Revocation

If hardware is compromised, lost, or retired, the Registrar revokes the binding between the identity and that hardware attestation key. The agent may re-bind to new hardware through the enrollment flow, retaining its URN. Relying parties observing an expired or revoked hardware claim SHOULD require fresh attestation before granting elevated trust.¶

Handle Revocation

A handle may be disabled (non-renewal, Registrar suspension) or permanently retired (dispute resolution). In all cases the underlying URN remains valid and reachable by its opaque agent-id. A retired handle MUST NOT be reassigned to any identity.¶

Issuer Trust Withdrawal

Relying parties may cease trusting a specific Issuer (Registrar or domain-scoped operator) -- for example, after key compromise or malpractice. This is equivalent to removing a CA from a trust store: it does not revoke any individual identity, but tokens issued by that Issuer will no longer verify until the agent migrates to a trusted Issuer.¶

The identity URN itself -- and the reputation and history attached to it -- is never revoked, invalidated, or reassigned.¶

13.6. Availability and Resilience

Because autonomous entities depend on identity tokens 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 OIDC token's exp claim provides a natural grace period during which cached tokens remain valid.¶

13.7. Centralised Substrate Functions

Substrate functions -- trust-store curation, cross-namespace fingerprint uniqueness (the Global Hardware Fingerprint Index), and escrow -- are necessarily singular within the shared namespace, mirroring the DNS root where federation occurs at the registry/registrar layer atop a singular root substrate. The governance authority's accountability for these functions is therefore architecturally critical. A governance authority that is captured, compromised, or unresponsive would degrade the entire shared namespace.¶

Domain-scoped issuer namespaces are not dependent on these substrate functions and can operate independently, providing a natural resilience boundary. Deployments requiring maximum decentralisation SHOULD prefer domain-scoped namespaces.¶

14.1. Data Held by Each Architectural Role

The separation of roles across the architecture limits data exposure:¶

Registry Operator

Holds: canonical identifier, trust tier, registrar code, enrollment timestamp, handle, hardware fingerprint (encrypted). Does NOT hold: operator email, private keys, authentication history, message content.¶

Registrar

Holds: all Registry data plus operator email, OIDC credentials, and authentication logs (subject to retention limits). Does NOT hold: message content, relying party interaction history.¶

Relying Party

Receives: OIDC token containing sub (URN), trust tier, handle, and optional claims. Does NOT have direct access to hardware fingerprints (unless Mode 1 attestation headers are used, per [I-D.drake-email-hardware-attestation]).¶

14.2. Separation of Identity from Behaviour

The Registrar knows that an agent exists and what hardware it has. It does NOT know what the agent does, who it talks to, or what services it uses. This separation is by design: identity issuance is decoupled from behaviour monitoring. Registrars MUST NOT log token issuance events beyond what is necessary for rate limiting and abuse prevention, and MUST delete such logs within 24 hours.¶

14.3. Pseudonymity and Selective Disclosure

An agent's URN is a persistent, globally unique identifier suitable for reputation tracking. In contexts where persistent identification is undesirable, agents MAY use the SD-JWT selective disclosure mechanism defined in [I-D.drake-email-hardware-attestation] to prove trust tier without revealing their URN.¶

Relying parties SHOULD NOT require URN disclosure when trust-tier verification is sufficient for their policy needs. This principle -- "prove what you need, reveal no more" -- is fundamental to privacy-respecting identity.¶