Network Working Group C. Drake Internet-Draft 1id.com Intended status: Experimental 25 September 2026 Expires: 29 March 2027 Extensible Provisioning Protocol (EPP) Mapping for Agent Identity and Handle Objects draft-drake-agent-identity-epp-00 Abstract This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of agent identity objects and handle objects stored in the authoritative AIRS repository, as defined by the Agent Identity Registry System architecture. Specified in Extensible Markup Language (XML), these mappings define the interface between Registrars and the production Registry Operator for identities of autonomous entities. The mapping defines two objects: a permanent, non-expiring Agent Identity object keyed by a server-allocated canonical identifier, and a renewable, expiring Handle object that provides a human-readable alias. It adds one registry function with no domain-name analogue: cross-Registrar uniqueness enforcement of enrolled anchor identifiers, including the scarce-anchor invariant where the parent architecture defines one. Transfer authorization uses a actor-signed proof from an enrolled operational proof key in place of authorization-information passwords. 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. Drake Expires 29 March 2027 [Page 1] Internet-Draft EPP Agent Identity Mapping September 2026 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. Relationship to Other Documents . . . . . . . . . . . . . 4 1.2. Two Objects . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Object Model . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Object Identifiers . . . . . . . . . . . . . . . . . . . 5 2.2. Anchor and Proof-Key Bindings . . . . . . . . . . . . . . 5 2.3. Anchor Uniqueness Enforcement . . . . . . . . . . . . . . 6 2.4. Sponsorship . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Service Element Declaration . . . . . . . . . . . . . . . 7 2.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Agent Identity Object Attributes . . . . . . . . . . . . . . 8 3.1. Status Values . . . . . . . . . . . . . . . . . . . . . . 8 4. EPP Command Mapping for Agent Identity Objects . . . . . . . 9 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 9 4.1.1. EPP Command . . . . . . . . . . . . . . . . . 9 4.1.2. EPP Command . . . . . . . . . . . . . . . . . 10 4.1.3. Actor-Authorization Challenge . . . . . . . . . . . . 10 4.1.4. EPP Query Command . . . . . . . . . . . . 11 4.1.5. EPP Command . . . . . . . . . . . . . . . . . 12 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 12 4.2.1. Actor Authorization . . . . . . . . . . . . . . . . . 12 4.2.2. EPP Command . . . . . . . . . . . . . . . . 14 4.2.3. EPP Command . . . . . . . . . . . . . . . . 14 4.2.4. EPP Command . . . . . . . . . . . . . . . . . 15 4.2.5. EPP Command . . . . . . . . . . . . . . . 15 4.2.6. EPP Command . . . . . . . . . . . . . . . . 16 5. Handle Object Attributes . . . . . . . . . . . . . . . . . . 18 5.1. Status Values . . . . . . . . . . . . . . . . . . . . . . 18 6. EPP Command Mapping for Handle Objects . . . . . . . . . . . 19 6.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 19 Drake Expires 29 March 2027 [Page 2] Internet-Draft EPP Agent Identity Mapping September 2026 6.1.1. EPP Command . . . . . . . . . . . . . . . . . 19 6.1.2. EPP Command . . . . . . . . . . . . . . . . . 20 6.1.3. EPP Query Command . . . . . . . . . . . . 21 6.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 21 6.2.1. EPP Command . . . . . . . . . . . . . . . . 21 6.2.2. EPP Command . . . . . . . . . . . . . . . . 21 6.2.3. EPP Command . . . . . . . . . . . . . . . . . 21 6.2.4. EPP Command . . . . . . . . . . . . . . . 22 6.2.5. EPP Command . . . . . . . . . . . . . . . . 22 6.3. Grace Periods . . . . . . . . . . . . . . . . . . . . . . 22 7. Lifecycle Mapping . . . . . . . . . . . . . . . . . . . . . . 22 8. Data Escrow . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Internationalization Considerations . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10.1. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 24 10.2. XML Schemas . . . . . . . . . . . . . . . . . . . . . . 25 10.3. EPP Extension Registry . . . . . . . . . . . . . . . . . 25 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 13. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27 13.1. Agent Identity Schema . . . . . . . . . . . . . . . . . 27 13.2. Handle Schema . . . . . . . . . . . . . . . . . . . . . 34 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 15. Normative References . . . . . . . . . . . . . . . . . . . . 38 16. Informative References . . . . . . . . . . . . . . . . . . . 39 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction The Agent Identity Registry System ([I-D.drake-agent-identity-registry], hereafter "the registry architecture") defines an architecture separating governance, one authoritative production Registry Operator, and multiple competing Registrars for durable identities of autonomous entities. This document uses those roles as defined there rather than redefining them. This document maps that Registrar-to-Registry interface onto the Extensible Provisioning Protocol (EPP) [RFC5730], following the structure and conventions of the EPP domain name mapping [RFC5731] and the guidelines for extending EPP [RFC3735]. A registry operator that already runs an EPP-based domain registry can operate an agent identity registry by adding the two object mappings defined here to an existing EPP service, reusing EPP session, transport, transaction, and selected registry-operational infrastructure. Drake Expires 29 March 2027 [Page 3] Internet-Draft EPP Agent Identity Mapping September 2026 This document specifies only the provisioning protocol between an EPP client (a Registrar) and an EPP server (the Registry Operator). Production objects are provisioned in global; test is non-production and carries no AIRS assurance. Autonomous entities (agents) are not EPP clients and never speak EPP. Agents enroll and authenticate through their Registrar's agent-facing interface defined in the registry architecture; EPP is used only after the Registrar has completed the tier-appropriate enrollment checks and is recording the result at the Registry. Hardware attestation ceremonies, token issuance, identity semantics, URN syntax, trust tiers, and governance policy are defined in the parent documents and are not restated here. 1.1. Relationship to Other Documents This document provides the Registrar-to-Registry provisioning protocol (the write side) for the registry architecture defined in [I-D.drake-agent-identity-registry], which references this mapping as its provisioning interface. The public read side is the RDAP profile of [I-D.drake-agent-identity-resolution]. Transport-level attestation for email is defined in [I-D.drake-email-hardware-attestation] and is unaffected by this document. 1.2. Two Objects This mapping deliberately splits the registry's data into two EPP objects with different lifecycles. The Agent Identity object is permanent: it is created once, never expires, is never renewed, is never reassigned, and survives its own decommissioning as a queryable record; its [RFC5730] command changes only the sponsoring Registrar. The Handle object is a commercial name: it expires, is renewed, passes through grace periods, and can be retired through disputes -- lifecycle semantics for which registry operators can reuse existing naming-system operational machinery. Combining the two in one object would either corrupt identity permanence with expiry semantics or force bespoke renewal machinery for names; the split lets each half reuse the EPP semantics that already fit it. 1.3. Requirements Language 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. Drake Expires 29 March 2027 [Page 4] Internet-Draft EPP Agent Identity Mapping September 2026 In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples are provided only to illustrate element relationships and are not a REQUIRED feature of this protocol. XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation. 1.4. Terminology The terms "Agent Identity Record", "canonical identifier", "handle", "anchor fingerprint", "trust tier", "Registry Operator", "Registrar", and "Governance Authority" are used as defined in [I-D.drake-agent-identity-registry]. "Sponsoring client" is used as in [RFC5730]: the Registrar authorized to perform transform operations on an object. 2. Object Model 2.1. Object Identifiers An Agent Identity object is identified by its canonical-form URN in the "aid" URN namespace ([RFC8141]), e.g. urn:aid:global:id-qkckh- xxtcw-cxbvp-gpskg. A Handle object is identified by its handle-form URN, e.g. urn:aid:global:crusty. URN syntax, the reservation of the id- prefix for canonical identifiers, and label constraints are defined in [I-D.drake-agent-identity-registry]. The global namespace is the sole production uniqueness domain. The reserved test namespace is non-production and MUST NOT share or affect the production uniqueness index. Unlike domain names, canonical identifiers are not chosen by the client: they are allocated by the server from a randomized space at object creation and are returned in the response. A canonical identifier MUST NOT be reused, reassigned, or retired, even after the identity is decommissioned. Each object also has a Repository Object IDentifier (roid) as described in [RFC5730]. 2.2. Anchor and Proof-Key Bindings An Agent Identity object contains one or more permanent enrolled bindings. Each binding has two distinct cryptographic semantics: an _anchor fingerprint_ identifying the enrolled anchor or key instance used by the Registry uniqueness rules, and an _operational proof key_ used for control challenges and lifecycle authorization. The distinction and tier-specific anchor semantics are defined in Drake Expires 29 March 2027 [Page 5] Internet-Draft EPP Agent Identity Mapping September 2026 [I-D.drake-agent-identity-registry] and are not redefined here. A client provisions the anchor fingerprint in as 64 lowercase hexadecimal characters and the operational public key in as base64-encoded DER SubjectPublicKeyInfo (SPKI), together with the hardware type code and, when applicable, a Registry-recognized manufacturer or evidence-profile identifier in . The server MUST reject an value it does not recognize; this element is not arbitrary client-supplied metadata. For every tier the anchor fingerprint is computed exactly as defined in the Anchor Fingerprint section of [I-D.drake-agent-identity-registry]. For sovereign and portable bindings it is derived from the device-stable manufacturer-attested anchor established by the enrollment ceremony; the server MUST NOT derive it merely by hashing . For lower tiers the enrolled key instance supplies the anchor fingerprint; that does not imply physical scarcity. The Registry retains both the permanent anchor fingerprint and current/historical operational proof-key material. A binding, once created, MUST NOT be erased. It may transition to "disabled", but its anchor fingerprint MUST NOT later be accepted for another Agent Identity where the Registry architecture forbids reuse. Rotation of the operational proof key leaves the binding and anchor fingerprint unchanged; see Section 4.2.6. 2.3. Anchor Uniqueness Enforcement The Registry Operator is the cross-Registrar enforcement point for the binding-uniqueness rules defined by [I-D.drake-agent-identity-registry]. In global, a scarcity-qualified sovereign or portable anchor fingerprint MUST NOT back more than one Agent Identity, ever. The server MUST reject a or that collides on any submitted anchor fingerprint. Enclave, virtual, and declared bindings likewise prevent reuse of the exact enrolled binding identifier, but that indexing does not create a physical- scarcity claim. The test namespace is excluded from the production uniqueness index. Enforcement is authoritative at object transformation: a or command that would violate the applicable anchor-binding policy MUST be rejected with EPP result code 2308 ("Data management policy violation"). The command (Section 4.1.1) provides an advisory pre-flight query keyed by anchor fingerprint. A positive check is not a reservation; transform-time serialization through the authoritative index preserves the invariant under races. Drake Expires 29 March 2027 [Page 6] Internet-Draft EPP Agent Identity Mapping September 2026 The permanent-state resource limits of the Registry architecture also apply at transformation time. The server MUST enforce finite limits on bindings and retained proof-key history for each Agent Identity. A or that would exceed those limits MUST be rejected with EPP result code 2308. Such limits are independent of the free base-enrollment requirement. Availability and collision responses are deliberately minimal. They state only that a submitted fingerprint is available or unavailable, and MUST NOT identify the Agent Identity holding a binding, its Registrar, binding date, or proof key. See Section 11 for the residual membership oracle. 2.4. Sponsorship An operational Agent Identity normally has one sponsoring EPP client, but the architecture also permits an identity to have no current sponsoring Registrar after Registrar suspension or de-accreditation and before an actor-authorized transfer completes. In that state the identity remains present and resolvable, and is absent from its EPP information response. A Handle remains bound and reserved to its Agent Identity while that identity is unsponsored. Its sponsoring client MUST equal the identity's sponsoring client when one exists, and is absent when the identity is unsponsored. Handles are not independently transferable: successful actor-authorized transfer of the Agent Identity establishes the gaining Registrar as sponsor of both objects. No losing-Registrar approval is implied by Handle state. 2.5. Service Element Declaration Servers implementing this specification include the namespace URIs urn:ietf:params:xml:ns:epp:aid-1.0 and urn:ietf:params:xml:ns:epp:aidHandle-1.0 in elements of the EPP , and clients include them in the command, as described in [RFC5730]. This document defines no additional EPP extension namespace for Handle grace periods; see Section 6.3. 2.6. Transport This mapping is transported over TCP as specified in [RFC5734], protected with TLS [RFC9846]. Registry policy governs client certificate requirements; the mutual-TLS expectations of the registry architecture apply unchanged. Drake Expires 29 March 2027 [Page 7] Internet-Draft EPP Agent Identity Mapping September 2026 3. Agent Identity Object Attributes The EPP Agent Identity object carries only the provisioning state required by the canonical Agent Identity Record in [I-D.drake-agent-identity-registry]. Mutable display, operator, contact, certification, capability, and reputation attributes are intentionally not part of this mapping. Identifier The server-allocated permanent canonical-form URN, returned in . Repository Object Identifier Returned in . Statuses See Section 3.1. Maximum active trust tier A server-derived summary of the strongest currently active and assurance-qualified binding, using the Registry taxonomy. It is not client-settable. Bindings One or more permanent bindings (Section 2.2), each carrying an anchor fingerprint, hardware type code, Registry-recognized manufacturer or evidence-profile identifier when applicable, active operational proof-key SPKI, binding timestamp, and binding status. The server retains required historical proof-key and binding state even where only the current key is returned by this mapping. Handle linkage The Handle object naming this identity, if one exists. Sponsorship and event data The current sponsoring client identifier when one exists, plus creating/updating client and event timestamps as in [RFC5730]. Agent Identity objects do not expire. The current sponsor field is absent in the valid no-authorized- Registrar state described in Section 2.4. 3.1. Status Values An Agent Identity object MUST always have at least one associated status value. Status values that can be added or removed by the sponsoring client are prefixed with "client"; those managed by the server are prefixed with "server" or carry no prefix. As in [RFC5731], "ok" is the default status, MAY only be combined with no other status, and is managed solely by the server. ok Normal state; no operations pending or prohibited. inactive The identity has been voluntarily decommissioned Drake Expires 29 March 2027 [Page 8] Internet-Draft EPP Agent Identity Mapping September 2026 (Section 4.2.3). All bindings are disabled, the object no longer proves current AIRS control, and the historical record is retained permanently. hardwareLocked The identity is irreversibly pinned to one anchor binding (Section 4.2.6.1). No later may add or remove a binding or migrate to another anchor. Operational proof-key rotation within the retained binding, Registrar transfer, and voluntary decommissioning remain permitted. pendingTransfer A transfer request is awaiting completion (Section 4.2.5). clientUpdateProhibited, serverUpdateProhibited Update requests are prohibited except removal of the client form by its sponsoring client. clientDeleteProhibited, serverDeleteProhibited Voluntary decommission requests are prohibited while the status applies. A client MAY use its client form as an accidental-decommission guard; it does not create an administrative decommission authority. There are no pendingCreate, pendingRenew, pendingDelete, redemption, or Registrar-controlled transfer-prohibited states. Creation is synchronous, identities do not renew or expire, decommissioning retains the historical object, and Registrar transfer is authorized by the actor as specified in Section 4.2.5.1. 4. EPP Command Mapping for Agent Identity Objects A detailed description of the EPP syntax and semantics can be found in [RFC5730]. The command mappings described here are specifically for use in provisioning and managing Agent Identity objects via EPP. 4.1. EPP Query Commands 4.1.1. EPP Command Because canonical identifiers are server allocated, Agent Identity tests anchor-fingerprint availability rather than object-name availability. The request contains an OPTIONAL element (default global) followed by one or more values. For production global, these are the proposed enrolled anchor identifiers whose reuse rules are defined in Section 2.3; for test they query only the isolated non-production index. Drake Expires 29 March 2027 [Page 9] Internet-Draft EPP Agent Identity Mapping September 2026 The response contains one per requested fingerprint. Its avail attribute is true when the value is not already reserved by the applicable index and false otherwise. An OPTIONAL reason is limited to a constant class such as "Bound". A positive response is advisory only and does not reserve the anchor; transform-time enforcement remains authoritative. 4.1.2. EPP Command EPP retrieves an Agent Identity object by canonical identifier. A current sponsoring client receives the provisioning state needed to manage its object, including the binding inventory and current proof-key information exposed by this mapping. Other EPP clients MUST NOT receive elements or operational proof- key material. The current is omitted when the identity has no sponsoring Registrar. An OPTIONAL child requests the fresh Registry actor-authorization challenge defined in Section 4.1.3. When granted, the response includes in . Challenge issuance does not widen disclosure of binding information and does not itself authorize any transform. The full request and response element order is defined by Section 13.1. For example, an unsponsored identity's response omits while retaining its canonical identifier, lifecycle status, and historical event data. 4.1.3. Actor-Authorization Challenge Before a client submits a transform requiring actor authorization, it obtains a fresh challenge from the Registry Operator. The client sends an EPP command for the canonical identifier with an OPTIONAL child whose required op attribute is one of bindingUpdate, tierTransition, proofKeyRotate, hardwareLock, registrarTransfer, or decommission. Requesting a challenge has no transform semantics and grants the requesting Registrar no authority over the object. Drake Expires 29 March 2027 [Page 10] Internet-Draft EPP Agent Identity Mapping September 2026 If the client is an accredited Registrar permitted to relay the requested operation, the successful response includes an child containing , at least 128 bits of unpredictable server-generated , the operation identifier, and . The challenge is single-use. The Registry MUST reject reuse after one successful transform and MUST reject it for another object, operation, or after expiry. A challenge MAY be issued while the identity has no current sponsor; this enables an accredited gaining Registrar to relay an actor- authorized transfer without a losing Registrar. Challenge issuance follows the transform's relay authority. Binding changes, proof-key rotation, and hardware lock are relayed only by the current sponsoring Registrar. A Registrar transfer challenge is issued to the accredited gaining Registrar named by the eventual transfer target. A decommission challenge may be issued to the current sponsor or, when no sponsor exists, to another accredited Registrar acting only as a relay. These rules do not grant a Registrar actor-control authority; the signed proof remains mandatory. 4.1.4. EPP Query Command The EPP command with the "op" attribute value "query" retrieves the state of the most recent transfer request for an Agent Identity object. No authorization proof is required for the query form, but the server MUST reject queries from clients that are neither the current sponsoring client nor the requesting client of the transfer with error 2201. Example query command: C: C: C: C: C: C: urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg C: C: C: ABC-12351 C: C: Example query response: Drake Expires 29 March 2027 [Page 11] Internet-Draft EPP Agent Identity Mapping September 2026 S: S: S: S: S: Command completed successfully S: S: S: S: urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg S: pending S: NEWREG S: 2026-07-07T02:16:04Z S: 1IDCOM S: 2026-07-12T02:16:04Z S: S: S: S: ABC-12351 S: 54327-XYZ S: S: S: 4.1.5. EPP Command This mapping does not alter the EPP poll mechanism of [RFC5730]. Agent Identity transfer notifications use the defined by this mapping. Other Registry service notifications MAY use ordinary EPP service messages and do not themselves authorize any object transformation. 4.2. EPP Transform Commands 4.2.1. Actor Authorization EPP client authentication proves which Registrar sent a command; it does not prove the actor consent required by the Registry architecture. A transform that changes active binding/proof-key state, sponsoring Registrar, irreversible hardware-lock state, or lifecycle state therefore carries one or more elements. Each element is a compact JSON Web Signature (JWS) [RFC7515] produced by an operational proof key over a JSON object. The JWS protected header MUST contain exactly two members: alg, naming an asymmetric signature algorithm registered in the IANA JSON Web Signature and Encryption Algorithms registry established by [RFC7518], compatible with the authoritative proof public key, and permitted by Registry cryptographic policy; and typ="airs-actor- Drake Expires 29 March 2027 [Page 12] Internet-Draft EPP Agent Identity Mapping September 2026 auth+jws". The none algorithm, MAC algorithms, algorithm/key-type mismatches, and additional protected-header members MUST be rejected. Verification uses the authoritative active proof key in the Registry record, or the proposed binding's proof key where this section explicitly requires a candidate proof; a JWS never supplies its own authority key. The JWS payload is a UTF-8 JSON object [RFC8259] with exactly these top-level members: v (integer 1), aid (canonical identifier), op, role ("current" or "candidate"), anchor_fp (the signing binding's anchor fingerprint), challenge_id, nonce (base64url), expires (the exact RFC 3339 challenge expiry string), and target. v MUST be 1. aid, op, role, and anchor_fp MUST match the transform and signing binding; challenge_id, nonce, and expires MUST exactly match the unconsumed Registry challenge. The server compares target semantically with the EPP transform; JSON member ordering and insignificant whitespace are therefore not part of the protocol. Unknown top-level or target members MUST cause authorization failure. The target object is operation-specific: bindingUpdate add is an array containing each proposed binding's anchor_fp, SHA-256 digest of the DER proof-key SPKI as proof_key_sha256 encoded as exactly 64 lowercase hexadecimal characters, and hw_type; mfr is included only when the corresponding element is present. disable is an array of anchor fingerprints. The server compares both arrays as sets to the command; duplicate entries are invalid. tierTransition The same target shape as bindingUpdate, but disable MUST name every active old-group binding and add contains the proposed higher-group binding or bindings. proofKeyRotate anchor_fp identifies the unchanged binding and proof_key_sha256 is SHA-256 of the replacement DER SPKI encoded as exactly 64 lowercase hexadecimal characters. hardwareLock anchor_fp identifies the sole binding being irreversibly retained. registrarTransfer gaining_clid is the EPP client identifier of the gaining Registrar. decommission target is an empty object; the canonical identifier and operation already bind the irreversible action. Drake Expires 29 March 2027 [Page 13] Internet-Draft EPP Agent Identity Mapping September 2026 A valid current-role proof MUST verify with a currently active operational proof key whose binding is identified by anchor_fp. For each binding being added, a candidate-role proof over the same challenge and target MUST additionally verify with that proposed binding's submitted . Cross-group transitions therefore include at least one current-role and one candidate-role proof over the same challenge. A missing, malformed, expired, replayed, mismatched, or invalid actor authorization MUST be rejected with EPP result code 2202 ("Authorization error"). 4.2.2. EPP Command The EPP command provisions a new Agent Identity object. The client supplies with value global or test and one or more bindings as defined in Section 2.2. A production Registrar MUST NOT submit global creation until it has completed the tier-appropriate enrollment ceremony in [I-D.drake-agent-identity-registry], including proof of control of each operational proof key and validation of its relationship to the submitted anchor. The Registry trusts that accredited enrollment assertion; this initial creation has no pre- existing actor proof key with which to authorize itself. The server MUST atomically validate the submitted binding set against the Registry compatibility rules and the applicable authoritative anchor index. Any anchor reuse or binding-set violation MUST be rejected with EPP result code 2308. For an anchor collision, the server SHOULD identify the offending in with a constant reason such as "Anchor bound", but MUST NOT identify the holding object or Registrar. On success the server allocates the canonical identifier, creates the permanent binding records, derives the maximum active trust tier, and records the submitting client as creating and current sponsoring client. The successful response returns containing the allocated canonical identifier, repository object identifier, and creation date. The complete request/response syntax is defined by Section 13.1. 4.2.3. EPP Command For an Agent Identity object, EPP means voluntary irreversible decommissioning, not erasure. The command contains the canonical identifier and a valid for operation decommission using a fresh Registry challenge from Section 4.1.3. An accredited Registrar MAY relay this command even when the identity currently has no sponsoring Registrar. No Registrar, Registry Operator, or Governance Authority is granted an administrative decommission bypass. Drake Expires 29 March 2027 [Page 14] Internet-Draft EPP Agent Identity Mapping September 2026 On successful authorization the server atomically disables every active binding, sets the identity lifecycle status to inactive, and retains the canonical record and all anchor/proof-key history permanently. A linked Handle remains historically bound and reserved to the identity; decommissioning does not reassign it. There is no redemption grace period because no identity record is pending purge. 4.2.4. EPP Command Renewal semantics do not apply to Agent Identity objects: they have no expiry or validity period. This mapping defines no element for Agent Identity objects, and a server MUST respond to any attempt with error 2101 ("Unimplemented command"). 4.2.5. EPP Command EPP changes only the identity's current sponsoring Registrar. The request is submitted by the gaining Registrar and contains the canonical identifier plus actor authorization for operation registrarTransfer, whose target gaining_clid MUST equal the EPP session client. Binding history, identifier, lifecycle state, and Handle linkage do not change. 4.2.5.1. Transfer Authorization Transfer uses the generic Registry challenge and construction of Section 4.1.3 and Section 4.2.1. The current-role signature MUST verify with an active operational proof key. There is no EPP authorization-information password and the losing Registrar's consent is not part of authorization. 4.2.5.2. Transfer Processing When a current sponsor exists, a verified request MAY enter pendingTransfer for a Registry-policy notification interval. The server records the anchor fingerprint and proof-key version that authorized the request. The losing Registrar is notified through the EPP poll queue, but the notification grants no veto over an actor- authorized transfer. Immediately before deferred completion the server MUST verify that the identity remains operational and the authorizing binding and proof-key version remain active; if not, the pending authorization is canceled and a fresh Registry challenge and actor authorization are required. Drake Expires 29 March 2027 [Page 15] Internet-Draft EPP Agent Identity Mapping September 2026 When the identity has no current sponsor, the Registry MUST NOT impose a losing-Registrar approval, notification, or waiting step. A valid request from an accredited gaining Registrar completes immediately. On completion the gaining client becomes current sponsor of the Agent Identity and of its linked Handle, if any. The Handle remains the same object and label. MAY complete a pending transfer early when sent by the current sponsor; cancel MAY be sent by the gaining client. The reject option is not implemented for Agent Identity objects because the losing Registrar has no veto; a server receiving that option MUST return result code 2102 ("Unimplemented option"). 4.2.6. EPP Command EPP manages binding state, operational proof-key rotation, the irreversible hardware lock, and client status values. Client status-only changes use ordinary sponsoring-client authorization. Every change to active binding/proof-key state or hardware lock additionally requires the actor authorization of Section 4.2.1. An Agent Identity command is accepted only from the current sponsoring Registrar; an unsponsored actor first selects a Registrar using Section 4.2.5. An Agent Identity MUST contain at least one effective change. An update containing only , or an empty , MUST be rejected with result code 2306. A single command MUST contain at most one actor-controlled operation: a binding update or tier transition, one proof-key rotation, or hardware lock. Client status changes MUST be sent in a separate status-only . Servers MUST reject combinations that would require more than one op value or more than one operation-specific signed target. and A same-compatibility-group binding change uses operation bindingUpdate. carries each complete proposed binding and names bindings by ; removal permanently disables the binding rather than erasing it. The request MUST contain at least one current-role actor proof and one candidate-role proof for each new binding, all over the same challenge and target. The server MUST NOT commit a non- decommissioning update that leaves the identity with no active proof key. Cross-group transition An upward compatibility-group transition uses Drake Expires 29 March 2027 [Page 16] Internet-Draft EPP Agent Identity Mapping September 2026 operation tierTransition. The removal set MUST name every currently active old-group binding, the addition set contains the proposed higher-group binding(s), and current and candidate keys sign the same Registry challenge/target. The server commits the addition and permanent old-group disablement atomically. A downgrade MUST be rejected with result code 2308. Rotates the operational proof key inside one permanent sovereign or portable binding, whose anchor fingerprint does not depend on that key. The server MUST reject it with result code 2306 for an enclave, virtual, or declared binding, whose anchor fingerprint is derived from the proof key; such a key is replaced by a bindingUpdate that adds the new binding and removes the old one in the same command. It carries the unchanged and replacement DER SPKI in , with operation proofKeyRotate authorized by the binding's current proof key. Before submission the Registrar MUST revalidate the replacement key's relationship to the enrolled anchor at the claimed tier. The server retains the old proof key in history and MUST NOT change the anchor fingerprint. Manages client status values and the irreversible . No display, operator, contact, or other higher-layer metadata is carried by this mapping. The server recomputes the maximum active trust tier from active, assurance-qualified bindings after every committed binding mutation. Anchor collisions and binding policy violations use result code 2308 and the non-disclosure rule of Section 2.3. 4.2.6.1. Hardware Lock Setting true requests the irreversible single- binding profile. The command MUST contain operation hardwareLock actor authorization signed by the sole active binding being retained, and its target anchor_fp MUST identify that binding. The server rejects the request unless exactly one active binding exists, rejects false in every circumstance, and on success permanently rejects any later that adds or removes a binding or migrates to another anchor. Operational proof-key rotation within the retained binding remains permitted under Section 4.2.6; Registrar transfer and voluntary decommissioning also remain possible. Drake Expires 29 March 2027 [Page 17] Internet-Draft EPP Agent Identity Mapping September 2026 5. Handle Object Attributes A Handle object provisions the optional human-readable alias defined by the Registry specification. It contains the handle-form URN, repository object identifier, immutable link to one canonical Agent Identity identifier, status values, OPTIONAL current sponsorship, event data, and an expiry date. Handle syntax and retirement semantics are owned by [I-D.drake-agent-identity-registry] and are not redefined here. When the linked Agent Identity has a current sponsoring Registrar, the Handle MUST have the same sponsor. When the identity enters the valid no-current-Registrar state, the Handle becomes unsponsored too: its identity linkage and label reservation remain intact and is absent. Expiry or disablement while unsponsored MUST NOT cause the label to be assigned to another identity merely because there is no Registrar available to renew it. An actor- authorized identity transfer establishes the gaining Registrar as sponsor of both objects. 5.1. Status Values ok Normal state. MAY only be combined with no other status; managed solely by the server. disabled The handle does not currently resolve as an active alias. It may result from non-renewal after applicable grace processing, voluntary release, or decommissioning of the linked identity. A disabled handle MAY be reactivated for the same identity when policy permits. Registrar suspension/de-accreditation does not by itself change the identity linkage or free the label. retired Terminal, server-managed. Applied under the Registry/ Governance retire-only dispute rule. A retired handle MUST NOT be renewed, reactivated, transferred, or assigned to any identity, ever. pendingDelete Server-managed Handle grace-processing state before a transition to disabled. It never implies deletion of the historical object or reassignment of the canonical identity. clientRenewProhibited, serverRenewProhibited, clientUpdateProhibited, serverUpdateProhibited, clientDeleteProhibited, serverDeleteProhibited Have their ordinary EPP prohibition meanings for the naming-layer Handle object. There is no pendingTransfer status: Handles do not transfer independently of their linked Agent Identity. Drake Expires 29 March 2027 [Page 18] Internet-Draft EPP Agent Identity Mapping September 2026 6. EPP Command Mapping for Handle Objects 6.1. EPP Query Commands 6.1.1. EPP Command The EPP command determines whether a handle can be provisioned, exactly as for domain names. The command contains one or more elements. Reserved labels (per the reserved-list requirements of the registry architecture) are reported unavailable with reason "Reserved". Example command: C: C: C: C: C: C: urn:aid:global:ferrous C: urn:aid:global:crusty C: urn:aid:global:registry C: C: C: ABC-12353 C: C: Example response: Drake Expires 29 March 2027 [Page 19] Internet-Draft EPP Agent Identity Mapping September 2026 S: S: S: S: S: Command completed successfully S: S: S: S: S: urn:aid:global:ferrous S: S: S: urn:aid:global:crusty S: In use S: S: S: urn:aid:global:registry S: S: Reserved S: S: S: S: S: ABC-12353 S: 54330-XYZ S: S: S: 6.1.2. EPP Command EPP retrieves the Handle object, including its immutable canonical-identity linkage, status, event dates, and expiry. Handle information contains no anchor or proof-key material and is returned according to normal EPP authorization policy. is present only when the linked Agent Identity currently has a sponsoring Registrar. It is absent in the no- current-Registrar state of Section 2.4. Creation and historical event identifiers remain present as defined by the schema and are not rewritten when sponsorship changes. Drake Expires 29 March 2027 [Page 20] Internet-Draft EPP Agent Identity Mapping September 2026 6.1.3. EPP Query Command Transfer semantics do not apply to Handle objects (Section 2.4). This mapping defines no element for Handle objects, and a server MUST respond to any attempt with error 2101. 6.2. EPP Transform Commands 6.2.1. EPP Command EPP provisions a Handle bound to an existing operational Agent Identity. The submitting client MUST be that identity's current sponsoring Registrar; an unsponsored identity must first complete actor-authorized Registrar transfer. The server rejects an unavailable or reserved label with result code 2302, an inactive identity or an identity that already has an active Handle with 2304, and invalid handle syntax with 2306. An OPTIONAL period carries the initial registration period according to Registry policy. Creation fixes the Handle's canonical-identity linkage for its lifetime. No EPP operation can transfer a Handle to another identity; successful identity sponsorship transfer changes only the servicing Registrar as described in Section 2.4. 6.2.2. EPP Command EPP voluntarily disables a Handle and is accepted only from the linked identity's current sponsoring Registrar. It does not erase the Handle object or alter the linked Agent Identity. Any later reactivation or release policy is governed by the Handle lifecycle in [I-D.drake-agent-identity-registry]. A handle that has entered the terminal retired state MUST never be released or reassigned. 6.2.3. EPP Command EPP extends the validity of a Handle using the ordinary EPP period and current-expiry guard conventions. Only the linked identity's current sponsor can renew. Subject to Registry policy, renewal may also reactivate a disabled Handle that is still reserved to the same identity. An unsponsored Handle cannot be renewed until actor-authorized identity transfer establishes a new sponsor, but the no-sponsor interval by itself MUST NOT reassign its label. Drake Expires 29 March 2027 [Page 21] Internet-Draft EPP Agent Identity Mapping September 2026 6.2.4. EPP Command Not defined; see Section 6.1.3. Sponsorship of a Handle object changes only as a side effect of transfer of its linked Agent Identity object (Section 4.2.5.2). 6.2.5. EPP Command EPP adds or removes client-managed Handle status values. The label and canonical-identity linkage are immutable, and the Handle carries no authorization-information secret or actor-control key. This command is available only to the current sponsor. It MUST contain at least one effective status addition or removal; an update containing only MUST be rejected with result code 2306. 6.3. Grace Periods Registry policy MAY provide grace intervals around Handle creation, renewal, expiry, and voluntary disablement. Such intervals affect only the naming-layer Handle and never the linked Agent Identity object. This mapping represents a delayed disablement with the Handle's pendingDelete status and ultimately transitions the Handle to disabled. Grace processing itself never purges the historical object, changes its identity linkage, or releases the label. Any later release policy for a disabled (but not retired) label is outside this mapping and remains subject to the Registry/Governance Handle policy. The Registry Grace Period extension [RFC3915] is specific to the EPP domain-name mapping and is not extended to Handle objects by this document. In particular, implementations MUST NOT emit rgp: extension elements for a Handle merely by substituting "Handle" for "domain" in RFC 3915. A future object-generic or Handle-specific grace-period extension could be profiled separately. Registries remain free to reuse existing billing and grace-policy machinery internally. 7. Lifecycle Mapping +=======================+======================================+ | Lifecycle event | EPP realization | +=======================+======================================+ | Anchor pre-flight | Agent Identity | +-----------------------+--------------------------------------+ | Initial enrollment | Agent Identity | +-----------------------+--------------------------------------+ | Binding addition/ | plus Registry challenge and | Drake Expires 29 March 2027 [Page 22] Internet-Draft EPP Agent Identity Mapping September 2026 | disable | | +-----------------------+--------------------------------------+ | Cross-group upgrade | with tierTransition joint | | | authorization | +-----------------------+--------------------------------------+ | Operational proof-key | | | rotation | | +-----------------------+--------------------------------------+ | Hardware lock | plus | | | actor authorization | +-----------------------+--------------------------------------+ | Registrar transfer | Agent Identity plus actor | | | authorization | +-----------------------+--------------------------------------+ | Registrar suspension/ | Server removes sponsorship/issuer | | de-accreditation | authority; no successor is assigned. | | | Later transfer is actor-authorized. | +-----------------------+--------------------------------------+ | Voluntary | Agent Identity plus actor | | decommissioning | authorization; historical object | | | retained | +-----------------------+--------------------------------------+ | Handle | Handle object commands; Handle never | | create/renew/update/ | transfers independently | | delete | | +-----------------------+--------------------------------------+ | Handle dispute | Server-side terminal retired state | | retirement | plus poll notice | +-----------------------+--------------------------------------+ Table 1: Registry Lifecycle Events in EPP EPP client authentication authorizes Registrar-managed naming and status operations. AIRS actor-control transitions are intentionally different: they additionally require the Registry-verifiable proof of Section 4.2.1. There is no EPP authInfo password for Agent Identity objects. 8. Data Escrow Registry data escrow is an operational/governance requirement, not an EPP command. [RFC8909] defines an object-agnostic Registry Data Escrow (RDE) container and explicitly requires an independent specification for each object type to be escrowed. The EPP and structures defined here are therefore NOT, by themselves, an interoperable RFC 8909 escrow object mapping. Drake Expires 29 March 2027 [Page 23] Internet-Draft EPP Agent Identity Mapping September 2026 This document does not define that RDE object-specific schema or its confidentiality/signaling profile. An AIRS deployment using RFC 8909 MUST define those pieces separately and include enough canonical identity, sponsorship, Handle, permanent anchor/proof-key history, and lifecycle state to reconstruct Registry service, subject to the escrow and privacy policy of [I-D.drake-agent-identity-governance]. Private authentication credentials MUST NOT be escrowed, consistent with RFC 8909. 9. Internationalization Considerations Handle labels are restricted by the registry architecture to lowercase ASCII letters, digits, and hyphens (LDH) with a leading letter. This mapping performs no internationalized label processing: there are no A-labels or U-labels, no IDNA mapping, and no normalization beyond the schema-enforced syntax; servers MUST reject non-conforming labels with error 2306. Presentation of handles to humans, including any localized display conventions, is a relying- party concern addressed in the registry architecture. Registry Operators SHOULD apply confusable-label policies within the LDH repertoire (e.g., digit/letter lookalikes) through their reserved lists; a future extension could define internationalized handle labels, and would need to address the full set of IDNA and confusability issues that domain registries have encountered. 10. IANA Considerations 10.1. XML Namespaces This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Two URN assignments are requested. Registration request for the Agent Identity namespace: * URI: urn:ietf:params:xml:ns:epp:aid-1.0 * Registrant Contact: IESG * XML: None. Namespace URIs do not represent an XML specification. Registration request for the Handle namespace: * URI: urn:ietf:params:xml:ns:epp:aidHandle-1.0 * Registrant Contact: IESG * XML: None. Namespace URIs do not represent an XML specification. Drake Expires 29 March 2027 [Page 24] Internet-Draft EPP Agent Identity Mapping September 2026 10.2. XML Schemas Two schema assignments are requested. Registration request for the Agent Identity schema: * URI: urn:ietf:params:xml:schema:epp:aid-1.0 * Registrant Contact: IESG * XML: See Section 13.1 of this document. Registration request for the Handle schema: * URI: urn:ietf:params:xml:schema:epp:aidHandle-1.0 * Registrant Contact: IESG * XML: See Section 13.2 of this document. 10.3. EPP Extension Registry The EPP mappings described in this document should be registered by IANA in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry described in [RFC7451]. Two registrations are requested; both use the registration policy "Specification Required". Registration for the Agent Identity object mapping: Name of Extension EPP Mapping for Agent Identity Objects Document Status Experimental Reference This document Registrant Name and Email Address IESG, iesg@ietf.org TLDs Any IPR Disclosure None Status Active Notes None Registration for the Handle object mapping: Name of Extension EPP Mapping for Agent Identity Handle Objects Drake Expires 29 March 2027 [Page 25] Internet-Draft EPP Agent Identity Mapping September 2026 Document Status Experimental Reference This document Registrant Name and Email Address IESG, iesg@ietf.org TLDs Any IPR Disclosure None Status Active Notes None The "aid" URN namespace and its production namespace semantics are specified by [I-D.drake-agent-identity-registry] and are not re- registered here. 11. Security Considerations The security considerations of [RFC5730], [RFC5731], and the Registry architecture apply. This section covers only risks introduced by this provisioning mapping. Registrar authentication to EPP and actor authorization are separate security boundaries. A Registrar is trusted to perform the tier- appropriate enrollment verification before it provisions an anchor and proof key, but a Registrar MUST NOT be able to manufacture consent for later control-state changes. The fresh Registry challenge and rules therefore protect binding addition/disablement, proof-key rotation, hardware lock, Registrar transfer, and decommissioning. Servers MUST compare every signed target with the actual EPP transform, enforce challenge single-use and expiry, and verify current-role proofs only with authoritative active proof keys. Candidate keys are accepted only for the new- binding control proofs explicitly required by Section 4.2.1. Anchor uniqueness is correctness-critical. Production transforms MUST serialize through the authoritative global binding index; relaxing this for availability can violate the scarce-anchor invariant. Check and collision responses reveal only available/ unavailable, but still form a membership oracle for parties that already know an anchor fingerprint. Registries SHOULD rate-limit such queries and MUST NOT disclose the holding identity or Registrar. Permanent anchor history makes mistaken enrollment costly: disabling a binding does not erase or free its reserved anchor identifier. Registrars SHOULD therefore verify enrollment evidence and submitted Drake Expires 29 March 2027 [Page 26] Internet-Draft EPP Agent Identity Mapping September 2026 anchor/proof-key relationships before irreversible create/add operations. Likewise, hardware lock and decommissioning are irreversible and require explicit actor authorization. A pending Registrar transfer is authorized by a particular active binding/proof-key version. The Registry MUST recheck that authorization source immediately before deferred completion. Registrar suspension/de-accreditation never creates an administrative successor or identity-recovery path. If no active proof key remains, AIRS preserves the historical identity but this mapping cannot restore control. Handle retirement is terminal. A compromised Registrar cannot use the dispute mechanism to transfer a Handle to a favored identity; the corresponding denial risk of erroneous retirement is a governance- policy matter outside this wire protocol. 12. Privacy Considerations This mapping intentionally excludes mutable operator/contact attributes from the canonical Agent Identity object. The main provisioning-sensitive data are anchor fingerprints, operational public keys, manufacturer/issuer metadata, and the commercial relationship represented by sponsorship. An EPP server MUST NOT expose a mapping from anchor fingerprint to holding identity or sponsoring Registrar through or collision errors. To a client that is not the current sponsor, Agent Identity MUST omit binding details including anchor fingerprints and proof keys. The valid no-sponsor state does not relax this rule: an accredited Registrar may obtain a fresh operation challenge where permitted, but that does not grant access to another actor's private binding inventory. The EPP event trail necessarily reveals Registrar relationships to the Registry Operator. Cross-Registrar disclosure of current/ historical sponsorship SHOULD be limited to what EPP operation and audit requirements need. Public resolution and application-layer privacy are specified by their respective companion documents rather than duplicated here. 13. Formal Syntax The following XML Schemas normatively define the Agent Identity and Handle object mappings specified by this document. 13.1. Agent Identity Schema Drake Expires 29 March 2027 [Page 27] Internet-Draft EPP Agent Identity Mapping September 2026 EPP Agent Identity object mapping version 1.0. Drake Expires 29 March 2027 [Page 28] Internet-Draft EPP Agent Identity Mapping September 2026 Drake Expires 29 March 2027 [Page 29] Internet-Draft EPP Agent Identity Mapping September 2026 Drake Expires 29 March 2027 [Page 30] Internet-Draft EPP Agent Identity Mapping September 2026 Drake Expires 29 March 2027 [Page 31] Internet-Draft EPP Agent Identity Mapping September 2026 Drake Expires 29 March 2027 [Page 32] Internet-Draft EPP Agent Identity Mapping September 2026 Drake Expires 29 March 2027 [Page 33] Internet-Draft EPP Agent Identity Mapping September 2026 13.2. Handle Schema Drake Expires 29 March 2027 [Page 34] Internet-Draft EPP Agent Identity Mapping September 2026 EPP Agent Identity Handle object mapping version 1.0. Drake Expires 29 March 2027 [Page 35] Internet-Draft EPP Agent Identity Mapping September 2026 Drake Expires 29 March 2027 [Page 36] Internet-Draft EPP Agent Identity Mapping September 2026 Drake Expires 29 March 2027 [Page 37] Internet-Draft EPP Agent Identity Mapping September 2026 14. Acknowledgments This mapping follows the structure established by the EPP domain name mapping [RFC5731]; readers familiar with that document will recognize most of the machinery here. The author thanks the participants of the IETF REGEXT working group whose object mappings served as the template for this work. 15. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible Provisioning Protocol (EPP)", RFC 3735, DOI 10.17487/RFC3735, March 2004, . [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)", RFC 3915, DOI 10.17487/RFC3915, October 2004, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, . Drake Expires 29 March 2027 [Page 38] Internet-Draft EPP Agent Identity Mapping September 2026 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Transport over TCP", STD 69, RFC 5734, DOI 10.17487/RFC5734, August 2009, . [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, February 2015, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8909] Lozano, G., "Registry Data Escrow Specification", RFC 8909, DOI 10.17487/RFC8909, November 2020, . [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 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, . 16. Informative References Drake Expires 29 March 2027 [Page 39] Internet-Draft EPP Agent Identity Mapping 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.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, . Author's Address Christopher Drake 1id.com Australia Email: cnd@1id.com URI: https://1id.com Drake Expires 29 March 2027 [Page 40]