TEL: +44 (0) 20 7421 8299   EMAIL: info@valideus.com

GDPR: Understanding the ICANN Temporary Specification for gTLD data

Written by: 
The Valideus Team
25 May 2018

As anticipated, on 17 May 2018 the ICANN Board approved a Temporary Policy to address changes to gTLD whois in response to the impending commencement of GDPR enforcement. The approval of the Temporary Policy creates the Temporary Specification for gTLD Registration Data (“Temp Spec”) – effectively an emergency measure which alters certain obligations in the contracts ICANN has with registries and registrars (the Registry Agreement and Registrar Accreditation Agreement, respectively).

The Temp Spec embodies the main substance of the changes to whois proposed in ICANN’s Calzone/Cookbook model. Thus, the Temp Spec requires contracted parties based in the EEA, and those who deal with EEA-based registrants, to redact the following data from public whois records, unless the contact has consented to their data being published:

For the registrant, admin, and technical contacts, the contact email address field must be published but only in an anonymised form, either in the shape of an anonymised email address or a web form which can be completed. This allows users to communicate with the contact without revealing their email address. Contracted parties are given the option of applying all of this in cases which are not strictly subject to GDPR (such as a Japanese-based registrant) where it is “commercially reasonable” to do so or where it is not technically feasible to limit the applicability of the Temp Spec to those only based in the EEA.

The other main element of the Calzone/Cookbook model was for a tiered whois system, whereby certain types of user (such as law enforcement, IP professionals, and security specialists) could be formally accredited in order to allow them to have access to the full whois data, including non-public fields. However ICANN recognized that it was unable to implement such a model before GDPR becomes effective on 25 May.  Under ICANN’s Temp Spec, therefore, contracted parties are now required only to provide “reasonable access” to non-public data where a party has a “legitimate interest” which is not “overridden by the interests or fundamental rights and freedoms of the Registered Name Holder or data subject pursuant to Article 6(1)(f) GDPR”.  Decisions on the granting of access, including to whom and how quickly such requests will be dealt with, and what non-public information to which they should have access have been left to the individual contracted parties to determine.  That said, ICANN Compliance has indicated that this is an aspect of the Temp Spec that they will be paying close attention to. 

The third core element of the Temp Spec is a requirement for contracted parties to implement a new RDAP service in the future, upon notice from ICANN. RDAP is an alternative protocol to the collection and distribution of whois related information.  The new protocol is a vehicle to enable the implementation of a tiered whois (or registry directory service) system. It provides a mechanism to provide different levels of access to different parties based on a pre-approved set of criteria.  Thus, for example, it would enable registries and registrars to provide certain data to law enforcement, but provide a subset of that information to other requestors or information.  A working group of registry operators is tasked with defining the profile of RDAP, along with the service level commitments of the RDAP service and they have been given until 31 July to do so.

The Temp Spec becomes effective on 25 May 2018.

What does it mean for Contracted Parties?

Although the passing of the Temp Spec finally provides contracted parties with some level of certainty about what ICANN will permit/require in terms of the published whois records, it still leaves a lot of confusion and unanswered questions. Firstly, it was approved only 1 week before it is due to become effective on contracted parties, making it practically impossible to implement all of the required changes (such as creating an anonymised email or web form mechanism in the whois, and incorporating required updates to data escrow agreements and Registry-Registrar Agreements – updates which ICANN has yet to publish) in such a short timeframe.

There is also a lack of clarity with respect to the requirement to provide non-public whois data to third parties on the basis of “reasonable access”, as noted above. What is “reasonable access”?  Who must access be granted to, for what elements of the non-public data, and how quickly must such requests be dealt with? A contracted party’s interpretation of “reasonable access” might not align with that of ICANN Compliance, so it leaves uncertainty instead of mitigating it.

The Temp Spec also modifies the process for transferring a domain from one registrar to another. Now, the gaining registrar may no longer be able to get the email approval of the registrant; they will be able to proceed with the authorisation code alone. Registrars may have to adjust their systems which could cause confusion for registrants used to processing transfer requests prior to these changes.

ICANN has stated that they will begin to enforce the new contractual requirements from the 25 May, yet informally they have suggested they will provide some leeway for implementation time. During the GDD Summit in Vancouver, the following actions were identified as being ICANN’s priority: continued collection by registrars of the full data set; transfer of the full data by the registrar to the registry; escrowing of the data; and provisioning of non-public data to appropriate requesters in a timely manner.   Since the escrowing and access actions are not yet fully-baked, this leaves the contracted parties with uncertainty as to whether ICANN Compliance might start to issue breach notices immediately after the 25 May.

What does it mean for Brand Protection?

The most obvious effect on IP professionals and those concerned with online brand protection is that the public whois for the majority of gTLD domains will be heavily redacted, with very little information about the domain owner available. Although contracted parties are mandated to provide a mechanism for users to contact a domain owner (either through a web form or anonymised email address) it is not clear how this will work in practise. Will there be a way to check that the correspondence has been received by the registrant?

Until an accreditation and access program is designed and implemented (which is likely to take a considerable amount of time) it could be challenging to obtain the full, non-public whois data for certain TLDs and through certain registrars, given the lack of clarity to the requirement for contracted parties to provide “reasonable access” to the data. This leaves it up to the individual contracted party to determine whether your request for the data is reasonable, and there are also no SLAs for handling data requests.

Lack of access to whois data could have an effect on brand monitoring services, most of which rely on whois data to some degree. It will also have some impact on the ability of IP professionals to file UDRP and URS cases. Although the Temp Spec expressly requires that contracted parties must provide full whois data to UDRP and URS providers upon the dispute resolution provider notifying the contracted party of the existence of a complaint, this is not, presently, extended to brand holders who wish to have this information in order to consider filing  UDRP or URS case. Therefore, in many cases it will not be possible to identify the registrant of an offending domain while putting together your UDRP/URS filing, which will also create challenges in identifying names with connected ownership, which you would wish to deal with in a single complaint.

The Temp Spec does make it clear that UDRP and URS cases can be filed as a “Doe” complaint where the registrant is not known, and Brian Beckham, of WIPO has confirmed that they would expect filings which list the respondent as “name redacted” to still be accepted by the provider, in the same way as filings against privacy/proxy services are accepted today. Brian has also confirmed that WIPO’s current position is that UDRP providers have a “reasonable and legitimate purpose to relay registrar-provided WHOIS data to filing complainants so as to provide complainants an opportunity to amend substantive and/or procedural portions of complaints (an accepted practice today as regards privacy/proxy services named as respondents), and also so as to facilitate withdrawal or settlement as case may be”.  Where a “Doe” complaint is immediately withdrawn once the registrant is known, WIPO would also generally refund $1000 of the UDRP fee since the case will not yet have gone to the panellist.  This may help mitigate some of the challenges associated with filing dispute proceedings.

Finally, although the Temp Spec only applies to ICANN contracted parties with respect to gTLDs, it should be noted that some ccTLDs will also be affected by GDPR and some will mask elements of the whois data as a consequence.

What is on the horizon?

The Temp Spec has an initial life of 90 days, meaning that the ICANN Board will need to reaffirm it every 90 days. However, it cannot be reaffirmed beyond one year. At that point, it would need to be replaced by a permanent, new Consensus Policy in order to maintain the new requirements on contracted parties. In other words, the GNSO have one year to agree on a Consensus Policy to deal with this issue. It will be challenging to reach community agreement on it within one year, especially on an issue as contentious as whois. The GNSO have indicated they will look to utilise a previously unused mechanism – an Expedited PDP (EPDP) – which in theory should be a quicker process than the standard PDP. The GNSO Council have already had an initial call to discuss this.

In the meantime, could ICANN be preparing for possible litigation against the EU in relation to GDPR? Their meeting agenda for 21 May lists “litigation strategy regarding GDPR” as a topic but there is no information yet as to what this means exactly. ICANN previously suggested they could litigate against the EU to try and receive forbearance on enforcement of GDPR, however this Board discussion may instead have been to prepare for any possible litigation against ICANN itself regarding its Temp Spec.