Extensible Provisioning Protocol (EPP) Mapping for Agent Identity and Handle Objects

Introduction The Agent Identity Registry System (, 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) , following the structure and conventions of the EPP domain name mapping and the guidelines for extending EPP . 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. 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.

Relationship to Other Documents This document provides the Registrar-to-Registry provisioning protocol (the write side) for the registry architecture defined in , which references this mapping as its provisioning interface. The public read side is the RDAP profile of . Transport-level attestation for email is defined in and is unaffected by this document.

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 <transfer> 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.

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 when, and only when, they appear in all capitals, as shown here. 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.

Terminology The terms "Agent Identity Record", "canonical identifier", "handle", "anchor fingerprint", "trust tier", "Registry Operator", "Registrar", and "Governance Authority" are used as defined in . "Sponsoring client" is used as in : the Registrar authorized to perform transform operations on an object.

Object Model

Object Identifiers An Agent Identity object is identified by its canonical-form URN in the "aid" URN namespace (), 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 . 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 <create> 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 .

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 and are not redefined here. A client provisions the anchor fingerprint in <aid:anchorFp> as 64 lowercase hexadecimal characters and the operational public key in <aid:proofKey> as base64-encoded DER SubjectPublicKeyInfo (SPKI), together with the hardware type code and, when applicable, a Registry-recognized manufacturer or evidence-profile identifier in <aid:mfr>. The server MUST reject an <aid:mfr> 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 . 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 <aid:proofKey>. 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 .

Anchor Uniqueness Enforcement The Registry Operator is the cross-Registrar enforcement point for the binding-uniqueness rules defined by . In global, a scarcity-qualified sovereign or portable anchor fingerprint MUST NOT back more than one Agent Identity, ever. The server MUST reject a <create> or <update> 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 <create> or <update> command that would violate the applicable anchor-binding policy MUST be rejected with EPP result code 2308 ("Data management policy violation"). The <check> command () 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. 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 <create> or <update> 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 for the residual membership oracle.

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 <aid:clID> 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 <aidHandle:clID> 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.

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 <objURI> elements of the EPP <greeting>, and clients include them in the <login> command, as described in . This document defines no additional EPP extension namespace for Handle grace periods; see .

Transport This mapping is transported over TCP as specified in , protected with TLS . Registry policy governs client certificate requirements; the mutual-TLS expectations of the registry architecture apply unchanged.

Agent Identity Object Attributes The EPP Agent Identity object carries only the provisioning state required by the canonical Agent Identity Record in . 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 <aid:id>.
Repository Object Identifier: Returned in <aid:roid>.
Statuses: See .
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 (), 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 . Agent Identity objects do not expire. The current sponsor field is absent in the valid no-authorized-Registrar state described in .

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 , "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 (). 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 (). No later <update> 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 ().
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 .

EPP Command Mapping for Agent Identity Objects A detailed description of the EPP syntax and semantics can be found in . The command mappings described here are specifically for use in provisioning and managing Agent Identity objects via EPP.

EPP Query Commands

EPP <check> Command Because canonical identifiers are server allocated, Agent Identity <check> tests anchor-fingerprint availability rather than object-name availability. The request contains an OPTIONAL <aid:ns> element (default global) followed by one or more <aid:anchorFp> values. For production global, these are the proposed enrolled anchor identifiers whose reuse rules are defined in ; for test they query only the isolated non-production index. The response contains one <aid:cd> 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.

EPP <info> Command EPP <info> 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 <aid:binding> elements or operational proof-key material. The current <aid:clID> is omitted when the identity has no sponsoring Registrar. An OPTIONAL <aid:challenge op="..."/> child requests the fresh Registry actor-authorization challenge defined in . When granted, the response includes <aid:authChallenge> in <aid:infData>. 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 . For example, an unsponsored identity's response omits <aid:clID> while retaining its canonical identifier, lifecycle status, and historical event data.

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 <info> command for the canonical identifier with an OPTIONAL <aid:challenge> 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. If the client is an accredited Registrar permitted to relay the requested operation, the successful <info> response includes an <aid:authChallenge> child containing <aid:challengeId>, at least 128 bits of unpredictable server-generated <aid:nonce>, the operation identifier, and <aid:expires>. 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.

EPP <transfer> Query Command The EPP <transfer> 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 <transfer> query command: C: C: C: C: C: urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg C: C: C: ABC-12351 C: C: ]]> Example <transfer> query response: 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: ]]>

EPP <poll> Command This mapping does not alter the EPP poll mechanism of . Agent Identity transfer notifications use the <aid:trnData> defined by this mapping. Other Registry service notifications MAY use ordinary EPP service messages and do not themselves authorize any object transformation.

EPP Transform Commands

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 <aid:actorAuth> elements. Each element is a compact JSON Web Signature (JWS) 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 , compatible with the authoritative proof public key, and permitted by Registry cryptographic policy; and typ="airs-actor-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 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 <aid:mfr> 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.

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 <aid:proofKey>. 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").

EPP <create> Command The EPP <create> command provisions a new Agent Identity object. The client supplies <aid:ns> with value global or test and one or more bindings as defined in . A production Registrar MUST NOT submit global creation until it has completed the tier-appropriate enrollment ceremony in , 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 <aid:anchorFp> in <extValue> 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 <create> response returns <aid:creData> containing the allocated canonical identifier, repository object identifier, and creation date. The complete request/response syntax is defined by .

EPP <delete> Command For an Agent Identity object, EPP <delete> means voluntary irreversible decommissioning, not erasure. The command contains the canonical identifier and a valid <aid:actorAuth> for operation decommission using a fresh Registry challenge from . 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. 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.

EPP <renew> Command Renewal semantics do not apply to Agent Identity objects: they have no expiry or validity period. This mapping defines no <renew> element for Agent Identity objects, and a server MUST respond to any attempt with error 2101 ("Unimplemented command").

EPP <transfer> Command EPP <transfer op="request"> 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.

Transfer Authorization Transfer uses the generic Registry challenge and <aid:actorAuth> construction of and . 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.

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. 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. <transfer op="approve"> 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").

EPP <update> Command EPP <update> 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 . An Agent Identity <update> command is accepted only from the current sponsoring Registrar; an unsponsored actor first selects a Registrar using . An Agent Identity <update> MUST contain at least one effective change. An update containing only <aid:id>, or an empty <aid:chg>, MUST be rejected with result code 2306. A single <update> 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 <update>. Servers MUST reject combinations that would require more than one op value or more than one operation-specific signed target.

<aid:add> and <aid:rem>: A same-compatibility-group binding change uses operation bindingUpdate. <aid:add> carries each complete proposed binding and <aid:rem> names bindings by <aid:anchorFp>; 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 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.
<aid:proofKeyChange>: 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 <aid:anchorFp> and replacement DER SPKI in <aid:proofKey>, 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.
<aid:chg>: Manages client status values and the irreversible <aid:hardwareLock>. 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 .

Hardware Lock Setting <aid:hardwareLock>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 <update> that adds or removes a binding or migrates to another anchor. Operational proof-key rotation within the retained binding remains permitted under ; Registrar transfer and voluntary decommissioning also remain possible.

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 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 <aidHandle:clID> 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.

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.

EPP Command Mapping for Handle Objects

EPP Query Commands

EPP <check> Command The EPP <check> command determines whether a handle can be provisioned, exactly as for domain names. The command contains one or more <aidHandle:name> elements. Reserved labels (per the reserved-list requirements of the registry architecture) are reported unavailable with reason "Reserved". Example <check> command: 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 <check> response: 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: ]]>

EPP <info> Command EPP <info> 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. <aidHandle:clID> is present only when the linked Agent Identity currently has a sponsoring Registrar. It is absent in the no-current-Registrar state of . Creation and historical event identifiers remain present as defined by the schema and are not rewritten when sponsorship changes.

EPP <transfer> Query Command Transfer semantics do not apply to Handle objects (). This mapping defines no <transfer> element for Handle objects, and a server MUST respond to any attempt with error 2101.

EPP Transform Commands

EPP <create> Command EPP <create> 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 .

EPP <delete> Command EPP <delete> 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 . A handle that has entered the terminal retired state MUST never be released or reassigned.

EPP <renew> Command EPP <renew> 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.

EPP <transfer> Command Not defined; see . Sponsorship of a Handle object changes only as a side effect of transfer of its linked Agent Identity object ().

EPP <update> Command EPP <update> 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 <aidHandle:name> MUST be rejected with result code 2306.

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 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.

Lifecycle Mapping Registry Lifecycle Events in EPP

Lifecycle event	EPP realization
Anchor pre-flight	Agent Identity `<check>`
Initial enrollment	Agent Identity `<create>`
Binding addition/disable	`<update>` plus Registry challenge and `<aid:actorAuth>`
Cross-group upgrade	`<update>` with `tierTransition` joint authorization
Operational proof-key rotation	`<update>` `<aid:proofKeyChange>`
Hardware lock	`<update>` `<aid:hardwareLock>` plus actor authorization
Registrar transfer	Agent Identity `<transfer>` plus actor authorization
Registrar suspension/de-accreditation	Server removes sponsorship/issuer authority; no successor is assigned. Later transfer is actor-authorized.
Voluntary decommissioning	Agent Identity `<delete>` plus actor authorization; historical object retained
Handle create/renew/update/delete	Handle object commands; Handle never transfers independently
Handle dispute retirement	Server-side terminal `retired` state plus poll notice

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 . There is no EPP authInfo password for Agent Identity objects.

Data Escrow Registry data escrow is an operational/governance requirement, not an EPP command. defines an object-agnostic Registry Data Escrow (RDE) container and explicitly requires an independent specification for each object type to be escrowed. The EPP <aid:infData> and <aidHandle:infData> structures defined here are therefore NOT, by themselves, an interoperable RFC 8909 escrow object mapping. 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 . Private authentication credentials MUST NOT be escrowed, consistent with RFC 8909.

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.

IANA Considerations

XML Namespaces This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in . 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.

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 of this document.

Registration request for the Handle schema:

URI: urn:ietf:params:xml:schema:epp:aidHandle-1.0
Registrant Contact: IESG
XML: See of this document.

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 . 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
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 and are not re-registered here.

Security Considerations The security considerations of , , 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 <aid:actorAuth> 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 . 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 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.

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 <check> or collision errors. To a client that is not the current sponsor, Agent Identity <info> 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.

Formal Syntax The following XML Schemas normatively define the Agent Identity and Handle object mappings specified by this document.

Agent Identity Schema EPP Agent Identity object mapping version 1.0. ]]>

Handle Schema EPP Agent Identity Handle object mapping version 1.0. ]]>

Acknowledgments This mapping follows the structure established by the EPP domain name mapping ; 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.