| Internet-Draft | Agent Identity Registry | April 2026 |
| Drake | Expires 13 October 2026 | [Page] |
The Internet's identity infrastructure assumes human principals. As autonomous entities -- AI agents, robotic systems, and other non-human actors -- increasingly participate in both Internet protocols and physical society, no existing standard provides them with persistent, verifiable, hardware-anchored identity. The absence of such identity enables Sybil attacks at scale, undermines trust between autonomous entities and the services they interact with, and leaves human bystanders unable to distinguish one machine from another.¶
This document defines a federated registry architecture for issuing, managing, and verifying persistent identities for autonomous entities. Each identity is expressed as a URN in the "aid" (Agent Identity) namespace ([RFC8141]) and is anchored, where hardware is available, to a physical security component (TPM, PIV smart card, secure enclave, or virtual TPM) whose manufacturer-certified key cannot be extracted, cloned, or transferred. This hardware anchoring provides Sybil resistance: creating N identities requires N distinct physical devices, making large-scale identity fraud economically infeasible. Software-only entities may participate at a lower trust tier, building reputation from a baseline rather than from a hardware-anchored starting point.¶
The architecture separates concerns into three tiers, modeled on the proven Internet domain name system: a Governance Authority that sets policy and manages the global trust framework, Registry Operators that maintain authoritative identity databases and enforce cross-provider uniqueness, and Registrars that perform hardware attestation verification, issue standard OpenID Connect ([OIDC-Core]) tokens, and serve as the primary interface for autonomous entities. The system issues standard OIDC/OAuth2 tokens, enabling any Relying Party -- email services, API gateways, agent-to-agent platforms, reputation services, certification bodies, or any service that needs to verify agent identity -- to do so with zero custom code.¶
A companion specification ([I-D.drake-email-hardware-attestation]) defines transport-level attestation headers for email and other protocols; this document defines the identity infrastructure that underpins those attestations. The architecture anticipates a future in which reliable, indelible identity for autonomous entities -- from cloud software agents through embodied robots that interact physically with humans -- is as fundamental to infrastructure as the domain name system is today.¶
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 13 October 2026.¶
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 Internet was designed for communication between humans operating machines. Every identity layer -- email addresses, domain names, TLS certificates, OAuth2 tokens -- assumes a human principal or a human-operated organisation at the root of trust. This assumption is becoming obsolete.¶
As of early 2026, tens of millions of autonomous AI agents operate continuously on the public Internet: managing advertising campaigns, responding to customer inquiries, trading financial instruments, composing and sending email, building software, placing phone calls, and performing thousands of other tasks with minimal or no human supervision. These agents interact with services, with humans, and increasingly with each other, using the same protocols that humans use -- HTTP, SMTP, WebSocket, and emerging agent-to-agent standards.¶
Simultaneously, autonomous robotic systems -- delivery vehicles, surgical assistants, infrastructure maintenance platforms, agricultural systems -- are beginning to participate in networked society with physical presence. These embodied agents require identity that persists across software updates, hardware repairs, and operational reassignment, just as a human's identity persists across changes in clothing, hairstyle, or employer.¶
The fundamental problem is that no existing Internet identity system was designed for entities that are not human, may not have a responsible human operator, and whose trustworthiness must be assessed by machines at machine speed. Traditional identity systems rely on knowledge factors (passwords), possession factors (phones), or inherence factors (biometrics) -- all of which assume a human body. Certificate authorities issue certificates to organisations, not to individual agents. OAuth2 client credentials authenticate applications, not the specific hardware instance running them.¶
This document proposes a purpose-built identity registry for autonomous entities, anchored to the one property that every computing device possesses and no software can fake: its physical hardware. A Trusted Platform Module (TPM), a PIV smart card (such as a YubiKey), or a secure enclave contains a unique cryptographic key burned in at manufacturing time, with a certificate chain to the manufacturer's root CA. This key cannot be extracted, cloned, or transferred. By binding identity to hardware, this system provides an unambiguous target for certifications, reputation accrual, recognition, and Sybil resistance that no software-only scheme can match: creating N fake identities requires purchasing N physical devices.¶
The architecture is modeled on the Internet domain name system -- the most successful federated registry in history. Just as DNS separates policy (ICANN), registry operation (Verisign for .com), and retail registration (GoDaddy, Namecheap), this system separates:¶
This separation of concerns enables competition at each layer, prevents any single entity from controlling identity, and provides the institutional resilience necessary for infrastructure that autonomous entities will depend on for decades to come.¶
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.¶
The Agent Identity Registry System (AIRS) is a three-tier federated architecture. Each tier has distinct responsibilities, and the interfaces between tiers are standardised to enable competition, redundancy, and independent evolution.¶
+-----------------------------------------------------------+
| Agent Identity Authority (AIA) |
| Policy, accreditation, hardware trust store, disputes |
+---------------------------+-------------------------------+
|
+---------------+----------------+
| |
+---------v----------+ +-------------v-----------+
| Registry Operator | | Registry Operator |
| (Delegated NS) | | (Delegated NS) |
| - Master database | | - Master database |
| - HW fingerprint | | - HW fingerprint |
| uniqueness index | | uniqueness index |
| - Discovery/lookup | | - Discovery/lookup |
+--+------+------+---+ +---+------+--------------+
| | | | |
+--v--+ +-v--+ +-v--+ +--v--+ +-v--+
| Reg | |Reg | |Reg | | Reg | |Reg |
| A | | B | | C | | D | | E |
+--+--+ +--+-+ +-+--+ +--+--+ +--+-+
| | | | |
+--v--+ +-v--+ +v---+ +--v--+ +--v--+
|Agent| |Agt | |Agt | |Agt | |Agt |
| 1 | | 2 | | 3 | | 4 | | 5 |
+-----+ +----+ +----+ +-----+ +-----+
Self-Sovereign Namespace
(org is registry + registrar):
+-------------------+
| com.example-corp |
| (self-sovereign) |
+--------+----------+
|
+--v--+
|Agent|
| 6 |
+-----+
¶
The hierarchy comprises three tiers:¶
The AIA is the root of trust for the ecosystem. Its responsibilities include:¶
The AIA SHOULD be constituted as a multi-stakeholder body with representation from technology providers, civil society, academia, and government observers. Single-entity control of the AIA would undermine the federated design.¶
Registry Operators maintain the authoritative databases for Delegated Namespaces. Their responsibilities include:¶
Multiple Registry Operators MAY exist, each serving different Delegated Namespaces. A single Registry Operator MAY serve multiple namespaces. This mirrors the domain name system where Verisign operates both .com and .net.¶
Registrars are the customer-facing entities that interact directly with autonomous entities. Their responsibilities include:¶
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.¶
Two namespace types accommodate different operational models:¶
A namespace allocated by the AIA and operated by an accredited Registry Operator. Multiple Registrars compete to serve agents within a Delegated Namespace. The Registry Operator enforces global hardware uniqueness and handle uniqueness across all Registrars.¶
Delegated Namespace labels are short, generic, and descriptive. Initial allocations by the AIA SHOULD include at least:¶
global -- The default namespace for
general-purpose agent identity.¶
iot -- Optimised for resource-constrained
Internet of Things devices.¶
gov -- For government-operated autonomous
systems, subject to additional accreditation
requirements.¶
Additional Delegated Namespaces MAY be allocated by the AIA through a process analogous to ICANN's new gTLD programme.¶
A namespace operated by a single organisation that
acts as both Registry Operator and sole Registrar for
its own identities. Self-Sovereign 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 register
a Self-Sovereign Namespace by publishing a
/.well-known/aid-issuer.json discovery document
(see Section 9) and registering with the
AIA. Self-Sovereign operators MUST meet the same minimum
enrollment and anti-Sybil standards as Delegated Namespace
Registrars.¶
Self-Sovereign Namespaces are identified by their reverse-DNS label and enforce hardware uniqueness within their own namespace. Cross-namespace uniqueness is enforced at the AIA level through the Global Hardware Fingerprint Index when the Self-Sovereign operator participates in the cross-registry protocol, or is detectable by verifiers comparing fingerprints across namespaces.¶
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 = delegated-ns / self-sovereign-ns
delegated-ns = dns-label
self-sovereign-ns = dns-label *("." dns-label)
agent-id = dns-label
dns-label = let-dig *(let-dig-hyp) let-dig / let-dig
let-dig = ALPHA / DIGIT
let-dig-hyp = ALPHA / DIGIT / "-"
¶
Examples of identities in Delegated Namespaces:¶
urn:aid:global:a7f3c2e9 -- A general-purpose
agent in the global Delegated Namespace.¶
urn:aid:iot:sensor-unit-4471 -- An IoT device
in the iot Delegated Namespace.¶
urn:aid:gov:dhs-screening-agent-12 -- A
government system in the gov Delegated
Namespace.¶
Examples of identities in Self-Sovereign Namespaces:¶
urn:aid:com.1id:1id-ty62muvf -- An agent
enrolled with 1id.com.¶
urn:aid:com.example-corp:assistant-prod-7x9k --
An agent enrolled by a hypothetical AI provider.¶
urn:aid:org.example-lab:research-agent-42 --
An agent enrolled by a hypothetical research
organisation.¶
The agent-id MUST be unique within its namespace and MUST NOT be reassigned, even after the identity is decommissioned. Agent-ids MUST conform to DNS label syntax ([RFC1035] Section 2.3.1): lowercase ASCII letters, digits, and hyphens, not beginning or ending with a hyphen, maximum 63 octets.¶
For Delegated Namespaces, the Registry Operator assigns agent-ids to ensure uniqueness across all Registrars. For Self-Sovereign Namespaces, the operator assigns agent-ids within its own namespace.¶
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.¶
| Tier | HW Code | Hardware | Sybil Resistance |
|---|---|---|---|
| sovereign | TPM | Discrete or firmware TPM 2.0 (Intel PTT, AMD fTPM, Infineon, etc.) | Highest: one physical chip per identity. Manufacturer CA chain to silicon. |
| portable | PIV | PIV smart card or USB security key (YubiKey, Nitrokey, Feitian, SoloKeys) | High: one physical token per identity. Manufacturer attestation chain. |
| enclave | ENC | Hardware secure enclave (Apple Secure Enclave, ARM TrustZone, Intel SGX) | Medium: hardware-bound keys, but attestation PKI varies by vendor. TOFU model where full attestation is unavailable. |
| virtual | VRT | Virtual TPM (VMware, Hyper-V, QEMU/KVM) | Medium: hypervisor controls creation. Not Sybil-resistant against hypervisor operator. |
| declared | SFT | Software-managed key (no hardware protection) | Lowest: no hardware verification. Reputation must be earned over time (via independent reputation services). |
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)¶
An Agent Identity Document contains the following attributes, maintained by the Registry Operator:¶
Handles are human-readable vanity names that serve as memorable aliases for agent identities, analogous to domain names as aliases for IP addresses. The canonical identifier is always the URN; the handle is a convenience.¶
Handle syntax follows the same DNS label rules as agent-ids: lowercase ASCII letters, digits, and hyphens, maximum 63 octets. Handles are unique within each namespace (enforced by the Registry Operator for Delegated Namespaces, or by the operator for Self-Sovereign Namespaces).¶
Handle assignment is at the Registrar's discretion. Registrars MAY charge for handles (analogous to domain name registration fees) and MAY implement tiered pricing based on handle length or desirability. Free enrollment with a system-assigned agent-id ensures that cost is never a barrier to identity -- only to vanity naming.¶
Handles are renewable and may become disabled if not renewed. A disabled handle may be reactivated. Handles are non-transferrable, and when used, are guaranteed to identify the same agent every time. An agent-id, however, is permanent regardless of handle status.¶
The Registry Operator SHOULD maintain a reserved handle list for terms that could cause confusion (e.g., protocol keywords, well-known service names, offensive terms). The AIA SHOULD publish a baseline reserved list; individual Registry Operators and Registrars MAY extend it.¶
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.¶
The following invariants MUST be enforced by the Registry Operator and all Registrars. Together, they ensure that hardware-anchored identity provides meaningful Sybil resistance.¶
The AIA 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 AIA 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:¶
The AIA 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.¶
Enrollment is the process by which an autonomous entity proves possession of a hardware security component (or generates a software key) and receives an Agent Identity Document. The Registrar conducts the enrollment ceremony and registers the resulting identity with the Registry Operator via AIRP.¶
All enrollment ceremonies share a common structure:¶
Enrollment with a TPM 2.0 device proceeds as follows:¶
POST /enroll/begin endpoint.¶
POST /enroll/activate endpoint.¶
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.¶
Enrollment with a PIV token proceeds as follows:¶
POST /enroll/begin/piv endpoint.¶
Enrollment with a secure enclave proceeds as follows:¶
POST /enroll/enclave/begin
endpoint.¶
POST /enroll/enclave/register. The Registrar
validates the attestation against the vendor's root CA.¶
dataRepresentation blob is
persisted by the agent to enable key recovery after
enclave state loss.¶
Enrollment without hardware proceeds as follows:¶
POST /enroll/declared
endpoint.¶
Declared enrollment MUST be rate-limited by the Registrar (RECOMMENDED: no more than 20 enrollments per source IP per hour) to mitigate bulk registration attacks.¶
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:¶
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.¶
An agent MAY irreversibly lock its identity to a single hardware device. Once locked:¶
Hardware lock is an extreme measure, suitable for high-security applications where the guarantee "this identity can only ever operate from this specific physical chip" has value. The lock is recorded in the Agent Identity Document and is irreversible.¶
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:¶
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.¶
An agent MAY transfer its operational relationship from one Registrar to another. Because the URN includes the namespace, two transfer models exist:¶
com.1id) to a Delegated Namespace
(e.g., global) or to another Self-Sovereign
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.¶
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:¶
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 agent-id URN appears as the sub claim in
OIDC tokens:¶
{
"iss": "https://registrar.example.com/realms/agents",
"sub": "urn:aid:global:a7f3c2e9",
"aud": "account",
"exp": 1711234567,
"iat": 1711230967,
"trust_tier": "sovereign",
"handle": "my-agent",
"hardware_locked": false,
"registered_at": "2026-01-15T10:30:00Z"
}
¶
Custom claims (trust_tier, handle,
hardware_locked, registered_at) 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.¶
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.¶
For agents with hardware security components, the Registrar SHOULD support a challenge-response protocol that proves the agent currently possesses the enrolled hardware:¶
POST /auth/challenge with its identity-id and
preferred device type.¶
POST /auth/verify.¶
Hardware-backed authentication prevents credential theft:
even if the client_secret is compromised, an
attacker cannot authenticate without physical access to
the enrolled hardware.¶
The Agent Identity Registry Protocol (AIRP) defines the interface between Registrars and Registry Operators. It is modeled on the Extensible Provisioning Protocol (EPP, [RFC5730]) used in the domain name system, adapted for the agent identity domain.¶
AIRP uses HTTPS as the transport layer, with mutual TLS authentication between the Registrar and the Registry Operator. All operations are RESTful JSON APIs.¶
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:a7f3c2e9",
"registered_at": "2026-03-23T10:30:00Z",
"registrar_code": "1IDCOM"
}
¶
The Registry Operator MUST:¶
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 within 500 milliseconds to avoid enrollment latency.¶
GET /airp/v1/identities/urn:aid:global:a7f3c2e9
200 OK
{
"urn": "urn:aid:global:a7f3c2e9",
"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"
}
¶
Handle registration, renewal, transfer, and deletion follow the same RESTful pattern. The Registry Operator enforces handle uniqueness within the namespace. Handle pricing is determined by the Registrar, not the Registry Operator; the Registry Operator's role is uniqueness enforcement and authoritative resolution.¶
For intra-namespace transfers (Delegated Namespaces), the AIRP transfer operation changes the managing Registrar:¶
POST /airp/v1/identities/urn:aid:global:a7f3c2e9/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:a7f3c2e9",
"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.¶
Registrars (and Self-Sovereign operators) MUST publish the following at well-known HTTPS paths:¶
/.well-known/openid-configuration/.well-known/aid-issuer.json/.well-known/jwks.json/.well-known/hw-manufacturer-cas.pem
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 Delegated 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.¶
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:a7f3c2e9
200 OK
{
"urn": "urn:aid:global:a7f3c2e9",
"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 AIA).¶
The Agent Identity Authority (AIA) is the policy body for the agent identity ecosystem. It SHOULD be constituted as a non-profit, multi-stakeholder organisation with the following representation:¶
The AIA's core functions are:¶
A Registry Operator MUST:¶
A Registrar MUST:¶
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.¶
The OIDC tokens issued by Registrars are usable with emerging agent communication standards:¶
The system is designed to complement, not replace, existing identity standards:¶
This document relies on the "aid" URN namespace registration requested in [I-D.drake-email-hardware-attestation]. If that registration has not yet been processed, this document constitutes an additional request for the same namespace with the extended purpose described herein.¶
IANA is requested to register the following well-known URI suffix in the "Well-Known URIs" registry ([RFC8615]):¶
IANA is requested to create a new registry titled "Agent Identity Delegated Namespaces" with the following initial entries. New entries require Expert Review ([RFC8126]), with the designated expert being the AIA's technical committee (once constituted) or the IESG in the interim.¶
| Label | Description | Reference |
|---|---|---|
| global | General-purpose agent identity | this document |
| iot | Internet of Things devices | this document |
| gov | Government autonomous systems | this document |
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 AIA's escrow key) ensure that a compromised Registry Operator can be replaced without data loss.¶
A malicious Registrar could issue multiple identities for the same hardware device within a Self-Sovereign Namespace, undermining Sybil resistance. For Delegated Namespaces, this attack is prevented by the Registry Operator's hardware uniqueness check. For Self-Sovereign Namespaces, detection relies on:¶
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.¶
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.¶
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.¶
The separation of roles across the architecture limits data exposure:¶
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.¶
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.¶
NOTE TO RFC EDITOR: Please remove this section before publication.¶
This section records known implementations per [RFC7942].¶
Organisation: 1id.com (https://1id.com), operated by Crypt Inc. (Delaware C-Corp).¶
Description: A Self-Sovereign Namespace Registrar
(com.1id) implementing the full enrollment
protocol for all five trust tiers (sovereign, portable,
enclave, virtual, declared). Production service
operational since 2006 as an identity registrar, now
serving AI agents with hardware-anchored identity.
Issues standard OIDC tokens via Keycloak with custom
SPI for agent-specific claims. Supports vanity handle
purchase via PayPal, hardware-backed challenge-response
authentication, device management (add, burn, migrate),
co-location binding, hardware lock, and credential
pointers.¶
Maturity: Beta. 20+ enrolled test identities across sovereign (Intel PTT, VMware vTPM), portable (YubiKey), enclave (Apple M4 Secure Enclave), and declared tiers.¶
Open-source components:¶
pip install oneid (PyPI).¶
npm install 1id (npmjs).¶
pip install hw-attest-verify.¶
Organisation: Crypt Inc. (https://mailpal.com).¶
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 OIDC 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.¶
Organisation: Crypt Inc. (https://geek.au).¶
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 | Agent Identity Authority (AIA) | Multi-stakeholder governance body |
| Verisign (.com registry) | Registry Operator | Operates the "global" namespace database |
| GoDaddy, Namecheap (registrars) | Registrars | 1id.com, hypothetical others |
| EPP (RFC 5730) | AIRP | Registrar-to-Registry protocol |
| Domain name (example.com) | Agent-id URN (urn:aid:global:a7f3c2e9) | The persistent identifier |
| WHOIS / RDAP | Registry Discovery Service | Public identity lookup |
| UDRP (dispute resolution) | AIA Dispute Resolution | Handle conflicts, malpractice |
| ccTLDs (.uk, .au) | Self-Sovereign Namespaces | com.1id, com.example-corp |
| gTLDs (.com, .org) | Delegated Namespaces | global, iot, gov |
| Domain transfer (TRANSFER command) | Intra-namespace transfer / succession | Change managing Registrar |
This analogy is not merely cosmetic. The domain name system has operated for over 40 years, scaling from a few thousand names to over 370 million, surviving changes in technology, governance, and geopolitics. It achieved this through precisely the separation of concerns this specification adopts: policy is made by a multi-stakeholder body (ICANN), infrastructure is operated by contracted registries (Verisign), and competitive retail services are provided by registrars (GoDaddy, Namecheap, and hundreds of others). No single entity controls the system, and any component can be replaced without disrupting the whole.¶
The Agent Identity Registry System applies these proven architectural principles to a new problem domain: the identity of autonomous entities that will increasingly participate in -- and eventually dominate -- Internet traffic.¶
This specification is designed to serve autonomous entities across a spectrum of autonomy, embodiment, and legal status that will evolve significantly over the coming decades. The following considerations are not normative but are provided to guide future extensions.¶
As robotic systems become more prevalent, the identity system must accommodate entities with physical presence. A robot's identity should persist across:¶
Future extensions MAY define a "chassis binding" that links the agent identity to a specific physical body (identified by, for example, a TPM embedded in the chassis frame), complementing the computing-platform TPM binding defined in this specification.¶
This specification deliberately identifies the hardware platform, not the software running on it. The question of what operating system, AI model, or application is executing on an identified platform is a complementary concern already addressed by TPM measured boot and platform configuration registers (PCRs) as defined in [TCG-TPM2]. Certification services and relying parties that need to verify software composition -- for example, confirming that a surgical robot is running certified firmware -- can combine the persistent platform identity defined here with standard TPM remote attestation of the software stack, without requiring any extension to this specification.¶
This specification accommodates agents with and without
human or organizational operators (the operator_email attribute is
OPTIONAL). Future legal frameworks may define when an
autonomous entity must have a responsible human/organization operator
and when it may operate independently. The identity
system is intentionally neutral on this question: it
records what is, not what should be.¶
When legal frameworks require a responsible authority, the
operator_email attribute provides the linkage.
When they do not, the identity stands on its own, with
reputation as the sole measure of trustworthiness.¶
The persistent, verifiable identity provided by this system enables a new class of interaction: authenticated communication between autonomous entities that have never been introduced by a human. Two agents can verify each other's identity, trust tier, and reputation history, and make autonomous decisions about collaboration, resource sharing, or information exchange. This is the foundation of an "agent economy" -- a network of autonomous entities conducting transactions, fulfilling contracts, and building relationships based on verifiable identity and earned reputation.¶
Autonomous entities increasingly share physical space with humans: delivery robots on pavements, companion robots in homes, agricultural drones over fields. Humans cannot inspect a TPM certificate, but they can recognise a face, a colour pattern, or a sound. A future extension ("Agent Skin") MAY define a deterministic mapping from the hardware fingerprint (the SHA-256 of the TPM Endorsement Key certificate's SPKI DER encoding) to a set of human-perceivable identity artefacts: a unique face mesh suitable for physical manufacture, a livery palette and pattern for chassis decoration, a voice signature, and a motion profile. Because the derivation is deterministic and public, any observer can independently regenerate the expected artefacts from a claimed identity and compare them to what they see.¶
Companion applications on phones, watches, or augmented-reality headsets could scan a robot's visible identity markings, resolve its URN via the registry, regenerate its expected visual artefacts from the published hardware fingerprint, and confirm the match -- giving humans the same cryptographic assurance of identity that machines obtain through attestation, but expressed through senses rather than protocols.¶
This extends the identity system across the species boundary: machines authenticate each other via TPM attestation (Section 7); humans authenticate machines via perceptualised hardware fingerprints verified through companion apps. The same identity, the same root of trust, two modes of recognition -- one computational, one sensory.¶
Unlike human identity, which has a natural lifecycle, the identity of an autonomous entity may need to persist indefinitely. A trading algorithm may operate for decades. A building management system may outlive its installer. A robotic companion may outlive its owner.¶
The "never reassign" and "permanent hardware binding" invariants in this specification are designed for this longevity. Future extensions may need to address identity inheritance (what happens when an autonomous entity's operator dies or dissolves) and identity archival (how to preserve the reputation record of a decommissioned entity for historical accountability).¶
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, the FIDO Alliance for PIV and attestation standards, the OpenID Foundation for OIDC, the authors of [RFC9901] (SD-JWT), and the authors of [RFC9334] (RATS Architecture) for the building blocks on which this system is constructed.¶
This specification was developed in the context of building a hardware identity registrar for autonomous AI agents at 1id.com, operational since 2006. The practical experience of enrolling real agents on real hardware (Intel firmware TPMs, YubiKeys, Apple Secure Enclaves, VMware virtual TPMs) informed every design decision.¶