On May 17, 2018, ICANN issued a  “Temporary Specification for gTLD Registration Data,” the purpose of which is to provide ICANN’s contracted parties (registrars and registries) a path towards compliance with both ICANN contractual requirements and the GDPR. This involved the introduction of numerous registrar requirements, aimed at resolving points of conflict between ICANN’s Registrar Accreditation Agreement (RAA) and the GDPR. Here, we’ll highlight those requirements that are most relevant to our resellers, provide our stance on the Temporary Specification, and discuss some related upcoming features being added to the OpenSRS platform.

What is a “Temporary Specification”?

To understand what makes the Temporary Specification unique, it’s important to understand how ICANN policy is typically developed. Normally, any policy that is binding on contracted parties (registrars and registries) is developed by a bottom-up, participatory process, taking input from all stakeholders and interested contributors, along a defined path called a  “policy development process” (or “PDP”).

The output of a PDP is presented for public comment, refined, and then presented to ICANN’s Generic Names Supporting Organization (GNSO) Council for a vote. After a policy is approved by the GNSO Council, it is presented to the ICANN Board for final review and approval. Only after the ICANN Board approves the policy does it become binding on registrars and registries through a contractual provision in the above RAA.

The Temporary Specification was issued as an “emergency policy,” meaning it was adopted by a super-majority of the ICANN Board and bypassed the normal policy development process. Emergency policies must be re-approved by the ICANN Board every ninety (90) days and can exist for no more than one year. The idea is that one year provides sufficient time for the ICANN community to develop a permanent policy along the normal, bottom-up development path. The Temporary Specification was adopted on May 17, 2018, and will expire on May 16, 2019.

What does the Temporary Specification require of registrars?

The Temporary Specification includes a long list of items that registrars “must” or “shall” implement in order to be in compliance with their Registrar Accreditation Agreement, many of which are pulled directly from, or are heavily based on, the GDPR itself.

Here are some of the highlights, specifically those most relevant to resellers and registrants, with a note about any related changes we’re making within the OpenSRS platform.

Registrars “must” or “shall”:

1. Redact personally identifying information from the public Whois output when (a) the registry or registrar is located in the EU, or (b) the registrant is located in the EU, or (c) the registry or registrar uses a data processor located in the EU for the registrant’s personal data. The redacted fields must say something like “REDACTED FOR PRIVACY.” (Temp. Spec. Appendix A Section 2)

OpenSRS’ approach: As of May 25, 2018, Whois lookups results for all domains on our platform have returned “Data Protected” in place of any personally-identifying information. However, we haven’t just limited this practice to the specific cases listed above; the redaction of personal data in the public Whois is our default for all domains on our platform.

2. Provide a method for third parties to contact the registrant through an anonymized email or web form. (Temp. Spec. Appendix A Section 2.5)

OpenSRS’ approach: We plan to launch a Whois Contactability service that will allow the registrant to be contacted through a hosted web form. We’ll provide more details in the next few weeks.

3. Provide a means for the registrant to consent to have their contact details displayed in the public Whois, instead of the “Data Protected” notice mentioned above. (Temp. Spec. Section 7.2.1)

OpenSRS’ approach: We’ll soon be launching a Whois Publicity service that allows registrants to opt into the display of their personal data in the public Whois, details of which will be released in the coming next weeks.

4. Implement Tiered Access to full Whois data, so that third parties with a legitimate interest in access to a registrant’s personal data (such as law enforcement agencies) can review that data when necessary and appropriate. (Temp. Spec. Appendix A Section 4)

OpenSRS’ approach: We’ve built a Tiered Access Directory — or “gated Whois” — that accomplishes this.

5. Provide mandatory disclosures to registrants detailing who has the registrant’s personal data, how it is processed, when and why a data transfer crosses international boundaries (if applicable), and the specific reasons that data is collected and transferred, among other subjects. (Temp. Spec. Section 7.1.)

OpenSRS’ approach: This information is easily located on our Data Use Information Page

6. Comply with a new transfer policy, described in Appendix G to the Temporary Specification.

OpenSRS’ approach: The domain transfer process changes we announced on April 30, 2018, anticipated the new transfer policy outlined in ICANN’s Temporary Specification. No further changes are needed.

7. Implement and observe Service Level Agreement (SLA) standards for Registration Data Access Protocol (RDAP), otherwise known as the successor to the WHOIS protocol. (Temp. Spec. Section 5.2)

OpenSRS’ approach: These Service Level Agreement standards are not yet finalized, but OpenSRS has played an active role in the RDAP pilot project. We’re in a position to easily implement any minor changes to our current system that the final agreement may call for, and help shape the SLA to ensure it’s something that all registrars can meet in order to provide a reliable and fast RDAP service to users.

How and when are registrars expected to comply with the Temporary Specification?

ICANN has stated that it is “enforcing the requirements of the Temporary Specification as of 25 May 2018, as it does any other ICANN agreement or policy requirement.” However, aware that the requirements of the Temporary Specification came late, ICANN has provided registrars with some leeway. While ICANN has already sent notices of non-compliance to many registrars, they appear to be withholding further action so long as the registrar demonstrates that they are working toward compliance. So we can expect that the various GDPR compliance processes in place now — which vary from registrar to registrar —  may look quite different down the road. Virtually every registrar, including Tucows, is changing its implementation in important ways to comply with the Temporary Specification.

What changes is OpenSRS implementing?

We have already implemented the majority of the mandatory requirements. As mentioned above, you can expect two new features in the coming months: Whois Contactability, which provides a means to contact the registrant through public Whois lookup results, and Whois Publicity, which allows registrants to opt into the public display of their contact data.

What is OpenSRS’ stance on the Temporary Specification?

We believe industry-standard processes are important — they provide a level of consistency very much needed in this highly connected registrant/registrar/registry network. Many of the Temporary Specification requirements will help move the industry forward towards a unified approach.

However, we view other aspects of the Temp. Spec. as problematic. The Temporary Specification aims to provide registries and registrars with a path to comply with both ICANN contractual requirements and the GDPR, but in a way that maintains “the existing Whois system to the greatest extent possible” and requires “robust collection of Registration Data.”

At Tucows, we believe that “maintaining the existing Whois system” and requiring “robust collection” of data violates the basic principles of GDPR. Put another way, we do not believe that the Temporary Specification is fully compliant with the GDPR. We have an ongoing disagreement with ICANN as to what the GDPR requires in three discrete areas, which is the subject of the ongoing ICANN v. EPAG litigation in Bonn, Germany.

Right now, we’re focused on implementing those Temporary Specification requirements that do not conflict with the GDPR (which is, of course, the vast majority). The GNSO has initiated an Expedited Policy Development Process (“EPDP”), which we are watching with great interest, as we work within the registrar community to advocate for the best outcome for registrars, resellers, and registrants. We’re advocating for a policy that fully complies with the GDPR, keeps domain registration and management simple, and protects the interests of our resellers. As we’ve said before, in any instance where ICANN policy conflicts with the law, our priority is compliance with the latter.