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]