Skip to main content

ICANN GDPR and Data Protection/Privacy Update

Data privacy protection update 3121x1560 24sep18 en

As part of our ongoing work together on the General Data Protection Regulation (GDPR) and seeking clarity for any access mechanism for non-public registration data, I promised to provide regular updates. These updates and any clarity received are input into the community's policy work, and do not replace it, as we continue our efforts together on this issue.

Since our last blog updating on the publication of a possible unified access model, we have been exploring different avenues to address the tension between ICANN's public interest requirements that contractually obligate registries and registrars to provide access to WHOIS data, and the potential liability faced by ICANN, registries and registrars as data controllers when making non-public registration data available to third-parties in response to WHOIS queries.

Lowering the legal risks for contracted parties as data controllers is necessary to develop a workable unified access model.

With that in mind we have been considering variations involving technical and legal approaches. A technical solution for authentication implementation for a possible unified access model for continued access to registration data could be implemented building on the technology available via the Registration Data Access Protocol (RDAP).

In addition to a technical approach, other approaches such as ICANN playing a role in possible terms of use or codes of conduct to satisfy requirements under the GDPR may also be worth exploring. As noted in our previous updates and discussions with the community, by exploring these possible approaches, we are also continuing to seek more guidance and certainty for all parties to reduce the legal risks for contracted parties who offer registration directory services. Achieving clarification and the information we receive is intended as input to the policy work, not to replace the community's policy development work.

The avenues we are exploring are also in line with correspondence and discussions with the European Commission1 and community2, where ICANN has stated that it wants to understand whether there are opportunities for ICANN, beyond its role as one of the 'controllers' with respect to WHOIS or its contractual enforcement role, to be acknowledged under the law as the coordinating authority of the WHOIS system.

We are looking forward to discussing these issues with the community to determine support for shifting the liability for providing access to non-public registration data to ICANN and establishing a globally scalable unified solution for access to non-public WHOIS data. Needless to say, that any avenue we pursue needs to be compliant under the GDPR. As such, it will be important to engage with the European Data Protection Board to test with them whether the approaches and interpretations of the law may ultimately provide a feasible solution meeting the needs of stakeholders seeking access to non-public WHOIS.

As to community engagement, as you may be aware, we had planned to hold a community webinar and are now working to find a new date in light of several stakeholder meetings that conflicted with the proposed time for the week of 24 September.

As you know, the ICANN Board of Directors held a workshop in Brussels recently where, in the margins, Board Chair Cherine Chalaby and I had the opportunity to meet with Mariya Gabriel, the European Commissioner for Digital Economy and Society. You may have seen her tweet following the meeting.

As a reminder, please also review the next iteration of the Draft Framework for a Possible Unified Access Model for Continued Access to Full WHOIS DATA published on 20 August. Your input to this is important as we continue our dialogue with the European Data Protection Board and decision makers in order to seek clarity on such an access mechanism. You can send your comments to You can also check our Data Protection/Privacy Issues page for the latest updates on this and related topics.




    John Laprise  20:34 UTC on 24 September 2018

    ICANN is either the data controller or a data processor-there is no other alternative nor shifting of liability. There is no negotiation on that point as long as it maintains the WHOIS. If it is the former, it must establish a lawful basis for data collection and address both data minimization and accuracy. If it is the latter, it must abide by the DPA issued by the data controller. At present, it seems as though the WHOIS suffers from inaccuracy and bloat, in addition to the questions of legitimacy asked by the EU. In a world where not all law enforcement agencies have similar degrees of legitimacy or act under similar ideas of rule of law, the potential for WHOIS abuse leading to persecution, imprisonment or even death of domain holders is a very real concern of the Internet community and every bit as real as the issues of trust in ecommerce and communication. While the latter can lead to financial ruin, the former are a threat to life and limb. If ICANN pursues legitimate interest as a basis for much of its data collection, it is likely to fail the balancing test between individual privacy and the good of the community so long as there are governments which oppress, imprison, and kill their populations.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."