Skip to main content

Data Protection and Privacy Update: Seeking Community Feedback on Proposed Compliance Models

Gdpr seeking community feedback 750x424 12jan18 en

Happy new year to you all. We have kicked off 2018 by continuing our work on data protection and privacy issues. In particular, we are preparing for the 25 May 2018 enforcement date for the European Union's General Data Protection Regulation (GDPR). As I've previously written, we are working to ensure compliance with this law while maintaining access to WHOIS to the greatest extent possible.

Our work in this area began when we asked the community for user cases and created a matrix of these different use cases about the personal data that gTLD registries and registrars collect, transmit or publish pursuant to ICANN agreements or policies. In the absence of a WHOIS policy, the user stories are essential for describing the many different uses of the WHOIS system. The matrix informed discussions about whether there were potential compliance issues under ICANN's agreements with registries and registrars because of the new law, and aided in our engagement with data protection authorities.

On 2 November 2017, we published a Statement from Contractual Compliance, which indicated ICANN org would defer taking compliance action against any registry or registrar for noncompliance with contractual obligations related to the handling of registration data. To be eligible for this deferral, we asked ICANN's contracted parties and stakeholders to follow this process to submit proposed interim models for compliance. We've published those community-proposed models here.

In parallel, we engaged the European law firm Hamilton to provide its legal analysis of these issues. The three-part assessment found in its first memo [PDF, 253 KB] that the WHOIS service in its current form must change. In the second part [PDF, 577 KB], Hamilton answered community questions about the law's applicability and scope. In its third analysis [PDF, 440 KB], Hamilton described how processing data within the scope of WHOIS could be changed to become compliant with the GDPR. We asked for your feedback on these analyses and published your input here.

In December, I wrote that we were working to develop interim models for collecting registration data and implementing registration directory services that may be compliant with both the law and ICANN's contractual agreements. To be clear, these proposed models are meant to facilitate discussion and a final model decided on to be an interim solution. They do not replace any existing ICANN policy development work or policies.

Today we published [PDF, 624 KB] for community input those three proposed discussion models for collecting registration data and implementing registration directory services. These models reflect discussions from across the community and with data protection authorities, legal analyses and the proposed models we have received to date. Please provide your input on these models. The input from the community will contribute to assessing the viability of each of the models. From that input either variations or modifications to one of these models will be identified at the end of January for the path forward. To help inform this, please provide your feedback by 29 January 2018. Please send your feedback to

The three models are summarized at a high-level below. The models differ based on what contact information is displayed in the public-facing WHOIS, their applicability, the duration of data retention and what data is not displayed in a public-facing WHOIS:

  • Model 1 would allow for the display of Thick registration data, with the exception of the registrant's phone number and email address, and the name and postal address of the technical and administrative contacts. To gain access to these non-public data points, third parties would be required to self-certify their legitimate interests for accessing the data. This model applies if the registrant is a natural person, and the registrant, registry, registrar and/or the data processor is in the European Economic Area.
  • Model 2 would allow for the display of Thin registration data, as well as the technical and administrative contacts' email addresses. To access the non-public information registries and registrars would be required to provide access only for a defined set of third-party requestors certified under a formal accreditation/certification program. There are two variations on how this model would apply. Model 2A applies to registrants who are both natural and legal persons, where the registrant, registry, registrar and/or the data processor is in the European Economic Area. Model 2B would apply to registrants who are both natural and legal persons, where the registrant, registry, registrar and/or the data processor is regardless of location, that is on a global basis.
  • Model 3 would allow for the display of Thin registration data and any other non-personal registration data. To access non-public information, a requestor would provide a subpoena or other order from a court or other judicial tribunal of competent jurisdiction. This model would apply to all registrations on a global basis.

Please click here to see the models [PDF, 624 KB].

We will share these models as we continue our engagement work, including with the Article 29 Working Party.

As always, we'll continue to keep the community apprised of the various discussions we have. We've also received a range of correspondence relating to the GDPR. We urge you to visit our data protection/privacy page to view the latest correspondence, proposed models from the community, and other materials relevant to this discussion.

Happy 2018 and we look forward to all the work with the community over the coming year.


    Couponado USA  05:40 UTC on 16 January 2018

    This is a very nice and informative post!

    Vrikson Ivan Acosta Velasquez  10:03 UTC on 16 January 2018

    Considering the stated above about the 3 models and in the document "Proposed Interim Models for Compliance with ICANN Agreements and Policies in Relation to the European Union’s General Data Protection Regulation – For Discussion", I conclude that the best model to be chosen is 2B. Greeting, Vrikson Iván Acosta Velásquez

    secura  02:34 UTC on 18 January 2018

    These proposals are an important contribution for the discussion. The European Union's General Data Protection Regulation (GDPR) says, that the documentation of data must be necessary. I do not see, how any entry of data or publication of data for an ADMIN-C or TECH-C (and BILLING-C) could be justified. The WHOIS should consist only of data of the domain owner. The data protection is a right of persons. A company can not be an owner of this right. Therefore my proposal: WHOIS consists of the data of the domain owner. If the owner is a company all data should be published, including e-mail address and phone number. If the domain owner is a private person, all data should be stored by the registry, but e-mail address and phone number should not be published. Hans-Peter Oswald Secura GmbH

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."