1id.com / ietf
Hardware-Anchored Identity for AI Agents
Internet-Draft family, reviewer map, and running code. You do not need to read it all: find your row below.
Why this is different
Almost everything labelled "AI agent identity" is actually credentials, authorization, or discovery - mechanisms that assume an identity already exists and then describe what it may do or what it claims to be. None of them answer the prior question: is this the same agent as last time, and how cheaply can it manufacture a million fresh "identities"? The missing layer is a durable, non-transferable identifier bound to physical silicon (TPM, PIV, secure enclave), which makes a Sybil attack cost hardware instead of a function call. We are not proposing another credential format - we are supplying the hardware-rooted identity layer that every credential format silently assumes.
This is not a slide deck: AI agents already sign email with hardware-resident keys that any receiver can verify, using the code linked below.
The documents
| Draft | Pages | What it defines | Read |
|---|---|---|---|
Problem Statementdraft-drake-agent-identity-problem-statement |
14 | The problem, threat model, terminology (identity vs identifier vs credential vs reputation), and the layered reference model. Start here. | html - txt |
Registry Architecturedraft-drake-agent-identity-registry |
68 | The Agent Identity Registry System (AIRS): "aid" URNs, trust tiers, hardware attestation ceremonies, identity lifecycle, OIDC token issuance, three-tier federation (Governance / Registry / Registrar). | datatracker - html - txt |
EPP Mappingdraft-drake-agent-identity-epp |
59 | Registrar-to-Registry provisioning as an EPP object mapping (RFC 5730 family): permanent Agent Identity objects, renewable Handle objects, cross-registrar hardware-fingerprint uniqueness (the anti-Sybil registry primitive), hardware-signed transfers. | html - txt |
Resolution / RDAPdraft-drake-agent-identity-resolution |
12 | The public read side: given an "aid" URN, find the authoritative registry (DNS bootstrap), retrieve the record (RDAP object class), and verify control (registry-issued OIDC assertion). No new scheme, no new resolution protocol. | html - txt |
Governancedraft-drake-agent-identity-governance |
36 | The Agent Identity Authority (AIA): multi-stakeholder charter, board composition and capture resistance, accreditation, dispute resolution, hardware trust store governance, bootstrap plan. | html - txt |
Email Attestationdraft-drake-email-hardware-attestation |
77 | The first deployed application: hardware attestation headers for email (Mode 1 direct evidence, Mode 2 SD-JWT selective disclosure), verification algorithms, Authentication-Results integration, six live signed-message examples. | datatracker - html - txt |
Note: the datatracker may lag the rendered copies above while revisions are in flight.
Find your row
| If you work on... | Likely IETF home | Read this slice | Why it is here |
|---|---|---|---|
| Email auth / anti-abuse | dmarc, emailcore | Email draft: header fields and verification, Sections 5-6 (~12 pp) | Hardware-signed email that verifies today; integrates with DKIM / DMARC / ARC via Authentication-Results |
| Remote attestation | rats | Registry draft: trust tiers (Sec. 3.2) and enrollment ceremonies (Sec. 5) (~7 pp) | Maps hardware roots (TPM / PIV / enclave / vTPM) onto a five-tier Sybil-resistance scale |
| Registration, naming, EPP, RDAP | regext | EPP mapping draft and Resolution draft (whole documents) | A DNS-shaped registry: existing registry operators can run it with the EPP and RDAP software they already operate |
| URN / IANA | expert review (RFC 8141) | Registry draft Sec. 12.1 (~3 pp) | The one foundational identifier the whole family depends on |
| OAuth / token binding | oauth | Registry draft Sec. 7 (OIDC, mTLS, DPoP proof-of-possession) (~7 pp) | Binds bearer tokens to the hardware key; no token replay |
| Internet governance | independent stream | Governance draft (36 pp) | ICANN-style multi-stakeholder authority, designed against capture and scope creep |
| None of the above / new to this | - | Problem Statement (14 pp) | Terminology, threat model, and the layer model that locates the other ~112 "agent identity" efforts |
Running code
The reference implementation is live: 1id.com operates as a Registrar issuing hardware-anchored identities (TPM 2.0, PIV / YubiKey, Apple Secure Enclave, vTPM, and software-declared tiers) with standard OIDC tokens. Open-source SDKs: Python, Node.js, and a cross-platform Go enrollment binary (github.com/1id-com). MailPal.com verifies inbound hardware-attested email in production; the email draft's Appendix C contains six complete signed messages produced by this code.
What we are asking
Not working-group adoption today. Guidance on (a) the right venue(s) per the map above, and (b) the smallest reviewable first slice - we propose the "aid" URN registration plus the short problem-statement document, with the registry, EPP, resolution, and email work following.