Extensible Provisioning Protocol (EPP) Authentication Token Mapping

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) , 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 , to provide granular, time-bound authorization till the lifetime of the digitally signed Authentication Token. This document describes a EPP Authentication Token object mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) . This mapping is specified using the XML 1.0 as described in and XML Schema notation as described in and .

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

Registrar User 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 , referred to as the EPP Registrar User is this document, is a registrar system that uses the EPP Registrar User credentials to authenticate with the <login> command to establish an EPP session. The Registrar User authenticates to create the Authentication Token that MUST be a Registrar User other than the EPP Registrar User since the EPP Registrar User is used only to create the EPP session.

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.

Authentication Token The Authentication Token uses JSON Web Signature (JWS), defined in , with JWS Compact Serialization, defined in Section 3.1 of , 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 ('.'):

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 . 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 , 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 ; the initial contents of this registry are the values defined in Section 3.1 of . 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 , identifies the media type of the complete JWS that uses the EPP Authentication Token specific value "eat+jws", which is registered in .
"kid": The "kid" (KEY ID) Header Parameter, defined in Section 4.1.4 of , 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 , assigned to the key pair.

Example Authentication Token Header using the "ES512" digital signature algorithm and the "kid" of "EAT_KEY1_SYSTEM-REP":

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 . The following JWT Claims are used in the Authentication Token Payload:

"jti": The "jti" (JWT ID) Claim, defined in Section 4.1.7 of , identifies the globally unique Repository Object IDentifier (ROID), defined in Section 2.8 of , for the Authentication Token. An example is "EAT_12345_SYSTEM-REP".
"sub": The "sub" (Subject) Claim, defined in Section 4.1.2 of , 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 , identifies the expiration time in epoch time on or after which the Authentication Token MUST NOT be used. An example is "1775682000".
"entitlements": The "entitlements" (Entitlements) Claim, defined in Section 4.1.2 of , 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:

Authentication Token Signature The Authentication Token Signature is a JWS Signature, as defined in Section 7.2.1 of . A list of defined "alg" values for this use can be found in the IANA "JSON Web Signature and Encryption Algorithms" registry established by ; the initial contents of this registry are the values defined in Section 3.1 of . 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.

Authentication Token Poll Message The EPP <poll> command and response are defined in section 2.9.2.3 of . For servers that support an Authentication Token object, the Authentication Token Info Response, as defined in Section 3.1.2, is inserted into the poll queue based on server policy, such as when an Authentication token is revoked by the server. Example <poll> command: C: C: C: C: 51364-CLI C: C: ]]> Example <poll> response: S: S: S: S: S: Command completed successfully; ack to dequeue S: S: S: 2026-04-08T09:00:00.0Z S: Revoked authentication token S: S: S: S: 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: S: revoked S: 2026-04-08T09:00:00.0Z S: S: ClientZ S: security issue S: S: S: S: S: 51364-CLI S: 54321-XYZ S: S: S: ]]>

EPP Command Mapping A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification . The command mappings described here are specifically for use in provisioning and managing Authentication Token information via EPP.

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.

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 , for the server to validate.

Example <check> command: C: C: C: C: C: 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: C: C:eyJ0eXAiOiJKV1QiLA0KICabcJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJ C:leHAiOjEzMDAabc4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp C:0cnVlfQ.dBjftJeZ4CVP-mB92K27abcuhbUJU1p1r_wW1gFWFOEjXk C: C: C:eyJ0eXAiOiJasdABBKJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJABCDMDA4MTkzODAsDQo C:gImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92KA C:BCDW1gFWFOEjXk C: C: C: C: 51364-CLI C: C: ]]> 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 , and MUST contain a "valid" attribute value that indicates whether the Authentication Token is valid. A value "1" or "true" means that the Authentication Token is valid. A value of "0" or "false" means that the Authentication Token is not valid. An Authentication Token is valid if its correctly signed by a trusted key, follows the format of the "eat+jws" media type, has not expired, and has not been revoked by the client or the server.
An OPTIONAL <authToken:reason> when the Authentication Token is not valid, such as "expired token" or "revoked token". This text MUST be represented in the response language previously negotiated with the client; an OPTIONAL "lang" attribute MAY be present to identify the language if the negotiated value is something other than the default value of "en" (English). This element MUST be returned when the Authentication Token is not valid.

Example <check> response: S: S: S: S: Command completed successfully S: S: S: S: S: S: S:eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleH S:AiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlf S:Q.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk S: S: S: S: S:eyJ0eXAiOiJKV1QiLA0KICabcJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJ S:leHAiOjEzMDAabc4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp S:0cnVlfQ.dBjftJeZ4CVP-mB92K27abcuhbUJU1p1r_wW1gFWFOEjXk S: S: expired token S: S: S: S:eyJ0eXAiOiJasdABBKJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJABCDMDA4MTkzODAsDQo S:gImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92KA S:BCDW1gFWFOEjXk S: S: revoked token S: S: S: S: S: 51364-CLI S: 54321-XYZ S: S: S: ]]> An EPP error response MUST be returned if a <check> command cannot be processed for any reason.

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 , to get information for.

Example <info> command: C: C: C: C: C: 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: C: C: C: 51364-CLI C: C: ]]> 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 .
A <authToken:status> element that contains the Authentication Token status with the following enumerated values:
- "active": Authentication Token is valid, has not expired, and has not been revoked.
- "expired": Authentication Token is not valid, since it has expired.
- "revoked": Authentication Token is not valid, since it has been revoked.
An OPTIONAL <authToken:crDate> element that contains the date and time of Authentication Token creation.
An OPTIONAL <authToken:exDate> element that contains the date and time when the Authentication token expires and MUST NOT be used.
An OPTIONAL <authToken:revokedDate> element that contains the date and time the Authentication Token was revoked. This element MUST be returned when the <authToken:status> element has the value of "revoked".
An OPTIONAL <authToken:revokedID> element that contains the identifier of the client that revoked the Authentication Token object. This element MUST be returned when the <authToken:status> element has the value of "revoked".
An OPTIONAL <authToken:revokedReason> element that contains a freeform reason for the Authentication Token revocation. This text MUST be represented in the response language previously negotiated with the client; an OPTIONAL "lang" attribute MAY be present to identify the language if the negotiated value is something other than the default value of "en" (English). This element MUST be returned when the <authToken:status> element has the value of "revoked".

Example <info> response for an active Authentication Token: S: S: S: S: Command completed successfully S: S: S: S: S: 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: S: active S: 2026-04-08T09:00:00.0Z S: 2026-04-08T10:00:00.0Z S: S: S: S: 51364-CLI S: 54321-XYZ S: S: S: ]]> Example <info> response for an expired Authentication Token: S: S: S: S: Command completed successfully S: S: S: S: S: 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: S: expired S: 2026-04-08T06:00:00.0Z S: 2026-04-08T07:00:00.0Z S: S: S: S: 51364-CLI S: 54321-XYZ S: S: S: ]]> Example <info> response for a revoked Authentication Token: S: S: S: S: Command completed successfully S: S: S: S: S: S:eyJhbGciOiJFUzUxMiIsInR5cCI6ImVhdCtqd3MiLCJraWQiOiJFQVRfS0VZMV9TWVN S:URU0tUkVQIn0.eyJqdGkiOiJFQVRfMTIzNDVfU1lTVEVNLVJFUCIsInN1YiI6IkNsaW S:udFkiLCJleHAiOiIxNzc1NjgyMDAwIiwiZW50aXRsZW1lbnRzIjpbIlNFUlZJQ0UxL S:JPIiwiU0VSVklDRTItUlciLCJUTEQxLVJXIiwiVExEMi1SVyJdfQ.ADJWkWMnZUFLl l2Jzxbw00919aC_qm_9UgeBKCY6MSAnVZtOmqVlE-Gfyut5dk7iU69VXKRi89RU3L4Y S:MyVvykFvAJm-aqNpHkYaYUZ_a0aZeN2KcVTVUXzPEtnq7kldvJTpYhB1-JmbFuQ2B6Z S:5PFZeR5k-ScmDEDdFl9nIFCLd5-mF S: S: revoked S: 2026-04-08T08:30:00.0Z S: S: 2026-04-08T09:00:00.0Z S: S: ClientZ S: security issue S: S: S: S: S: 51364-CLI S: 54321-XYZ S: S: S: ]]> 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.

EPP <transfer> Query Command The transfer semantics do not apply to Authentication Token objects. No EPP <transfer> query command is defined in this document.

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.

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 value and a required "type" attribute, representing the type of the bearer token. The <authToken:credentials> element includes the following child elements:
- A <authToken:clID> element that contains the registrar user identifier for the authenticating user.
- A <authToken:pw> element that contains the registrar user password for the authenticating user, which must be at least 6 characters long.
- A <authToken:mfa> element that contains the Multi-Factor Authentication (MFA) value, which represents what the registrar user "has" versus what the user "knows" with the <authToken:clID> and <authToken:pw> elements. The type of the MFA credential is defined with the "type" attribute, with the default value of "totp". The following are the predefined MFA types:
  - "totp" is a time-based one-time password (TOTP), defined in . "totp" is the default "type" attribute value.
  - "key" is a shared key that is Base64 encoded .
  - "biometric" is data that is Base64 encoded , where the biometric data accepted by the server is up to server policy.
  - "device" is a device-level key as represented by a hardware or software token that is Base64 encoded .
  - "push" is a push to the registrar user's device application. The user device application needs to be configured in the server.
  - "custom" is a custom MFA type defined by the "custom" attribute. The supported set of custom MFA types is up to server policy.

Example <create> command with MFA credential: C: C: C: C: C: C: example1 C: example2 C: C: C: ClientY C: foo-BAR2 C: 123456 C: C: C: C: C: 51364-CLI C: C: ]]> Example <create> command with Bearer Token: C: C: C: C: C: C: example1 C: example2 C: C: C: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... C: C: C: C: 51364-CLI C: C: ]]> 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 : Example <create> response: S: S: S: S: Command completed successfully S: S: S: S: S: 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: S: S: S: S: 51364-CLI S: 54321-XYZ S: S: S: ]]> An EPP error response MUST be returned if a <create> command cannot be processed for any reason.

EPP <update> Command Update semantics do not apply to Authentication Token objects, so there is no mapping defined for the EPP <update> command.

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 , 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: C: C: C: C: 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: C: C: C: 51364-CLI C: C: ]]> Example <delete> command with a reason: C: C: C: C: C: 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: C: User inactivity C: C: C: C: 51364-CLI C: C: ]]> When a <delete> command has been processed successfully, the server MUST respond with an EPP response with no <resData> element. Example <delete> response: S: S: S: S: Command completed successfully S: S: 51364-CLI S: SRV-43659 S: S: S: ]]> An EPP error response MUST be returned if a <delete> command cannot be processed for any reason.

EPP <renew> Command Renewal semantics do not apply to Authentication Token objects, so there is no mapping defined for the EPP <renew> command.

EPP <transfer> Command Transfer semantics do not apply to Authentication Token objects, so there is no mapping defined for the EPP <transfer> command.

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. Extensible Provisioning Protocol v1.0 shared structures schema. END]]>

IANA Considerations

XML Namespace This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in . 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.

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

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

The mapping extensions described in this document extends the security services described by EPP and protocol layers used by EPP by creating an authentication token that can be passed on top of EPP for registrar users to perform more fine grained authorization by other EPP extensions. The security considerations for the server include:

The granularity of the "entitlements" (Entitlements) Claim in the authentication token 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.
Setting the "exp" (Expiration Time) Claim in the authentication token 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.
The authentication token 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, so the security risk is higher.
A revocation policy SHOULD be defined, where if a registrar is compromized, all active authentication tokens for the registrar SHOULD be revoked with a notification to the registrar, as defined in .
Selection of an "alg" (Algorithm) in the authentication token 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 signature by the client and additional server-side components.

The security considerations for the client include:

The authentication token MUST be securely stored and transferred over an encrypted channel, such as defined in the EPP over TCP Transport.
M-of-N authorization can be chosen or required, where M defines the number of registrar users with a valid authentication token of N registrar users needed to authorize an operation. The client would need to coordinate creating and access to more than one authentication token to perform an operation, so the client needs to consider how many registrar users can generate authentication tokens and be capable of sharing the authentication tokens. The sharing of authentication tokens across many users and operations raises the level of exposure of the authentication token that reduces the security. The client needs to consider the tradeoffs of M-of-N authorization with the risk of sharing authentication tokens across many registrar users.
The client MAY have access to the authentication token public key to pre-verify it prior to using it. An additional option is to use the check command to have the server perform the validation. All known invalid authentication tokens SHOULD be removed by the client storage.