| Internet-Draft | EPP Agent Identity Mapping | September 2026 |
| Drake | Expires 29 March 2027 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 29 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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].¶
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. 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 both the permanent anchor fingerprint and current/historical operational proof-key material. A binding, once created, MUST NOT be erased. It may transition to "disabled", but its anchor fingerprint MUST NOT later be accepted for another Agent Identity where the Registry architecture forbids reuse. Rotation of the operational proof key leaves the binding and anchor fingerprint unchanged; see Section 4.2.6.¶
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 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 Section 11 for the residual membership oracle.¶
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.¶
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.¶
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.¶
<aid:id>.¶
<aid:roid>.¶
An Agent Identity object MUST always have at least one associated status value. Status values that can be added or removed by the sponsoring client are prefixed with "client"; those managed by the server are prefixed with "server" or carry no prefix. As in [RFC5731], "ok" is the default status, MAY only be combined with no other status, and is managed solely by the server.¶
<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.¶
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.¶
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.¶
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.¶
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 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.¶
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.¶
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>¶
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.¶
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". The none algorithm,
MAC algorithms, algorithm/key-type mismatches, and additional
protected-header members MUST be rejected. Verification uses
the authoritative active proof key in the Registry record, or
the proposed binding's proof key where this section explicitly
requires a candidate proof; a JWS never supplies its own
authority key.¶
The JWS payload is a UTF-8 JSON object
[RFC8259] with exactly these top-level
members: v (integer 1), aid (canonical
identifier), op, role ("current" or
"candidate"), anchor_fp (the signing binding's
anchor fingerprint), challenge_id,
nonce (base64url), expires (the exact
RFC 3339 challenge expiry string), and target.
v MUST be 1. aid, op,
role, and anchor_fp MUST match the
transform and signing binding; challenge_id,
nonce, and expires MUST exactly match the
unconsumed Registry challenge. The server compares
target semantically with the EPP transform; JSON
member ordering and insignificant whitespace are therefore
not part of the protocol. Unknown top-level or target
members MUST cause authorization failure.¶
The target object is operation-specific:¶
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.¶
bindingUpdate, but
disable MUST name every active old-group binding
and add contains the proposed higher-group
binding or bindings.¶
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.¶
anchor_fp identifies the sole binding being
irreversibly retained.¶
gaining_clid is the EPP client identifier of
the gaining Registrar.¶
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").¶
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.¶
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.¶
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 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 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.¶
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> manages binding state,
operational proof-key rotation, the irreversible hardware
lock, and client status values. Client status-only changes
use ordinary sponsoring-client authorization. Every change
to active binding/proof-key state or hardware lock additionally
requires the actor authorization of
Section 4.2.1. An Agent Identity
<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,
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.¶
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.¶
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.¶
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: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 Section 2.3.¶
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 Section 4.2.6; Registrar transfer
and voluntary decommissioning also remain possible.¶
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 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.¶
There is no pendingTransfer status: Handles do not transfer independently of their linked Agent Identity.¶
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>¶
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.¶
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.¶
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 Section 2.4.¶
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
[I-D.drake-agent-identity-registry]. A
handle that has entered the terminal retired
state MUST never be released or reassigned.¶
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.¶
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).¶
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.¶
Registry policy MAY provide grace intervals around Handle
creation, renewal, expiry, and voluntary disablement. Such
intervals affect only the naming-layer Handle and never the linked
Agent Identity object. This mapping represents a delayed
disablement with the Handle's pendingDelete status and
ultimately transitions the Handle to disabled. Grace
processing itself never purges the historical object, changes its
identity linkage, or releases the label. Any later release policy
for a disabled (but not retired) label is outside this mapping and
remains subject to the Registry/Governance Handle policy.¶
The Registry Grace Period extension [RFC3915] is
specific to the EPP domain-name mapping and is not extended to
Handle objects by this document. In particular, implementations
MUST NOT emit rgp: extension elements for a Handle merely
by substituting "Handle" for "domain" in RFC 3915. A future
object-generic or Handle-specific grace-period extension could be
profiled separately. Registries remain free to reuse existing
billing and grace-policy machinery internally.¶
| 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 Section 4.2.1.
There is no EPP authInfo password for Agent Identity
objects.¶
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, and lifecycle state to reconstruct Registry service, subject to the escrow and privacy policy of [I-D.drake-agent-identity-governance]. Private authentication credentials MUST NOT be escrowed, consistent with RFC 8909.¶
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.¶
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:¶
Registration request for the Handle namespace:¶
Two schema assignments are requested.¶
Registration request for the Agent Identity schema:¶
Registration request for the Handle schema:¶
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:¶
Registration for the Handle object mapping:¶
The "aid" URN namespace and its production namespace semantics are specified by [I-D.drake-agent-identity-registry] and are not re-registered here.¶
The security considerations of [RFC5730], [RFC5731], and the Registry architecture apply. This section covers only risks introduced by this provisioning mapping.¶
Registrar authentication to EPP and actor authorization are
separate security boundaries. A Registrar is trusted to
perform the tier-appropriate enrollment verification before it
provisions an anchor and proof key, but a Registrar MUST NOT be
able to manufacture consent for later control-state changes.
The fresh Registry challenge and
<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 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/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.¶
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.¶
The following XML Schemas normatively define the Agent Identity and Handle object mappings specified by this document.¶
<?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="proofKeyRotate"/>
<enumeration value="hardwareLock"/>
<enumeration value="registrarTransfer"/>
<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">
<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>
<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="dateTime"/>
</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="proofKeyChange" type="aid:proofKeyChangeType"
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">
<choice minOccurs="1" maxOccurs="unbounded">
<element name="binding" type="aid:bindingInputType"/>
<element name="status" type="aid:statusType"/>
</choice>
</complexType>
<complexType name="remType">
<choice minOccurs="1" maxOccurs="unbounded">
<element name="anchorFp" type="aid:anchorFpType"/>
<element name="status" type="aid:statusType"/>
</choice>
</complexType>
<complexType name="proofKeyChangeType">
<sequence>
<element name="anchorFp" type="aid:anchorFpType"/>
<element name="proofKey" type="aid:proofKeyType"/>
</sequence>
</complexType>
<complexType name="chgType">
<sequence>
<element name="hardwareLock" type="boolean"/>
</sequence>
</complexType>
<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="pendingTransfer"/>
<enumeration value="clientUpdateProhibited"/>
<enumeration value="serverUpdateProhibited"/>
<enumeration value="clientDeleteProhibited"/>
<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>¶
<?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>¶
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.¶