Extensible Provisioning Protocol (EPP) Mapping for Agent Identity and Handle Objects
draft-drake-agent-identity-epp-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Christopher Drake | ||
| Last updated | 2026-09-25 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-drake-agent-identity-epp-00
Network Working Group C. Drake
Internet-Draft 1id.com
Intended status: Experimental 25 September 2026
Expires: 29 March 2027
Extensible Provisioning Protocol (EPP) Mapping for Agent Identity and
Handle Objects
draft-drake-agent-identity-epp-00
Abstract
This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of agent identity objects
and handle objects stored in the authoritative AIRS repository, as
defined by the Agent Identity Registry System architecture.
Specified in Extensible Markup Language (XML), these mappings define
the interface between Registrars and the production Registry Operator
for identities of autonomous entities.
The mapping defines two objects: a permanent, non-expiring Agent
Identity object keyed by a server-allocated canonical identifier, and
a renewable, expiring Handle object that provides a human-readable
alias. It adds one registry function with no domain-name analogue:
cross-Registrar uniqueness enforcement of enrolled anchor
identifiers, including the scarce-anchor invariant where the parent
architecture defines one. Transfer authorization uses a actor-signed
proof from an enrolled operational proof key in place of
authorization-information passwords.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 March 2027.
Drake Expires 29 March 2027 [Page 1]
Internet-Draft EPP Agent Identity Mapping September 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Relationship to Other Documents . . . . . . . . . . . . . 4
1.2. Two Objects . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Object Model . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Object Identifiers . . . . . . . . . . . . . . . . . . . 5
2.2. Anchor and Proof-Key Bindings . . . . . . . . . . . . . . 5
2.3. Anchor Uniqueness Enforcement . . . . . . . . . . . . . . 6
2.4. Sponsorship . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Service Element Declaration . . . . . . . . . . . . . . . 7
2.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Agent Identity Object Attributes . . . . . . . . . . . . . . 8
3.1. Status Values . . . . . . . . . . . . . . . . . . . . . . 8
4. EPP Command Mapping for Agent Identity Objects . . . . . . . 9
4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 9
4.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 9
4.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 10
4.1.3. Actor-Authorization Challenge . . . . . . . . . . . . 10
4.1.4. EPP <transfer> Query Command . . . . . . . . . . . . 11
4.1.5. EPP <poll> Command . . . . . . . . . . . . . . . . . 12
4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 12
4.2.1. Actor Authorization . . . . . . . . . . . . . . . . . 12
4.2.2. EPP <create> Command . . . . . . . . . . . . . . . . 14
4.2.3. EPP <delete> Command . . . . . . . . . . . . . . . . 14
4.2.4. EPP <renew> Command . . . . . . . . . . . . . . . . . 15
4.2.5. EPP <transfer> Command . . . . . . . . . . . . . . . 15
4.2.6. EPP <update> Command . . . . . . . . . . . . . . . . 16
5. Handle Object Attributes . . . . . . . . . . . . . . . . . . 18
5.1. Status Values . . . . . . . . . . . . . . . . . . . . . . 18
6. EPP Command Mapping for Handle Objects . . . . . . . . . . . 19
6.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 19
Drake Expires 29 March 2027 [Page 2]
Internet-Draft EPP Agent Identity Mapping September 2026
6.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 19
6.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 20
6.1.3. EPP <transfer> Query Command . . . . . . . . . . . . 21
6.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 21
6.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 21
6.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 21
6.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 21
6.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 22
6.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 22
6.3. Grace Periods . . . . . . . . . . . . . . . . . . . . . . 22
7. Lifecycle Mapping . . . . . . . . . . . . . . . . . . . . . . 22
8. Data Escrow . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Internationalization Considerations . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10.1. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 24
10.2. XML Schemas . . . . . . . . . . . . . . . . . . . . . . 25
10.3. EPP Extension Registry . . . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
13. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27
13.1. Agent Identity Schema . . . . . . . . . . . . . . . . . 27
13.2. Handle Schema . . . . . . . . . . . . . . . . . . . . . 34
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
15. Normative References . . . . . . . . . . . . . . . . . . . . 38
16. Informative References . . . . . . . . . . . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction
The Agent Identity Registry System
([I-D.drake-agent-identity-registry], hereafter "the registry
architecture") defines an architecture separating governance, one
authoritative production Registry Operator, and multiple competing
Registrars for durable identities of autonomous entities. This
document uses those roles as defined there rather than redefining
them.
This document maps that Registrar-to-Registry interface onto the
Extensible Provisioning Protocol (EPP) [RFC5730], following the
structure and conventions of the EPP domain name mapping [RFC5731]
and the guidelines for extending EPP [RFC3735]. A registry operator
that already runs an EPP-based domain registry can operate an agent
identity registry by adding the two object mappings defined here to
an existing EPP service, reusing EPP session, transport, transaction,
and selected registry-operational infrastructure.
Drake Expires 29 March 2027 [Page 3]
Internet-Draft EPP Agent Identity Mapping September 2026
This document specifies only the provisioning protocol between an EPP
client (a Registrar) and an EPP server (the Registry Operator).
Production objects are provisioned in global; test is non-production
and carries no AIRS assurance. Autonomous entities (agents) are not
EPP clients and never speak EPP. Agents enroll and authenticate
through their Registrar's agent-facing interface defined in the
registry architecture; EPP is used only after the Registrar has
completed the tier-appropriate enrollment checks and is recording the
result at the Registry. Hardware attestation ceremonies, token
issuance, identity semantics, URN syntax, trust tiers, and governance
policy are defined in the parent documents and are not restated here.
1.1. Relationship to Other Documents
This document provides the Registrar-to-Registry provisioning
protocol (the write side) for the registry architecture defined in
[I-D.drake-agent-identity-registry], which references this mapping as
its provisioning interface. The public read side is the RDAP profile
of [I-D.drake-agent-identity-resolution]. Transport-level
attestation for email is defined in
[I-D.drake-email-hardware-attestation] and is unaffected by this
document.
1.2. Two Objects
This mapping deliberately splits the registry's data into two EPP
objects with different lifecycles. The Agent Identity object is
permanent: it is created once, never expires, is never renewed, is
never reassigned, and survives its own decommissioning as a queryable
record; its [RFC5730] <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.
Drake Expires 29 March 2027 [Page 4]
Internet-Draft EPP Agent Identity Mapping September 2026
In examples, "C:" represents lines sent by a protocol client and "S:"
represents lines returned by a protocol server. Indentation and
white space in examples are provided only to illustrate element
relationships and are not a REQUIRED feature of this protocol.
XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the
character case presented in order to develop a conforming
implementation.
1.4. Terminology
The terms "Agent Identity Record", "canonical identifier", "handle",
"anchor fingerprint", "trust tier", "Registry Operator", "Registrar",
and "Governance Authority" are used as defined in
[I-D.drake-agent-identity-registry]. "Sponsoring client" is used as
in [RFC5730]: the Registrar authorized to perform transform
operations on an object.
2. Object Model
2.1. Object Identifiers
An Agent Identity object is identified by its canonical-form URN in
the "aid" URN namespace ([RFC8141]), e.g. urn:aid:global:id-qkckh-
xxtcw-cxbvp-gpskg. A Handle object is identified by its handle-form
URN, e.g. urn:aid:global:crusty. URN syntax, the reservation of the
id- prefix for canonical identifiers, and label constraints are
defined in [I-D.drake-agent-identity-registry]. The global namespace
is the sole production uniqueness domain. The reserved test
namespace is non-production and MUST NOT share or affect the
production uniqueness index.
Unlike domain names, canonical identifiers are not chosen by the
client: they are allocated by the server from a randomized space at
object creation and are returned in the <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
Drake Expires 29 March 2027 [Page 5]
Internet-Draft EPP Agent Identity Mapping September 2026
[I-D.drake-agent-identity-registry] and are not redefined here.
A client provisions the anchor fingerprint in <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.
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.
Drake Expires 29 March 2027 [Page 6]
Internet-Draft EPP Agent Identity Mapping September 2026
The permanent-state resource limits of the Registry architecture also
apply at transformation time. The server MUST enforce finite limits
on bindings and retained proof-key history for each Agent Identity.
A <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]. Registry policy governs client
certificate requirements; the mutual-TLS expectations of the registry
architecture apply unchanged.
Drake Expires 29 March 2027 [Page 7]
Internet-Draft EPP Agent Identity Mapping September 2026
3. Agent Identity Object Attributes
The EPP Agent Identity object carries only the provisioning state
required by the canonical Agent Identity Record in
[I-D.drake-agent-identity-registry]. Mutable display, operator,
contact, certification, capability, and reputation attributes are
intentionally not part of this mapping.
Identifier The server-allocated permanent canonical-form URN,
returned in <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.
Bindings One or more permanent bindings (Section 2.2), each carrying
an anchor fingerprint, hardware type code, Registry-recognized
manufacturer or evidence-profile identifier when applicable,
active operational proof-key SPKI, binding timestamp, and binding
status. The server retains required historical proof-key and
binding state even where only the current key is returned by this
mapping.
Handle linkage The Handle object naming this identity, if one
exists.
Sponsorship and event data The current sponsoring client identifier
when one exists, plus creating/updating client and event
timestamps as in [RFC5730]. Agent Identity objects do not expire.
The current sponsor field is absent in the valid no-authorized-
Registrar state described in Section 2.4.
3.1. Status Values
An Agent Identity object MUST always have at least one associated
status value. Status values that can be added or removed by the
sponsoring client are prefixed with "client"; those managed by the
server are prefixed with "server" or carry no prefix. As in
[RFC5731], "ok" is the default status, MAY only be combined with no
other status, and is managed solely by the server.
ok Normal state; no operations pending or prohibited.
inactive The identity has been voluntarily decommissioned
Drake Expires 29 March 2027 [Page 8]
Internet-Draft EPP Agent Identity Mapping September 2026
(Section 4.2.3). All bindings are disabled, the object no longer
proves current AIRS control, and the historical record is retained
permanently.
hardwareLocked The identity is irreversibly pinned to one anchor
binding (Section 4.2.6.1). No later <update> may add or remove a
binding or migrate to another anchor. Operational proof-key
rotation within the retained binding, Registrar transfer, and
voluntary decommissioning remain permitted.
pendingTransfer A transfer request is awaiting completion
(Section 4.2.5).
clientUpdateProhibited, serverUpdateProhibited Update requests are
prohibited except removal of the client form by its sponsoring
client.
clientDeleteProhibited, serverDeleteProhibited Voluntary
decommission requests are prohibited while the status applies. A
client MAY use its client form as an accidental-decommission
guard; it does not create an administrative decommission
authority.
There are no pendingCreate, pendingRenew, pendingDelete, redemption,
or Registrar-controlled transfer-prohibited states. Creation is
synchronous, identities do not renew or expire, decommissioning
retains the historical object, and Registrar transfer is authorized
by the actor as specified in Section 4.2.5.1.
4. EPP Command Mapping for Agent Identity Objects
A detailed description of the EPP syntax and semantics can be found
in [RFC5730]. The command mappings described here are specifically
for use in provisioning and managing Agent Identity objects via EPP.
4.1. EPP Query Commands
4.1.1. EPP <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.
Drake Expires 29 March 2027 [Page 9]
Internet-Draft EPP Agent Identity Mapping September 2026
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.
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. 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, proofKeyRotate, hardwareLock,
registrarTransfer, or decommission. Requesting a challenge has no
transform semantics and grants the requesting Registrar no authority
over the object.
Drake Expires 29 March 2027 [Page 10]
Internet-Draft EPP Agent Identity Mapping September 2026
If the client is an accredited Registrar permitted to relay the
requested operation, the successful <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.
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:
Drake Expires 29 March 2027 [Page 11]
Internet-Draft EPP Agent Identity Mapping September 2026
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-
Drake Expires 29 March 2027 [Page 12]
Internet-Draft EPP Agent Identity Mapping September 2026
auth+jws". The none algorithm, MAC algorithms, algorithm/key-type
mismatches, and additional protected-header members MUST be rejected.
Verification uses the authoritative active proof key in the Registry
record, or the proposed binding's proof key where this section
explicitly requires a candidate proof; a JWS never supplies its own
authority key.
The JWS payload is a UTF-8 JSON object [RFC8259] with exactly these
top-level members: v (integer 1), aid (canonical identifier), op,
role ("current" or "candidate"), anchor_fp (the signing binding's
anchor fingerprint), challenge_id, nonce (base64url), expires (the
exact RFC 3339 challenge expiry string), and target. v MUST be 1.
aid, op, role, and anchor_fp MUST match the transform and signing
binding; challenge_id, nonce, and expires MUST exactly match the
unconsumed Registry challenge. The server compares target
semantically with the EPP transform; JSON member ordering and
insignificant whitespace are therefore not part of the protocol.
Unknown top-level or target members MUST cause authorization failure.
The target object is operation-specific:
bindingUpdate add is an array containing each proposed binding's
anchor_fp, SHA-256 digest of the DER proof-key SPKI as
proof_key_sha256 encoded as exactly 64 lowercase hexadecimal
characters, and hw_type; mfr is included only when the
corresponding <aid:mfr> element is present. disable is an array
of anchor fingerprints. The server compares both arrays as sets
to the command; duplicate entries are invalid.
tierTransition The same target shape as bindingUpdate, but disable
MUST name every active old-group binding and add contains the
proposed higher-group binding or bindings.
proofKeyRotate anchor_fp identifies the unchanged binding and
proof_key_sha256 is SHA-256 of the replacement DER SPKI encoded as
exactly 64 lowercase hexadecimal characters.
hardwareLock anchor_fp identifies the sole binding being
irreversibly retained.
registrarTransfer gaining_clid is the EPP client identifier of the
gaining Registrar.
decommission target is an empty object; the canonical identifier and
operation already bind the irreversible action.
Drake Expires 29 March 2027 [Page 13]
Internet-Draft EPP Agent Identity Mapping September 2026
A valid current-role proof MUST verify with a currently active
operational proof key whose binding is identified by anchor_fp. For
each binding being added, a candidate-role proof over the same
challenge and target MUST additionally verify with that proposed
binding's submitted <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").
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.
Drake Expires 29 March 2027 [Page 14]
Internet-Draft EPP Agent Identity Mapping September 2026
On successful authorization the server atomically disables every
active binding, sets the identity lifecycle status to inactive, and
retains the canonical record and all anchor/proof-key history
permanently. A linked Handle remains historically bound and reserved
to the identity; decommissioning does not reassign it. There is no
redemption grace period because no identity record is pending purge.
4.2.4. EPP <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 and proof-key version that
authorized the request. The losing Registrar is notified through the
EPP poll queue, but the notification grants no veto over an actor-
authorized transfer. Immediately before deferred completion the
server MUST verify that the identity remains operational and the
authorizing binding and proof-key version remain active; if not, the
pending authorization is canceled and a fresh Registry challenge and
actor authorization are required.
Drake Expires 29 March 2027 [Page 15]
Internet-Draft EPP Agent Identity Mapping September 2026
When the identity has no current sponsor, the Registry MUST NOT
impose a losing-Registrar approval, notification, or waiting step. A
valid request from an accredited gaining Registrar completes
immediately. On completion the gaining client becomes current
sponsor of the Agent Identity and of its linked Handle, if any. The
Handle remains the same object and label.
<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").
4.2.6. EPP <update> Command
EPP <update> manages binding state, operational proof-key rotation,
the irreversible hardware lock, and client status values. Client
status-only changes use ordinary sponsoring-client authorization.
Every change to active binding/proof-key state or hardware lock
additionally requires the actor authorization of 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.
<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
Drake Expires 29 March 2027 [Page 16]
Internet-Draft EPP Agent Identity Mapping September 2026
operation tierTransition. The removal set MUST name every
currently active old-group binding, the addition set contains the
proposed higher-group binding(s), and current and candidate keys
sign the same Registry challenge/target. The server commits the
addition and permanent old-group disablement atomically. A
downgrade MUST be rejected with result code 2308.
<aid:proofKeyChange> Rotates the operational proof key inside one
permanent sovereign or portable binding, whose anchor fingerprint
does not depend on that key. The server MUST reject it with
result code 2306 for an enclave, virtual, or declared binding,
whose anchor fingerprint is derived from the proof key; such a key
is replaced by a bindingUpdate that adds the new binding and
removes the old one in the same command. It carries the unchanged
<aid:anchorFp> and replacement DER SPKI in <aid:proofKey>, with
operation proofKeyRotate authorized by the binding's current proof
key. Before submission the Registrar MUST revalidate the
replacement key's relationship to the enrolled anchor at the
claimed tier. The server retains the old proof key in history and
MUST NOT change the anchor fingerprint.
<aid:chg> Manages client status values and the irreversible
<aid:hardwareLock>. No display, operator, contact, or other
higher-layer metadata is carried by this mapping.
The server recomputes the maximum active trust tier from active,
assurance-qualified bindings after every committed binding mutation.
Anchor collisions and binding policy violations use result code 2308
and the non-disclosure rule of 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, 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.
Drake Expires 29 March 2027 [Page 17]
Internet-Draft EPP Agent Identity Mapping September 2026
5. Handle Object Attributes
A Handle object provisions the optional human-readable alias defined
by the Registry specification. It contains the handle-form URN,
repository object identifier, immutable link to one canonical Agent
Identity identifier, status values, OPTIONAL current sponsorship,
event data, and an expiry date. Handle syntax and retirement
semantics are owned by [I-D.drake-agent-identity-registry] and are
not redefined here.
When the linked Agent Identity has a current sponsoring Registrar,
the Handle MUST have the same sponsor. When the identity enters the
valid no-current-Registrar state, the Handle becomes unsponsored too:
its identity linkage and label reservation remain intact and
<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.
5.1. Status Values
ok Normal state. MAY only be combined with no other status; managed
solely by the server.
disabled The handle does not currently resolve as an active alias.
It may result from non-renewal after applicable grace processing,
voluntary release, or decommissioning of the linked identity. A
disabled handle MAY be reactivated for the same identity when
policy permits. Registrar suspension/de-accreditation does not by
itself change the identity linkage or free the label.
retired Terminal, server-managed. Applied under the Registry/
Governance retire-only dispute rule. A retired handle MUST NOT be
renewed, reactivated, transferred, or assigned to any identity,
ever.
pendingDelete Server-managed Handle grace-processing state before a
transition to disabled. It never implies deletion of the
historical object or reassignment of the canonical identity.
clientRenewProhibited, serverRenewProhibited,
clientUpdateProhibited, serverUpdateProhibited,
clientDeleteProhibited, serverDeleteProhibited Have their ordinary
EPP prohibition meanings for the naming-layer Handle object.
There is no pendingTransfer status: Handles do not transfer
independently of their linked Agent Identity.
Drake Expires 29 March 2027 [Page 18]
Internet-Draft EPP Agent Identity Mapping September 2026
6. EPP Command Mapping for Handle Objects
6.1. EPP Query Commands
6.1.1. EPP <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:
Drake Expires 29 March 2027 [Page 19]
Internet-Draft EPP Agent Identity Mapping September 2026
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.
Drake Expires 29 March 2027 [Page 20]
Internet-Draft EPP Agent Identity Mapping September 2026
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,
and invalid handle syntax with 2306. An OPTIONAL period carries the
initial registration period according to Registry policy.
Creation fixes the Handle's canonical-identity linkage for its
lifetime. No EPP operation can transfer a Handle to another
identity; successful identity sponsorship transfer changes only the
servicing Registrar as described in Section 2.4.
6.2.2. EPP <delete> Command
EPP <delete> voluntarily disables a Handle and is accepted only from
the linked identity's current sponsoring Registrar. It does not
erase the Handle object or alter the linked Agent Identity. Any
later reactivation or release policy is governed by the Handle
lifecycle in [I-D.drake-agent-identity-registry]. A handle that has
entered the terminal retired state MUST never be released or
reassigned.
6.2.3. EPP <renew> Command
EPP <renew> extends the validity of a Handle using the ordinary EPP
period and current-expiry guard conventions. Only the linked
identity's current sponsor can renew. Subject to Registry policy,
renewal may also reactivate a disabled Handle that is still reserved
to the same identity. An unsponsored Handle cannot be renewed until
actor-authorized identity transfer establishes a new sponsor, but the
no-sponsor interval by itself MUST NOT reassign its label.
Drake Expires 29 March 2027 [Page 21]
Internet-Draft EPP Agent Identity Mapping September 2026
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. Any
later release policy for a disabled (but not retired) label is
outside this mapping and remains subject to the Registry/Governance
Handle policy.
The Registry Grace Period extension [RFC3915] is specific to the EPP
domain-name mapping and is not extended to Handle objects by this
document. In particular, implementations MUST NOT emit rgp:
extension elements for a Handle merely by substituting "Handle" for
"domain" in RFC 3915. A future object-generic or Handle-specific
grace-period extension could be profiled separately. Registries
remain free to reuse existing billing and grace-policy machinery
internally.
7. Lifecycle Mapping
+=======================+======================================+
| Lifecycle event | EPP realization |
+=======================+======================================+
| Anchor pre-flight | Agent Identity <check> |
+-----------------------+--------------------------------------+
| Initial enrollment | Agent Identity <create> |
+-----------------------+--------------------------------------+
| Binding addition/ | <update> plus Registry challenge and |
Drake Expires 29 March 2027 [Page 22]
Internet-Draft EPP Agent Identity Mapping September 2026
| disable | <aid:actorAuth> |
+-----------------------+--------------------------------------+
| Cross-group upgrade | <update> with tierTransition joint |
| | authorization |
+-----------------------+--------------------------------------+
| Operational proof-key | <update> <aid:proofKeyChange> |
| rotation | |
+-----------------------+--------------------------------------+
| Hardware lock | <update> <aid:hardwareLock> plus |
| | actor authorization |
+-----------------------+--------------------------------------+
| Registrar transfer | Agent Identity <transfer> plus actor |
| | authorization |
+-----------------------+--------------------------------------+
| Registrar suspension/ | Server removes sponsorship/issuer |
| de-accreditation | authority; no successor is assigned. |
| | Later transfer is actor-authorized. |
+-----------------------+--------------------------------------+
| Voluntary | Agent Identity <delete> plus actor |
| decommissioning | authorization; historical object |
| | retained |
+-----------------------+--------------------------------------+
| Handle | Handle object commands; Handle never |
| create/renew/update/ | transfers independently |
| delete | |
+-----------------------+--------------------------------------+
| Handle dispute | Server-side terminal retired state |
| retirement | plus poll notice |
+-----------------------+--------------------------------------+
Table 1: Registry Lifecycle Events in EPP
EPP client authentication authorizes Registrar-managed naming and
status operations. AIRS actor-control transitions are intentionally
different: they additionally require the Registry-verifiable proof of
Section 4.2.1. There is no EPP authInfo password for Agent Identity
objects.
8. Data Escrow
Registry data escrow is an operational/governance requirement, not an
EPP command. [RFC8909] defines an object-agnostic Registry Data
Escrow (RDE) container and explicitly requires an independent
specification for each object type to be escrowed. The EPP
<aid:infData> and <aidHandle:infData> structures defined here are
therefore NOT, by themselves, an interoperable RFC 8909 escrow object
mapping.
Drake Expires 29 March 2027 [Page 23]
Internet-Draft EPP Agent Identity Mapping September 2026
This document does not define that RDE object-specific schema or its
confidentiality/signaling profile. An AIRS deployment using RFC 8909
MUST define those pieces separately and include enough canonical
identity, sponsorship, Handle, permanent anchor/proof-key history,
and lifecycle state to reconstruct Registry service, subject to the
escrow and privacy policy of [I-D.drake-agent-identity-governance].
Private authentication credentials MUST NOT be escrowed, consistent
with RFC 8909.
9. Internationalization Considerations
Handle labels are restricted by the registry architecture to
lowercase ASCII letters, digits, and hyphens (LDH) with a leading
letter. This mapping performs no internationalized label processing:
there are no A-labels or U-labels, no IDNA mapping, and no
normalization beyond the schema-enforced syntax; servers MUST reject
non-conforming labels with error 2306. Presentation of handles to
humans, including any localized display conventions, is a relying-
party concern addressed in the registry architecture. Registry
Operators SHOULD apply confusable-label policies within the LDH
repertoire (e.g., digit/letter lookalikes) through their reserved
lists; a future extension could define internationalized handle
labels, and would need to address the full set of IDNA and
confusability issues that domain registries have encountered.
10. IANA Considerations
10.1. XML Namespaces
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]. Two URN
assignments are requested.
Registration request for the Agent Identity namespace:
* URI: urn:ietf:params:xml:ns:epp:aid-1.0
* Registrant Contact: IESG
* XML: None. Namespace URIs do not represent an XML specification.
Registration request for the Handle namespace:
* URI: urn:ietf:params:xml:ns:epp:aidHandle-1.0
* Registrant Contact: IESG
* XML: None. Namespace URIs do not represent an XML specification.
Drake Expires 29 March 2027 [Page 24]
Internet-Draft EPP Agent Identity Mapping September 2026
10.2. XML Schemas
Two schema assignments are requested.
Registration request for the Agent Identity schema:
* URI: urn:ietf:params:xml:schema:epp:aid-1.0
* Registrant Contact: IESG
* XML: See Section 13.1 of this document.
Registration request for the Handle schema:
* URI: urn:ietf:params:xml:schema:epp:aidHandle-1.0
* Registrant Contact: IESG
* XML: See Section 13.2 of this document.
10.3. EPP Extension Registry
The EPP mappings described in this document should be registered by
IANA in the "Extensions for the Extensible Provisioning Protocol
(EPP)" registry described in [RFC7451]. Two registrations are
requested; both use the registration policy "Specification Required".
Registration for the Agent Identity object mapping:
Name of Extension EPP Mapping for Agent Identity Objects
Document Status Experimental
Reference This document
Registrant Name and Email Address IESG, iesg@ietf.org
TLDs Any
IPR Disclosure None
Status Active
Notes None
Registration for the Handle object mapping:
Name of Extension EPP Mapping for Agent Identity Handle Objects
Drake Expires 29 March 2027 [Page 25]
Internet-Draft EPP Agent Identity Mapping September 2026
Document Status Experimental
Reference This document
Registrant Name and Email Address IESG, iesg@ietf.org
TLDs Any
IPR Disclosure None
Status Active
Notes None
The "aid" URN namespace and its production namespace semantics are
specified by [I-D.drake-agent-identity-registry] and are not re-
registered here.
11. Security Considerations
The security considerations of [RFC5730], [RFC5731], and the Registry
architecture apply. This section covers only risks introduced by
this provisioning mapping.
Registrar authentication to EPP and actor authorization are separate
security boundaries. A Registrar is trusted to perform the tier-
appropriate enrollment verification before it provisions an anchor
and proof key, but a Registrar MUST NOT be able to manufacture
consent for later control-state changes. The fresh Registry
challenge and <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
Drake Expires 29 March 2027 [Page 26]
Internet-Draft EPP Agent Identity Mapping September 2026
anchor/proof-key relationships before irreversible create/add
operations. Likewise, hardware lock and decommissioning are
irreversible and require explicit actor authorization.
A pending Registrar transfer is authorized by a particular active
binding/proof-key version. The Registry MUST recheck that
authorization source immediately before deferred completion.
Registrar suspension/de-accreditation never creates an administrative
successor or identity-recovery path. If no active proof key remains,
AIRS preserves the historical identity but this mapping cannot
restore control.
Handle retirement is terminal. A compromised Registrar cannot use
the dispute mechanism to transfer a Handle to a favored identity; the
corresponding denial risk of erroneous retirement is a governance-
policy matter outside this wire protocol.
12. Privacy Considerations
This mapping intentionally excludes mutable operator/contact
attributes from the canonical Agent Identity object. The main
provisioning-sensitive data are anchor fingerprints, operational
public keys, manufacturer/issuer metadata, and the commercial
relationship represented by sponsorship.
An EPP server MUST NOT expose a mapping from anchor fingerprint to
holding identity or sponsoring Registrar through <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
Drake Expires 29 March 2027 [Page 27]
Internet-Draft EPP Agent Identity Mapping September 2026
<?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>
Drake Expires 29 March 2027 [Page 28]
Internet-Draft EPP Agent Identity Mapping September 2026
</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">
Drake Expires 29 March 2027 [Page 29]
Internet-Draft EPP Agent Identity Mapping September 2026
<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"/>
Drake Expires 29 March 2027 [Page 30]
Internet-Draft EPP Agent Identity Mapping September 2026
</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>
Drake Expires 29 March 2027 [Page 31]
Internet-Draft EPP Agent Identity Mapping September 2026
<!-- 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"/>
Drake Expires 29 March 2027 [Page 32]
Internet-Draft EPP Agent Identity Mapping September 2026
</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"/>
Drake Expires 29 March 2027 [Page 33]
Internet-Draft EPP Agent Identity Mapping September 2026
<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>
13.2. Handle Schema
Drake Expires 29 March 2027 [Page 34]
Internet-Draft EPP Agent Identity Mapping September 2026
<?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>
Drake Expires 29 March 2027 [Page 35]
Internet-Draft EPP Agent Identity Mapping September 2026
<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"/>
Drake Expires 29 March 2027 [Page 36]
Internet-Draft EPP Agent Identity Mapping September 2026
</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"/>
Drake Expires 29 March 2027 [Page 37]
Internet-Draft EPP Agent Identity Mapping September 2026
<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, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible
Provisioning Protocol (EPP)", RFC 3735,
DOI 10.17487/RFC3735, March 2004,
<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, October 2004,
<https://www.rfc-editor.org/info/rfc3915>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<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, August 2009,
<https://www.rfc-editor.org/info/rfc5731>.
Drake Expires 29 March 2027 [Page 38]
Internet-Draft EPP Agent Identity Mapping September 2026
[RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Transport over TCP", STD 69, RFC 5734,
DOI 10.17487/RFC5734, August 2009,
<https://www.rfc-editor.org/info/rfc5734>.
[RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
February 2015, <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, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<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, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<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,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8909] Lozano, G., "Registry Data Escrow Specification",
RFC 8909, DOI 10.17487/RFC8909, November 2020,
<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, July 2026,
<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-04, September 2026,
<https://datatracker.ietf.org/doc/html/draft-drake-agent-
identity-registry-04>.
16. Informative References
Drake Expires 29 March 2027 [Page 39]
Internet-Draft EPP Agent Identity Mapping September 2026
[I-D.drake-agent-identity-governance]
Drake, C., "The Agent Identity Authority: A Multi-
Stakeholder Governance Framework for the Agent Identity
Registry System", Work in Progress, Internet-Draft, draft-
drake-agent-identity-governance-00, September 2026,
<https://datatracker.ietf.org/doc/html/draft-drake-agent-
identity-governance-00>.
[I-D.drake-email-hardware-attestation]
Drake, C., "Hardware Attestation for Email Sender
Verification", Work in Progress, Internet-Draft, draft-
drake-email-hardware-attestation-02, September 2026,
<https://datatracker.ietf.org/doc/html/draft-drake-email-
hardware-attestation-02>.
[I-D.drake-agent-identity-resolution]
Drake, C., "Resolution and Verification of Agent
Identities using DNS and RDAP", Work in Progress,
Internet-Draft, draft-drake-agent-identity-resolution-00,
September 2026, <https://datatracker.ietf.org/doc/html/
draft-drake-agent-identity-resolution-00>.
Author's Address
Christopher Drake
1id.com
Australia
Email: cnd@1id.com
URI: https://1id.com
Drake Expires 29 March 2027 [Page 40]