Applicant Information

Does or will this RSP have a publicly verifiable, third-party certification (e.g. ISO 27001) held directly by the organization and relevant to the registry services under application?

Yes

Does or will this RSP have processes and controls to manage physical access to infrastructure and systems, including building access controls, security cameras and/or other sensors, physical environmental monitoring and safety equipment, and alarm systems related to the physical infrastructure?

Yes

Does or will this RSP have processes and controls to manage non-physical access to infrastructure, including network access from both internal systems and external Internet systems, intrusion detection systems, security information and event management systems, network firewalls, network segmentation and isolation, user identification and authentication, and authorization schemes?

Yes

Does or will this RSP have processes and controls pertaining to the selection of vendors and equipment suppliers, management and maintenance of assets while in use, procurement of assets, and safe disposal of assets?

Yes

Does or will this RSP routinely renew and keep safe all cryptographic material necessary for the operation of the RSP?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) at-rest data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

Does or will this RSP secure (e.g. encryption, tamper detection, etc…) in-transit data relevant to the operation of the RSP, including but not limited to DNSSEC if applicable?

Yes

If applicable, does or will this RSP have security controls for data in virtualized environments, including controls relevant to both on-premises or private virtualization environments as well as public clouds, network isolation, memory isolation, process isolation, and hypervisor access controls?

Yes

Does or will this RSP have a senior executive primarily in charge of and responsible for security?

Yes

Does or will this RSP conduct background checks, both initial and on-going, of personnel and vendors relevant to the registry services under application?

Yes

Does or will this RSP implement BCP 38?

Yes

Does or will this RSP implement routing security of some nature, such as automated route filters, RPKI route origin validation, or other operational practices defined by the Internet Society and Global Cyber Alliance's Mutually Agreed Norms for Routing Security (MANRS)?

Yes

Describe the processes and procedures to be used to practice and ensure a successful KSK rollover for both emergency and non-emergency situations, including coordination with the DNSSEC RSP and IANA.

Online KSK Rollovers For Online Key Signing Keys (KSKs), Identity Digital follows the “double DS” rollover method, as described in RFC 5011. The procedure is as follows: - A new KSK is generated. - The new KSK is added to the apex DNSKEY RRSet and signed using the current KSK. - A hold-down period of 2x the DNSKEY TTL is performed. - The new DS record is added to the parent zone (via IANA RZM request). - A hold-down period of 2x the DS TTL is performed. - The DNSKEY RRSet is signed using the new KSK. - A hold-down period of 2x the DNSKEY TTL is performed. - The old DS record is removed from the parent zone (via IANA RZM request). - The old DNSKEY record is removed from the apex DNSKEY RRSet. Offline KSK Rollovers For offline KSK Rollovers, Identity Digital, as the DNSSEC-RSP, generates the necessary Key Signing Request / Signed Key Response operations to facilitate the KSK rollover: - KSK owner informs Identity Digital of desired KSK rollover. - KSK owner generates a new KSK. - Identity Digital generates a KSR that will span the timeframe of the KSK rollover and validates the KSR. - Identity Digital encrypts the KSR and sends it to the KSK owner. - KSK owner generates the SKR based on the KSR. - KSK owner encrypts the SKR and sends it to Identity Digital. - Identity Digital validates the SKR and loads it into the DNSSEC Signing Subsystem. - KSK owner then proceeds with their rollover, sending IANA the new DS when appropriate. External DNSSEC-RSP KSK Rollovers Identity Digital performs DNSSEC operations after the registry has prepared an unsigned zone. As such, for a DNSSEC-RSP outside of the organization, the unsigned zone will be transferred out to the DNSSEC-RSP. It is the responsibility of the DNSSEC-RSP to then correctly perform the KSK rollover according to their preferred methodology. The signed zone is then transferred from the DNSSEC-RSP to the DNS-RSP for publication and resolution. The flow of the DNSSEC data is depicted in ID_MAIN.1.16_DNSSEC-Data-Flow_1of1. Emergency KSK Rollovers There are two distinct emergency scenarios that could involve a KSK rollover: The compromise of a key using external methods, or the compromise of one or more Hardware Security Modules (HSMs). In these scenarios, the highest priority is to keep the zone resolving. This requires taking steps to ensure that the correct DS or DNSKEY data is present and the DNSSEC signature can always be validated. The most prudent way to accomplish this is to remove the current DNSSEC signature, and then quickly perform a KSK installation. This allows new queries for the DS record to immediately show the change in the zone, decreasing the possibility of the zone not resolving if caches do not purge the DS or DNSKEY data quickly enough. This would be executed as follows: - Identity Digital informs IANA as the parent zone operator of an emergency KSK rollover, and requests that the DS record for the compromised key be removed immediately. - A new KSK is generated. - The new KSK replaces the old KSK in the apex DNSKEY RRSet, and is signed using the current KSK with a TTL of 120. - A hold-down period of 2x the DNSKEY TTL is performed. - The new DS record is added to the parent zone (via IANA RZM request). - A hold-down period of 2x the DS TTL is performed. - The DNSKEY RRSet is signed using the new KSK. - A hold-down period of 2x the DNSKEY TTL is performed. For the first emergency scenario, Identity Digital would follow the steps above. For the second emergency scenario, if there is potential that all keys on the HSM have been compromised, the above steps would be repeated, but across all affected zones.

Does or will this RSP have documented, regular, and active practices for the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented, regular, and active practices for the secure development of software?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the maintenance, upgrading, and patching of software relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the lifecycle of hardware relevant to the registry services under application?

Yes

Does or will this RSP have documented contingency plans for extraordinary scenarios regarding the development of software?

Yes

Does or will this RSP use Infrastructure-as-Code (IaC) to manage all systems relevant to operation of the registry services under application?

Yes

Does or will this RSP use automated orchestration to manage all systems relevant to the operation of the registry services under application?

Yes

Does or will this RSP have at least two Tier III (as defined here: https://uptimeinstitute.com/tiers) or equivalent data centers having no inter-dependencies?

Yes

Does or will this RSP have on-site backups of registration data?

Yes

Does or will this RSP have off-site backups of registration data?

Yes

Does or will this RSP practice data retention policies with regard to backups of registration data?

Yes

Does or will this RSP practice documented standards regarding media and data backups for registration data?

Yes

Does or will this RSP practice regularly scheduled validation of registration data backups, separately from recovery practices?

Yes

Does or will this RSP practice regularly scheduled recovery of registration data backups?

Yes

Does or will this RSP forbid the use of production data in testing and/or development environments?

Yes

Does or will this RSP encrypt registration data at-rest in the data store?

Yes

Does or will this RSP encrypt registration data in-transit to and from the data store?

Yes

Does or will this RSP regularly and frequently renew the cryptographic material used for the encryption of registration data both at-rest and in-transit with regard to the data store in accordance with industry best common practices?

Yes

Does or will this RSP keep safe the cryptographic material used for the encryption of registration data both at-rest and in-transit with regard to the data store in accordance with industry best common practices?

Yes

Does or will this RSP use modern and known-secure cryptographic algorithms for the encryption of registration data at-rest and in-transit with regard to the data store?

Yes

Does or will this RSP implement RFC 5730 (“Extensible Provisioning Protocol (EPP)”)?

Yes

Does or will this RSP implement RFC 5731 (“Extensible Provisioning Protocol (EPP) Domain Name Mapping”)?

Yes

Does or will this RSP implement RFC 5734 (“Extensible Provisioning Protocol (EPP) Transport over TCP”)?

Yes

Does or will this RSP implement RFC 5910 (“Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)”)?

Yes

If applicable, does or will this RSP implement RFC 5732 (“Extensible Provisioning Protocol (EPP) Host Mapping”)?

Yes

If applicable, does or will this RSP implement RFC 5733 (“Extensible Provisioning Protocol (EPP) Contact Mapping”)?

Yes

Does or will this RSP implement RFC 8334 (“Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)”)?

Yes

If applicable, does or will this RSP implement RFC 8748 (“Registry Fee Extension for the Extensible Provisioning Protocol (EPP)”)?

No - Identity Digital is not planning to implement support for RFC 8748, “Registry Fee Extension for the Extensible Provisioning Protocol (EPP)" as part of our Registry Service. However, we will support a proprietary EPP extension with similar functionality, "Domain Charge Extension for the Extensible Provisioning Protocol (EPP)." This extension has been in use by ICANN-accredited registrars since 2013, and is registered with the IANA per RFC 7451. Identity Digital's charge extension supports the return of domain pricing for standard and premium domain names as well as other domain name-based charges such as token activation fees for allocation of restricted domains, and early access program.

Does or will this RSP forbid access to contacts via EPP to registrars other than the sponsoring registrar?

Yes

Provide a list of all EPP extensions to be used that are registered in the IANA EPP extensions registry, and an attestation that all EPP extensions to be used are registered with the IANA as per RFC 7451 (“Extension Registry for the Extensible Provisioning Protocol”).

Identity Digital’s EPP service supports the following features that have associated EPP extensions. Identity Digital attests that all EPP extensions that it supports are registered with the IANA as per RFC 7451: - Internationalized Domain Name Mapping: Allows association of a language/script tag with the IDN EPP domain create command. - Domain Charge Extension: Supports the return of domain pricing for standard and premium domain names as well as other domain name-based charges such as token activation fees for allocation of restricted domains, and early access program. - Finance Mapping: Enables registrars to retrieve the balance and threshold information associated with their registry account. - Allocation Token Extension (RFC 8495): Authorizes a registrar to allocate a restricted domain that would otherwise not be available for registration using the EPP domain create command. - Launch Phase Mapping (RFC 8334): Enables the provisioning and management of domain name registrations and applications during the launch of a TLD (e.g., sunrise, landrush). - Change Poll Extension (RFC 8590): Supports the ability to notify registrars of operations on domain names that were not initiated by the sponsoring registrar. In addition to the above EPP extensions, Identity Digital’s EPP service supports the following ICANN required standard RFC EPP extensions: - Domain Registry Grace Period Mapping (RFC 3915) - Domain Name System (DNS) Security Extensions (RFC 5910)

Does or will this RSP forgo the use of any EPP extensions which are not registered with the IANA as per RFC 7451 (“Extension Registry for the Extensible Provisioning Protocol”)?

Yes

Does or will this RSP implement and operate EPP according to the performance requirements defined in the standards established in Specification 10 of the ICANN Registry Agreement (version 2024)?

Yes

Does or will this RSP have controls to prevent EPP misuse and ensure all registrars have fair and equal access to EPP per the standards established in Specification 9 of the ICANN Registry Agreement (version 2024)?

Yes

Does or will this RSP implement RFC 9325 (“Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”) notwithstanding RFC 5734 (“Extensible Provisioning Protocol (EPP) Transport over TCP”)? Note: while RFC 9325 covers TLS and DTLS, EPP only uses TLS.

Yes

Does or will this RSP regularly and frequently renew the cryptographic material used to secure EPP communications in accordance with industry best common practices?

Yes

Does or will this RSP keep safe the cryptographic material used to secure EPP communication in accordance with industry best common practices?

Yes

Does or will this RSP meet the standards established in Specification 3 of the ICANN Registry Agreement (version 2024) with respect to EPP?

Yes

Does or will this RSP compartmentalize (e.g. virtualization) the EPP service in such a manner that each compartment (e.g. containers, virtual machines, physical machines) is dedicated to EPP (excluding system services such as monitoring, remote access and NTP)?

Yes

Does or will this RSP implement RFC 7480 (“HTTP Usage in the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP implement RFC 7481 (“Security Services for the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP implement RFC 8521 (“Registration Data Access Protocol (RDAP) Object Tagging”) for all currently operated gTLDs?

Yes

Does this RSP plan to continue to implement RFC 8521 (“Registration Data Access Protocol (RDAP) Object Tagging”) for all gTLDs operated in the future?

Yes

Does or will this RSP implement RFC 9082 (“Registration Data Access Protocol (RDAP) Query Format”)?

Yes

Does or will this RSP implement RFC 9083 (“JSON Responses for the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP implement RFC 9224 (“Finding the Authoritative Registration Data Access Protocol (RDAP) Service”) for all currently operated gTLDs?

Yes

Will this RSP implement RFC 9224 (“Finding the Authoritative Registration Data Access Protocol (RDAP) Service”) for all gTLDs operated in the future?

Yes

Does or will this RSP implement the ICANN gTLD RDAP Technical Implementation Guide?

Yes

Does or will this RSP implement the ICANN gTLD RDAP Response Profile?

Yes

Provide a list of all RDAP extensions to be used.

Identity Digital’s RDAP solution is designed to be robust and scalable, consistently meeting or exceeding all performance, availability, quality and contractual requirements, and SLAs. We provide RDAP services that are fully compliant with the relevant RFCs and global industry best practices. Identity Digital’s RDAP solution is fully compliant with STD95 which includes the following RFCs: - HTTP Usage in the Registration Data Access Protocol (RFC7480) - Security Services for the Registration Data Access Protocol (RFC7481) - Registration Data Access Protocol (RDAP) Query Format (RFC9082) - JSON Responses for the Registration Data Access Protocol (RFC9083) - Finding the Authoritative Registration Data (RDAP) Service (RFC9224) - Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping (RFC8056) As of August 2025, Identity Digital’s RDAP solution fully supports the following RDAP extensions: - icann_rdap_response_profile_1 - icann_rdap_technical_implementation_guide_1 - redacted These ICANN required extensions are registered with the IANA and are documented under the February-2024 version of the ICANN RDAP Technical Implementation Guide and ICANN RDAP Response Profile published on ICANN’s website.

Does or will this RSP forgo the use of any RDAP extensions which are not registered with the IANA as per RFC 7480 (“HTTP Usage in the Registration Data Access Protocol (RDAP)”)?

Yes

Does or will this RSP meet the standards established in the Service Level Agreements specified in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to RDAP?

Yes

Does or will this RSP implement methods to prevent mining of registration data via RDAP?

Yes

Does or will this RSP implement RFC 9325 (“Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”) with respect to RDAP?

Yes

Does or will this RSP regularly and frequently renew the cryptographic material used to secure RDAP communications in accordance with industry best common practices?

Yes

Does or will this RSP keep safe the cryptographic material used to secure RDAP communication in accordance with industry best common practices?

Yes

Does or will this RSP meet the standards established in Specification 3 of the ICANN Registry Agreement (version 2024) with respect to RDAP?

Yes

Does or will this RSP compartmentalize (e.g. virtualization) the RDAP service in such a manner that each compartment (e.g. containers, virtual machines, physical machines) is dedicated to RDAP (excluding system services such as monitoring, remote access and NTP)?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to RDAP and IPv4?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to EPP and IPv4?

Yes

Does or will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to RDAP and IPv6?

Yes

Will this RSP meet the standards established in Specification 10 of the ICANN Registry Agreement (version 2024) with regard to EPP and IPv6 if requested by a registrar?

Yes

Will this RSP provide tools and mechanisms to Registry Operators for the purposes of automated processing and identification of abusive domain registrations.

Yes

Describe the EPP and RDAP status values as they relate to domain name registrations considered to be abusive registrations and those not considered to be abusive registrations.

Identity Digital takes a multi-faceted approach to address DNS Abuse, which includes strong policies and procedures, reviews of each report we receive, sophisticated and state-of-the-art software, a network of Trusted Notifiers, and an experienced group of compliance staff. Each report of DNS Abuse received is independently reviewed on a case-by-case basis. To be actionable, DNS Abuse reports should at minimum include the following factors: - Well-evidenced abusive activity. - The action requested (e.g., suspension, redirect, or transfer). Given the consequences of the actions Identity Digital can take on DNS Abuse, for a report of DNS Abuse to escalate to an active case, the report must be accompanied by evidence of the abuse. Reports or allegations of abuse alone (e.g., uncorroborated blacklistings) will rarely be considered sufficient to merit any action, whether working with our registrar partners or independently. When a domain is determined to be abusive and action is warranted, Identity Digital may apply a range of statuses to assist in the mitigation of the abuse. These statuses may be applied individually or in combination, depending on the specific circumstances, or as required by court order. - clientHold (EPP) | client hold (RDAP), serverHold (EPP) | server hold (RDAP): Prevent the domain from being published to the DNS and may be applied to cease resolution of abusive domains. - clientDeleteProhibited (EPP) | client delete prohibited (RDAP), serverDeleteProhibited (EPP) | server delete prohibited (RDAP): Prohibit the deletion of a domain and may be applied to prevent the deletion, and rapid re-registration of abusive domains. - clientRenewProhibited (EPP) | client renew prohibited (RDAP), serverRenewProhibited (EPP) | server renew prohibited (RDAP): Prohibit the explicit renewal of the domain, but do not prevent auto-renewal. - clientTransferProhibited (EPP) | client transfer prohibited (RDAP), serverTransferProhibited (EPP) | “server transfer prohibited (RDAP): Prohibit the transfer of the domain to another registrar, and may be applied to limit the ability of the domain owner to generate confusion or seek a registrar sympathetic to the domain owner’s preferred use of the domain. - clientUpdateProhibited (EPP) | client update prohibited (RDAP), serverUpdateProhibited (EPP) | server update prohibited (RDAP): Prohibit any updates from being made to the domain, with the exception of removing this status. These statuses may be applied to abusive domains as part of a court order or similar security operation to preserve evidence. Status values added or removed by a registrar are prefixed with "client" whereas statuses added or removed by Identity Digital as the registry are prefixed with "server" and cannot be updated by the registrar. Registrars may only update “client” domain statuses for their sponsoring domains.

Describe the EPP and RDAP status values and their applicability to Uniform Rapid Suspension (URS).

Identity Digital has implemented the Uniform Rapid Suspension (URS) in alignment with the URS guidelines published on the ICANN website. Within 24 hours of being notified by a URS provider and in line with the URS Rules and Technical Requirements, Identity Digital applies a URS Lock to the domain name. The URS Lock includes adding the following statuses to the domain: serverUpdateProhibited (EPP), server update prohibited (RDAP), serverTransferProhibited (EPP), server transfer prohibited (RDAP), serverDeleteProhibited (EPP), server delete prohibited (RDAP). These statuses prevent the domain name from being updated, transferred, or deleted, respectively, during the URS proceedings. If a domain name is suspended as part of the final decision of the URS Complaint (a “URS Suspended Domain”), Identity Digital temporarily removes the serverUpdateProhibited (EPP) and server update prohibited (RDAP) statuses to update the nameserver (NS) and delegation signer (DS) records for the domain, as instructed by the URS Provider. Identity Digital then reapplies the serverUpdateProhibited (EPP) and server update prohibited (RDAP) statuses. If the URS Provider requests the domain name be transitioned to a Non-URS State, Identity Digital removes the URS Lock described above and restores the original information of the domain name, including NS and DS records. When the domain name subject to the URS Lock expires, Identity Digital removes the serverDeleteProhibited (EPP) and server delete prohibited (RDAP) statuses to allow the registrar of record to delete the domain name.

Does or will this RSP implement the Registry Operator-related elements of RFC9361

Yes

Describe all potential registration lifecycle(s) of domain names supported in the system.

Identity Digital adopts the standard ICANN domain registration lifecycle that is supported by all ICANN accredited registrars. A graphical depiction is in ID_MAIN.10.1_Lifecycle_1of2. Registration Lifecycle States 1. Available: The registration lifecycle begins in this state where the domain is available for registration if it is not already registered, reserved, or blocked. 2. Registered: If a domain is available, it may be registered for periods between 1 and 10 years. Upon registration, the domain enters a 5-day Add Grace Period (AGP) during which it may be deleted. If the domain is deleted while in this period, it becomes available for registration without going through the Redemption Grace Period (RGP). During the Registered state, the domain may be renewed for 1 to 10 years, provided the total registration term does not exceed 10 years. Upon renewal, the domain moves to the “renew grace period” status for 5 days. If the domain is deleted while in this status, it is sent to the RGP. A registered domain may also be transferred to another registrar during the registered state if it meets the criteria in the Transfer Policy. If the domain is eligible for transfer, upon receipt of a valid transfer request, the domain is placed in a “pending transfer” status for 5 days. If the domain is deleted while in the “pending transfer” status, it is sent to the RGP. Successful transfers result in a one year registration term extension. Upon transfer, the domain moves to the “transfer grace period” status for 5 days. 3. Expired: At the end of the registration period, the domain immediately moves into the Auto-Renew Grace Period. 4. Auto-Renew Grace Period (ARGP): Upon entering the ARGP, the registry automatically extends the registration period for 1 year and places it in ARGP for 45 days. If deleted during this period, the domain moves to RGP. 5. Redemption Grace Period: RGP is a 30-day period following the deletion of a domain during which the deleted domain is removed from the DNS zone. During RGP, the only available action is to restore the domain. Upon receiving a restore request, the domain is placed in a “pending restore” status for a period of 7 days. Upon successful completion of a restore request, the domain is returned to the Registered state, otherwise the domain is reverted back to the RGP state. 6. Pending Delete: If the domain is not restored during RGP, it transitions to the “pending delete” state for 5 days. No command or other activity can be applied to the domain while it is in this state. Upon expiration of the Pending Delete state, the domain moves to the Available state. Additional Services Provided As a leading global DNS provider trusted by governments and companies of all sizes, Identity Digital also offers services at different points in the registration lifecycle to drive growth for our customers and to enable them to deliver on their commitments to their communities.These additional services do not impact the registration lifecycle. DropZone is an ICANN-approved service offering that gives TLD operators an opportunity to monetize expired domains. On a daily basis, registrars have the ability to re-register expired domains that are put in the DropZone by the registry before they are released for general registration. This allows TLD operators to optimize revenue capture. Verification is a service offering that supports TLD operators with eligibility-based registration policies. As part of this service, only successfully verified registrants are eligible to register a domain. This enables TLD operators to ensure compliance with their registration requirements while preserving the integrity and trust of their namespace. A depiction of how DropZone and Verification interact with the domain registration lifecycle is in ID_MAIN.10.1_Services_2of2.

Describe the registration lifecycle(s) of domain names with respect to EPP status values and RDAP status values.

Identity Digital adopts the standard ICANN EPP and RDAP status values related to the domain registration lifecycle that are supported by all ICANN accredited registrars. Below is a mapping of statuses to the various states of the domain registration lifecycle in ID_MAIN.10.2_Lifecycle_1of2: 1. Available Available domains are not in the registry and therefore do not have an EPP or RDAP status associated with them. 2. Registered - addPeriod (EPP) | add period (RDAP): Upon registration, a domain is assigned this status to indicate that it is in the 5-day Add Grace Period. - renewPeriod (EPP) | renew period (RDAP): Upon renewal, a domain is assigned this status to indicate that it is in the 5-day renew grace period. - pendingTransfer (EPP) | pending transfer (RDAP): Upon initiation of a transfer request in the registry, a domain is assigned this status to indicate that it is in the 5-day pending transfer period. - transferPeriod (EPP) | transfer period (RDAP): Upon successful completion of the transfer between two registrars, a domain is assigned this status to indicate that it is in the 5-day transfer period. 3. Expired Upon expiration, the domain retains any existing statuses and immediately moves into the Auto-Renew Grace Period. 4. Auto-Renew Grace Period (ARGP) - autoRenewPeriod (EPP) | auto renew period (RDAP): Upon entering the ARGP, an expired domain is automatically renewed for 1 year and is assigned this status to indicate that it is in the 45-day ARGP. 5. Redemption Grace Period (RGP) - redemptionPeriod (EPP) | redemption period (RDAP): Upon deletion, a domain is assigned this status to indicate that it is in the 30-day RGP. - pendingRestore (EPP) | pending restore (RDAP): Upon being restored while in the RGP, a domain is assigned this status to indicate that it is in the 7-day pending restore period. 6. Pending Delete - pendingDelete (EPP) | pending delete (RDAP): Upon expiration of the RGP, a domain is assigned this status to indicate that it is in a 5-day Pending Delete state. In addition to these registration lifecycle states and their associated EPP and RDAP status values, Identity Digital also supports other standard ICANN EPP and RDAP status values. A listing of the standard ICANN status values used by Identity Digital is included in ID_MAIN.10.2_Statuses_2of2. These values are as published on ICANN’s website. Additional Services DropZone and Verification are two additional service offerings that Identity Digital provides. Domains that are in DropZone or Verification are not in the registry and therefore do not have an EPP or RDAP status associated with them. Neither of these services impact domain lifecycle.

Describe the nameserver host lifecycle, including relevance to EPP and RDAP status values, with respect to the lifecycle of domain names. This should include a description of nameservers as either attributes of domains or as host objects.

Identity Digital adopts the standard ICANN domain registration lifecycle that is supported by all ICANN accredited registrars. In regards to EPP and RDAP status values relating to nameserver host object lifecycle, Identity Digital is fully compliant with RFC 5732, Extensible Provisioning Protocol (EPP) Host Mapping. 1. Nameserver Host Object Creation Nameserver host objects may be created if the host object name is not already registered and is available. Once created, the nameserver host object can be associated with one or more existing domains. The associated nameserver host object will have the following EPP and RDAP status value: - linked (EPP) | associated (RDAP): The nameserver host object has at least one active association with a domain name. 2. Nameserver Host Object Deletion A nameserver host object may be deleted only when it is not associated with a domain name. Stated another way, if a host object is still associated with a domain within our registry, it cannot be deleted (i.e. the deletion request returns an error code). This applies to both internal (in-zone) or external (out-of-zone) host objects. If a nameserver host object has the linked (EPP) | associated (RDAP) status value, then deletion of the nameserver host object is not permitted. In order to delete a nameserver host object used to delegate one or more domain names in the registry, registrars must either: a) Remove the host object link from all domain name delegates in the registry. This is only practical if the registrar sponsors all delegate domain names. b) Update the host object to a different host name value. This solution will work even if the delegated domain names are sponsored by different registrars. The parent domain name of an internal (in-zone) host cannot be deleted if any child host is used to delegate any other domain names in the registry. One of the two mechanisms above must be used to remove delegations from all child hosts before the parent domain name can be deleted. This behavior is in compliance with RFC 5731 (Extensible Provisioning Protocol Domain Name Mapping) and RFC 5732 (Extensible Provisioning Protocol Host Mapping). 3. Other EPP and RDAP Status Values Supported In addition to the domain registration lifecycle states and their associated EPP and RDAP status values, Identity Digital also supports the following EPP and RDAP status values: - clientDeleteProhibited (EPP) | client delete prohibited (RDAP), serverDeleteProhibited (EPP) | server delete prohibited (RDAP): These statuses prohibit the deletion of the nameserver host object. - clientUpdateProhibited (EPP) | client update prohibited (RDAP), serverUpdateProhibited (EPP) | server update prohibited (RDAP): These statuses prohibit any updates to the nameserver host object, with the exception of removing this status. - ok (EPP) | active (RDAP): This status is assigned when a nameserver host object has no pending operations or prohibitions. This status is removed if other status values are added, and is added if other associated statuses are removed.

If applicable, describe the contact lifecycle, including relevance to EPP and RDAP status values, with respect to the lifecycle of domain names and nameservers. Include a description of the deletion of orphaned contacts.

Identity Digital adopts the standard ICANN domain registration lifecycle that is supported by all ICANN accredited registrars. In regards to EPP and RDAP status values relating to contact object lifecycle, Identity Digital is fully compliant with RFC 5733, Extensible Provisioning Protocol (EPP) Contact Mapping. 1. Contact Object Creation Contact objects may be created by the registrar. Once created, the contact object can be associated with one or more registered domains. The associated contact object has the following EPP and RDAP status value: - linked (EPP) | associated (RDAP): The contact has at least one active association with a domain name. Contact objects cannot be associated with nameservers. 2. Contact Object Deletion A contact object may be deleted as long as it is not associated with a registered domain. If a contact object has the linked (EPP) | associated (RDAP) status value, then deletion of the contact object is not permitted. 3. Identity Digital’s Unassociated Contact Management Policy Identity Digital implements an Unassociated Contact Management policy for all TLDs under our management. Any contact objects that are unassociated with a domain name 30 days after creation are purged. In addition, Identity Digital does not permit the transfer of contact objects from one registrar to another registrar. 4. ICANN’s Registration Data Policy In line with ICANN’s Registration Data Policy, in 2025 many of Identity Digital’s supported gTLDs will no longer permit the association of contact objects with domains. 5. Other EPP and RDAP Status Values Supported In addition to the domain registration lifecycle states and their associated EPP and RDAP status values, Identity Digital also supports the following EPP and RDAP status values: - clientDeleteProhibited (EPP) | client delete prohibited (RDAP), serverDeleteProhibited (EPP) | server delete prohibited (RDAP): These statuses prohibit the deletion of the contact object. - clientUpdateProhibited (EPP) | client update prohibited (RDAP), serverUpdateProhibited (EPP) | server update prohibited (RDAP): These statuses prohibit any updates to the contact object, with the exception of removing this status. - ok (EPP) | active (RDAP): This status is assigned when a contact object has no pending operations or prohibitions. This status is removed if other status values are added, and is added if other associated statuses are removed.

Does or will this RSP be capable of removing orphaned glue in accordance with the standards established in Specification 6 of the ICANN Registry Agreement (version 2024)?

Yes

Describe how this RSP will meet the standards established in Specification 2 of the ICANN Registry Agreement (version 2024), and describe any other data escrow processes. This includes escrow extensions for data related additional registry services.

Identity Digital has supported the requirements described in Specification 2 of the ICANN Registry Agreement since the 2012 Round of gTLDs. We conform to all requirements for the technical specifications of escrow, including: 1. Creating and transmitting full deposits. - We ensure that full deposits are made daily to the escrow provider selected by the Registry Operator. These deposits include all registry objects needed to offer all of the approved registry services. - Full deposits reflect the state of the registry as of 00:00:00 UTC on each day. 2. Creating escrow deposits in the defined format. - We submit all escrow deposits in a file constructed as described in RFC 8909. Although the specification describes some elements as optional, we include those elements in the deposit if they are available. - We use UTF-8 character encoding (RFC 3629). - If there are additional registry services offered, we also include that data (plus any relevant “extension schemas” required). - We map the objects as described in RFC 9022. 3. Processing the deposits with consideration to using file compression, encryption, digital signatures, secure electronic transfer to the escrow agent, and obtaining confirmation of receipt. - We compress files using ZIP as per RFC 4880. Data is encrypted using the escrow provider’s public key. - A digital signature file is generated for every processed file using the registry’s private key in binary OpenPGP format as per RFC 4880. Digital signature files are not compressed or encrypted. - All fields are transmitted to the escrow provider through a secure file upload mechanism via SFTP, as agreed between us and the escrow provider. - We require the escrow provider to check each deposit and confirm that it was received successfully within 12 hours of its deposit. 4. Using specified file naming conventions. We use the standard naming convention for every deposit, specifically: {tld}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} where: - {YYYY-MM-DD} is replaced by the date corresponding to the time used as a timeline watermark for the transactions. - {type} is replaced by “full”, if the data represents a Full Deposit; “diff”, if the data represents a Differential Deposit. - {#} is replaced by the position of the file in a series of files, beginning with “1”; in case of a lone file, this must be replaced by “1”. - {rev} is replaced by the number of revisions (or resend) of the file beginning with “0”. - {ext} is replaced by “sig” if it is a digital signature file of the quasi-homonymous file. Otherwise it is replaced by “ryde” for the encrypted deposit file. 5. Distributing public keys to appropriate parties. - Identity Digital and the escrow provider distribute their respective public key to the other party via email to an email address agreed to by the parties. - Each party confirms receipt of the other’s public key via email, followed by confirmation of the authenticity of the transmitted key via offline methods such as phone call, in-person meeting, or other method as agreed to by the parties. 6. Notification of deposits to ICANN. - In addition to transmitting the escrow deposit to the escrow provider, we send a deposit notification to ICANN. - The transmission of this deposit notification report is fully automated, and occurs immediately following the successful delivery of the escrow deposit to the escrow provider. 7. Monitoring of escrow deposits. - Each step of the deposit process is retried on failure by the system and also monitored for successful completion. Should a continued failure occur in any portion of the process, the failed step can be repeated by our 24x7 Network Operations Center (NOC) staff. Should subsequent failures occur, the issue is escalated to the appropriate on-call teams to diagnose and resolve the issue.

Does or will this RSP regularly exercise registry continuity actions?

Yes

Does or will this RSP be capable of transferring all applicable operations to another RSP as defined by the Material Subcontracting Arrangement Technical Questions?

Yes

Does or will this RSP participate in coordinated Emergency Back-end Registry Operator (EBERO) transitions, including but not limited to maintaining the DNSSEC chain of trust, of hosted gTLDs when the business relationship of this RSP and the Registry Operator is not in good standing?

Yes

Does or will this RSP monitor for faults inside its own network?

Yes

Does or will this RSP monitor for faults from a point outside any of its own networks?

Yes

Does or will this RSP have documented processes for aggregation and triage of faults?

Yes

Does or will this RSP have documented processes to mitigate faults once detected?

Yes

Does or will this RSP have processes to minimize faults during maintenance of systems, including both automated processes and manual change control processes?

Yes

Does or will this RSP have personnel capable of reacting to and mitigating faults 24 hours per day of every day of every year of service?

Yes

Provide documentation regarding any RSP functions currently being served for any gTLD, the domain names of the gTLDs, and all service disruptions for each gTLD in the past six months, where a service disruption is defined by Specification 10 of the ICANN Registry Agreement (version 2024).

Per the clarifying information ICANN has provided regarding this question via the FAQs posted on the RSP Pre-Evaluation site, Identity Digital confirms that in the six months preceding the submission of this application, we have not experienced any service disruptions that went beyond the Emergency Threshold defined in Section 6 of Specification 10 of the ICANN Registry Agreement for any supported TLDs.