Summary

  • draft-drake-agent-identity-problem-statement-00 distinguishes one continuing autonomous entity from the replaceable keys, credentials, accounts, names, hardware, providers and operators around it.
  • Cryptography can show continuity of control over anchors, but cannot by itself prove that the real referent remained the same; legitimate migration and covert transfer may produce the same transcript.
  • Durable accountability needs separate records for subject continuity, control transitions, credential state, operator authority and conduct. Identification does not prove safety, authorization or outcome.

A clean rotation can still erase accountability

Key rotation is supposed to reduce exposure. It should not offer a route out of history. If a service indexes reputation by the current public key, every correct rotation creates a new subject. Sanctions disappear, rate history fragments and a costly review starts again. The opposite failure is equally dangerous: if an account or key survives a sale, the new controller may inherit trust earned by somebody else.

Revision 00 of Identity for Autonomous Agents and Robots: Problem Statement, Threat Model, and Terminology gives this mismatch a name: the continuity gap. Identifiers, credentials and anchors may change while the entity continues; the artifacts may also remain stable while the entity behind them changes. The draft coins identity0 for its strict idea of one context-independent referent. That term is a proposal, not established IETF vocabulary, but the operational distinction is useful.

The document is an active individual Internet-Draft with an Informational target. It is not an RFC, an IETF consensus position or a Working Group product. It defines no protocol and makes no IANA request. Five companion drafts describe one possible registry, EPP provisioning, RDAP resolution, hardware-attestation application and governance structure. They are proposals by the same author, who discloses operating a reference implementation. The problem can be evaluated without endorsing that architecture.

Count accountable actors, not processes

An orchestrator can launch a hundred workers for one task. A robot can reboot. An agent can move from one cloud to another. None of those facts decides whether a new historical subject exists.

The draft places the boundary at the smallest independently accountable actor: the unit whose actions, obligations, reputation or history relying parties need to distinguish over time. A short-lived worker may act under a parent identity. A fleet may require a separate durable subject for each physical unit because recall, insurance and incident attribution depend on identifying which unit acted. Process count is therefore an implementation fact; identity count is a reliance decision.

This also rules out familiar shortcuts. An IP address, account, cookie, message style, traffic rate or visual appearance can be evidence about context or behavior. It is not proof of which continuing entity acted. Treating a proxy as the subject creates a cheap escape: change the proxy and abandon the record. Treating a shared proxy as proof can attach somebody else's conduct to the wrong agent.

Keep the layers apart

A durable system needs more than a stronger credential. It needs a vocabulary that refuses to let neighboring records impersonate one another.

The hardware anchor protects a key or makes additional high-assurance identities costly. It is not the entity. An identifier names the entity in a context. A credential carries claims and may expire or be revoked. Authentication checks a presented proof. An operator relationship records who may direct the agent and during which interval. Authorization says what the agent may do. Reputation evaluates observed conduct. Policy assigns consequences.

Those records should link, but they should not collapse. A hardware-backed signature can support the claim that a protected key produced a message. It does not establish that the message was safe, that the operator was authorized for this task, or that an external control took effect. RFC 9334's separation of attestation evidence, appraisal and relying-party policy is a useful adjacent discipline: a verified evidence object does not automatically contain the relying party's decision.

WebAuthn and NIST's digital identity guidance likewise show why lifecycle matters. Credentials are bound, replaced, recovered and revoked inside scoped systems. Those ceremonies can be rigorous without answering the distinct question of whether an autonomous referent was sold, split, merged or silently reassigned.

The limit the draft admits

The most important sentence in revision 00 is not its proposed terminology. It is the limit on what cryptography can know.

The document says non-transferability is a rule about what an identity denotes, not a property cryptography alone can enforce. A protocol can demonstrate continuity of control over an anchor chain. It cannot observe which entity exercises that control. A legitimate hardware migration and a cooperating seller handing control to a buyer may produce the same sequence of valid approvals.

That admission prevents a registry entry from becoming a metaphysical oracle. The honest system records every control change, never silently reassigns the referent and lets contracts, governance and relying-party policy address covert transfer. It does not turn “signature valid” into “same accountable entity proved.”

For leaders, this means a migration record needs at least five separable questions. Which durable subject is asserted? Which anchors entered or left? Which credential is currently valid? Which operator held authority at the relevant time? Which conduct record supports the reputation update? A green continuity badge that answers all five at once hides the very uncertainty an audit needs.

Hardware solves two narrower problems

Software can be copied at negligible cost. The draft therefore proposes scarce, hard-to-clone anchors for a high-assurance tier and labeled lower assurance for software-only entities. The original Sybil analysis explains the general risk: one faulty actor can present many identities when identity creation has no effective constraint.

But scarcity and extraction resistance are different controls. Scarcity raises the cost of manufacturing many high-assurance identities. A non-exportable key reduces the chance that host compromise becomes a reusable credential elsewhere. Neither proves that the authenticated entity behaves well. Neither establishes who is entitled to operate it. Neither makes a policy decision correct.

This distinction matters commercially. “Hardware-backed agent” can easily become a premium label whose implied promise exceeds the evidence. The defensible claim is narrower: a named proof key was protected under a stated mechanism and assurance basis. Safety, trust and authority need their own records.

History must survive revocation without becoming transferable

Revoking a credential should stop future reliance on that proof. It should not delete the subject of actions already taken. Otherwise every compromise response becomes an accountability amnesty.

Positive history needs the inverse protection. An agent with years of reliable conduct should not be able to sell the token that carries its reputation to an unrelated agent. The history belongs to the referent, not to whichever account, key or device currently presents it. If continuity is uncertain, the system should expose that uncertainty rather than granting or destroying inherited trust.

The same reasoning applies to operator change. A new operator is a new authorization relationship, not necessarily a new entity. Encoding the operator into the identifier forces identity churn; leaving the old operator embedded creates stale authority. Mutable role, jurisdiction, capability and trust tier belong above the continuity layer.

Persistence creates a privacy obligation

A durable machine identity is deliberately correlatable. That can support accountability, but agents act for people and organizations. The identifier may become a proxy for an employee, customer, household or company across contexts.

RFC 6973 emphasizes contextual identities for human privacy. Revision 00 uses a different, singular concept for machine provenance, then proposes keeping attributes separate and permitting selective disclosure. That is directionally sensible, but it does not erase correlation risk. A durable subject does not need one public handle everywhere, and accountability does not require publishing every operator attribute to every relying party.

The minimum common layer should therefore be thin: continuity, uniqueness, proof-of-control and explicit transition semantics. Role, capability, operator, jurisdiction, behavior and policy can remain contextual. The more a central registry accumulates, the more an interoperability function becomes a surveillance and governance chokepoint.

Do not mistake a six-document stack for deployment

The companion AIRS documents are detailed enough to invite architectural debate. That debate should come later than the evidence question. A registry hierarchy, EPP mapping, RDAP profile, email binding and constitutional draft are not proof that independent implementations agree on issuance, recovery, anchor retirement or conflict handling.

Adjacent work makes the same caution necessary. The WIMSE agent-identity draft explores binding workload credentials to an owner or organizational authority, while leaving parts of trust establishment outside scope; it expired on 1 September 2026. Current agentic use-case requirements cover discovery, authentication and authorization. Another agent-ID requirements draft has expired. These efforts can be useful at their own layers without supplying a universally durable referent.

Heng Lu's running-code test is the right discipline. Show version-pinned independent implementations rotating and retiring anchors, recovering after loss, rejecting reuse, preserving history and exposing conflicts. Test the negative cases: a copied credential, a stale operator relationship, a sold device and two claimants presenting a plausible migration transcript. A schema-valid happy path is symbolic evidence, not interoperability.

Sources and limits

The evidence was frozen on 30 September 2026 Asia/Shanghai. Revision 00 is an active individual Internet-Draft with an Informational target. The five AIRS companion texts are also individual drafts, not IETF consensus or deployed infrastructure. The WIMSE and draft-yl documents cited above had expired by the freeze date. No source establishes that one architecture has solved referent continuity, non-transferability, privacy or governance in production. Heng Lu's framework is applied here by Daniel Kade and is not language attributed to the drafts.