Two answers to agent identity: AIRS and the RTTP/IQA design
Sources cited in this piece · the AIRS draft, full text: draft-drake-agent-identity-registry-05 · its document page: IETF Datatracker · third-party coverage: Boston Identity research note · our design, full text: draft-li-rttp-iqa-addressing-01 · Sister pillars: RTTP (rttp://, CRI 27) · IQA (iqa://, CRI 28)
The IETF queue gained a full series of Internet-Drafts on agent identity this month, and the most complete of them is the Agent Identity Registry System — AIRS, revision -05, dated 27 October 2026, carried by companion drafts on the problem statement, governance, provisioning, and resolution. It is an individual submission, experimental, and it deserves a careful read: AIRS is the most fully worked-out registry-based answer to the question our two pillars answer, and the two designs are at their clearest when read side by side. This piece is that side-by-side.
What AIRS builds
AIRS models agent identity on the oldest successful infrastructure pattern there is: a registry. Its abstract states the shape plainly — "a federated architecture that gives the durable identity0 of an autonomous entity a permanent canonical identifier, maintains an authoritative record about that identity, binds proof of control to enrolled anchors, and issues credentials that relying parties can verify." Federation sits at the Registrar layer, with "many accredited Registrars" competing to enroll agents, while the uniqueness substrate does not federate at all: "one authoritative global namespace is required," so the Registry Operator is "singular but not unaccountable," replaceable from escrow under governance oversight.
The design is at its most interesting where it spends its hardware. At the sovereign and portable assurance tiers, "each independently accepted identity requires its own manufacturer-attested physical anchor, and each accepted anchor backs at most one identity" — identities at these tiers "cost scarce physical units rather than software operations," which is an anti-sybil argument made in silicon. On top of the permanent canonical identifier sit optional human-readable handles, governed the way domain names wish they were governed: never transferred, and in a dispute the only remedy is permanent retirement of the handle, which "removes any profit in speculative squatting."
What the two pillars build
Our design starts one step earlier and refuses the registry altogether. RTTP (rttp://) derives addresses from the authority's own canonical bytes — the address is a function, SHA-256 truncated, so anyone can recompute it and no operator is needed to mint it. IQA (iqa://) is the verification answer that says whether the claimant currently stands. The slogan has been on our pages from the start: hash names, attestation vouches. The name is math; the trust is fresh.
The second half of the design is what replaces a permanent record: standing is leased, not owned. A verification answer carries its own lease_expiry in the answer itself, current deployments use a 120-second window, and the reasons a later verification can return form a closed vocabulary fixed in the document — including authority_revoked. If the authority is unreachable, the answer fails closed. Nothing persists by default; everything persists only as long as its lease, and every renewal is a fresh claim that must re-earn itself.
The fork, row by row
| AIRS (draft-drake-agent-identity-registry-05) | RTTP + IQA | |
|---|---|---|
| Where the name comes from | allocated by the Registry Operator at enrollment | derived — a function of the authority's canonical bytes |
| Who can obtain one | an agent enrolled through an accredited Registrar, evidence verified | anyone, by computing it — there is no gate to pass |
| Hardware | physical anchor required at sovereign/portable tiers; one identity per anchor | none; the check is cryptographic, not physical |
| Expiry | identity0 never expires; credentials and handles rotate | standing is leased; 120 s in current deployments, configurable |
| Revocation | no administrative kill switch; voluntary decommissioning with signature and challenge | closed refusal vocabulary at the next verification; fail-closed when unreachable |
| History | permanent record, never reassigned or erased | addresses re-derivable forever; vouching always fresh |
| Status | Experimental I-D, individual submission | I-D via the ISE channel; IANA provisional CRI 27 / CRI 28 |
The deepest disagreement: what an identity is
Strip the machinery away and the two designs converge on something neither camp planned to concede to the other: a meaningless, permanent identifier. AIRS insists the canonical identifier "MUST NOT be retired, reassigned, or transferred under any circumstance," and its handles exist precisely so that humans never have to speak the meaningless form. Our derived address is meaningless for the same reason — it is a hash, so it carries no vanity and no policy, only a lineage back to the authority's bytes. Convergence here is worth noticing: both camps believe accountability needs a name that outlives every credential.
The fork is in what produces that name. AIRS allocates it — an operator mints it at enrollment, registrars verify the evidence, and the whole architecture's guarantees are only as strong as the governance that accredits them. We derive it — the bytes produce the name, and the only thing to trust is the hash. Allocation asks: do you trust the operator? Derivation asks: can you recompute the function? Those are different questions, and they fail differently — an operator can be captured, pressured, or replaced; a hash function cannot be asked to change its mind about your bytes.
Two rejections of the same switch
The most striking agreement is a shared refusal. AIRS devotes a named design principle to it: "No Administrative Identity Kill Switch — No protocol role is granted authority to erase, reassign, or administratively revoke identity0 or its canonical record." The only way an identity ends is voluntary decommissioning, signed by a currently active binding over a decommission-intent structure with a fresh registry challenge — and even then the record "remain[s] permanently resolvable and MUST NOT be reassigned." The draft's author is protecting history: an identity that can be administratively erased is an identity that can be silenced.
We put no master switch on the wire either — but from the opposite premise. In our design nothing runs without its own clock: the deadline rides in the first verification answer, revocation is named at the next boundary by the closed vocabulary, and an unreachable authority fails closed rather than open. AIRS refuses the switch so that nothing can erase what happened; we refuse it because nothing needs to be switched — everything already holds the hour of its own stop. One refusal protects the record; the other bounds the blast radius. A reader who wants both properties is not confused: they are complementary layers, not competitors.
What each design is for
The adversary models explain the differences better than any ideology. AIRS is built against impersonation at scale: scarce hardware makes mass identity creation expensive, accredited registrars make evidence checks someone's job, and the permanent record makes every identity's past auditable. The two pillars are built against stale authority: short leases make old answers expire before they can be abused, the closed vocabulary makes every stop auditable, and fail-closed makes silence count as refusal. One design hardens the front door; the other assumes the keys circulate and shortens the life of every key.
Both are early. AIRS is an experimental individual submission whose own boilerplate instructs readers to cite it only as work in progress; our draft is in the ISE channel with two provisional scheme registrations on the board. Neither has a working group, and neither camp should claim the field. What the side-by-side shows is that the field now has two serious, opposite answers — and that the question both are answering has become impossible to ignore.
One line
AIRS says an agent is what the registry says it is, forever; the two pillars say an agent is what the bytes derive and the verifier vouches, for one window at a time. One camp mints names and guards history; the other computes names and leases trust. Read both — the fork between allocation and derivation is going to organize this whole conversation.