Hello TPR WG members,

We recently received an inquiry concerning the reference to Charter Questions d4-d8 in Recommendation 26’s rationale (found in the current working document). The end of the rationale paragraph states that: “…Rationale regarding the working group’s proposed elimination of the 60-day lock can be found in its responses to Charter Questions d4-d8.”

For your reference, please find Charter Questions d4-d8 and the proposed draft responses below, noting that the WG has not yet reviewed or approved this draft text. If you have any further questions, please do not hesitate to contact us.

Kind regards,

Caitlin, Berry, Julie, Feodora, and Christian

----------

Draft responses to Charter Questions d4-d8 (still to be reviewed by TPR WG):

Charter Question d4

              Survey responses and data provided by ICANN’s Global Support Center indicate that registrants do not understand the 60-day lock and express frustration when it prevents them from completing an inter-registrar transfer. Does the 60-day lock meet the objective of reducing the incidence of domain hijacking? What data is available to help answer this question? Is it the 60-day lock the most appropriate and efficient mechanism for reducing the incidence of hijacking? If not, what alternative mechanisms might be used to meet the same goals? Are there technical solutions, such as those using the control panel or two-factor authentication, or other alternatives that should be explored?

Working Group Response: The working group reviewed the complaint metrics from ICANN Global Support and Contractual Compliance and, after discussing the metrics at length, has determined that the 60-day lock following a Change of Registrant appears to be a greater source of registrant frustration than proven registrant security. Furthermore, available data suggests that valid reports of domain hijacking are not as numerous as may be expected. For example, according to complaint metrics shared by ICANN Contractual Compliance, from September 2020 to October 2023 ICANN Compliance received:

• 205 complaints regarding Unauthorized Changes of Registrant
  • 169 were closed as invalid (without addressing with the Contracted Party)
  • 42 were sent to the Contracted Party
• 780 complaints regarding Unauthorized Inter-Registrar Transfers
  • 679 were closed as invalid (without addressing with the Contracted Party)
  • 88 were sent to the Contracted Party

The working group considered the number of complaints received by ICANN Compliance and sent to Contracted Parties to be relatively low, particularly when considering the vast number of domain names, changes of registrant, and inter-registrar transfers that occur worldwide. While most complaints of domain hijacking may be addressed internally with Registrars and are not escalated to ICANN Compliance, such issue tracking and reporting across Registrars may not be consistent or readily available and was not provided to the Working Group when requested. 

Based on available data, it is not clear that the 60-day lock demonstrably reduces instances of domain hijacking. However, the working group noted that from the perspective of registrars, it is often difficult, if not impossible, to determine whether a registrant’s email address or account login credentials have been compromised until after a complaint is received. While the 60-day lock temporarily prevents the registrant (and possible hijacker) from transferring the domain to another Registrar (also assuming the transfer lock was not opted-out of by the hijacker prior to the change of registrant), the lock does not prevent any initial hijacking of the registrant’s credentials or account. 

The working group discussed various ways that Registrars could address domain hijacking proactively rather than reactively, such as through additional requirements around accounts, control panels, and multifactor authentication. However, the working group noted that given the variety of Registrars and their business models, there is no one-size-fits-all security apparatus, and that flexibility should be given to Registrars to secure registrant data and accounts in ways that work best for them and their customers. That being said, the working group has proposed several preliminary recommendations within this Initial Report which would increase the security of inter-registrar transfers and help registrants catch and combat domain hijacking (such as required notifications to the RNH, instructions for how an RNH may reverse an invalid transfer, additional TAC requirements, implementation of a 30-day post-transfer restriction, etc.).

Charter Question d5

Survey responses and data provided by ICANN’s Global Support Center and Contractual Compliance Department indicate that registrants have expressed significant frustration with their inability to remove the 60-day lock. If the 60-day lock is retained, to what extent should there be a process or options to remove the 60-day lock?

Working Group Response: Rather than retaining the 60-day inter-registrar transfer lock following a Change of Registrant, the working group recommends eliminating it from the future Change of Registrant Data Policy (See Preliminary Recommendation 26.4). The working group has noted several reasons why this 60-day post Change of Registrant inter-registrar transfer restriction/lock should be eliminated.

1. The working group discussed at length about the confusion and frustration from registrants around this restriction. Input from the Transfer Policy survey, which was administered as part of the Transfer Policy Status Report, also noted the inconsistency with which this lock is applied. Specifically, the language provides that registrars MAY offer an opt-out, but not all registrars choose to offer this, which ultimately leads to confusion among Registered Name Holders. Additionally, the working group noted that the common occurrence of a Registrar acting as the Designated Agent and opting out of the lock on behalf of the RNH, which is permitted in the COR policy, has rendered the security value of the 60-day lock meaningless or of negligible value. 

2. In recognition of the diminished security value of the 60-day post-COR lock, the working group instead recommends requiring a 30-day post inter-registrar transfer restriction, which is detailed in Preliminary Recommendation 19. Barring an exception as described in Recommendation 19, domain names will remain at a registrar for 30 days following an inter-registrar transfer, allowing for any fraudulent changes to be unwound during this restriction period. 

3. The working group notes that the “clientTransferProhibited” status can be applied to a domain name at any time to prevent unwanted transfer. The 60-day COR lock is an unnecessary trigger, as such a lock is already available without additional requirements.

4. The working group further notes that it has recommended a series of measures to increase the security of the Transfer Authorization Code (TAC) and reduce the risk that the TAC is obtained by an unauthorized party, as detailed in Preliminary Recommendations 2-15. With the added security measures, the TAC becomes a stronger means to demonstrate that the TAC holder is an appropriate party to request the transfer, which makes the post-COR transfer restriction less important.

5. The working group notes that when a Material Change to specified registration data elements occurs, the Registrar MUST send notifications to the Registered Name Holder further to Preliminary Recommendation 27.

Charter Question d6

Due to requirements under privacy law, certain previously public fields, such as registrant name and email may be redacted by the registrar. Is there data to support the idea that the lack of public access to this information has reduced the risk of hijacking and has therefore obviated the need for the 60-day lock when underlying registrant information is changed?

Working Group Response: The working group believes that the widespread removal of public access to registrant data has indeed reduced the risk of hijacking. Working group members anecdotally observed that since 2018 and the redaction of registrant data from public lookup tools, there has been a noticeable drop in reports of domain data theft. This increased security of registrant data was a factor the working group considered when developing its recommendation to eliminate the 60-day lock from the future Change of Registrant Data Policy (See Preliminary Recommendation 26.4).

Charter Question d7

In its survey response, the Registrar Stakeholder Group indicated that the 60-day lock hinders corporate acquisitions, consolidations, and divestitures of large lists of domains to new legal entities. To what extent should this concern be taken into consideration in reviewing the 60-day lock?

Working Group Response: The working group considered the 60-day lock’s hindrance on legitimate domain transfers, including transfers resulting from corporate acquisitions, consolidations, and divestitures of large domain portfolios. In such circumstances, it is not uncommon that a Registrar transfer request follows a recent change of registrant, triggering the 60-day transfer lock much to the registrant’s frustration. Having considered the concerns of registrants and the situations where it is necessary to readily transfer Registrars following a change of registrant, the working group recommends eliminating the 60-day lock from the future Change of Registrant Data Policy (See Preliminary Recommendation 26.4).

Charter Question d8

If the policy is retained, are there areas of the existing policy that require clarification? For example, based on complaints received by ICANN Contractual Compliance, the following areas of the policy may be appropriate to review and clarify:

• There have been different interpretations of footnote 4 in the Transfer Policy, which states: “The Registrar may, but is not required to, impose restrictions on the removal of the lock described in Section II.C.2. For example, the Registrar will only remove the lock after five business days have passed, the lock removal must be authorized via the Prior Registrant’s affirmative response to email, etc.” Is the language in footnote 4 sufficiently clear as to whether registrars are permitted to remove the 60-day lock once imposed under the existing policy? If not, what revisions are needed?
• Should additional clarification be provided in Section II.C.1.3, which addresses how the information about the lock must be provided in a clear and conspicuous manner? Does the policy contemplate enough warning for registrants concerning the 60-day lock where they are requesting a COR?
• Should clarification be provided in Section II.C.2 that the option to opt-out is provided only to the Prior Registrant? For example, would the following revision be appropriate: “The Registrar must impose a 60-day inter-registrar transfer lock following a Change of Registrant, provided, however, that the Registrar may allow the Prior Registrant to opt out of the 60-day inter-registrar transfer lock prior to any Change of Registrant request.”?

Working Group Response: The working group recommends eliminating from the future Change of Registrant Data Policy the requirement that the Registrar impose a 60-day inter-registrar transfer lock following a Change of Registrant. Additionally, the working group recommends eliminating the option to opt-out of the 60-day lock, as there would no longer be a 60-day lock to opt-out of (See Preliminary Recommendation 26.4). This elimination obviates the need to further clarify the 60-day lock and opt-out policy text. However, the working group has identified other areas of the existing change of registrant policy (namely concerning notifications of a change of registrant) that it believes should be clarified and expanded on within the new standalone Change of Registrant Data Policy.