Defer Compliance Enforcement of Gaining Registrar Form of Authorization

Why is the Board addressing the issue?

The Board is addressing this issue at the request of the GNSO Council. On 31 October 2019, the GNSO Council sent a letter to the ICANN Board asking the Board to instruct ICANN org to defer Contractual Compliance enforcement of the Transfer Policy's Gaining Registrar FOA requirement until the matter is settled in the planned GNSO Transfer Policy review.

What is the proposal being considered?

The proposal being considered is a request from the GNSO Council that the ICANN Board direct ICANN org to defer Contractual Compliance enforcement of the requirement in the Transfer Policy regarding the Gaining Registrar FOA.

The Transfer Policy requires that an inter-registrar transfer "only proceed if confirmation of the transfer is received by the Gaining Registrar from the Transfer Contact." Such authorization "must be made via a valid Standardized Form of Authorization (FOA)." The Temporary Specification, effective 25 May 2018, superseded this Gaining Registrar FOA requirement in certain circumstances, stating that, "[u]ntil such time when the RDAP service (or other secure methods for transferring data) is required by ICANN to be offered, if the Gaining Registrar is unable to gain access to then-current Registration Data for a domain name subject of a transfer, the related requirements in the Transfer Policy will be superseded…[.]." Section 1.1 of Appendix G to the Temporary Specification provides that when the Gaining Registrar is unable to gain access to then-current Registration Data for the domain name subject to a transfer, the "Gaining Registrar is not REQUIRED to obtain a Form of Authorization from the Transfer Contact."

However, this superseding provision in Appendix G of the Temporary Specification only applies if the then-current registration data is not accessible in the public WHOIS/Registration Data Directory Service (RDDS) at the time of the transfer request. Where the registration data is displayed in the public WHOIS/RDDS, the Gaining Registrar FOA requirement continues to apply.

As set forth in greater detail below, the Registrar Stakeholder Group (RrSG) has identified issues with the implementation of this requirement. The GNSO Council cited these issues in submitting this request to the Board.

The Interim Registration Data Policy for gTLDs (Interim Policy), effective 20 May 2019, requires continued implementation of measures consistent with the Temporary Specification. Additionally, the Phase 1 Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process, at Recommendation #24, is consistent with the Temporary Specification and does not alter the current contractual obligations. Thus, the implementation issues identified by the RrSG will continue to persist when the Registration Data Policy becomes effective.

In light of these implementation issues, the GNSO Council asked the ICANN Board to refer the Gaining Registrar FOA issue to the anticipated Transfer Policy review and to direct ICANN org to defer compliance enforcement of the Gaining Registrar FOA requirement until this issue is settled in the Transfer Policy review.

What concerns or issues were raised by the community?

The RrSG raised concerns about the Gaining Registrar FOA requirement in a 9 October 2019 letter to the GNSO Council. In raising these issues, the RrSG said it was concerned that the Transfer Policy must be implemented in compliance with the General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), and other applicable privacy laws.

The RrSG pointed out in its letter that, even where data is present in the registrant email field in the public RDDS output, an email sent to that address may not go directly to the registrant due to the email being obfuscated, redacted, replaced by a web form URL, or use of pseudonymized email addresses. They believe that if a registrar implemented a system to send the Gaining Registrar FOA to any address listed in the public RDDS, there is no guarantee that the email would reach the registrant. As a result, the registrars contend that they are unable to build a reliable automated process to continue processing the large volume of transfers between registrars. According to the registrars, this would ultimately defeat the purpose of the Transfer Policy, which is to enable registrants to have the ability to transfer domain names to other registrars. Additionally, the RrSG asserts that many registrars believe that under the European Union's General Data Protection Regulation (GDPR), the gaining registrar does not have consent to process this information because that would require registrars to send an email to an individual that is not their customer.

Prior to the adoption of the Temporary Specification, on 1 May 2018, the Contracted Party House (CPH) Tech-Ops committee proposed to ICANN org to remove the Gaining Registrar FOA requirement, stating in a letter that, "After 25 May 2018, gaining registrars will not have the ability to pull the registrant email or a proxy from the public WHOIS output; data will not be available from losing registrar or registry on a consistent basis." They further stated that the current transfer process, which requires both FOAs, was developed before authorization codes were used consistently across registrars. Additionally, the committee said that the Gaining Registrar FOA provides negligible protection in the context of a domain transfer and that registrars seldom rely upon the Gaining Registrar FOA in the context of a transfer dispute.

Are there positive or negative community impacts?

In the 9 October 2019 letter, the RrSG stated that they have "observed that the vast majority of ICANN-accredited registrars are no longer sending the Gaining Registrar FOA post Temporary Specification, and there appears to be no evidence of an increase in unauthorized transfers since May 2018." Additionally, ICANN Contractual Compliance has not seen a material increase in complaints regarding unauthorized transfers. The data gathered by ICANN Contractual Compliance shows that 143 unauthorized transfer cases were closed 13 months prior to the adoption of the Temporary Specification (May 2017 – May 2018); and 138 cases were closed 13 months directly following the adoption of the Temporary Specification (June 2018 – June 2019).

As identified by the CPH Tech-Ops committee, during gTLD transfers when the email address is not present in public RDDS, the AuthInfo code is sufficient to confirm the intent of the registrant to transfer. The Losing Registrar FOA also confirms this intent.

The Gaining Registrar FOA requirement continues to cause implementation difficulties and compliance issues for many registrars. This deferred compliance period will allow the ICANN community time to consider the Gaining Registrar FOA requirement through the Transfer Policy review. Furthermore, the additional time will allow the affected contracted parties to assess any potential impact on the Transfer Policy and allow ICANN's Contractual Compliance function to focus its resources on requests with greater urgency or impact.

Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?

There are no anticipated fiscal impacts on ICANN's resources, the community, and/or the public as a result of this action.

Are there any security, stability or resiliency issues relating to the DNS?

There is no anticipated impact on the security, stability or resiliency of the DNS.

Is this either a defined policy process within ICANN's Supporting Organizations or ICANN's Organizational Administrative Function decision requiring public comment or not requiring public comment?

This resolution is an organizational administrative function for which no public comment is required.

Is this action within ICANN's Mission? How does it relate to the global public interest?

This action is in line with ICANN's mission and is in the public interest as it helps to ensure a consistent and coordinated implementation of policies in gTLDs.