Extensible Provisioning Protocol (EPP) Authentication Token Mapping
draft-gould-regext-auth-token-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) | |
|---|---|---|---|
| Authors | James Gould , Poonam Garg , Mohammad Suhale Malang Khader | ||
| Last updated | 2026-07-20 | ||
| 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-gould-regext-auth-token-00
Network Working Group J. Gould
Internet-Draft P. Garg
Intended status: Standards Track M.S. Malang Khader
Expires: 21 January 2027 VeriSign, Inc.
20 July 2026
Extensible Provisioning Protocol (EPP) Authentication Token Mapping
draft-gould-regext-auth-token-00
Abstract
This document describes an Extensible Provisioning Protocol (EPP)
mapping for provisioning and management of EPP Authentication Token
objects in a shared central repository, where an Authentication Token
is a JSON Web Signature (JWS), defined in RFC 7515, and is used to
authorize actions by registrar users. The Authentication Token can
be passed over an authenticated EPP session, as defined in RFC 5730,
to provide elevated, fine-grained authorization exclusively valid
until the lifetime of the digitally signed Authentication Token.
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 21 January 2027.
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
Gould, et al. Expires 21 January 2027 [Page 1]
Internet-Draft EPP Authentication Token Mapping July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.2. Registrar User . . . . . . . . . . . . . . . . . . . . . 3
2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Authentication Token . . . . . . . . . . . . . . . . . . 4
2.1.1. Authentication Token Header . . . . . . . . . . . . . 4
2.1.2. Authentication Token Payload . . . . . . . . . . . . 5
2.1.3. Authentication Token Signature . . . . . . . . . . . 6
2.2. Authentication Token Poll Message . . . . . . . . . . . . 6
3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 8
3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 8
3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 8
3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 12
3.1.3. EPP <transfer> Query Command . . . . . . . . . . . . 16
3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 17
3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 17
3.2.2. EPP <update> Command . . . . . . . . . . . . . . . . 20
3.2.3. EPP <delete> Command . . . . . . . . . . . . . . . . 21
3.2.4. EPP <renew> Command . . . . . . . . . . . . . . . . . 22
3.2.5. EPP <transfer> Command . . . . . . . . . . . . . . . 23
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 23
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 25
5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 26
5.3. RDAP JSON Media Type Registration . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Normative References . . . . . . . . . . . . . . . . . . 28
7.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction
This document describes an Extensible Provisioning Protocol (EPP)
mapping for provisioning and management of EPP Authentication Token
objects in a shared central repository, where an Authentication Token
is a JSON Web Signature (JWS) [RFC7515], which uses JWS Compact
Serialization and is embedded as a string in the EPP XML to authorize
actions by registrar users. The Authentication Token can be passed
over an authenticated EPP session, as defined in [RFC5730], to
provide granular, time-bound authorization till the lifetime of the
digitally signed Authentication Token.
Gould, et al. Expires 21 January 2027 [Page 2]
Internet-Draft EPP Authentication Token Mapping July 2026
This document describes a EPP Authentication Token object mapping for
version 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730].
This mapping is specified using the XML 1.0 as described in
[W3C.REC-xml-20040204] and XML Schema notation as described in
[W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028].
1.1. Conventions Used in This Document
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
[BCP14] 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 is provided only to illustrate element
relationships and is not a REQUIRED feature of this specification.
XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the
character case presented to develop a conforming implementation.
The XML namespace prefix "authToken" is used for the namespace
"urn:ietf:params:xml:ns:epp:authToken-0.1", but implementations MUST
NOT depend on it; instead, they should employ a proper namespace-
aware XML parser and serializer to interpret and output the XML
documents.
Cryptographic algorithms and identifiers for use with this
specification are described in the separate JSON Web Algorithms (JWA)
[RFC7518] specification and an IANA registry defined by that
specification.
The line breaks in the JWS Compact Serialization values are used only
illustration purposes and MUST NOT be used in a conforming
implementation.
1.2. Registrar User
[RFC8499] defines the registrar as "a service provider that acts as a
go-between for registrants and registries." and defines the
registrant and registry. A registrar can have many users that
interface with the registry across many channels, such as EPP and Web
User Interface (UI), which is referred to as a Registrar User in this
document. The EPP client in [RFC5730], referred to as the EPP
Registrar User is this document, is a registrar system that uses the
EPP Registrar User credentials to authenticate with the <login>
Gould, et al. Expires 21 January 2027 [Page 3]
Internet-Draft EPP Authentication Token Mapping July 2026
command to establish an EPP session. The Registrar User
authenticates to create the Authentication Token that MUST be a
Registrar User other than the EPP Registrar User since the EPP
Registrar User is used only to create the EPP session.
2. Object Attributes
An Authentication Token has attributes and associated values that is
generated and signed by the server and may be viewed and verified by
the sponsoring client or the server. This section describes each
attribute type in detail. The formal syntax for the attribute values
described here can be found in the "Formal Syntax" section of this
document and in the appropriate normative references.
2.1. Authentication Token
The Authentication Token uses JSON Web Signature (JWS), defined in
[RFC7515], with JWS Compact Serialization, defined in Section 3.1 of
[RFC7515], to digitally sign the JWS Protected Header properties and
JWS Payload claims in a single string that is embedded in an EPP XML
element. The following sections define the JWS Protected Header and
the JWS Payload JSON members.
Example Authentication Token that is serialized using JWS Compact
Serialization, where the JWS Protected Header, the JWS Payload, and
the JWS Signature using ES512 are separated with a period ('.'):
eyJhbGciOiJFUzUxMiIsInR5cCI6ImVhdCtqd3MiLCJraWQiOiJFQVRfS0VZMV9TWVNUR
U0tUkVQIn0.eyJqdGkiOiJFQVRfMTIzNDVfU1lTVEVNLVJFUCIsInN1YiI6IkNsaWVudF
kiLCJleHAiOiIxNzc1NjgyMDAwIiwiZW50aXRsZW1lbnRzIjpbIlNFUlZJQ0UxLVJPIiw
iU0VSVklDRTItUlciLCJUTEQxLVJXIiwiVExEMi1SVyJdfQ.ADJWkWMnZUFLll2Jzxbw0
0919aC_qm_9UgeBKCY6MSAnVZtOmqVlE-Gfyut5dk7iU69VXKRi89RU3L4YMyVvykFvAJ
m-aqNpHkYaYUZ_a0aZeN2KcVTVUXzPEtnq7kldvJTpYhB1-JmbFuQ2B6Z5PFZeR5k-Scm
DEDdFl9nIFCLd5-mF
2.1.1. Authentication Token Header
The Authentication Token Header is a JWS Protected Header that is
protected by the JWS Signature and follows the format of a JOSE
Header, defined in Section 4 of [RFC7515]. The following Header
Parameter Names are used in the Authentication Token Header:
* "alg": The "alg" (Algorithm) Header Parameter, defined in
Section 4.1.1 of [RFC7515], identifies the cryptographic algorithm
used to secure the Authentication Token. A list of defined "alg"
values for this use can be found in the IANA "JSON Web Signature
and Encryption Algorithms" registry established by [RFC7518]; the
initial contents of this registry are the values defined in
Gould, et al. Expires 21 January 2027 [Page 4]
Internet-Draft EPP Authentication Token Mapping July 2026
Section 3.1 of [RFC7518]. A digital signature algorithm, such as
"ES512", is RECOMMENDED to enable protecting the private key and
distributing the public key to validate the Authentication Token
signature.
* "typ": The "typ" (Type) Header Parameter, defined in Section 4.1.9
of [RFC7515], identifies the media type of the complete JWS that
uses the EPP Authentication Token specific value "eat+jws", which
is registered in Section 5.3.
* "kid": The "kid" (KEY ID) Header Parameter, defined in
Section 4.1.4 of [RFC7515], identifies the key used to sign the
Authentication Token, where the "kid" can be used to locate the
certificate containing the public key to verify the Authentication
Token signature. The "kid" value contains the globally unique
Repository Object IDentifier (ROID), defined in Section 2.8 of
[RFC5730], assigned to the key pair.
Example Authentication Token Header using the "ES512" digital
signature algorithm and the "kid" of "EAT_KEY1_SYSTEM-REP":
{
"alg" : "ES512",
"typ" : "eat+jws",
"kid" : "EAT_KEY1_SYSTEM-REP"
}
2.1.2. Authentication Token Payload
The Authentication Token Payload is a JWS Payload that is protected
by the JWS Signature and includes a set of JWT Claims, as defined in
Section 4 of [RFC7519]. The following JWT Claims are used in the
Authentication Token Payload:
* "jti": The "jti" (JWT ID) Claim, defined in Section 4.1.7 of
[RFC7519], identifies the globally unique Repository Object
IDentifier (ROID), defined in Section 2.8 of [RFC5730], for the
Authentication Token. An example is "EAT_12345_SYSTEM-REP".
* "sub": The "sub" (Subject) Claim, defined in Section 4.1.2 of
[RFC7519], identifies the user that is associated with the
Authentication Token. An example is "ClientY".
* "exp": The "exp" (Expiration Time) Claim, defined in Section 4.1.4
of [RFC7519], identifies the expiration time in epoch time on or
after which the Authentication Token MUST NOT be used. An example
is "1775682000".
Gould, et al. Expires 21 January 2027 [Page 5]
Internet-Draft EPP Authentication Token Mapping July 2026
* "entitlements": The "entitlements" (Entitlements) Claim, defined
in Section 4.1.2 of [RFC7643], identifies the list of entitlements
or authorization groups for the user. The authorization group
values are up to server policy and are used by the server to
implement the authorization of operations. Examples include
service-level authorization groups, such as read-only access to
SERVICE1 with "SERVICE1-RO", read-write access to SERVICE2 with
"SERVICE2-RW", read-write access to Top Level Domains (TLDs)
"TLD1" and "TLD2" with "TLD1-RW" and "TLD2-RW", respectively.
Example Authentication Token Payload for user "ClientY", with "jti"
of "EAT_KEY1_SYSTEM-REP", and with a list of entitlements:
{
"jti": "EAT_12345_SYSTEM-REP",
"sub": "ClientY",
"exp": "1775682000",
"entitlements": [
"SERVICE1-RO",
"SERVICE2-RW",
"TLD1-RW",
"TLD2-RW"
]
}
2.1.3. Authentication Token Signature
The Authentication Token Signature is a JWS Signature, as defined in
Section 7.2.1 of [RFC7519]. A list of defined "alg" values for this
use can be found in the IANA "JSON Web Signature and Encryption
Algorithms" registry established by [RFC7518]; the initial contents
of this registry are the values defined in Section 3.1 of [RFC7518].
A digital signature algorithm, such as "ES512", is RECOMMENDED by
this document to enable protecting the private key and distributing
the public key to validate the Authentication Token signature.
2.2. Authentication Token Poll Message
The EPP <poll> command and response are defined in section 2.9.2.3 of
[RFC5730]. For servers that support an Authentication Token object,
the Authentication Token Info Response, as defined in Section 3.1.2,
is inserted into the poll queue based on server policy, such as when
an Authentication token is revoked by the server.
Example <poll> command:
Gould, et al. Expires 21 January 2027 [Page 6]
Internet-Draft EPP Authentication Token Mapping July 2026
C:<?xml version="1.0" encoding="UTF-8"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:<command xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <poll op="req"/>
C: <clTRID>51364-CLI</clTRID>
C:</command>
C:</epp>
Example <poll> response:
S:<?xml version="1.0" encoding="UTF-8"?>
S:<epp
S: xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1301">
S: <msg lang="en-US">
S: Command completed successfully; ack to dequeue</msg>
S: </result>
S: <msgQ id="200" count="1">
S: <qDate>2026-04-08T09:00:00.0Z</qDate>
S: <msg>Revoked authentication token</msg>
S: </msgQ>
S: <resData>
S: <authToken:infData
S: xmlns:authToken="urn:ietf:params:xml:ns:epp:authToken-0.1">
S: <authToken:authToken>
S:eyJhbGciOiJFUzUxMiIsInR5cCI6ImVhdCtqd3MiLCJraWQiOiJFQVRfS0VZMV9TWVN
S:URU0tUkVQIn0.eyJqdGkiOiJFQVRfMTIzNDVfU1lTVEVNLVJFUCIsInN1YiI6IkNsaW
S:VudFkiLCJleHAiOiIxNzc1NjgyMDAwIiwiZW50aXRsZW1lbnRzIjpbIlNFUlZJQ0UxL
S:VJPIiwiU0VSVklDRTItUlciLCJUTEQxLVJXIiwiVExEMi1SVyJdfQ.ADJWkWMnZUFLl
S:l2Jzxbw00919aC_qm_9UgeBKCY6MSAnVZtOmqVlE-Gfyut5dk7iU69VXKRi89RU3L4Y
S:MyVvykFvAJm-aqNpHkYaYUZ_a0aZeN2KcVTVUXzPEtnq7kldvJTpYhB1-JmbFuQ2B6Z
S:5PFZeR5k-ScmDEDdFl9nIFCLd5-mF
S: </authToken:authToken>
S: <authToken:status>revoked</authToken:status>
S: <authToken:revokedDate>2026-04-08T09:00:00.0Z
S: </authToken:revokedDate>
S: <authToken:revokedID>ClientZ</authToken:revokedID>
S: <authToken:revokedReason>security issue
S: </authToken:revokedReason>
S: </authToken:infData>
S: </resData>
S: <trID>
S: <clTRID>51364-CLI</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
Gould, et al. Expires 21 January 2027 [Page 7]
Internet-Draft EPP Authentication Token Mapping July 2026
3. EPP Command Mapping
A detailed description of the EPP syntax and semantics can be found
in the EPP core protocol specification [RFC5730]. The command
mappings described here are specifically for use in provisioning and
managing Authentication Token information via EPP.
3.1. EPP Query Commands
This document provides two commands to retrieve Authentication Token
information:
<check> to determine if an Authentication Token is valid and <info>
to retrieve detailed information associated with an Authentication
Token object. This document does not define a mapping for the EPP
<transfer> command.
3.1.1. EPP <check> Command
The EPP <check> command is used to determine if an Authentication
Token is valid, where an Authentication Token is properly signed, has
not expired, and has not been revoked by either the client or the
server.
In addition to the standard EPP command elements, the <check> command
MUST contain an <authToken:check> element. This element or its
ancestor element MUST identify the "authToken" namespace. The
<authToken:check> element contains the following child elements:
* One or more <authToken:authToken> elements that contains the
Authentication Token, defined in Section 2.1, for the server to
validate.
Example <check> command:
Gould, et al. Expires 21 January 2027 [Page 8]
Internet-Draft EPP Authentication Token Mapping July 2026
C:<?xml version="1.0" encoding="UTF-8"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <check>
C: <authToken:check
C: xmlns:authToken="urn:ietf:params:xml:ns:epp:authToken-0.1">
C: <authToken:authToken>
C:eyJhbGciOiJFUzUxMiIsInR5cCI6ImVhdCtqd3MiLCJraWQiOiJFQVRfS0VZMV9TWVN
C:URU0tUkVQIn0.eyJqdGkiOiJFQVRfMTIzNDVfU1lTVEVNLVJFUCIsInN1YiI6IkNsaW
C:VudFkiLCJleHAiOiIxNzc1NjgyMDAwIiwiZW50aXRsZW1lbnRzIjpbIlNFUlZJQ0UxL
C:VJPIiwiU0VSVklDRTItUlciLCJUTEQxLVJXIiwiVExEMi1SVyJdfQ.ADJWkWMnZUFLl
C:l2Jzxbw00919aC_qm_9UgeBKCY6MSAnVZtOmqVlE-Gfyut5dk7iU69VXKRi89RU3L4Y
C:MyVvykFvAJm-aqNpHkYaYUZ_a0aZeN2KcVTVUXzPEtnq7kldvJTpYhB1-JmbFuQ2B6Z
C:5PFZeR5k-ScmDEDdFl9nIFCLd5-mF
C: </authToken:authToken>
C: <authToken:authToken>
C:eyJ0eXAiOiJKV1QiLA0KICabcJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJ
C:leHAiOjEzMDAabc4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp
C:0cnVlfQ.dBjftJeZ4CVP-mB92K27abcuhbUJU1p1r_wW1gFWFOEjXk
C: </authToken:authToken>
C: <authToken:authToken>
C:eyJ0eXAiOiJasdABBKJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJABCDMDA4MTkzODAsDQo
C:gImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92KA
C:BCDW1gFWFOEjXk
C: </authToken:authToken>
C: </authToken:check>
C: </check>
C: <clTRID>51364-CLI</clTRID>
C: </command>
C:</epp>
When a <check> command has been processed successfully, the EPP
<resData> element MUST contain a child <authToken:chkData> element
that identifies the "authToken" namespace. The <authToken:chkData>
element contains the following child elements:
one or more <authToken:cd> elements that contain the following child
elements:
* An <authToken:authToken> element that contains the Authentication
Token, defined in Section 2.1, and MUST contain a "valid"
attribute value that indicates whether the Authentication Token is
valid. A value "1" or "true" means that the Authentication Token
is valid. A value of "0" or "false" means that the Authentication
Token is not valid. An Authentication Token is valid if its
correctly signed by a trusted key, follows the format of the
"eat+jws" media type, has not expired, and has not been revoked by
the client or the server.
Gould, et al. Expires 21 January 2027 [Page 9]
Internet-Draft EPP Authentication Token Mapping July 2026
* An OPTIONAL <authToken:reason> when the Authentication Token is
not valid, such as "expired token" or "revoked token". This text
MUST be represented in the response language previously negotiated
with the client; an OPTIONAL "lang" attribute MAY be present to
identify the language if the negotiated value is something other
than the default value of "en" (English). This element MUST be
returned when the Authentication Token is not valid.
Example <check> response:
Gould, et al. Expires 21 January 2027 [Page 10]
Internet-Draft EPP Authentication Token Mapping July 2026
S:<?xml version="1.0" encoding="UTF-8"?>
S:<epp
S: xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully
S: </msg>
S: </result>
S: <resData>
S: <authToken:chkData
S: xmlns:authToken="urn:ietf:params:xml:ns:epp:authToken-0.1">
S: <authToken:cd>
S: <authToken:authToken valid="true">
S:eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleH
S:AiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlf
S:Q.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
S: </authToken:authToken>
S: </authToken:cd>
S: <authToken:cd>
S: <authToken:authToken valid="false">
S:eyJ0eXAiOiJKV1QiLA0KICabcJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJ
S:leHAiOjEzMDAabc4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp
S:0cnVlfQ.dBjftJeZ4CVP-mB92K27abcuhbUJU1p1r_wW1gFWFOEjXk
S: </authToken:authToken>
S: <authToken:reason>expired token</authToken:reason>
S: </authToken:cd>
S: <authToken:cd>
S: <authToken:authToken valid="false">
S:eyJ0eXAiOiJasdABBKJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJABCDMDA4MTkzODAsDQo
S:gImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92KA
S:BCDW1gFWFOEjXk
S: </authToken:authToken>
S: <authToken:reason>revoked token</authToken:reason>
S: </authToken:cd>
S: </authToken:chkData>
S: </resData>
S: <trID>
S: <clTRID>51364-CLI</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if a <check> command cannot be
processed for any reason.
Gould, et al. Expires 21 January 2027 [Page 11]
Internet-Draft EPP Authentication Token Mapping July 2026
3.1.2. EPP <info> Command
The EPP <info> command is used to retrieve information associated
with the Authentication Token, such as whether it has been revoked
with related revocation data elements. In addition to the standard
EPP command elements, the <info> command MUST contain a
<authToken:info> element that identifies the "authToken" namespace.
The <authToken:info> element contains the following child elements:
* A <authToken:authToken> element that contains the Authentication
Token, defined in Section 2.1, to get information for.
Example <info> command:
C:<?xml version="1.0" encoding="UTF-8"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <authToken:info
C: xmlns:authToken="urn:ietf:params:xml:ns:epp:authToken-0.1">
C: <authToken:authToken>
C:eyJhbGciOiJFUzUxMiIsInR5cCI6ImVhdCtqd3MiLCJraWQiOiJFQVRfS0VZMV9TWVN
C:URU0tUkVQIn0.eyJqdGkiOiJFQVRfMTIzNDVfU1lTVEVNLVJFUCIsInN1YiI6IkNsaW
C:VudFkiLCJleHAiOiIxNzc1NjgyMDAwIiwiZW50aXRsZW1lbnRzIjpbIlNFUlZJQ0UxL
C:VJPIiwiU0VSVklDRTItUlciLCJUTEQxLVJXIiwiVExEMi1SVyJdfQ.ADJWkWMnZUFLl
C:l2Jzxbw00919aC_qm_9UgeBKCY6MSAnVZtOmqVlE-Gfyut5dk7iU69VXKRi89RU3L4Y
C:MyVvykFvAJm-aqNpHkYaYUZ_a0aZeN2KcVTVUXzPEtnq7kldvJTpYhB1-JmbFuQ2B6Z
C:5PFZeR5k-ScmDEDdFl9nIFCLd5-mF
C: </authToken:authToken>
C: </authToken:info>
C: </info>
C: <clTRID>51364-CLI</clTRID>
C: </command>
C:</epp>
When an <info> command has been processed successfully by the server
validating the Authentication Token and retrieving any revocation
data, the EPP <resData> element MUST contain a child
<authToken:infData> element that identifies the "authToken"
namespace. The <authToken:infData> element contains the following
child elements:
* A <authToken:authToken> element that contains the Authentication
Token passed in the <info> command, defined in Section 2.1.
* A <authToken:status> element that contains the Authentication
Token status with the following enumerated values:
Gould, et al. Expires 21 January 2027 [Page 12]
Internet-Draft EPP Authentication Token Mapping July 2026
- "active": Authentication Token is valid, has not expired, and
has not been revoked.
- "expired": Authentication Token is not valid, since it has
expired.
- "revoked": Authentication Token is not valid, since it has been
revoked.
* An OPTIONAL <authToken:crDate> element that contains the date and
time of Authentication Token creation.
* An OPTIONAL <authToken:exDate> element that contains the date and
time when the Authentication token expires and MUST NOT be used.
* An OPTIONAL <authToken:revokedDate> element that contains the date
and time the Authentication Token was revoked. This element MUST
be returned when the <authToken:status> element has the value of
"revoked".
* An OPTIONAL <authToken:revokedID> element that contains the
identifier of the client that revoked the Authentication Token
object. This element MUST be returned when the <authToken:status>
element has the value of "revoked".
* An OPTIONAL <authToken:revokedReason> element that contains a
freeform reason for the Authentication Token revocation. This
text MUST be represented in the response language previously
negotiated with the client; an OPTIONAL "lang" attribute MAY be
present to identify the language if the negotiated value is
something other than the default value of "en" (English). This
element MUST be returned when the <authToken:status> element has
the value of "revoked".
Example <info> response for an active Authentication Token:
Gould, et al. Expires 21 January 2027 [Page 13]
Internet-Draft EPP Authentication Token Mapping July 2026
S:<?xml version="1.0" encoding="UTF-8"?>
S:<epp
S: xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully
S: </msg>
S: </result>
S: <resData>
S: <authToken:infData
S: xmlns:authToken="urn:ietf:params:xml:ns:epp:authToken-0.1">
S: <authToken:authToken>
S:eyJhbGciOiJFUzUxMiIsInR5cCI6ImVhdCtqd3MiLCJraWQiOiJFQVRfS0VZMV9TWVN
S:URU0tUkVQIn0.eyJqdGkiOiJFQVRfMTIzNDVfU1lTVEVNLVJFUCIsInN1YiI6IkNsaW
S:VudFkiLCJleHAiOiIxNzc1NjgyMDAwIiwiZW50aXRsZW1lbnRzIjpbIlNFUlZJQ0UxL
S:VJPIiwiU0VSVklDRTItUlciLCJUTEQxLVJXIiwiVExEMi1SVyJdfQ.ADJWkWMnZUFLl
S:l2Jzxbw00919aC_qm_9UgeBKCY6MSAnVZtOmqVlE-Gfyut5dk7iU69VXKRi89RU3L4Y
S:MyVvykFvAJm-aqNpHkYaYUZ_a0aZeN2KcVTVUXzPEtnq7kldvJTpYhB1-JmbFuQ2B6Z
S:5PFZeR5k-ScmDEDdFl9nIFCLd5-mF
S: </authToken:authToken>
S: <authToken:status>active</authToken:status>
S: <authToken:crDate>2026-04-08T09:00:00.0Z</authToken:crDate>
S: <authToken:exDate>2026-04-08T10:00:00.0Z</authToken:exDate>
S: </authToken:infData>
S: </resData>
S: <trID>
S: <clTRID>51364-CLI</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
Example <info> response for an expired Authentication Token:
Gould, et al. Expires 21 January 2027 [Page 14]
Internet-Draft EPP Authentication Token Mapping July 2026
S:<?xml version="1.0" encoding="UTF-8"?>
S:<epp
S: xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully
S: </msg>
S: </result>
S: <resData>
S: <authToken:infData
S: xmlns:authToken="urn:ietf:params:xml:ns:epp:authToken-0.1">
S: <authToken:authToken>
S:eyJhbGciOiJFUzUxMiIsInR5cCI6ImVhdCtqd3MiLCJraWQiOiJFQVRfS0VZMV9TWVN
S:URU0tUkVQIn0.eyJqdGkiOiJFQVRfMTIzNDVfU1lTVEVNLVJFUCIsInN1YiI6IkNsaW
S:VudFkiLCJleHAiOiIxNzc1NjgyMDAwIiwiZW50aXRsZW1lbnRzIjpbIlNFUlZJQ0UxL
S:VJPIiwiU0VSVklDRTItUlciLCJUTEQxLVJXIiwiVExEMi1SVyJdfQ.ADJWkWMnZUFLl
S:l2Jzxbw00919aC_qm_9UgeBKCY6MSAnVZtOmqVlE-Gfyut5dk7iU69VXKRi89RU3L4Y
S:MyVvykFvAJm-aqNpHkYaYUZ_a0aZeN2KcVTVUXzPEtnq7kldvJTpYhB1-JmbFuQ2B6Z
S:5PFZeR5k-ScmDEDdFl9nIFCLd5-mF
S: </authToken:authToken>
S: <authToken:status>expired</authToken:status>
S: <authToken:crDate>2026-04-08T06:00:00.0Z</authToken:crDate>
S: <authToken:exDate>2026-04-08T07:00:00.0Z</authToken:exDate>
S: </authToken:infData>
S: </resData>
S: <trID>
S: <clTRID>51364-CLI</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
Example <info> response for a revoked Authentication Token:
Gould, et al. Expires 21 January 2027 [Page 15]
Internet-Draft EPP Authentication Token Mapping July 2026
S:<?xml version="1.0" encoding="UTF-8"?>
S:<epp
S: xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully
S: </msg>
S: </result>
S: <resData>
S: <authToken:infData
S: xmlns:authToken="urn:ietf:params:xml:ns:epp:authToken-0.1">
S: <authToken:authToken>
S:eyJhbGciOiJFUzUxMiIsInR5cCI6ImVhdCtqd3MiLCJraWQiOiJFQVRfS0VZMV9TWVN
S:URU0tUkVQIn0.eyJqdGkiOiJFQVRfMTIzNDVfU1lTVEVNLVJFUCIsInN1YiI6IkNsaW
S:udFkiLCJleHAiOiIxNzc1NjgyMDAwIiwiZW50aXRsZW1lbnRzIjpbIlNFUlZJQ0UxL
S:JPIiwiU0VSVklDRTItUlciLCJUTEQxLVJXIiwiVExEMi1SVyJdfQ.ADJWkWMnZUFLl
l2Jzxbw00919aC_qm_9UgeBKCY6MSAnVZtOmqVlE-Gfyut5dk7iU69VXKRi89RU3L4Y
S:MyVvykFvAJm-aqNpHkYaYUZ_a0aZeN2KcVTVUXzPEtnq7kldvJTpYhB1-JmbFuQ2B6Z
S:5PFZeR5k-ScmDEDdFl9nIFCLd5-mF
S: </authToken:authToken>
S: <authToken:status>revoked</authToken:status>
S: <authToken:crDate>2026-04-08T08:30:00.0Z
S: </authToken:crDate>
S: <authToken:revokedDate>2026-04-08T09:00:00.0Z
S: </authToken:revokedDate>
S: <authToken:revokedID>ClientZ</authToken:revokedID>
S: <authToken:revokedReason>security issue
S: </authToken:revokedReason>
S: </authToken:infData>
S: </resData>
S: <trID>
S: <clTRID>51364-CLI</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if a <info> command cannot be
processed for any reason. A 2306 EPP error response MUST be returned
if the Authentication Token signature is invalid and a 2305 EPP error
response MUST be returned if the Authentication Token does not
conform to the "application/eat+jws" media type.
3.1.3. EPP <transfer> Query Command
The transfer semantics do not apply to Authentication Token objects.
No EPP <transfer> query command is defined in this document.
Gould, et al. Expires 21 January 2027 [Page 16]
Internet-Draft EPP Authentication Token Mapping July 2026
3.2. EPP Transform Commands
This document provides two commands to transform Authentication Token
object information:
<create> to create an instance of an Authentication Token object and
<delete> to revoke an instance of an Authentication Token object.
This document does not define a mapping for the EPP <transfer>,
<renew>, and <update> command.
3.2.1. EPP <create> Command
The EPP <create> command is used to authenticate a user and create an
Authentication Token object.
In addition to the standard EPP command elements, the <create>
command MUST contain a <authToken:create> element that identifies the
"authToken" namespace. The <authToken:create> element contains the
following child elements:
* An OPTIONAL <authToken:scope> element that scopes the
authentication to a set of registry systems or domain names, which
are typically Top Level Domains (TLDs). This enables the client
system to restrict authorization groups contained in the created
Authentication Token for the registrar user. If no
<authToken:scope> element is provided, the authorization groups
assigned to the registrar user will be set by the server. The
<authToken:scope> contains the following child elements:
- OPTIONAL zero or more <authToken:system> elements that contain
the names of the registry system to scope the Authentication
Token authorization groups. The registry system names are up
to server policy and are made available by the server out-of-
band.
- OPTIONAL zero or more <authToken:domain> elements that contain
the authoritative domain names managed by the registry to scope
the Authentication Token authorization groups.
* Authentication credentials that consists of a choice between
Multi-Factor Authentication (MFA) credentials, represented by the
<authToken:credentials> element, or a bearer token, represented by
the <authToken:bearerToken> element, supported by the server. The
<authToken:bearerToken> element contains a Base64 encoded
[RFC4648] value and a required "type" attribute, representing the
type of the bearer token. The <authToken:credentials> element
includes the following child elements:
Gould, et al. Expires 21 January 2027 [Page 17]
Internet-Draft EPP Authentication Token Mapping July 2026
- A <authToken:clID> element that contains the registrar user
identifier for the authenticating user.
- A <authToken:pw> element that contains the registrar user
password for the authenticating user, which must be at least 6
characters long.
- A <authToken:mfa> element that contains the Multi-Factor
Authentication (MFA) value, which represents what the registrar
user "has" versus what the user "knows" with the
<authToken:clID> and <authToken:pw> elements. The type of the
MFA credential is defined with the "type" attribute, with the
default value of "totp". The following are the predefined MFA
types:
o "totp" is a time-based one-time password (TOTP), defined in
[RFC6238]. "totp" is the default "type" attribute value.
o "key" is a shared key that is Base64 encoded [RFC4648].
o "biometric" is data that is Base64 encoded [RFC4648], where
the biometric data accepted by the server is up to server
policy.
o "device" is a device-level key as represented by a hardware
or software token that is Base64 encoded [RFC4648].
o "push" is a push to the registrar user's device application.
The user device application needs to be configured in the
server.
o "custom" is a custom MFA type defined by the "custom"
attribute. The supported set of custom MFA types is up to
server policy.
Example <create> command with MFA credential:
Gould, et al. Expires 21 January 2027 [Page 18]
Internet-Draft EPP Authentication Token Mapping July 2026
C:<?xml version="1.0" encoding="UTF-8"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <create>
C: <authToken:create
C: xmlns:authToken="urn:ietf:params:xml:ns:epp:authToken-0.1">
C: <authToken:scope>
C: <authToken:domain>example1</authToken:domain>
C: <authToken:domain>example2</authToken:domain>
C: </authToken:scope>
C: <authToken:credential>
C: <authToken:clID>ClientY</authToken:clID>
C: <authToken:pw>foo-BAR2</authToken:pw>
C: <authToken:mfa type="totp">123456
C: </authToken:mfa>
C: </authToken:credential>
C: </authToken:create>
C: </create>
C: <clTRID>51364-CLI</clTRID>
C: </command>
C:</epp>
Example <create> command with Bearer Token:
C:<?xml version="1.0" encoding="UTF-8"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <create>
C: <authToken:create
C: xmlns:authToken="urn:ietf:params:xml:ns:epp:authToken-0.1">
C: <authToken:scope>
C: <authToken:domain>example1</authToken:domain>
C: <authToken:domain>example2</authToken:domain>
C: </authToken:scope>
C: <authToken:bearerToken type="example">
C: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
C: </authToken:bearerToken>
C: </authToken:create>
C: </create>
C: <clTRID>51364-CLI</clTRID>
C: </command>
C:</epp>
Gould, et al. Expires 21 January 2027 [Page 19]
Internet-Draft EPP Authentication Token Mapping July 2026
When a <create> command has been processed successfully the
Authentication Token is created and the EPP <resData> element MUST
contain a child <authToken:creData> element that identifies the
"authToken" namespace. The <authToken:creData> element has the
<authToken:authToken> child element that contains the Authentication
Token defined in Section 2.1:
Example <create> response:
S:<?xml version="1.0" encoding="UTF-8"?>
S:<epp
S: xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully
S: </msg>
S: </result>
S: <resData>
S: <authToken:creData
S: xmlns:authToken="urn:ietf:params:xml:ns:epp:authToken-0.1">
S: <authToken:authToken>
S:eyJhbGciOiJFUzUxMiIsInR5cCI6ImVhdCtqd3MiLCJraWQiOiJFQVRfS0VZMV9TWVN
S:URU0tUkVQIn0.eyJqdGkiOiJFQVRfMTIzNDVfU1lTVEVNLVJFUCIsInN1YiI6IkNsaW
S:VudFkiLCJleHAiOiIxNzc1NjgyMDAwIiwiZW50aXRsZW1lbnRzIjpbIlNFUlZJQ0UxL
S:VJPIiwiU0VSVklDRTItUlciLCJUTEQxLVJXIiwiVExEMi1SVyJdfQ.ADJWkWMnZUFLl
S:l2Jzxbw00919aC_qm_9UgeBKCY6MSAnVZtOmqVlE-Gfyut5dk7iU69VXKRi89RU3L4Y
S:MyVvykFvAJm-aqNpHkYaYUZ_a0aZeN2KcVTVUXzPEtnq7kldvJTpYhB1-JmbFuQ2B6Z
S:5PFZeR5k-ScmDEDdFl9nIFCLd5-mF
S: </authToken:authToken>
S: </authToken:creData>
S: </resData>
S: <trID>
S: <clTRID>51364-CLI</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if a <create> command cannot
be processed for any reason.
3.2.2. EPP <update> Command
Update semantics do not apply to Authentication Token objects, so
there is no mapping defined for the EPP <update> command.
Gould, et al. Expires 21 January 2027 [Page 20]
Internet-Draft EPP Authentication Token Mapping July 2026
3.2.3. EPP <delete> Command
The EPP <delete> command is used to revoke an Authentication Token
object.
In addition to the standard EPP command elements, the <delete>
command MUST contain a <authToken:delete> element that identifies the
"authToken" namespace. The <authToken:delete> element contains the
following child elements:
* A <authToken:authToken> element that contains the Authentication
Token, defined in Section 2.1, to revoke.
An OPTIONAL <authToken:revokedReason> element that contains
freeform revocation reason for the Authentication Token. This
text MUST be represented in the response language previously
negotiated with the client; an OPTIONAL "lang" attribute MAY be
present to identify the language if the negotiated value is
something other than the default value of "en" (English).
Example <delete> command:
C:<?xml version="1.0" encoding="UTF-8"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <delete>
C: <authToken:delete
C: xmlns:authToken="urn:ietf:params:xml:ns:epp:authToken-0.1">
C: <authToken:authToken>
C:eyJhbGciOiJFUzUxMiIsInR5cCI6ImVhdCtqd3MiLCJraWQiOiJFQVRfS0VZMV9TWVN
C:URU0tUkVQIn0.eyJqdGkiOiJFQVRfMTIzNDVfU1lTVEVNLVJFUCIsInN1YiI6IkNsaW
C:VudFkiLCJleHAiOiIxNzc1NjgyMDAwIiwiZW50aXRsZW1lbnRzIjpbIlNFUlZJQ0UxL
C:VJPIiwiU0VSVklDRTItUlciLCJUTEQxLVJXIiwiVExEMi1SVyJdfQ.ADJWkWMnZUFLl
C:l2Jzxbw00919aC_qm_9UgeBKCY6MSAnVZtOmqVlE-Gfyut5dk7iU69VXKRi89RU3L4Y
C:MyVvykFvAJm-aqNpHkYaYUZ_a0aZeN2KcVTVUXzPEtnq7kldvJTpYhB1-JmbFuQ2B6Z
C:5PFZeR5k-ScmDEDdFl9nIFCLd5-mF
C: </authToken:authToken>
C: </authToken:delete>
C: </delete>
C: <clTRID>51364-CLI</clTRID>
C: </command>
C:</epp>
Example <delete> command with a reason:
Gould, et al. Expires 21 January 2027 [Page 21]
Internet-Draft EPP Authentication Token Mapping July 2026
C:<?xml version="1.0" encoding="UTF-8"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <delete>
C: <authToken:delete
C: xmlns:authToken="urn:ietf:params:xml:ns:epp:authToken-0.1">
C: <authToken:authToken>
C:eyJhbGciOiJFUzUxMiIsInR5cCI6ImVhdCtqd3MiLCJraWQiOiJFQVRfS0VZMV9TWVN
C:URU0tUkVQIn0.eyJqdGkiOiJFQVRfMTIzNDVfU1lTVEVNLVJFUCIsInN1YiI6IkNsaW
C:VudFkiLCJleHAiOiIxNzc1NjgyMDAwIiwiZW50aXRsZW1lbnRzIjpbIlNFUlZJQ0UxL
C:VJPIiwiU0VSVklDRTItUlciLCJUTEQxLVJXIiwiVExEMi1SVyJdfQ.ADJWkWMnZUFLl
C:l2Jzxbw00919aC_qm_9UgeBKCY6MSAnVZtOmqVlE-Gfyut5dk7iU69VXKRi89RU3L4Y
C:MyVvykFvAJm-aqNpHkYaYUZ_a0aZeN2KcVTVUXzPEtnq7kldvJTpYhB1-JmbFuQ2B6Z
C:5PFZeR5k-ScmDEDdFl9nIFCLd5-mF
C: </authToken:authToken>
C: <authToken:revokedReason>User inactivity
C: </authToken:revokedReason>
C: </authToken:delete>
C: </delete>
C: <clTRID>51364-CLI</clTRID>
C: </command>
C:</epp>
When a <delete> command has been processed successfully, the server
MUST respond with an EPP response with no <resData> element.
Example <delete> response:
S:<?xml version="1.0" encoding="UTF-8"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000"><msg>
S: Command completed successfully</msg></result>
S: <trID>
S: <clTRID>51364-CLI</clTRID>
S: <svTRID>SRV-43659</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if a <delete> command cannot
be processed for any reason.
3.2.4. EPP <renew> Command
Renewal semantics do not apply to Authentication Token objects, so
there is no mapping defined for the EPP <renew> command.
Gould, et al. Expires 21 January 2027 [Page 22]
Internet-Draft EPP Authentication Token Mapping July 2026
3.2.5. EPP <transfer> Command
Transfer semantics do not apply to Authentication Token objects, so
there is no mapping defined for the EPP <transfer> command.
4. Formal Syntax
An EPP object mapping is specified in XML Schema notation. The
formal syntax presented here is a complete schema representation of
the object mapping suitable for automated validation of EPP XML
instances. The BEGIN and END tags are not part of the schema; they
are used to note the beginning and ending of the schema for URI
registration purposes.
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0
shared structures schema.
</documentation>
</annotation>
<!--
Object authorization information types.
-->
<complexType name="pwAuthInfoType">
<simpleContent>
<extension base="normalizedString">
<attribute name="roid" type="eppcom:roidType"/>
</extension>
</simpleContent>
</complexType>
<complexType name="extAuthInfoType">
<sequence>
<any namespace="##other"/>
</sequence>
</complexType>
<!--
<check> response types.
Gould, et al. Expires 21 January 2027 [Page 23]
Internet-Draft EPP Authentication Token Mapping July 2026
-->
<complexType name="reasonType">
<simpleContent>
<extension base="eppcom:reasonBaseType">
<attribute name="lang" type="language"/>
</extension>
</simpleContent>
</complexType>
<simpleType name="reasonBaseType">
<restriction base="token">
<minLength value="1"/>
<maxLength value="32"/>
</restriction>
</simpleType>
<!--
Abstract client and object identifier type.
-->
<simpleType name="clIDType">
<restriction base="token">
<minLength value="3"/>
<maxLength value="16"/>
</restriction>
</simpleType>
<!--
DNS label type.
-->
<simpleType name="labelType">
<restriction base="token">
<minLength value="1"/>
<maxLength value="255"/>
</restriction>
</simpleType>
<!--
Non-empty token type.
-->
<simpleType name="minTokenType">
<restriction base="token">
<minLength value="1"/>
</restriction>
</simpleType>
<!--
Repository Object IDentifier type.
-->
Gould, et al. Expires 21 January 2027 [Page 24]
Internet-Draft EPP Authentication Token Mapping July 2026
<simpleType name="roidType">
<restriction base="token">
<pattern value="(\w|_){1,80}-\w{1,8}"/>
</restriction>
</simpleType>
<!--
Transfer status identifiers.
-->
<simpleType name="trStatusType">
<restriction base="token">
<enumeration value="clientApproved"/>
<enumeration value="clientCancelled"/>
<enumeration value="clientRejected"/>
<enumeration value="pending"/>
<enumeration value="serverApproved"/>
<enumeration value="serverCancelled"/>
</restriction>
</simpleType>
<!--
End of schema.
-->
</schema>
END
5. IANA Considerations
5.1. XML Namespace
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]. The
following URI assignment has been made by IANA:
Registration request for the Authentication Token Mapping namespace:
URI: urn:ietf:params:xml:ns:epp:authToken-0.1
Registrant Contact: Registrant Contact: IESG
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the Authentication Token Mapping XML Schema:
URI: urn:ietf:params:xml:schema:epp:authToken-0.1
Registrant Contact: Registrant Contact: IESG
XML: See the "Formal Syntax" section of this document.
Gould, et al. Expires 21 January 2027 [Page 25]
Internet-Draft EPP Authentication Token Mapping July 2026
5.2. EPP Extension Registry
The EPP extension described in this document has been registered by
IANA in the "Extensions for the Extensible Provisioning Protocol
(EPP)" registry described in [RFC7451]. The details of the
registration is as follows:
Name of Extension: "Extensible Provisioning Protocol (EPP)
Authentication Token Mapping"
Document Status: Standards Track
Reference: (insert reference to RFC version of this document)
Registrant Name and Email Address: IESG, <iesg@ietf.org>
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None
5.3. RDAP JSON Media Type Registration
This specification registers the "application/eat+jws" media type.
Type name: application
Subtype name: eat+jws
Required parameters: n/a
Encoding considerations: 8bit; values are represented as a JSON
Object or as a series of base64url-encoded values each separated
from the next by a single period ('.') character.
Security considerations: Section 6 of this document.
Interoperability considerations: n/a
Published specification: this document
Applications that use this media type: Implementations of the
Extensible Provisioning Protocol (EPP) and the EPP Authentication
Token extension.
Person & email address to contact for further information: IESG
<iesg@ietf.org>
Intended usage: COMMON
Restrictions on usage: none
Author/Change controller: IETF
Provisional Registration: no
6. Security Considerations
The mapping extensions described in this document extends the
security services described by EPP [RFC5730] and protocol layers used
by EPP by creating an authentication token that can be passed on top
of EPP for registrar users to perform more fine grained authorization
by other EPP extensions.
Gould, et al. Expires 21 January 2027 [Page 26]
Internet-Draft EPP Authentication Token Mapping July 2026
The security considerations for the server include:
1. The granularity of the "entitlements" (Entitlements) Claim in the
authentication token (Section 2.1) SHOULD consider the Principle
of Least Privilege (PoLP) that provides registrar users with
limited access rights based on the task necessary to perform the
needed operations.
2. Setting the "exp" (Expiration Time) Claim in the authentication
token (Section 2.1) SHOULD consider the Principle of Least
Privilege (PoLP) is defining the Expiration Time as low as
possible for the registrar user to perform the needed operations.
The number of "entitlements" (Entitlements) MAY be a factor in
defining the length of the "exp" (Expiration Time) Claim.
3. The authentication token (Section 2.1) MAY be created for BOT
users and non-BOT or actual human users. The type of registrar
user (BOT or non-BOT) SHOULD be considered in defining the
"entitlements" (Entitlements) Claim and "exp" (Expiration Time)
Claim. A BOT user can be fully automated in performing
operations with the authentication token (Section 2.1), so the
security risk is higher.
4. A revocation policy SHOULD be defined, where if a registrar is
compromized, all active authentication tokens (Section 2.1) for
the registrar SHOULD be revoked with a notification to the
registrar, as defined in Section 2.2.
5. Selection of an "alg" (Algorithm) in the authentication token
(Section 2.1) SHOULD use the latest security best practices.
It's recommended to select an algorithm that includes both a
private key and a public key, where the public key can be
distributed for validating the authentication token (Section 2.1)
signature by the client and additional server-side components.
The security considerations for the client include:
1. The authentication token (Section 2.1) MUST be securely stored
and transferred over an encrypted channel, such as defined in the
EPP over TCP Transport [RFC5734].
2. M-of-N authorization can be chosen or required, where M defines
the number of registrar users with a valid authentication token
(Section 2.1) of N registrar users needed to authorize an
operation. The client would need to coordinate creating and
access to more than one authentication token (Section 2.1) to
perform an operation, so the client needs to consider how many
registrar users can generate authentication tokens (Section 2.1)
Gould, et al. Expires 21 January 2027 [Page 27]
Internet-Draft EPP Authentication Token Mapping July 2026
and be capable of sharing the authentication tokens
(Section 2.1). The sharing of authentication tokens
(Section 2.1) across many users and operations raises the level
of exposure of the authentication token (Section 2.1) that
reduces the security. The client needs to consider the tradeoffs
of M-of-N authorization with the risk of sharing authentication
tokens (Section 2.1) across many registrar users.
3. The client MAY have access to the authentication token
(Section 2.1) public key to pre-verify it prior to using it. An
additional option is to use the check command (Section 3.1.1) to
have the server perform the validation. All known invalid
authentication tokens (Section 2.1) SHOULD be removed by the
client storage.
7. References
7.1. Normative References
[BCP14] Best Current Practice 14,
<https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:
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>.
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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[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>.
Gould, et al. Expires 21 January 2027 [Page 28]
Internet-Draft EPP Authentication Token Mapping July 2026
[RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP:
Time-Based One-Time Password Algorithm", RFC 6238,
DOI 10.17487/RFC6238, May 2011,
<https://www.rfc-editor.org/info/rfc6238>.
[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>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C.
Mortimore, "System for Cross-domain Identity Management:
Core Schema", RFC 7643, DOI 10.17487/RFC7643, September
2015, <https://www.rfc-editor.org/info/rfc7643>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 8499, DOI 10.17487/RFC8499, January
2019, <https://www.rfc-editor.org/info/rfc8499>.
[W3C.REC-xml-20040204]
Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, ""Extensible Markup Language (XML) 1.0 (Third
Edition)", World Wide Web Consortium FirstEdition REC-xml-
20040204", February 2004,
<http://www.w3.org/TR/2004/REC-xml-20040204>.
[W3C.REC-xmlschema-1-20041028]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
""XML Schema Part 1: Structures Second Edition", World
Wide Web Consortium Recommendation REC-xmlschema-
1-20041028", October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, ""XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Recommendation
REC-xmlschema-2-20041028", October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
7.2. Informative References
Gould, et al. Expires 21 January 2027 [Page 29]
Internet-Draft EPP Authentication Token Mapping July 2026
[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>.
Authors' Addresses
James Gould
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: jgould@verisign.com
URI: http://www.verisign.com
Poonam Garg
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: pogarg@verisign.com
URI: http://www.verisign.com
Mohammad Suhale Malang Khader
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: mmalangkhader@verisign.com
URI: http://www.verisign.com
Gould, et al. Expires 21 January 2027 [Page 30]