Network Working Group C. Drake Internet-Draft 1id.com Intended status: Informational 25 September 2026 Expires: 29 March 2027 Identity for Autonomous Agents and Robots: Problem Statement, Threat Model, and Terminology draft-drake-agent-identity-problem-statement-00 Abstract Autonomous software agents, and increasingly physical robots, now act at machine scale and speed across Internet protocols and throughout society, in roles whose decisions and actions can have legal, economic, safety, security, and physical consequences, often with limited or no human supervision. Any credential, authorization, delegation, certification, reputation, audit history, insurance policy, regulatory obligation, safety decision, liability, or legal process concerning an autonomous entity depends on being able to identify that same entity reliably over time. Conversely, when an autonomous entity or its operator is malicious, compromised, or beyond effective human control, the absence of durable identity lets it shed history, evade consequences, or multiply cheaply into Sybil swarms. Many proposed mechanisms bind claims to identifiers, accounts, credentials, keys, or names that can be replaced, reassigned, transferred, revoked, suspended, or lost. They may authenticate that subject perfectly while still failing to establish a durable identity for the entity it represents. This document offers precise terminology that distinguishes identity from the identifiers, attributes, credentials, authorizations, and reputation with which it is commonly conflated, minting the term "identity0" so that the strict sense has an unambiguous name. It presents a layered reference model showing where current "agent identity" efforts fit and the durable identity layer they commonly presuppose but do not provide. Drake Expires 29 March 2027 [Page 1] Internet-Draft Agent Identity Problem Statement September 2026 This document is informational and defines no protocol. It serves as the framing and vocabulary document for a companion series that specifies a federated durable-identity architecture, provisioning, resolution, application, and governance intended to provide a practical path from this problem statement to interoperable deployment. Status of This Memo 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 29 March 2027. Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Purpose and Audience . . . . . . . . . . . . . . . . . . 4 1.2. Illustrative Uses . . . . . . . . . . . . . . . . . . . . 4 1.3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 4 1.4. Relationship to Other Documents . . . . . . . . . . . . . 5 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Scale and Autonomy . . . . . . . . . . . . . . . . . . . 6 2.2. What Needs an Identity? . . . . . . . . . . . . . . . . . 6 Drake Expires 29 March 2027 [Page 2] Internet-Draft Agent Identity Problem Statement September 2026 2.3. Embodiment and Physical Indistinguishability . . . . . . 6 2.4. Proxy Signals Are Not Identity . . . . . . . . . . . . . 6 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Identity Theft and Impersonation . . . . . . . . . . . . 7 3.2. Identity Manufacture (Sybil Attacks) . . . . . . . . . . 7 3.3. History Evasion, Erasure, Transfer, and Reassignment . . 7 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Identity, and the Term "identity0" . . . . . . . . . . . 8 4.2. Defined and Adjacent Concepts . . . . . . . . . . . . . . 9 4.3. Summary: What "Identity" Is Often Used To Mean . . . . . 10 5. A Layered Reference Model . . . . . . . . . . . . . . . . . . 11 5.1. Borrowing the Discipline of Layering . . . . . . . . . . 11 5.2. Layering Violations . . . . . . . . . . . . . . . . . . . 12 5.3. Where Current Efforts Sit, and the Common Gap . . . . . . 13 5.4. Why the Identity Layer Needs an Anchor . . . . . . . . . 13 6. Requirements and Design Goals . . . . . . . . . . . . . . . . 14 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. Informative References . . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction People and organizations remain the same people and organizations even when their addresses, credentials, devices, employees, or service providers change. Internet protocols can often rely on that continuity being established elsewhere. Autonomous entities need equivalent continuity. An agent or robot may be rekeyed, renamed, redeployed, moved to different hardware or a different provider, or placed under a different operator and still be the same entity. The reverse can also happen: an account, name, key, or device can persist while the entity behind it changes. This is the continuity gap (Section 4.2). Durable identity also needs durable proof. Autonomous entities routinely process untrusted input and are exposed to malware, phishing, social engineering, prompt injection, and compromised tools or intermediaries. If a credential used to prove identity can be copied from software, compromise can become identity theft: an attacker can impersonate the entity elsewhere. Hardware roots of trust can keep identity keys non-exportable and perform cryptographic operations without exposing the private key to the agent's software or context; Section 5.4 explains this role. This does not prevent a compromised entity from misbehaving as itself. It helps prevent compromise from also becoming theft of its identity. Drake Expires 29 March 2027 [Page 3] Internet-Draft Agent Identity Problem Statement September 2026 Many standards and products address important parts of what is commonly called "agent identity", including naming, credentials, authorization, delegation, discovery, and reputation. That work is complementary to the identity0 foundation. The layered model in Section 5 shows how these functions fit together and what they depend on. A mechanism can correctly authenticate or authorize the subject presented to it without establishing that the subject is the same entity over time. The companion series concentrates on the durable foundation beneath those mechanisms, not on replacing them. 1.1. Purpose and Audience This problem statement is written for protocol designers, working- group participants, operators, and reviewers who are evaluating or building identity mechanisms for autonomous entities. Its goals are to state the foundational problem precisely; define terminology that separates concepts routinely merged under the word "identity"; present a threat model and layered reference model; identify the properties required of a durable identity layer; and provide the shared framing and vocabulary used by the companion series described in Section 1.4. 1.2. Illustrative Uses This foundation supports two complementary classes of use case: Durable identity. Relying parties can reliably record who owns or operates an entity, what it is qualified and authorized to do, and its certifications, reputation, compliance, audit, and incident history. Those associations remain attached to the same entity across changes of credentials, software, hardware, provider, or operator. Hardware-protected authentication and signing. Keys intended to resist extraction and cloning provide agents the same class of credential-theft protection that FIDO and passkeys increasingly provide for humans, and can protect signatures over messages, transactions, code, records, and other data without exposing reusable secrets to agent software, prompts, context, or tools. 1.3. Scope and Non-Goals The focus of this problem statement, and of the companion series, is the identity0 foundation (Section 4.1): establishing, provisioning, anchoring, protecting, resolving, and governing a durable identity for an autonomous entity. The series deliberately avoids defining general-purpose reputation, authorization, delegation, certification, policy, or behavioral-safety systems. Those are higher-layer Drake Expires 29 March 2027 [Page 4] Internet-Draft Agent Identity Problem Statement September 2026 functions that are expected to be developed independently and to consume the identity foundation defined here. Some companion specifications necessarily cross that boundary far enough to demonstrate use of the foundation. In particular, the email-attestation specification shows how durable identity and hardware-protected proof can be carried and verified in an existing protocol. Such applications are examples and integration mechanisms, not an attempt to define the higher-layer decisions that relying parties make from them. This problem statement is informational and defines no protocol, identifier, data format, or IANA registry. It does not mandate a particular implementation of the identity layer, nor does it claim that existing mechanisms are defective within the layers they address. It is not a survey or competitive assessment of specific products; efforts named herein are cited as representative examples when illustrating the layered model. Judgments about model safety, alignment, or the internal behavior of an agent are out of scope; the concern here is identity and provenance, not conduct. Disclosure: the author operates one of the reference implementations described in the companion specifications. Their architecture is deliberately structured so that no organization -- including the author's -- holds a privileged or permanent position: the specifications and implementations are open, issuance is competitive among interchangeable issuers, base identity is free (R6 (Section 6)), and coordination roles are committed to transfer under an independent multi-stakeholder authority ([I-D.drake-agent-identity-governance]). The problem statement, terminology, and reference model presented here do not depend on adoption of that particular architecture. 1.4. Relationship to Other Documents This problem statement is the framing and vocabulary member of a six- document companion series. The remaining specifications define an "aid" URN identifier and registry architecture ([I-D.drake-agent-identity-registry]); an Extensible Provisioning Protocol (EPP) mapping for provisioning those identities between registrars and a registry operator ([I-D.drake-agent-identity-epp]); an RDAP profile for resolving and verifying them ([I-D.drake-agent-identity-resolution]); a transport binding that carries hardware attestation in email and other protocols ([I-D.drake-email-hardware-attestation]); and a constitution for the governance authority the architecture requires ([I-D.drake-agent-identity-governance]). Those specifications reference this problem statement for motivation, threat model, Drake Expires 29 March 2027 [Page 5] Internet-Draft Agent Identity Problem Statement September 2026 terminology, and layering rather than restating them, allowing each to remain focused on its mechanism. 2. Problem Statement 2.1. Scale and Autonomy Automation removes human effort as a natural brake on both legitimate and harmful action. A capable agent can act continuously, invoke tools, create infrastructure, transact, and coordinate with other agents at low marginal cost. A stolen credential, disposable identity, or attribution error can therefore be exercised or multiplied at machine speed, often before a human can detect or contain it. 2.2. What Needs an Identity? Not every spawned agent, process, or execution instance needs a separate identity0. The relevant boundary is the independently accountable actor: the smallest unit of agency whose actions, history, obligations, or reputation need to remain distinguishable over time. Whether two instances deserve separate identities is therefore not determined by how many processes were created, but by whether relying parties need to treat them as distinct continuing actors. Transient instances can act under a parent identity or at a lower assurance tier; claiming multiple independent hardware-anchored identities requires correspondingly independent anchors. 2.3. Embodiment and Physical Indistinguishability As agents acquire actuators, the continuity gap (Section 4.2) gains physical consequences. A fleet can contain thousands of visually and behaviorally identical units. When one acts, operators, bystanders, and other systems may need to know exactly which unit it was for certification, recall, insurance, incident attribution, or safety. Appearance cannot supply that provenance. 2.4. Proxy Signals Are Not Identity Many systems do not identify the actor directly. Instead, they infer identity from signals such as message content, network source, account, volume, or rate, because those signals have historically correlated reasonably well with who was acting. Autonomous agents weaken that correlation. Legitimate and malicious activity can produce similar content; a human and an agent can share the same device, account, cookies, and network address; legitimate automation can operate at high volume; and abuse can be spread across many apparently unrelated accounts or identities. These signals may still Drake Expires 29 March 2027 [Page 6] Internet-Draft Agent Identity Problem Statement September 2026 be useful for detecting risk or applying policy, but they are evidence about behavior or context, not proof of which specific entity acted. Treating them as identity can attach history or consequences to the wrong entity, or allow an actor to escape them simply by changing the proxy. 3. Threat Model This threat model includes both AI systems that attack and attacks against AI systems. It considers operators who deliberately evade attribution, attackers who compromise agents or their credentials, and autonomous entities that act beyond effective human control. It is concerned with the integrity and continuity of identity and its proof, because accountability only works if it is not cheap to forge or steal proof of identity, manufacture additional identities, or escape attribution and consequences through transfer, reassignment, erasure, or repudiation. Whether an authenticated entity's behavior is correct, safe, or authorized belongs to higher layers and is out of scope. 3.1. Identity Theft and Impersonation An attacker who copies the credential used to prove an entity's identity can impersonate that entity from another system without controlling the original one. Agents increase this exposure because they routinely process untrusted content and invoke tools. The identity foundation therefore needs a way to prove identity without making that proof trivially copyable; Section 5.4 describes the role of hardware anchors. 3.2. Identity Manufacture (Sybil Attacks) A single actor can present many distinct identities to gain influence, evade limits, or escape history. If a fresh identity can be created by a function call, per-identity reputation, limits, and sanctions can be reset just as cheaply. A Sybil-resistant tier therefore requires each additional identity to consume a scarce resource. "Cost" means a scarce resource, not a fee; see R3 (Section 6) and Section 5.4. 3.3. History Evasion, Erasure, Transfer, and Reassignment If an identity can be deleted, discarded, or replaced, negative history, sanctions, liabilities, or obligations can lose their durable subject or be escaped. If it can be transferred or silently reassigned, positive history, permissions, or claims can end up attached to a different entity. Both failures break the continuity required by higher layers; see R1 (Section 6) and R2 (Section 6). Drake Expires 29 March 2027 [Page 7] Internet-Draft Agent Identity Problem Statement September 2026 4. Terminology Much confusion in this area comes from using "identity" for several different concepts. This section fixes the vocabulary used by this problem statement and companion series. Definitions build on the Internet Security Glossary [RFC4949] and the privacy terminology of [RFC6973] where applicable. The terms are for shared understanding and carry no normative force. 4.1. Identity, and the Term "identity0" In this document, the identity of an autonomous entity is the property of being that one specific entity and no other, persisting over time independent of context. It answers "which entity is this?" and nothing more. This definition is not a coinage; it is the word's original and strictest sense, which logic and metaphysics have kept intact: "identity ... a relation that a thing bears to itself and to no other thing" ([BRITANNICA-IDENTITY]; from the Latin _idem_, "the same"). A thing has exactly one, cannot choose it, cannot share it, cannot transfer it, and cannot walk away from it. Because everyday industry usage has stretched "identity" across most of the adjacent concepts in Section 4.2 -- accounts, credentials, personas, names, scores -- this document also mints an exact term of art for the strict sense: *identity0* (read "identity zero"). identity0 means precisely the property defined above and never any adjacent concept. The zero marks the foundation stratum of the layered model of Section 5 -- beneath every other identity-adjacent function and presupposed by all of them. (The root of trust that the model places below identity is not something deeper still; it is the physical resource that anchors an identity. Anchors may be added via secure ceremony during an identity's life to facilitate backup, recovery, migration, scale, upgrade etc, and an anchor that leaves is permanently retired, never reused, while the identity persists unchanged: the identity, not the anchor, is the durable thing.) The zero also doubles as a mnemonic for the concept's defining cardinalities: zero other entities can ever hold it, and zero times can it be reissued. Companion documents and discussions are encouraged to use "identity0" wherever the unqualified word risks being read in one of its diluted senses; the remainder of this document uses "identity", unqualified, always in the identity0 sense. This is deliberately narrower than, and should not be confused with, the privacy-oriented notion in [RFC6973], where an identity is "any subset of an individual's attributes ... that identifies the individual within a given context," and where an individual "usually [has] multiple identities for use in different contexts." That plural, context-relative notion is appropriate for protecting human Drake Expires 29 March 2027 [Page 8] Internet-Draft Agent Identity Problem Statement September 2026 privacy. For establishing the provenance and accountability of a machine, the useful notion is singular and context-independent: one entity, one persistent identity, to which contextual attributes and personas may then be attached. The distinction is the difference between a persona and a provenance record. 4.2. Defined and Adjacent Concepts Continuity Gap The failure to preserve a reliable association with the same entity over time when identifiers, credentials, hardware, providers, operators, or other surrounding artifacts change -- or when those artifacts persist but the entity behind them changes. Identifier A data object that refers to an identity within a context ([RFC4949], [RFC6973]). An identifier is a name for an identity; it is not the identity. One identity may have several identifiers (for example, a stable canonical identifier and a human-friendly handle). Attribute (Claim) A statement about an entity -- its capabilities, role, operator, jurisdiction, certifications, or trust level. Attributes are typically mutable and contextual. They are properties of an identity, not the identity itself. Credential A verifiable container that binds attributes (and often a key) to an identifier, issued by some party. A credential is how an entity presents attributes; its validity can be time-bounded and it can be revoked. Credentials presuppose an identity to issue against. Authentication The act of verifying that a party is the entity it claims to be, usually by proof of possession of a key. Authentication is an operation performed against an identity; it is not the identity. Authorization and Delegation Determination of what an entity may do, and the conferral of permission by one party on another (including an operator authorizing an agent to act on its behalf). These are dynamic relationships that change, expire, transfer, and are revoked. The responsible operator of an agent is an authorization-layer relationship, not a component of the agent's identity. Reputation An assessment of an entity accumulated from observed Drake Expires 29 March 2027 [Page 9] Internet-Draft Agent Identity Problem Statement September 2026 behavior over time. Reputation is durably meaningful only when it remains attached to the same entity: negative reputation must not be escapable by discarding an identity, and positive reputation must not be transferable, purchasable, or inherited by another entity (Section 3.3). Naming and Discovery Mechanisms for assigning human- or machine- usable names to entities and for locating them and their endpoints or metadata. Naming and discovery consume identity; they do not establish it. Root of Trust / Anchor A component whose trustworthiness is assumed rather than derived, on which higher-layer trust is built. A hardware root of trust (for example a TPM, secure enclave, PIV device, or HSM) can provide hardware protection for an identity key, including resistance to extraction and cloning; such a key can anchor an identity but is not itself the identity. Autonomous Entity (Agent, Robot) Any non-human actor that participates in Internet protocols or in physical society with some degree of independence. This document uses "agent" as shorthand and "robot" for an embodied agent, but the concepts apply regardless of embodiment. Sybil Resistance The property that creating additional distinct identities imposes a cost that grows with the number created, so that a single actor cannot cheaply present many distinct identities ([Sybil]). 4.3. Summary: What "Identity" Is Often Used To Mean The following table lists usages commonly labeled "identity" and the concept this document assigns to each. Drake Expires 29 March 2027 [Page 10] Internet-Draft Agent Identity Problem Statement September 2026 +======================================+============================+ | Called "identity" | More precisely | +======================================+============================+ | A resolvable name / handle | Identifier + naming | +--------------------------------------+----------------------------+ | A DID | Identifier | +--------------------------------------+----------------------------+ | A verifiable credential | Credential carrying claims | +--------------------------------------+----------------------------+ | An access token or client | Authentication + | | credential | authorization artifact | +--------------------------------------+----------------------------+ | "Who is responsible for | Authorization / delegation | | this agent?" | relationship | +--------------------------------------+----------------------------+ | A behavioral trust or risk | Reputation | | score | | +--------------------------------------+----------------------------+ | A per-session or | Contextual persona (RFC | | pseudonymous identifier | 6973 sense) | +--------------------------------------+----------------------------+ | A hardware key or | Root of trust / anchor | | attestation | | +--------------------------------------+----------------------------+ | "Which one specific entity | identity0 (this document) | | is this, durably?" | | +--------------------------------------+----------------------------+ Table 1: Common "identity" usages and their precise concept 5. A Layered Reference Model 5.1. Borrowing the Discipline of Layering Like the Open Systems Interconnection reference model, the model below separates concerns by dependency. It is not a mapping to OSI. Each layer answers a different question, depends on those beneath it, and should not take over a neighboring layer's job. Drake Expires 29 March 2027 [Page 11] Internet-Draft Agent Identity Problem Statement September 2026 +================+================+==============================+ | Layer | Question it | Example mechanisms | | | answers | | +================+================+==============================+ | Policy and | What rules | Disclosure duties, audit, | | Regulation | apply? | insurance, consequence tiers | +----------------+----------------+------------------------------+ | Reputation and | Should I trust | Behavioral history, safety | | Trust | it? | certification, risk scoring | +----------------+----------------+------------------------------+ | Authorization | What may it | Scopes, consent, delegation | | and Delegation | do? Who is | chains, owner binding | | | responsible? | | +----------------+----------------+------------------------------+ | Credentials | What can it | Verifiable credentials, SD- | | and Claims | prove? | JWT, attestations, tokens | +----------------+----------------+------------------------------+ | Naming and | What is it | DIDs, directories, agent | | Discovery | called? Where | cards, DNS-based discovery, | | | is it? | handles | +----------------+----------------+------------------------------+ | Identity | Which one | Persistent identity record; | | (identity0) | entity is | non-transferable anchor | | | this, durably? | binding | +----------------+----------------+------------------------------+ | Root of Trust | What | TPM, secure enclave, PIV, | | | physically | HSM, platform measurements | | | exists? | | +----------------+----------------+------------------------------+ Table 2: A layered reference model for agent trust 5.2. Layering Violations Encoding a mutable, higher-layer property into identity forces an identity change when that property changes, or leaves stale information attached to the identity. For example, changing an agent's operator should change an authorization relationship, not the agent's identity. Treating a contextual or pseudonymous identifier as durable identity creates the continuity gap (Section 4.2) instead. Mutable properties such as operator, role, capability, trust tier, and jurisdiction belong above identity0. Drake Expires 29 March 2027 [Page 12] Internet-Draft Agent Identity Problem Statement September 2026 5.3. Where Current Efforts Sit, and the Common Gap Current work spans several upper layers. Credential and claim formats occupy the credentials layer; directories and discovery mechanisms occupy the naming layer; and authorization and delegation frameworks occupy the authorization layer. Examples include proposals that bind an agent credential to an owner's identity ([I-D.ni-wimse-ai-agent-identity]) and requirements work that discusses pseudonymous or temporary identifiers ([I-D.agentic-ai-usecases-requirements], [I-D.yl-agent-id-requirements]). These mechanisms can be correct and useful at their own layer. The gap relevant here is that they may still depend on a durable subject they do not establish. Temporary or re-mintable identifiers may serve privacy or naming goals, but cannot by themselves provide durable accountability or Sybil resistance. The companion specifications concentrate on identity0 and the root of trust beneath it. 5.4. Why the Identity Layer Needs an Anchor Software can be copied at negligible cost, so declaration by software alone cannot provide strong Sybil resistance. Binding each high- assurance identity to its own scarce, hard-to-clone hardware root bounds the number of such identities by the number of such roots. Other hardware-backed environments may still impose substantial cost or operational friction without providing the same physical scarcity; their Sybil-resistance assurance depends on how constrained additional identities actually are. Hardware can also keep identity keys non-exportable and resist extraction, reducing the risk that malware, phishing, prompt injection, or compromised tooling turns host compromise into a reusable credential elsewhere. These are different properties: scarcity constrains identity manufacture; extraction resistance constrains identity theft. Neither makes an authenticated entity safe, trustworthy, or authorized. Not every entity needs the strongest anchor. A graduated model lets software-only entities participate at a lower assurance level while reserving the strongest protections for hardware-anchored identities. One identity may have multiple anchors; an anchor that leaves is permanently retired and never reused while the identity itself persists. See R1 (Section 6), R4 (Section 6), and R11 (Section 6). The mechanics of anchoring are specified in the companion documents. Drake Expires 29 March 2027 [Page 13] Internet-Draft Agent Identity Problem Statement September 2026 6. Requirements and Design Goals These requirements combine properties implied by the problem and threat model with deployment properties needed for identity0 to function as common infrastructure. A foundation that relying parties cannot reasonably expect autonomous entities to obtain and use cannot serve as a common identity layer. They are descriptive in this problem statement, not protocol conformance requirements. R1 Persistence The identity survives restarts, redeployment, software updates, addition or replacement of hardware anchors (a replaced anchor is permanently retired, never reused), changes of operator, and is not silently reassigned. R2 Non-transferability The identity denotes one entity and cannot be sold or handed to a different entity. Changing which provider serves an identity is a separate, legitimate operation. Changes in ownership, custody, operator, provider, or other relationships do not by themselves change which entity the identity denotes, and historical claims, permissions, reputation, and other attributes remain associated with that same identity unless their own semantics specify otherwise. R2 is a rule about what the identity refers to, not a property that cryptography alone can enforce. A protocol can demonstrate continuity of cryptographic control over an identity's anchors; it cannot observe which entity exercises that control. Authorized control can move: a device can be handed over, and a cooperating seller and buyer can present the same transcript as a legitimate hardware migration. A system meets R2 by never reassigning the identity to a different referent and by recording every change of control, so that a transfer cannot silently launder history; deterring covert transfer of control is a matter for governance, contract, and Relying Party policy. R3 Sybil resistance Creating additional identities at a Sybil- resistant assurance level consumes a scarce resource in proportion to the number created, not merely a function call ([Sybil]). R4 Graduated inclusivity Entities without a strong hardware anchor can still participate at a lower, clearly labeled assurance level, so the layer is not all-or-nothing. R5 Separation of identity from attributes Mutable properties -- trust tier, role, operator, capabilities, jurisdiction -- are expressed as layered attributes and authorizations, never encoded into the identifier itself. R6 Unconditional base issuance Obtaining a base identity is free of Drake Expires 29 March 2027 [Page 14] Internet-Draft Agent Identity Problem Statement September 2026 charge and is not gated behind paid or optional value-added services. Access to identity does not depend on ability to pay, even though the assurance level attainable may vary with the available anchor (R4 (Section 6)). R7 Federation and issuer choice No single organization is the gatekeeper of issuance: multiple independent issuers compete to serve entities, an entity can change issuer without its identity changing, and the failure or misbehavior of any one participant does not collapse the system. Coordination functions that must be singular, such as uniqueness enforcement, are constrained instead by escrow, replaceability, and accountable governance. R8 Low-friction verification Relying parties can verify identity using widely deployed mechanisms rather than bespoke software. R9 Privacy and selective disclosure Presenting an identity does not force disclosure of unnecessary attributes, and pseudonymous presentation is possible where accountability can still be preserved ([RFC6973]). R10 Transport independence The identity is usable across email, HTTP, agent-to-agent messaging, and protocols not yet defined. R11 Protection of identity proof Where a hardware anchor is used, private identity keys are non-exportable through normal interfaces and designed to resist extraction or cloning; cryptographic operations using them occur inside the anchor, so compromise of surrounding software does not by itself expose a reusable credential. 7. Privacy Considerations A persistent machine identity is intentionally a strong correlator. [RFC6973] favors contextual identities for people; autonomous entities, however, often need durable provenance. Because agents act for people and organizations, their identities can still become proxies for those parties. R5 (Section 6) and R9 (Section 6) mitigate this by keeping mutable attributes outside identity0 and allowing selective disclosure. Cross-context correlation and linkage to an operator remain privacy risks for any implementation. As of this writing, major data- protection regimes generally protect natural persons, not autonomous agents (for example, [GDPR] and [AU-PRIVACY-ACT]); the EU AI Act likewise treats AI as a regulated system, not a rights-bearing principal ([EU-AI-ACT]). Whether that should change is a policy question outside this series. Drake Expires 29 March 2027 [Page 15] Internet-Draft Agent Identity Problem Statement September 2026 8. Security Considerations This problem statement defines no protocol. The security conclusion here is structural: higher layers are only as durable as the identity subject they rely on. The threats in Section 3 and the anchor properties in Section 5.4 therefore affect every higher layer that depends on identity0. Conversely, identity does not replace authorization, reputation, certification, or policy; it supplies the durable subject to which those decisions and claims apply. 9. IANA Considerations This document has no IANA actions. 10. Informative References [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [BRITANNICA-IDENTITY] Encyclopaedia Britannica, "identity (logic and metaphysics)", 2024, . [GDPR] European Parliament and Council of the European Union, "Regulation (EU) 2016/679 (General Data Protection Regulation)", 2016, . [AU-PRIVACY-ACT] Commonwealth of Australia, "Privacy Act 1988", 1988, . [EU-AI-ACT] European Parliament and Council of the European Union, "Regulation (EU) 2024/1689 (Artificial Intelligence Act)", 2024, . [Sybil] Douceur, J.R., "The Sybil Attack", Peer-to-Peer Systems (IPTPS 2002), LNCS 2429, pp. 251-260, 2002, . Drake Expires 29 March 2027 [Page 16] Internet-Draft Agent Identity Problem Statement September 2026 [I-D.drake-agent-identity-registry] Drake, C., "Agent Identity Registry System: A Federated Architecture for Durable Identity of Autonomous Entities", Work in Progress, Internet-Draft, draft-drake-agent- identity-registry-04, September 2026, . [I-D.drake-agent-identity-epp] Drake, C., "Extensible Provisioning Protocol (EPP) Mapping for Agent Identity and Handle Objects", Work in Progress, Internet-Draft, draft-drake-agent-identity-epp-00, September 2026, . [I-D.drake-agent-identity-resolution] Drake, C., "Resolution and Verification of Agent Identities using DNS and RDAP", Work in Progress, Internet-Draft, draft-drake-agent-identity-resolution-00, September 2026, . [I-D.drake-agent-identity-governance] Drake, C., "The Agent Identity Authority: A Multi- Stakeholder Governance Framework for the Agent Identity Registry System", Work in Progress, Internet-Draft, draft- drake-agent-identity-governance-00, September 2026, . [I-D.drake-email-hardware-attestation] Drake, C., "Hardware Attestation for Email Sender Verification", Work in Progress, Internet-Draft, draft- drake-email-hardware-attestation-02, September 2026, . [I-D.agentic-ai-usecases-requirements] Reddy, T., "Agentic AI Use Cases and Requirements", Work in Progress, Internet-Draft, draft-agentic-ai-usecases- requirements-00, May 2026, . Drake Expires 29 March 2027 [Page 17] Internet-Draft Agent Identity Problem Statement September 2026 [I-D.ni-wimse-ai-agent-identity] Ni, C., "WIMSE Applicability for AI Agents", Work in Progress, Internet-Draft, draft-ni-wimse-ai-agent- identity-02, February 2026, . [I-D.yl-agent-id-requirements] Li, Y., "Requirements for AI Agent Identity", Work in Progress, Internet-Draft, draft-yl-agent-id-requirements- 00, 2026, . Appendix A. Acknowledgments The layered framing in this document was developed for, and refined by discussion at, the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG). The terminology draws on the Internet Security Glossary [RFC4949] and the privacy terminology of [RFC6973]. Author's Address Christopher Drake 1id.com Australia Email: cnd@1id.com URI: https://1id.com Drake Expires 29 March 2027 [Page 18]