Internet-Draft EPP Authentication Token Mapping July 2026
Gould, et al. Expires 21 January 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-gould-regext-auth-token-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Gould
VeriSign, Inc.
P. Garg
VeriSign, Inc.
M.S. Malang Khader
VeriSign, Inc.

Extensible Provisioning Protocol (EPP) Authentication Token Mapping

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.

▲

Table of Contents

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.

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> 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 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".
  • "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:

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>

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:

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

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.

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:

    • "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:

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:

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:

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.

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:

    • 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:

      • "totp" is a time-based one-time password (TOTP), defined in [RFC6238]. "totp" is the default "type" attribute value.
      • "key" is a shared key that is Base64 encoded [RFC4648].
      • "biometric" is data that is Base64 encoded [RFC4648], where the biometric data accepted by the server is up to server policy.
      • "device" is a device-level key as represented by a hardware or software token that is Base64 encoded [RFC4648].
      • "push" is a push to the registrar user's device application. The user device application needs to be configured in the server.
      • "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:

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>

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.

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:

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.

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

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.

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) 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, , <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, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC3688]
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, , <https://www.rfc-editor.org/info/rfc3688>.
[RFC4648]
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <https://www.rfc-editor.org/info/rfc4648>.
[RFC5730]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, , <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, , <https://www.rfc-editor.org/info/rfc5734>.
[RFC6238]
M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: Time-Based One-Time Password Algorithm", RFC 6238, DOI 10.17487/RFC6238, , <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, , <https://www.rfc-editor.org/info/rfc7515>.
[RFC7518]
Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, , <https://www.rfc-editor.org/info/rfc7518>.
[RFC7519]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <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, , <https://www.rfc-editor.org/info/rfc7643>.
[RFC8499]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 8499, DOI 10.17487/RFC8499, , <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", , <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", , <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", , <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

7.2. Informative References

[RFC7451]
Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, , <https://www.rfc-editor.org/info/rfc7451>.

Authors' Addresses

James Gould
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America
URI: http://www.verisign.com
Poonam Garg
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America
URI: http://www.verisign.com
Mohammad Suhale Malang Khader
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America
URI: http://www.verisign.com