Internet-Draft EPP Agent Identity Mapping October 2026
Drake Expires 30 April 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-drake-agent-identity-epp-01
Published:
Intended Status:
Experimental
Expires:
Author:
C. Drake
1id.com

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

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 30 April 2027.

▲

Table of Contents

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.

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

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.

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 <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 [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 [I-D.drake-agent-identity-registry] 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. A manufacturer code is written exactly as recorded in the Global Hardware Trust Store: lowercase ASCII letters, digits, and hyphens. 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 <aid:proofKey>. For lower tiers the enrolled key instance supplies the anchor fingerprint; that does not imply physical scarcity.

The Registry retains the permanent anchor fingerprint and the binding's operational proof key. 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. The operational proof key of a binding is never replaced; a replacement is a new binding (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 <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 (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.

The permanent-state resource limits of the Registry architecture also apply at transformation time. The server MUST enforce finite limits on bindings 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 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 <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.

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 <objURI> elements of the EPP <greeting>, and clients include them in the <login> 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]. Mutual TLS authentication of client and server is REQUIRED, as in [RFC5734]; Registry policy governs which client certificates are accepted and how they are managed.

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 <aid:id>.
Repository Object Identifier
Returned in <aid:roid>.
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. It is <aid:maxTrust> here, maxActiveTrustTier in RDAP, and max_active_trust_tier in the Registry record.
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, operational proof-key SPKI, binding timestamp, and binding status.
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. All status values of an Agent Identity object are managed by the server; the sponsoring client cannot add or remove any. As in [RFC5731], "ok" is the default status and MAY only be combined with no other status.

ok
Normal state; no operations pending or prohibited.
inactive
The identity has been voluntarily decommissioned (Section 4.2.3). All bindings are disabled, the object no longer proves current AIRS control, and the historical record is retained permanently. This mapping defines the meaning of inactive for Agent Identity objects, not the meaning it has in [RFC5731]; public resolution reports it with the registered RDAP status inactive.
hardwareLocked
The identity is irreversibly pinned to one anchor binding (Section 4.2.6.1). No later <update> may add or remove a binding or migrate to another anchor. Registrar transfer and voluntary decommissioning remain permitted.
sponsorHold
The actor has turned on the sponsor hold (Section 4.2.6.2). Server-managed; set and cleared only by the operations of that section.
pendingTransfer
A transfer request is awaiting completion (Section 4.2.5).
serverUpdateProhibited, serverDeleteProhibited
Set by the Registry Operator only for technical processing that must not be interleaved with changes, such as restoration from escrow, and cleared when that processing ends. They MUST NOT be used to withhold an operation that carries valid actor authorization beyond that processing.

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.

A server recognizes a command that this mapping does not define (the Agent Identity <renew> and the Handle <transfer>) from the command element and the object namespace, and MUST answer result code 2101 before it validates the object payload against the schema.

4.1. EPP Query Commands

4.1.1. 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 Section 2.3; 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. The server MUST limit the number of <aid:anchorFp> values in one <check> by Registry policy, and answers a larger request with result code 2306.

4.1.2. 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, and receive <aid:handle>, <aid:maxTrust>, and the creating and updating client information only where Registry policy states an operational need for them; otherwise they receive what public resolution publishes: the canonical identifier, status values, and sponsoring client. 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 Section 4.1.3. 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 Section 13.1. For example, an unsponsored identity's response omits <aid:clID> 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 <info> command for the canonical identifier with an OPTIONAL <aid:challenge> child whose required op attribute is one of bindingUpdate, tierTransition, hardwareLock, registrarTransfer, transferCancel, sponsorHold, 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 server issues <aid:expires> in UTC in the form YYYY-MM-DDThh:mm:ssZ, with no fractional seconds. 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, hardware lock, transfer cancellation, and sponsor hold 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 <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:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <transfer op="query">
C:      <aid:transfer
C:        xmlns:aid="urn:ietf:params:xml:ns:epp:aid-1.0">
C:        <aid:id>urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg</aid:id>
C:      </aid:transfer>
C:    </transfer>
C:    <clTRID>ABC-12351</clTRID>
C:  </command>
C:</epp>

Example <transfer> query response:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <resData>
S:      <aid:trnData
S:        xmlns:aid="urn:ietf:params:xml:ns:epp:aid-1.0">
S:        <aid:id>urn:aid:global:id-qkckh-xxtcw-cxbvp-gpskg</aid:id>
S:        <aid:trStatus>pending</aid:trStatus>
S:        <aid:reID>NEWREG</aid:reID>
S:        <aid:reDate>2026-07-07T02:16:04Z</aid:reDate>
S:        <aid:acID>1IDCOM</aid:acID>
S:        <aid:acDate>2026-07-12T02:16:04Z</aid:acDate>
S:      </aid:trnData>
S:    </resData>
S:    <trID>
S:      <clTRID>ABC-12351</clTRID>
S:      <svTRID>54327-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

4.1.5. EPP <poll> Command

This mapping does not alter the EPP poll mechanism of [RFC5730]. 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.

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 <aid:actorAuth> 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-auth+jws". This typ value is private to this mapping and is not a registered media type; it exists so that an actor authorization cannot be accepted as any other 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 challenge expiry as issued), and target. v MUST be 1. aid, op, role, and anchor_fp MUST match the transform and signing binding; challenge_id and nonce MUST exactly match the unconsumed Registry challenge, and expires MUST denote the same instant. 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.
hardwareLock
anchor_fp identifies the sole binding being irreversibly retained.
sponsorHold
hold is true to turn the hold on or false to turn it off.
registrarTransfer
gaining_clid is the EPP client identifier of the gaining Registrar.
decommission and transferCancel
target is an empty object; the canonical identifier and operation already bind the 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 ("Invalid authorization information").

4.2.2. 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 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 <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 Section 13.1.

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

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

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

4.2.5.1. Transfer Authorization

Transfer uses the generic Registry challenge and <aid:actorAuth> 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 of the binding 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 remains active; if not, the pending authorization is canceled and a fresh Registry challenge and actor authorization are required. Other actor-authorized operations remain permitted while the transfer is pending.

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, or by the current sponsor with actor authorization for operation transferCancel, so that the actor can stop a pending transfer without the gaining Registrar's agreement. 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 <update> Command

EPP <update> manages binding state and the irreversible hardware lock. Every change to binding state or hardware lock requires the actor authorization of Section 4.2.1. An Agent Identity <update> command is accepted only from the current sponsoring Registrar; an unsponsored actor first selects a Registrar using Section 4.2.5.

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, hardware lock, or sponsor hold change. A hold release is sent in its own sponsor-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:chg>
Carries the irreversible <aid:hardwareLock>, the <aid:sponsorHold> change, or a sponsor's <aid:holdRelease>. No display, operator, contact, or other higher-layer metadata is carried by this mapping.

The server validates and commits each transform atomically for the Agent Identity object, against the state at the moment of commit: the signing binding is still active, the compatibility rules hold, and an active proof key remains. When two commands race, the second is evaluated against the result of the first. A challenge is consumed only by a successful transform.

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 <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 with result code 2306, and on success permanently rejects any later <update> that adds or removes a binding or migrates to another anchor. Registrar transfer and voluntary decommissioning remain possible.

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 <aidHandle:clID> is absent. Expiry or disablement never causes the label to be assigned to another identity. 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 stays reserved to its identity and is never assigned to another; the same identity MAY reactivate it. Registrar suspension/de-accreditation does not change the identity linkage.
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.

6. EPP Command Mapping for Handle Objects

6.1. EPP Query Commands

6.1.1. 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:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <check>
C:      <aidHandle:check
C:        xmlns:aidHandle=
C:          "urn:ietf:params:xml:ns:epp:aidHandle-1.0">
C:        <aidHandle:name>urn:aid:global:ferrous</aidHandle:name>
C:        <aidHandle:name>urn:aid:global:crusty</aidHandle:name>
C:        <aidHandle:name>urn:aid:global:registry</aidHandle:name>
C:      </aidHandle:check>
C:    </check>
C:    <clTRID>ABC-12353</clTRID>
C:  </command>
C:</epp>

Example <check> response:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <resData>
S:      <aidHandle:chkData
S:        xmlns:aidHandle=
S:          "urn:ietf:params:xml:ns:epp:aidHandle-1.0">
S:        <aidHandle:cd>
S:          <aidHandle:name
S:            avail="1">urn:aid:global:ferrous</aidHandle:name>
S:        </aidHandle:cd>
S:        <aidHandle:cd>
S:          <aidHandle:name
S:            avail="0">urn:aid:global:crusty</aidHandle:name>
S:          <aidHandle:reason>In use</aidHandle:reason>
S:        </aidHandle:cd>
S:        <aidHandle:cd>
S:          <aidHandle:name
S:            avail="0">urn:aid:global:registry
S:          </aidHandle:name>
S:          <aidHandle:reason>Reserved</aidHandle:reason>
S:        </aidHandle:cd>
S:      </aidHandle:chkData>
S:    </resData>
S:    <trID>
S:      <clTRID>ABC-12353</clTRID>
S:      <svTRID>54330-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

6.1.2. 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 Section 2.4. Creation and historical event identifiers remain present as defined by the schema and are not rewritten when sponsorship changes.

6.1.3. EPP <transfer> Query Command

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

6.2. EPP Transform Commands

6.2.1. 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, invalid handle syntax with 2306, and a Handle whose namespace differs from that of the identity 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 <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. A disabled Handle stays reserved to the same identity, which MAY reactivate it (Section 6.2.3), and MUST NOT be released or reassigned. A Handle in the terminal retired state can never be reactivated.

6.2.3. 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. Renewal may also reactivate a disabled Handle of the same identity; the server MUST reject with result code 2304 a renewal or reactivation that would leave the identity with more than one active Handle. 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.

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

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.

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

Table 1: 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
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 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 <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, lifecycle state, and the acknowledged-command records needed to reconcile a restored snapshot with the Registrars' records, 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.

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
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. The scope boundaries stated in the Security Considerations of [I-D.drake-agent-identity-registry] apply here as well: this mapping does not treat changed control of a credential, or misbehavior by a party that a Relying Party chose to trust, as a protocol failure.

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

A sponsor hold lets the sponsoring Registrar delay an operation the actor has authorized, but never perform one. It exists only while the actor keeps it on, and it lapses with the sponsorship, so a failed or hostile Registrar cannot keep an identity frozen.

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

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 

<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:epp:aid-1.0"
        xmlns:aid="urn:ietf:params:xml:ns:epp:aid-1.0"
        xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
        xmlns="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified">

  <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"/>

  <annotation><documentation>
    EPP Agent Identity object mapping version 1.0.
  </documentation></annotation>

  <!-- EPP command children. -->
  <element name="check" type="aid:checkType"/>
  <element name="create" type="aid:createType"/>
  <element name="delete" type="aid:deleteType"/>
  <element name="info" type="aid:infoType"/>
  <element name="transfer" type="aid:transferType"/>
  <element name="update" type="aid:updateType"/>

  <!-- EPP response children. -->
  <element name="chkData" type="aid:chkDataType"/>
  <element name="creData" type="aid:creDataType"/>
  <element name="infData" type="aid:infDataType"/>
  <element name="trnData" type="aid:trnDataType"/>

  <simpleType name="namespaceType">
    <restriction base="token">
      <enumeration value="global"/>
      <enumeration value="test"/>
    </restriction>
  </simpleType>

  <simpleType name="idType">
    <restriction base="token">
      <pattern
     value="urn:aid:(global|test):id(-[bcdfghjkmnpqrstvwxz]{5}){4}"/>
      <maxLength value="255"/>
    </restriction>
  </simpleType>

  <simpleType name="handleType">
    <restriction base="token">
      <pattern
      value="urn:aid:(global|test):[a-z]([a-z0-9-]{0,61}[a-z0-9])?"/>
      <maxLength value="78"/>
    </restriction>
  </simpleType>

  <simpleType name="anchorFpType">
    <restriction base="token">
      <pattern value="[0-9a-f]{64}"/>
    </restriction>
  </simpleType>

  <simpleType name="hwType">
    <restriction base="token">
      <enumeration value="TPM"/>
      <enumeration value="PIV"/>
      <enumeration value="ENC"/>
      <enumeration value="VRT"/>
      <enumeration value="SFT"/>
    </restriction>
  </simpleType>

  <simpleType name="trustTierType">
    <restriction base="token">
      <enumeration value="sovereign"/>
      <enumeration value="portable"/>
      <enumeration value="enclave"/>
      <enumeration value="virtual"/>
      <enumeration value="declared"/>
    </restriction>
  </simpleType>

  <simpleType name="bindingStatusType">
    <restriction base="token">
      <enumeration value="active"/>
      <enumeration value="disabled"/>
    </restriction>
  </simpleType>

  <simpleType name="operationType">
    <restriction base="token">
      <enumeration value="bindingUpdate"/>
      <enumeration value="tierTransition"/>
      <enumeration value="hardwareLock"/>
      <enumeration value="registrarTransfer"/>
      <enumeration value="transferCancel"/>
      <enumeration value="sponsorHold"/>
      <enumeration value="decommission"/>
    </restriction>
  </simpleType>

  <simpleType name="nonceType">
    <restriction base="token">
      <pattern value="[A-Za-z0-9_-]+"/>
      <minLength value="22"/>
    </restriction>
  </simpleType>

  <simpleType name="jwsType">
    <restriction base="token">
      <minLength value="16"/>
      <maxLength value="16384"/>
    </restriction>
  </simpleType>

  <simpleType name="proofKeyType">
    <restriction base="base64Binary">
      <maxLength value="16384"/>
    </restriction>
  </simpleType>

  <simpleType name="mfrType">
    <restriction base="token">
      <pattern value="[a-z0-9-]+"/>
      <minLength value="1"/>
      <maxLength value="64"/>
    </restriction>
  </simpleType>

  <complexType name="bindingInputType">
    <sequence>
      <element name="anchorFp" type="aid:anchorFpType"/>
      <element name="proofKey" type="aid:proofKeyType"/>
      <element name="hwType" type="aid:hwType"/>
      <element name="mfr" type="aid:mfrType" minOccurs="0"/>
    </sequence>
  </complexType>

  <complexType name="bindingInfoType">
    <sequence>
      <element name="anchorFp" type="aid:anchorFpType"/>
      <element name="proofKey" type="aid:proofKeyType"/>
      <element name="hwType" type="aid:hwType"/>
      <element name="mfr" type="aid:mfrType" minOccurs="0"/>
      <element name="status" type="aid:bindingStatusType"/>
      <element name="assuranceQualified" type="boolean"/>
      <element name="boundAt" type="dateTime"/>
    </sequence>
  </complexType>

  <complexType name="challengeRequestType">
    <attribute name="op" type="aid:operationType" use="required"/>
  </complexType>

  <simpleType name="challengeExpiresType">
    <restriction base="dateTime">
      <pattern value="[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}Z"/>
    </restriction>
  </simpleType>

  <complexType name="authChallengeType">
    <sequence>
      <element name="challengeId" type="token"/>
      <element name="nonce" type="aid:nonceType"/>
      <element name="op" type="aid:operationType"/>
      <element name="expires" type="aid:challengeExpiresType"/>
    </sequence>
  </complexType>

  <!-- Compact JWS whose payload is defined in Actor Authorization.
  -->
  <complexType name="actorAuthType">
    <simpleContent><extension base="aid:jwsType"/></simpleContent>
  </complexType>

  <complexType name="checkType">
    <sequence>
      <element name="ns" type="aid:namespaceType" minOccurs="0"/>
      <element name="anchorFp" type="aid:anchorFpType"
               maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <complexType name="infoType">
    <sequence>
      <element name="id" type="aid:idType"/>
      <element name="challenge" type="aid:challengeRequestType"
               minOccurs="0"/>
    </sequence>
  </complexType>

  <complexType name="createType">
    <sequence>
      <element name="ns" type="aid:namespaceType"/>
      <element name="binding" type="aid:bindingInputType"
               maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <complexType name="deleteType">
    <sequence>
      <element name="id" type="aid:idType"/>
      <element name="actorAuth" type="aid:actorAuthType"/>
    </sequence>
  </complexType>

  <!-- actorAuth is optional in the XSD because
       query/approve/reject/cancel use the same object element; prose
       requires it for request. -->
  <complexType name="transferType">
    <sequence>
      <element name="id" type="aid:idType"/>
      <element name="actorAuth" type="aid:actorAuthType"
               minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <complexType name="updateType">
    <sequence>
      <element name="id" type="aid:idType"/>
      <element name="add" type="aid:addType" minOccurs="0"/>
      <element name="rem" type="aid:remType" minOccurs="0"/>
      <element name="chg" type="aid:chgType" minOccurs="0"/>
      <element name="actorAuth" type="aid:actorAuthType"
               minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <complexType name="addType">
    <sequence>
      <element name="binding" type="aid:bindingInputType"
               maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <complexType name="remType">
    <sequence>
      <element name="anchorFp" type="aid:anchorFpType"
               maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <complexType name="chgType">
    <choice>
      <element name="hardwareLock" type="boolean"/>
      <element name="sponsorHold" type="boolean"/>
      <element name="holdRelease" type="aid:heldOperationType"/>
    </choice>
  </complexType>

  <simpleType name="heldOperationType">
    <restriction base="token">
      <enumeration value="bindingUpdate"/>
      <enumeration value="tierTransition"/>
      <enumeration value="registrarTransfer"/>
      <enumeration value="decommission"/>
      <enumeration value="sponsorHold"/>
    </restriction>
  </simpleType>

  <complexType name="chkDataType">
    <sequence>
      <element name="cd" type="aid:checkDataType"
               maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <complexType name="checkDataType">
    <sequence>
      <element name="anchorFp" type="aid:checkedFpType"/>
      <element name="reason" type="eppcom:reasonType" minOccurs="0"/>
    </sequence>
  </complexType>

  <complexType name="checkedFpType">
    <simpleContent>
      <extension base="aid:anchorFpType">
        <attribute name="avail" type="boolean" use="required"/>
      </extension>
    </simpleContent>
  </complexType>

  <complexType name="creDataType">
    <sequence>
      <element name="id" type="aid:idType"/>
      <element name="roid" type="eppcom:roidType"/>
      <element name="crDate" type="dateTime"/>
    </sequence>
  </complexType>

  <complexType name="infDataType">
    <sequence>
      <element name="id" type="aid:idType"/>
      <element name="roid" type="eppcom:roidType"/>
      <element name="status" type="aid:statusType"
               maxOccurs="unbounded"/>
      <element name="maxTrust" type="aid:trustTierType"
               minOccurs="0"/>
      <element name="binding" type="aid:bindingInfoType"
               minOccurs="0" maxOccurs="unbounded"/>
      <element name="handle" type="aid:handleType" minOccurs="0"/>
      <element name="clID" type="eppcom:clIDType" minOccurs="0"/>
      <element name="crID" type="eppcom:clIDType"/>
      <element name="crDate" type="dateTime"/>
      <element name="upID" type="eppcom:clIDType" minOccurs="0"/>
      <element name="upDate" type="dateTime" minOccurs="0"/>
      <element name="trDate" type="dateTime" minOccurs="0"/>
      <element name="authChallenge" type="aid:authChallengeType"
               minOccurs="0"/>
    </sequence>
  </complexType>

  <complexType name="statusType">
    <simpleContent>
      <extension base="normalizedString">
        <attribute name="s" type="aid:statusValueType"
                   use="required"/>
        <attribute name="lang" type="language" default="en"/>
      </extension>
    </simpleContent>
  </complexType>

  <simpleType name="statusValueType">
    <restriction base="token">
      <enumeration value="ok"/>
      <enumeration value="inactive"/>
      <enumeration value="hardwareLocked"/>
      <enumeration value="sponsorHold"/>
      <enumeration value="pendingTransfer"/>
      <enumeration value="serverUpdateProhibited"/>
      <enumeration value="serverDeleteProhibited"/>
    </restriction>
  </simpleType>

  <complexType name="trnDataType">
    <sequence>
      <element name="id" type="aid:idType"/>
      <element name="trStatus" type="eppcom:trStatusType"/>
      <element name="reID" type="eppcom:clIDType"/>
      <element name="reDate" type="dateTime"/>
      <element name="acID" type="eppcom:clIDType" minOccurs="0"/>
      <element name="acDate" type="dateTime" minOccurs="0"/>
    </sequence>
  </complexType>
</schema>

13.2. Handle Schema 

<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:epp:aidHandle-1.0"
        xmlns:aidHandle="urn:ietf:params:xml:ns:epp:aidHandle-1.0"
        xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
        xmlns="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified">

  <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"/>
  <annotation><documentation>
    EPP Agent Identity Handle object mapping version 1.0.
  </documentation></annotation>

  <element name="check" type="aidHandle:mNameType"/>
  <element name="create" type="aidHandle:createType"/>
  <element name="delete" type="aidHandle:sNameType"/>
  <element name="info" type="aidHandle:sNameType"/>
  <element name="renew" type="aidHandle:renewType"/>
  <element name="update" type="aidHandle:updateType"/>

  <element name="chkData" type="aidHandle:chkDataType"/>
  <element name="creData" type="aidHandle:creDataType"/>
  <element name="infData" type="aidHandle:infDataType"/>
  <element name="renData" type="aidHandle:renDataType"/>

  <simpleType name="urnType">
    <restriction base="token">
      <pattern
      value="urn:aid:(global|test):[a-z]([a-z0-9-]{0,61}[a-z0-9])?"/>
      <maxLength value="78"/>
    </restriction>
  </simpleType>

  <simpleType name="idUrnType">
    <restriction base="token">
      <pattern
     value="urn:aid:(global|test):id(-[bcdfghjkmnpqrstvwxz]{5}){4}"/>
      <maxLength value="255"/>
    </restriction>
  </simpleType>

  <complexType name="mNameType"><sequence>
    <element name="name" type="aidHandle:urnType"
             maxOccurs="unbounded"/>
  </sequence></complexType>

  <complexType name="sNameType"><sequence>
    <element name="name" type="aidHandle:urnType"/>
  </sequence></complexType>

  <complexType name="createType"><sequence>
    <element name="name" type="aidHandle:urnType"/>
    <element name="identity" type="aidHandle:idUrnType"/>
    <element name="period" type="aidHandle:periodType"
             minOccurs="0"/>
  </sequence></complexType>

  <complexType name="periodType"><simpleContent>
    <extension base="aidHandle:pLimitType">
      <attribute name="unit" type="aidHandle:pUnitType"
                 use="required"/>
    </extension>
  </simpleContent></complexType>

  <simpleType name="pLimitType"><restriction base="unsignedShort">
    <minInclusive value="1"/><maxInclusive value="99"/>
  </restriction></simpleType>

  <simpleType name="pUnitType"><restriction base="token">
    <enumeration value="y"/><enumeration value="m"/>
  </restriction></simpleType>

  <complexType name="renewType"><sequence>
    <element name="name" type="aidHandle:urnType"/>
    <element name="curExpDate" type="date"/>
    <element name="period" type="aidHandle:periodType"
             minOccurs="0"/>
  </sequence></complexType>

  <complexType name="updateType"><sequence>
    <element name="name" type="aidHandle:urnType"/>
    <element name="add" type="aidHandle:addRemType" minOccurs="0"/>
    <element name="rem" type="aidHandle:addRemType" minOccurs="0"/>
  </sequence></complexType>

  <complexType name="addRemType"><sequence>
    <element name="status" type="aidHandle:statusType"
             maxOccurs="unbounded"/>
  </sequence></complexType>

  <complexType name="chkDataType"><sequence>
    <element name="cd" type="aidHandle:checkNameType"
             maxOccurs="unbounded"/>
  </sequence></complexType>

  <complexType name="checkNameType"><sequence>
    <element name="name" type="aidHandle:checkedNameType"/>
    <element name="reason" type="eppcom:reasonType" minOccurs="0"/>
  </sequence></complexType>

  <complexType name="checkedNameType"><simpleContent>
    <extension base="aidHandle:urnType">
      <attribute name="avail" type="boolean" use="required"/>
    </extension>
  </simpleContent></complexType>

  <complexType name="creDataType"><sequence>
    <element name="name" type="aidHandle:urnType"/>
    <element name="crDate" type="dateTime"/>
    <element name="exDate" type="dateTime"/>
  </sequence></complexType>

  <complexType name="renDataType"><sequence>
    <element name="name" type="aidHandle:urnType"/>
    <element name="exDate" type="dateTime"/>
  </sequence></complexType>

  <complexType name="infDataType"><sequence>
    <element name="name" type="aidHandle:urnType"/>
    <element name="roid" type="eppcom:roidType"/>
    <element name="identity" type="aidHandle:idUrnType"/>
    <element name="status" type="aidHandle:statusType"
             maxOccurs="unbounded"/>
    <element name="clID" type="eppcom:clIDType" minOccurs="0"/>
    <element name="crID" type="eppcom:clIDType"/>
    <element name="crDate" type="dateTime"/>
    <element name="upID" type="eppcom:clIDType" minOccurs="0"/>
    <element name="upDate" type="dateTime" minOccurs="0"/>
    <element name="exDate" type="dateTime"/>
  </sequence></complexType>

  <complexType name="statusType"><simpleContent>
    <extension base="normalizedString">
      <attribute name="s" type="aidHandle:statusValueType"
                 use="required"/>
      <attribute name="lang" type="language" default="en"/>
    </extension>
  </simpleContent></complexType>

  <simpleType name="statusValueType"><restriction base="token">
    <enumeration value="ok"/>
    <enumeration value="disabled"/>
    <enumeration value="retired"/>
    <enumeration value="pendingDelete"/>
    <enumeration value="clientRenewProhibited"/>
    <enumeration value="serverRenewProhibited"/>
    <enumeration value="clientUpdateProhibited"/>
    <enumeration value="serverUpdateProhibited"/>
    <enumeration value="clientDeleteProhibited"/>
    <enumeration value="serverDeleteProhibited"/>
  </restriction></simpleType>
</schema>

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, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688]
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, , <https://www.rfc-editor.org/info/rfc3688>.
[RFC3735]
Hollenbeck, S., "Guidelines for Extending the Extensible Provisioning Protocol (EPP)", RFC 3735, DOI 10.17487/RFC3735, , <https://www.rfc-editor.org/info/rfc3735>.
[RFC3915]
Hollenbeck, S., "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)", RFC 3915, DOI 10.17487/RFC3915, , <https://www.rfc-editor.org/info/rfc3915>.
[RFC5730]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, , <https://www.rfc-editor.org/info/rfc5730>.
[RFC5731]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, , <https://www.rfc-editor.org/info/rfc5731>.
[RFC5734]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Transport over TCP", STD 69, RFC 5734, DOI 10.17487/RFC5734, , <https://www.rfc-editor.org/info/rfc5734>.
[RFC7451]
Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, , <https://www.rfc-editor.org/info/rfc7451>.
[RFC7515]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <https://www.rfc-editor.org/info/rfc7515>.
[RFC7518]
Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, , <https://www.rfc-editor.org/info/rfc7518>.
[RFC8259]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/info/rfc8259>.
[RFC8141]
Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, , <https://www.rfc-editor.org/info/rfc8141>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8909]
Lozano, G., "Registry Data Escrow Specification", RFC 8909, DOI 10.17487/RFC8909, , <https://www.rfc-editor.org/info/rfc8909>.
[RFC9846]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, , <https://www.rfc-editor.org/info/rfc9846>.
[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-05, , <https://datatracker.ietf.org/doc/html/draft-drake-agent-identity-registry-05>.

16. Informative References

[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-01, , <https://datatracker.ietf.org/doc/html/draft-drake-agent-identity-governance-01>.
[I-D.drake-email-hardware-attestation]
Drake, C., "Hardware Attestation for Email Sender Verification", Work in Progress, Internet-Draft, draft-drake-email-hardware-attestation-03, , <https://datatracker.ietf.org/doc/html/draft-drake-email-hardware-attestation-03>.
[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-01, , <https://datatracker.ietf.org/doc/html/draft-drake-agent-identity-resolution-01>.

Author's Address

Christopher Drake
1id.com
Australia
URI: https://1id.com