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

Status Set Extension Mapping for the Extensible Provisioning Protocol

Abstract

This document describes an Extensible Provisioning Protocol (EPP) extension for the provisioning and management of status sets applied to EPP objects, such as the domain name object in RFC 5731. The EPP status values defined in the EPP object mappings, such as Section 2.3 of RFC 5731, support human-readable text that describes the rationale or reason for the status applied to the object. There can be many overlapping reasons for a status value being applied to the object, such as implementing a lock service, complying with a court order, or addressing domain abuse. A status set defines an object representing the reason for setting a list of status values, so clients and servers can manage the status sets in place of individual status values to effectively manage the overlapping reasons. The EPP extension supports the provisioning of client status sets, disclosure of the server status sets, and an enhanced authorization model for client status sets with the EPP Authentication Token in draft-gould-regext-epp-auth-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) extension for the provisioning and management of status sets applied to EPP objects, such as the domain name object in [RFC5731] and the host object in [RFC5732]. The EPP status values defined in the EPP object mappings, such as Section 2.3 of [RFC5731], support human-readable text that describes the rationale or reason for the status applied to the object. There can be many overlapping reasons for a status value being applied to the object, such as implementing a lock service, complying with a court order, or addressing domain abuse. A status set defines an object representing the reason for setting a list of status values, so clients and servers can manage the status sets in place of individual status values to effectively manage the overlapping reasons. The EPP extension supports the provisioning of client status sets, disclosure of the server status sets, and an enhanced authorization model for client status sets with the Authentication Token in draft-gould-regext-epp-auth-token. This document defines new EPP commands in the form of the Status Set Info, Status Set Create, Status Set Delete, Status Set Renew, and Status Set Update.

This document describes a Status Set Extension Mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730]. This extension 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 "statusSet" is used for the namespace "urn:ietf:params:xml:ns:epp:statusSet-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.

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, defined in draft-gould-regext-epp-auth-token, that MUST NOT be the EPP Registrar User since the EPP Registrar User is used only to create the EPP session. The ability to provision Status Sets using an Authentication Token is based on enabling a Registrar User to generate an Authentication Token and having the required set of authorization groups to authorize a Status Set action.

2. Object Attributes

This extension adds additional elements to EPP objects, such as the domain name mapping described in [RFC5731] and the host mapping described in [RFC5732]. Common attributes are described here.

2.1. Status Value

A Status Value is defined for EPP objects in the EPP extensions, such as Status Values in Section 2.3 of [RFC5731] and Section 3.1 of [RFC3915]. There is a single Status Value assigned to an object by type, such as the "clientUpdateProhibited" Status Value in [RFC5731] and the "redemptionPeriod" Status Value in [RFC3915]. The Status Value can include a text message indicating the reason(s) that the Status Value is set, such as:

<domain:status s="clientUpdateProhibited">
Auth Token Lock,Registrar Lock
</domain:status>

Inclusion and format of the Status Value reason(s) is specific to each server implemenation, and the client needs to implement the server-specific format. The Status Set, described in Section 2.2, makes the reason string into a named object with a set of attributes, including the associated Status Values.

2.2. Status Set

A Status Set is an object that defines the reason for the Status Values (Section 2.1) for an EPP object, such as the domain name object in [RFC5731] and the host object in [RFC5732]. The Status Set can also be used as a Marker Status Set when there are no mapped Status Values that can drive additional business logic and publishing use cases. An EPP object can have many assigned Status Sets, and the Status Sets can include an overlapping set of Status Values. The Status Value will be assigned to the object if there is at least one Status Set assigned to the object with the mapped Status Value. The Status Value will be unassigned from the object when all Status Sets are unassigned with the mapped Status Value. For example, both the "Registrar Lock" Status Set and the "Auth Token Lock" Status Set are mapped to the "clientUpdateProhibited" Status Value, where if either of the Status Sets are assigned to the EPP object, the "clientUpdateProhibited" Status Value will be assigned. "clientUpdateProhibited" Status Value will be unassigned if both "Registrar Lock" Status Set and "Auth Token Lock" Status Sets are unassigned. A Status Set has the following attributes:

  • "name": The unique name for the Status Set that is up to server policy. The reserved name "REDACTED" can be used for a Server Status Set where the server cannot disclose the reason, such as the case for a sealed court order. Example names include "Registrar Lock", "Auth Token Lock", and "Registry Lock".
  • "type": The type of Status Set, which is either "client" for a Client Status Set or "server" for a Server Status Set. A Client Status Set MAY be set, unset, and overridden with authorization defined in the Authentication Token (Section 2.3) by the client. A Server Status Set MUST only be set and unset by the server and MUST NOT be overridden by the client.
  • "authTokenUsed": A boolean value indicating whether or not an Authentication Token (Section 2.3) is used with the Client Status Set. If "true", an Authentication Token (Section 2.3) is needed to authorize setting, unsetting, and overriding the Client Status Set; otherwise the Authentication Token (Section 2.3) does not need to be passed. This value MUST be set only when the "type" attribute is set to "client".
  • "inherited": A boolean value indicating whether or not the Status Set is inherited from the parent object (domain name) and is inherited by the child objects (hosts). The Status Values of the object only include Status Sets directly assigned and not inherited by the object. Inherited Status Values are enforced by the server but NOT persisted to the child object.
  • "assigned": A boolean value indicating whether or not the Status Set is directly assigned to the object. The <info> command supports returning "all" Status Sets for the client to see what Client Status Sets are available and directly assigned to the object. Only "assigned" Server Status Sets will be returned in the <info> response extension.
  • "crDate": Date and time that the Status Set was assigned to the EPP object.
  • "status": List of 0 or more Status Values (Section 2.1) mapped to the Status Set. A Status Set with zero Status Values is considered a Marker Status Set. Example Status Values include the lock statuses from [RFC5731] and [RFC5732] with "clientUpdateProhibited", "clientDeleteProhibited", "clientTransferProhibited", "serverUpdateProhibited", "serverDeleteProhibited", and "serverTransferProhibited".
  • "reason": Reason that the Status Set was assigned to the object. This is only needed when the "name" attribute alone doesn't clearly indicate the reason. An example is providing the more detailed reason "Botnet domain name" for the "Domain Abuse" Status Set.

A client can manage Client Status Values using Client Status Sets instead of setting individual Client Status Values, since the Status Set represents a container of Status Values that can overlap. The Status Set provides an explicit signal of the Status Value reasons that improves the status management when there are overlapping reasons. The support for the Authentication Token (Section 2.3) provides an additional layer of authorization with the ability to override Client Status Sets in Status Set transform commands.

2.3. Authentication Token

The Authentication Token, defined in section 2.1 of draft-gould-regext-epp-auth-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 the <statusSet:authToken> XML element. An Authentication Token is used to authorize provisioning and overriding a Client Status Set that has the <statusSet:authTokenUsed> element set to "1" or "true" in the Status Set Info Response (Section 3.1.2). The overriding capability MUST only apply to Client Status Sets.

Example Authentication Token XML element:

      <statusSet:authToken>
eyJhbGciOiJFUzUxMiIsInR5cCI6ImVhdCtqd3MiLCJraWQiOiJFQVRfS0VZMV9TWVN
URU0tUkVQIn0.eyJqdGkiOiJFQVRfMTIzNDVfU1lTVEVNLVJFUCIsInN1YiI6IkNsaW
VudFkiLCJleHAiOiIxNzc1NjgyMDAwIiwiZW50aXRsZW1lbnRzIjpbIlNFUlZJQ0UxL
VJPIiwiU0VSVklDRTItUlciLCJUTEQxLVJXIiwiVExEMi1SVyJdfQ.ADJWkWMnZUFLl
l2Jzxbw00919aC_qm_9UgeBKCY6MSAnVZtOmqVlE-Gfyut5dk7iU69VXKRi89RU3L4Y
MyVvykFvAJm-aqNpHkYaYUZ_a0aZeN2KcVTVUXzPEtnq7kldvJTpYhB1-JmbFuQ2B6Z
5PFZeR5k-ScmDEDdFl9nIFCLd5-mF
      </statusSet:authToken>

2.4. M-of-N

M-of-N applies to the use of Authentication Tokens (Section 2.3), where M defines the number of registrar users (Section 1.2) with a valid Authentication Token (Section 2.3) needed to authorize a Status Set action out of N registrar users (Section 1.2) that can generate an Authentication Token. The Status Set transform commands support providing a list of Authentication Tokens (Section 2.3), using the <statusSet:authToken> elements. The value of M is up to server policy and can be at the server-level that applies to all registrars or can apply at the registrar-level and configured on a per-registrar basis. The value of N is dynamic and is based on the number of registrar users (Section 1.2) that support the generation of Authentication Tokens (Section 2.3) in the server.

3. EPP Command Mapping

A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730].

3.1. EPP Query Commands

This document defines one EPP Query Command with <info> to retrieve the Status Set information for the object. This document does not define a mapping for the EPP <check> command or the <transfer> command.

3.1.1. EPP <check> Command

This extension does not add any elements to the EPP <check> command or <check> response.

3.1.2. EPP <info> Command

A new Status Set Info Command by extending the EPP <info> command to get information for an EPP object with the inclusion of the Status Set information, defined in Section 2.2, that is optionally authorized by applying the Authentication Tokens and their authorization groups, defined in Section 2.3.

In addition to the EPP command elements described in the EPP <info> command, the command MAY contain an <extension> element. The <extension> element MUST contain a child <statusSet:info> element with an OPTIONAL "sets" attribute that can be either "assigned" or "all", with "assigned" being the default value. The value "assigned" can be used to return the Status Sets directly assigned to or inherited by the EPP object, and "all" to return the Status Sets that are assigned to and available for the EPP object. The <statusSet:info> element contains the following child elements:

  • An OPTIONAL list of <statusSet:authToken> elements, defined in Section 2.3, that supports authorizing the data returned in the Status Set Info Response in support of M-of-N authorization, defined in Section 2.4. The authorization groups in the list of Authentication Tokens (Section 2.3) are intersected to determine the data that will be returned. If no <statusSet:authToken> elements are provided, the server will return the default data based on the EPP Registrar User (Section 1.2) authorization of the EPP session.

Example Domain Name Status Set Info Command that uses the default "assigned" form:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp
C:  xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <info>
C:      <domain:info
C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>domain.example</domain:name>
C:      </domain:info>
C:    </info>
C:   <extension>
C:      <statusSet:info
C:      xmlns:statusSet="urn:ietf:params:xml:ns:epp:statusSet-0.1"/>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

Example Domain Name Status Set Info Command that uses the "assigned" form with two authentication tokens to determine the data returned:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp
C:  xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <info>
C:      <domain:info
C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>domain.example</domain:name>
C:      </domain:info>
C:    </info>
C:    <extension>
C:      <statusSet:info
C:        xmlns:statusSet="urn:ietf:params:xml:ns:epp:statusSet-0.1"
C:        sets="assigned">
C:        <statusSet: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:        </statusSet:authToken>
C:        <statusSet:authToken>
C:eyJ0eXAiOiJKV1QiLA0KICabcJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJ
C:leHAiOjEzMDAabc4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp
C:0cnVlfQ.dBjftJeZ4CVP-mB92K27abcuhbUJU1p1r_wW1gFWFOEjXk
C:        </statusSet:authToken>
C:      </statusSet:info>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

Example Domain Name Status Set Info Command that uses the "all" form:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp
C:  xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <info>
C:      <domain:info
C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>domain.example</domain:name>
C:      </domain:info>
C:    </info>
C:    <extension>
C:      <statusSet:info
C:        xmlns:statusSet="urn:ietf:params:xml:ns:epp:statusSet-0.1"
C:        sets="all"/>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

If the query was successful, the server replies with a <statusSet:infData> element along with the regular EPP <resData>. The <statusSet:infData> contains the following child elements:

  • A <statusSet:name> element that includes the unique name for the Status Set that is up to server policy. Example names include "Registrar Lock", "Auth Token Lock", and "Registry Lock". There is a reserved value of "REDACTED" that is used for a Server Status Set, where the name must be redacted based on server policy.
  • A <statusSet:type> element that indicates whether the Status Set is a Client Status Set with a value of "client" or the Status Set is a Server Status Set with a value of "server".
  • An OPTIONAL <statusSet:authTokenUsed> element that is a boolean with a default value of "false" that indicates whether the Status Set uses the Authentication Token, defined in Section 2.3. If "1" or "true", an Authentication Token is needed to authorize the setting, unsetting, and overriding the Client Status Set; otherwise with a value of "0" or "false" the Authentication Token does not need to be passed. An OPTIONAL "num" attribute, with a default value of "1", indicates the M value in M-of-N, defined in Section 2.4.
  • An OPTIONAL <statusSet:inherited> element that is a boolean with a default value of "false" that indicates whether the Status Set is inherited from the parent object (domain name), in the case of the EPP Host object in [RFC5732], and is inherited by the child objects (hosts), in the case of the EPP Domain Name object in [RFC5731].
  • An OPTIONAL <statusSet:assigned> element that is a boolean with a default value of "true" that indicates whether the Status Set is assigned to the EPP object. A value of "false" indicates that the Status Set is available to be set, which only applies to Client Status Sets.
  • An OPTIONAL <statusSet:crDate> element that is the date and time that the Status Set was assigned to the object.
  • An OPTIONAL list of zero or more <statusSet:status> elements that includes the Status Values, defined in Section 2.1 mapped to the Status Set.
  • An OPTIONAL <statusSet:reason> element that indicates the freefrom text reason that Status Set was assigned to the object.

Example Domain Name Status Set Info Response that includes the assigned Client Status Sets ("Auth Token Lock" and "Registrar Lock") and the assigned Server Status Set ("Registry Lock"):

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <resData>
S:      <domain:infData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:        <domain:name>example.com</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:status s="clientUpdateProhibited">
S:       Auth Token Lock,Registrar Lock
S:        </domain:status>
S:        <domain:status s="clientDeleteProhibited">
S:        Auth Token Lock,Registrar Lock
S:        </domain:status>
S:        <domain:status s="clientTransferProhibited">
S:        Auth Token Lock,Registrar Lock
S:        </domain:status>
S:        <domain:status s="serverUpdateProhibited">
S:        Registry Lock
S:        </domain:status>
S:        <domain:status s="serverDeleteProhibited">
S:        Registry Lock
S:        </domain:status>
S:        <domain:status s="serverTransferProhibited">
S:        Registry Lock
S:        </domain:status>
S:        <domain:ns>
S:          <domain:hostObj>ns1.example.com</domain:hostObj>
S:          <domain:hostObj>ns1.example.net</domain:hostObj>
S:        </domain:ns>
S:        <domain:host>ns1.example.com</domain:host>
S:        <domain:host>ns2.example.com</domain:host>
S:        <domain:clID>ClientX</domain:clID>
S:        <domain:crID>ClientY</domain:crID>
S:        <domain:crDate>2000-04-03T22:00:00.0Z</domain:crDate>
S:        <domain:upID>ClientX</domain:upID>
S:        <domain:upDate>2026-05-03T09:10:00.0Z</domain:upDate>
S:        <domain:exDate>2027-04-03T22:00:00.0Z</domain:exDate>
S:        <domain:trDate>2022-04-08T09:00:00.0Z</domain:trDate>
S:        <domain:authInfo>
S:          <domain:pw>2fooBAR</domain:pw>
S:        </domain:authInfo>
S:      </domain:infData>
S:    </resData>
S:    <extension>
S:      <statusSet:infData
S:        xmlns:statusSet="urn:ietf:params:xml:ns:epp:statusSet-0.1">
S:        <statusSet:statusSet>
S:          <statusSet:name>Auth Token Lock</statusSet:name>
S:          <statusSet:type>client</statusSet:type>
S:          <statusSet:authTokenUsed>true</statusSet:authTokenUsed>
S:          <statusSet:inherited>true</statusSet:inherited>
S:          <statusSet:assigned>true</statusSet:assigned>
S:          <statusSet:crDate>2026-05-03T09:00:00.0Z
S:          </statusSet:crDate>
S:          <statusSet:status>clientUpdateProhibited
S:          </statusSet:status>
S:          <statusSet:status>clientDeleteProhibited
S:          </statusSet:status>
S:          <statusSet:status>clientTransferProhibited
S:          </statusSet:status>
S:        </statusSet:statusSet>
S:       <statusSet:statusSet>
S:          <statusSet:name>Registrar Lock</statusSet:name>
S:          <statusSet:type>client</statusSet:type>
S:          <statusSet:authTokenUsed>false</statusSet:authTokenUsed>
S:          <statusSet:inherited>false</statusSet:inherited>
S:          <statusSet:assigned>true</statusSet:assigned>
S:          <statusSet:crDate>2026-05-03T09:00:00.0Z
S:          </statusSet:crDate>
S:          <statusSet:status>clientUpdateProhibited
S:          </statusSet:status>
S:          <statusSet:status>clientDeleteProhibited
S:          </statusSet:status>
S:          <statusSet:status>clientTransferProhibited
S:          </statusSet:status>
S:        </statusSet:statusSet>
S:        <statusSet:statusSet>
S:          <statusSet:name>Registry Lock</statusSet:name>
S:          <statusSet:type>server</statusSet:type>
S:          <statusSet:authTokenUsed>false</statusSet:authTokenUsed>
S:          <statusSet:inherited>false</statusSet:inherited>
S:          <statusSet:assigned>true</statusSet:assigned>
S:          <statusSet:crDate>2026-05-03T09:10:00.0Z
S:          </statusSet:crDate>
S:          <statusSet:status>serverUpdateProhibited
S:          </statusSet:status>
S:          <statusSet:status>serverDeleteProhibited
S:          </statusSet:status>
S:          <statusSet:status>serverTransferProhibited
S:          </statusSet:status>
S:        </statusSet:statusSet>
S:      </statusSet:infData>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

Example Domain Name Status Set Info Response with the "all" form that includes the two assigned Client Status Sets ("Registrar Lock", "Auth Token Lock"), the two assigned Server Status Sets ("Registry Lock" and the reserved "REDACTED"), and the available Client Status Set ("Registrar Court Order Lock"):

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <resData>
S:      <domain:infData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:        <domain:name>example.com</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:status s="clientUpdateProhibited">
S:        Auth Token Lock,Registrar Lock
S:        </domain:status>
S:        <domain:status s="clientDeleteProhibited">
S:        Auth Token Lock,Registrar Lock
S:        </domain:status>
S:        <domain:status s="clientTransferProhibited">
S:        Auth Token Lock,Registrar Lock
S:        </domain:status>
S:        <domain:status s="serverUpdateProhibited">
S:        Registry Lock
S:        </domain:status>
S:        <domain:status s="serverDeleteProhibited">
S:        Registry Lock
S:        </domain:status>
S:        <domain:status s="serverTransferProhibited">
S:        Registry Lock
S:        </domain:status>
S:        <domain:status s="serverHold">
S:        REDACTED
S:        </domain:status>
S:        <domain:ns>
S:         <domain:hostObj>ns1.example.com</domain:hostObj>
S:          <domain:hostObj>ns1.example.net</domain:hostObj>
S:        </domain:ns>
S:        <domain:host>ns1.example.com</domain:host>
S:        <domain:host>ns2.example.com</domain:host>
S:        <domain:clID>ClientX</domain:clID>
S:        <domain:crID>ClientY</domain:crID>
S:        <domain:crDate>2000-04-03T22:00:00.0Z</domain:crDate>
S:        <domain:upID>ClientX</domain:upID>
S:        <domain:upDate>2026-05-03T09:10:00.0Z</domain:upDate>
S:        <domain:exDate>2027-04-03T22:00:00.0Z</domain:exDate>
S:        <domain:trDate>2022-04-08T09:00:00.0Z</domain:trDate>
S:        <domain:authInfo>
S:          <domain:pw>2fooBAR</domain:pw>
S:        </domain:authInfo>
S:      </domain:infData>
S:    </resData>
S:    <extension>
S:      <statusSet:infData
S:        xmlns:statusSet="urn:ietf:params:xml:ns:epp:statusSet-0.1">
S:        <statusSet:statusSet>
S:          <statusSet:name>Auth Token Lock</statusSet:name>
S:          <statusSet:type>client</statusSet:type>
S:          <statusSet:authTokenUsed>true</statusSet:authTokenUsed>
S:          <statusSet:inherited>true</statusSet:inherited>
S:          <statusSet:assigned>true</statusSet:assigned>
S:          <statusSet:crDate>2026-05-03T09:00:00.0Z<
S:            /statusSet:crDate>
S:          <statusSet:status>clientUpdateProhibited
S:          </statusSet:status>
S:          <statusSet:status>clientDeleteProhibited
S:          </statusSet:status>
S:          <statusSet:status>clientTransferProhibited
S:          </statusSet:status>
S:        </statusSet:statusSet>
S:       <statusSet:statusSet>
S:          <statusSet:name>Registrar Lock</statusSet:name>
S:          <statusSet:type>client</statusSet:type>
S:          <statusSet:authTokenUsed>false</statusSet:authTokenUsed>
S:          <statusSet:inherited>false</statusSet:inherited>
S:          <statusSet:assigned>true</statusSet:assigned>
S:          <statusSet:crDate>2026-05-03T09:00:00.0Z
S:          </statusSet:crDate>
S:          <statusSet:status>clientUpdateProhibited
S:          </statusSet:status>
S:          <statusSet:status>clientDeleteProhibited
S:          </statusSet:status>
S:          <statusSet:status>clientTransferProhibited
S:          </statusSet:status>
S:        </statusSet:statusSet>
S:        <statusSet:statusSet>
S:          <statusSet:name>Registry Lock</statusSet:name>
S:          <statusSet:type>server</statusSet:type>
S:          <statusSet:authTokenUsed>false</statusSet:authTokenUsed>
S:          <statusSet:inherited>false</statusSet:inherited>
S:          <statusSet:assigned>true</statusSet:assigned>
S:          <statusSet:crDate>2026-05-03T09:10:00.0Z
S:          </statusSet:crDate>
S:          <statusSet:status>serverUpdateProhibited
S:          </statusSet:status>
S:          <statusSet:status>serverDeleteProhibited
S:          </statusSet:status>
S:          <statusSet:status>serverTransferProhibited
S:          </statusSet:status>
S:        </statusSet:statusSet>
S:        <statusSet:statusSet>
S:          <statusSet:name>REDACTED</statusSet:name>
S:          <statusSet:type>server</statusSet:type>
S:          <statusSet:authTokenUsed>false</statusSet:authTokenUsed>
S:          <statusSet:inherited>false</statusSet:inherited>
S:          <statusSet:assigned>true</statusSet:assigned>
S:          <statusSet:crDate>2026-05-01T10:11:00.0Z
S:          </statusSet:crDate>
S:          <statusSet:status>serverHold</statusSet:status>
S:        </statusSet:statusSet>
S:       <statusSet:statusSet>
S:          <statusSet:name>Registrar Court Order Lock
S:          </statusSet:name>
S:          <statusSet:type>client</statusSet:type>
S:          <statusSet:authTokenUsed>false</statusSet:authTokenUsed>
S:          <statusSet:inherited>false</statusSet:inherited>
S:          <statusSet:assigned>false</statusSet:assigned>
S:          <statusSet:status>clientUpdateProhibited
S:          </statusSet:status>
S:          <statusSet:status>clientDeleteProhibited
S:          </statusSet:status>
S:          <statusSet:status>clientTransferProhibited
S:          </statusSet:status>
S:        </statusSet:statusSet>
S:      </statusSet:infData>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

Example Host Status Set Info Response that includes an the inherited Client Status Set ("Auth Token Lock") from the parent domain name:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <resData>
S:      <host:infData
S:       xmlns:host="urn:ietf:params:xml:ns:host-1.0">
S:        <host:name>ns1.example.com</host:name>
S:        <host:roid>NS1_EXAMPLE1-REP</host:roid>
S:        <host:status s="ok"/>
S:        <host:addr ip="v4">192.0.2.2</host:addr>
S:        <host:addr ip="v4">192.0.2.29</host:addr>
S:        <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
S:        <host:clID>ClientY</host:clID>
S:        <host:crID>ClientX</host:crID>
S:        <host:crDate>2000-04-03T22:00:00.0Z</host:crDate>
S:        <host:upID>ClientX</host:upID>
S:        <host:upDate>2026-05-03T09:00:00.0Z</host:upDate>
S:        <host:trDate>2022-04-08T09:00:00.0Z</host:trDate>
S:      </host:infData>
S:    </resData>
S:    <extension>
S:      <statusSet:infData
S:        xmlns:statusSet="urn:ietf:params:xml:ns:epp:statusSet-0.1">
S:        <statusSet:statusSet>
S:          <statusSet:name>Auth Token Lock</statusSet:name>
S:          <statusSet:type>client</statusSet:type>
S:          <statusSet:authTokenUsed>true</statusSet:authTokenUsed>
S:          <statusSet:inherited>true</statusSet:inherited>
S:          <statusSet:assigned>false</statusSet:assigned>
S:          <statusSet:crDate>2026-05-03T09:00:00.0Z
S:          </statusSet:crDate>
S:          <statusSet:status>clientUpdateProhibited
S:          </statusSet:status>
S:          <statusSet:status>clientDeleteProhibited
S:          </statusSet:status>
S:          <statusSet:status>clientTransferProhibited
S:          </statusSet:status>
S:        </statusSet:statusSet>
S:      </statusSet:infData>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

3.1.3. EPP <transfer> Command

This extension does not add any elements to the EPP <transfer> query command or <transfer> query response.

3.2. EPP Transform Commands

This document defines a new EPP Status Set Command for each of the EPP Transform Commands, defined in [RFC5730], to enable the provisioning of the Client Status Sets in the <create> and <update> commands and the overriding of the Client Status Sets with the passing of one or more Authentication Tokens in each of the EPP Status Set Transform Commands. An example is the definition of the EPP Domain Status Set Update Command in Section 3.2.5 extending the domain name <update> command in [RFC5731].

3.2.1. EPP <create> Command

A new Status Set Create Command by extending the EPP <create> command to create an EPP object, such as the domain name in [RFC5731] or a host in [RFC5732], with a list of Status Sets (Section 2.2) that will be assigned initially. In addition to the EPP command elements described in the EPP <create> command, the command MAY contain an <extension> element. The <extension> element MUST contain a child <statusSet:create> element that contains the following child elements:

  • An OPTIONAL list of <statusSet:authToken> elements, defined in Section 2.3, that supports authorizing the assigning of the Status Sets in support of M-of-N authorization, defined in Section 2.4.
  • One or more <statusSet:statusSet> elements that include the unique name of the Status Set, defined in Section 2.2.

Example Domain Name Status Set Create Command that sets the "Registrar Lock" Status Set:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <create>
C:      <domain:create
C:      xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:        <domain:period unit="y">2</domain:period>
C:        <domain:ns>
C:          <domain:hostObj>ns1.example.net</domain:hostObj>
C:          <domain:hostObj>ns2.example.net</domain:hostObj>
C:        </domain:ns>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:create>
C:    </create>
C:    <extension>
C:      <statusSet:create
C:        xmlns:statusSet="urn:ietf:params:xml:ns:epp:statusSet-0.1">
C:        <statusSet:statusSet>Registrar Lock</statusSet:statusSet>
C:      </statusSet:create>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

Example Domain Name Status Set Create Command that sets the "Registrar Lock" Status Set and the "Auth Token Lock", which includes 2 Authentication Tokens to meet an M value of 2, in M-of-N:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <create>
C:      <domain:create
C:      xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:        <domain:period unit="y">2</domain:period>
C:        <domain:ns>
C:          <domain:hostObj>ns1.example.net</domain:hostObj>
C:          <domain:hostObj>ns2.example.net</domain:hostObj>
C:        </domain:ns>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:create>
C:    </create>
C:    <extension>
C:      <statusSet:create
C:        xmlns:statusSet="urn:ietf:params:xml:ns:epp:statusSet-0.1">
C:        <statusSet: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:        </statusSet:authToken>
C:        <statusSet:authToken>
C:eyJ0eXAiOiJKV1QiLA0KICabcJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJ
C:leHAiOjEzMDAabc4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp
C:0cnVlfQ.dBjftJeZ4CVP-mB92K27abcuhbUJU1p1r_wW1gFWFOEjXk
C:        </statusSet:authToken>
C:        <statusSet:statusSet>Registrar Lock</statusSet:statusSet>
C:        <statusSet:statusSet>Auth Token Lock</statusSet:statusSet>
C:      </statusSet:create>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

This extension does not define any extension to the response of a <create> command. After processing the command, the server replies with a standard EPP response as defined in the EPP object mapping, such as defined in Section 3.2.1 of [RFC5731].

3.2.2. EPP <delete> Command

A new Status Set Delete Command by extending the EPP <delete> command to delete an EPP object that is authorized by applying the Authentication Tokens and their authorization groups, defined in Section 2.3, to override the assigned Client Status Sets that uses Authentication Tokens. In addition to the EPP command elements described in the EPP <delete> command, the command MAY contain an <extension> element. The <extension> element MUST contain a child <statusSet:delete> element that contains the following child elements:

  • One or more <statusSet:authToken> elements, defined in Section 2.3, that authorizes the overriding of the Client Status Sets in support of M-of-N authorization, defined in Section 2.4.

Example Domain Name Status Set Delete Command that includes a single Authentication Token (M = 1 with M-of-N authorization) to authorize the delete:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <delete>
C:      <domain:delete
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:      </domain:delete>
C:    </delete>
C:    <extension>
C:      <statusSet:delete
C:        xmlns:statusSet="urn:ietf:params:xml:ns:epp:statusSet-0.1">
C:        <statusSet: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:        </statusSet:authToken>
C:      </statusSet:delete>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

This extension does not define any extension to the response of an <delete> command. After processing the command, the server replies with a standard EPP response as defined in the EPP object mapping, such as defined in Section 3.2.2 of [RFC5731].

3.2.3. EPP <renew> Command

A new Status Set Renew Command by extending the EPP <renew> command to renew an EPP object that is authorized by applying the Authentication Tokens and their authorization groups, defined in Section 2.3, to override the assigned Client Status Sets that uses Authentication Tokens. In addition to the EPP command elements described in the EPP <renew> command, the command MAY contain an <extension> element. The <extension> element MUST contain a child <statusSet:renew> element that contains the following child elements:

  • One or more <statusSet:authToken> elements, defined in Section 2.3, that authorizes the overriding of the Client Status Sets in support of M-of-N authorization, defined in Section 2.4.

Example Domain Name Status Set Renew Command that includes a single Authentication Token (M = 1 with M-of-N authorization) to authorize the renew:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <renew>
C:      <domain:renew
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:        <domain:curExpDate>2026-04-03</domain:curExpDate>
C:        <domain:period unit="y">5</domain:period>
C:      </domain:renew>
C:    </renew>
C:    <extension>
C:      <statusSet:renew
C:        xmlns:statusSet="urn:ietf:params:xml:ns:epp:statusSet-0.1">
C:        <statusSet: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:        </statusSet:authToken>
C:     </statusSet:renew>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

This extension does not define any extension to the response of an <renew> command. After processing the command, the server replies with a standard EPP response as defined in the EPP object mapping, such as defined in Section 3.2.3 of [RFC5731].

3.2.4. EPP <transfer> Command

A new Status Set Transfer Command by extending the EPP <transfer> command to transfer an EPP object that is authorized by applying the Authentication Tokens and their authorization groups, defined in Section 2.3, to override the assigned Client Status Sets that uses Authentication Tokens. In addition to the EPP command elements described in the EPP <transfer> command, the command MAY contain an <extension> element. The <extension> element MUST contain a child <statusSet:transfer> element that contains the following child elements:

  • One or more <statusSet:authToken> elements, defined in Section 2.3, that authorizes the overriding of the Client Status Sets in support of M-of-N authorization, defined in Section 2.4.

Example Domain Name Status Set Transfer Command that includes a single Authentication Token (M = 1 with M-of-N authorization) to authorize the transfer:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <transfer op="request">
C:      <domain:transfer
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:        <domain:period unit="y">1</domain:period>
C:        <domain:authInfo>
C:          <domain:pw roid="JD1234-REP">2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:transfer>
C:    </transfer>
C:    <extension>
C:      <statusSet:transfer
C:        xmlns:statusSet="urn:ietf:params:xml:ns:epp:statusSet-0.1">
C:        <statusSet: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:        </statusSet:authToken>
C:      </statusSet:transfer>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

This extension does not define any extension to the response of an <transfer> command. After processing the command, the server replies with a standard EPP response as defined in the EPP object mapping, such as defined in Section 3.2.4 of [RFC5731].

3.2.5. EPP <update> Command

A new Status Set Update Command by extending the EPP <update> command to transfer an EPP object that is authorized by applying the Authentication Tokens and their authorization groups, defined in Section 2.3, to override the assigned Client Status Sets that uses Authentication Tokens. In addition to the EPP command elements described in the EPP <update> command, the command MAY contain an <extension> element. The <extension> element MUST contain a child <statusSet:update> element that contains the following child elements:

  • An OPTIONAL list of <statusSet:authToken> elements, defined in Section 2.3, that authorizes the overriding of the Client Status Sets in support of M-of-N authorization, defined in Section 2.4.
  • An OPTIONAL <statusSet:add> element that includes zero or more <statusSet:statusSet> elements that includes the unique name of the Status Set, defined in Section 2.2, to add to the EPP object.
  • An OPTIONAL <statusSet:rem> element that includes zero or more <statusSet:statusSet> elements that includes the unique name of the Status Set, defined in Section 2.2, to remove from the EPP object. The Status Set removes MUST be processed prior to the adds.

Example Domain Name Status Set Update Command that includes a single Authentication Token (M = 1 with M-of-N authorization) to authorize the update:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C:     epp-1.0.xsd">
C:  <command>
C:    <update>
C:      <domain:update
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name>example.com</domain:name>
C:        <domain:add>
C:          <domain:ns>
C:            <domain:hostObj>ns2.example.com</domain:hostObj>
C:          </domain:ns>
C:        </domain:add>
C:        <domain:rem>
C:          <domain:ns>
C:            <domain:hostObj>ns1.example.com</domain:hostObj>
C:          </domain:ns>
C:        </domain:rem>
C:      </domain:update>
C:    </update>
C:    <extension>
C:      <statusSet:update
C:        xmlns:statusSet="urn:ietf:params:xml:ns:epp:statusSet-0.1">
C:        <statusSet: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:        </statusSet:authToken>
C:      </statusSet:update>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

Example Domain Name Status Set Update Command that includes a two Authentication Tokens (M = 2 with M-of-N authorization) to authorize the update:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C:     epp-1.0.xsd">
C:  <command>
C:    <update>
C:      <domain:update
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name>example.com</domain:name>
C:        <domain:add>
C:          <domain:ns>
C:            <domain:hostObj>ns2.example.com</domain:hostObj>
C:          </domain:ns>
C:        </domain:add>
C:        <domain:rem>
C:          <domain:ns>
C:            <domain:hostObj>ns1.example.com</domain:hostObj>
C:          </domain:ns>
C:        </domain:rem>
C:      </domain:update>
C:    </update>
C:    <extension>
C:      <statusSet:update
C:        xmlns:statusSet="urn:ietf:params:xml:ns:epp:statusSet-0.1">
C:        <statusSet: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:        </statusSet:authToken>
C:        <statusSet:authToken>
C:eyJ0eXAiOiJKV1QiLA0KICabcJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJ
C:leHAiOjEzMDAabc4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp
C:0cnVlfQ.dBjftJeZ4CVP-mB92K27abcuhbUJU1p1r_wW1gFWFOEjXk
C:        </statusSet:authToken>
C:       </statusSet:update>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

Example Domain Name Status Set Update Command that includes a single Authentication Token (M = 1 with M-of-N authorization) to authorize removing the "Auth Token Lock" Status Set and adding the "Auth Token Lock - Transfer Allowed" Status Set, which removes the "clientTransferProhibited" Status Value from the domain name and keeps the "clientUpdateProhibited" and "clientDeleteProhibited" Status Values:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C:     epp-1.0.xsd">
C:  <command>
C:    <update>
C:     <domain:update
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name>example.com</domain:name>
C:       <domain:chg/>
C:      </domain:update>
C:    </update>
C:    <extension>
C:      <statusSet:update
C:        xmlns:statusSet="urn:ietf:params:xml:ns:epp:statusSet-0.1">
C:        <statusSet: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:        </statusSet:authToken>
C:        <statusSet:add>
C:          <statusSet:statusSet>Auth Token Lock - Transfer Allowed
C:          </statusSet:statusSet>
C:        </statusSet:add>
C:        <statusSet:rem>
C:          <statusSet:statusSet>Auth Token Lock
C:          </statusSet:statusSet>
C:        </statusSet:rem>
C:      </statusSet:update>
C:    </extension>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

This extension does not define any extension to the response of an <update> command. After processing the command, the server replies with a standard EPP response as defined in the EPP object mapping, such as defined in Section 3.2.4 of [RFC5731].

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:epp:statusSet-0.1"
  xmlns:statusSet=
    "urn:ietf:params:xml:ns:epp:statusSet-0.1"
  xmlns="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified">

  <annotation>
    <documentation>
      Extensible Provisioning Protocol v1.0
      Status Set Extension.
    </documentation>
  </annotation>

  <!-- status set info command element -->
  <element name="info" type="statusSet:infoType"/>

  <complexType name="infoType">
    <simpleContent>
      <extension base="statusSet:authTokenListType">
        <attribute name="sets"
        type="statusSet:setsEnum" default="assigned"/>
      </extension>
    </simpleContent>
  </complexType>

  <simpleType name="setsEnum">
    <restriction base="token">
      <enumeration value="assigned"/>
      <enumeration value="all"/>
    </restriction>
  </simpleType>


  <!-- status set info response element -->
  <element name="infData" type="statusSet:infDataType"/>

  <complexType name="infDataType">
    <sequence>
      <element name="statusSet"
        type="statusSet:statusSetDataType"
        minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <complexType name="statusSetDataType">
    <sequence>
      <element name="name" type="token"/>
      <element name="type" type="statusSet:statusSetTypeEnum"/>
      <element name="authTokenUsed"
        type="statusSet:authTokenUsedType"
        minOccurs="0" default="false"/>
      <element name="inherited" type="boolean"
        minOccurs="0" default="false"/>
      <element name="assigned" type="boolean"
        minOccurs="0" default="true"/>
      <element name="crDate" type="dateTime"
        minOccurs="0"/>
      <element name="status" type="token"
        minOccurs="0" maxOccurs="unbounded"/>
      <element name="reason" type="token"
        minOccurs="0"/>
    </sequence>
  </complexType>

  <complexType name="authTokenUsedType">
    <simpleContent>
      <extension base="boolean">
        <attribute name="num"
        type="int" default="1"/>
      </extension>
    </simpleContent>
  </complexType>

  <simpleType name="statusSetTypeEnum">
    <restriction base="token">
      <enumeration value="client"/>
      <enumeration value="server"/>
    </restriction>
  </simpleType>

  <!-- authentication token -->
  <simpleType name="authTokenType">
    <restriction base="token">
    <pattern value="[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+"/>
    </restriction>
  </simpleType>

 <complexType name="authTokenListType">
    <sequence>
      <element name="authToken" type="statusSet:authTokenType"
      minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
  </complexType>


  <!-- status set create command element -->
  <element name="create" type="statusSet:createType"/>

  <complexType name="createType">
    <sequence>
      <element name="authToken" type="statusSet:authTokenType"
      minOccurs="0" maxOccurs="unbounded"/>
      <element name="statusSet" type="token"
      minOccurs="1" maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <!-- status set delete command element -->
  <element name="delete" type="statusSet:authTokenListType"/>

  <!-- status set renew command element -->
  <element name="renew" type="statusSet:authTokenListType"/>

  <!-- status set transfer command element -->
  <element name="transfer" type="statusSet:authTokenListType"/>

  <!-- status set update command element -->
  <element name="update" type="statusSet:updateType"/>

  <complexType name="updateType">
    <sequence>
      <element name="authToken" type="statusSet:authTokenType"
       minOccurs="0" maxOccurs="unbounded"/>
      <element name="add" type="statusSet:addRemType"
       minOccurs="0"/>
      <element name="rem" type="statusSet:addRemType"
       minOccurs="0"/>
    </sequence>
  </complexType>

  <complexType name="addRemType">
    <sequence>
      <element name="statusSet" type="token"
       minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
  </complexType>

</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 Status Set Extension Mapping namespace:

URI:
urn:ietf:params:xml:ns:epp:statusSet-0.1
Registrant Contact:
Registrant Contact: IESG
XML:
None. Namespace URIs do not represent an XML specification.

Registration request for the Status Set Extension Mapping XML Schema:

URI:
urn:ietf:params:xml:schema:epp:statusSet-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 are as follows:

Name of Extension:
"Status Set Extension Mapping for the Extensible Provisioning Protocol"
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

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 using an Authentication Token, in draft-gould-regext-epp-auth-token, that is passed on top of EPP for registrar users to perform more fine grained authorization in the form of overriding a Client Status Set.

The security considerations for the server include:

  1. The Server Status Sets and the associated Server Status Values can only be managed by the server. The server MUST NOT allow the client to set, unset, or override a Server Status Set.
  2. The authorization model for a server operation is driven by the mapping of the Status Values to the asasigned Status Sets. The server applies the Authentication Token, in draft-gould-regext-epp-auth-token, by matching the operation, the entitlements in the Authentication Token, and the assigned Client Status Sets to determine which Client Status Sets are overriden to authorize the execution of the operation.
  3. Applying the inherited Client Staus Sets to the child objects (child host for parent domain name) MAY be enforced by the server business logic without having to directly change the child objects. There can be an unlimited number of child objects, so there is a resource consumption issue associated with cascading inherited Status Sets directly to the child objects.
  4. Implementing the M-of-N authorization performs a intersection of the "entitlements" in the Authentication Tokens, in draft-gould-regext-epp-auth-token, when authorizing a Status Set Command.

The security considerations for the client include:

  1. There are no additional client security considerations other than what's defined for the Authentication Token in draft-gould-regext-epp-auth-token.

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>.
[RFC3915]
Hollenbeck, S., "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)", RFC 3915, DOI 10.17487/RFC3915, , <https://www.rfc-editor.org/info/rfc3915>.
[RFC5730]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, , <https://www.rfc-editor.org/info/rfc5730>.
[RFC5731]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, , <https://www.rfc-editor.org/info/rfc5731>.
[RFC5732]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, , <https://www.rfc-editor.org/info/rfc5732>.
[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>.
[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
Poonam Garg
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America
Mohammad Suhale Malang Khader
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America