Skip to main content

Data Protection/Privacy Update: Key GDPR WHOIS Updates and Next Steps

Gdpr whois updates 1563x886 27jul18 en

As our discussions regarding the impact of the European Union's General Data Protection Regulation (GDPR) continue to move forward, I want to take this opportunity to thank you for the productive conversations that took place at ICANN62 in Panama City. With this blog, I'd like to take a moment to highlight some areas of work underway and lay out our next steps to seek further clarification of the GDPR in relation to a proposed unified access model [PDF, 93 KB].

In relation to current work, one of the topics that frequently came up during the community's discussions was the process for requesting access to non-public registration data. As noted in the Temporary Specification for gTLD Registration Data (Temp Spec), any requestor with legitimate purpose for access to registration data must contact the relevant registry or registrar, which will then determine how to respond to those requests. As noted in a blog published last week, ICANN's Contractual Compliance department is enforcing the Temp Spec as of 25 May 2018. To report a claim of noncompliance, please submit the appropriate form available on ICANN's Contractual Compliance page (

With regards to work underway, exploring options to provide continued access to non-public registration data is at the top of our priorities list as we discuss the next steps. As a reminder, we're still seeking input on the draft discussion document entitled "Framework Elements for a Unified Access Model for Continued Access to Full WHOIS Data [PDF, 93 KB]." I encourage you to review the document and send your feedback to, which will be considered as we continue our work to seek further clarification of the GDPR to develop together a model that complies with the law.

As you may be aware, the European Data Protection Board (EDPB) recently provided [PDF, 764 KB] ICANN with useful guidance that may help the community advance its discussions on this important topic. In a recent blog, ICANN General Counsel and Secretary, John Jeffrey, explained how the ICANN org is considering this newly received input. With your input and this clarification, we aim to prepare another iteration of a potential unified access model to gain as much clarity as possible on the GDPR's application to how non-public registration data may be accessed and used. An updated model will be posted in August.

In parallel, the RDAP Pilot Working Group has been making progress in its efforts to define a profile by the end of July to provide the technology platform for access to non-public registration data. Work is also under way on a technology to authenticate access to non-public data, while the current draft unified access model would provide a process for how third parties could access non-public registration data.

Additionally, the Generic Names Supporting Organization (GNSO) has launched an Expedited Policy Development Process (EPDP) to consider whether the Temp Spec ought to be adopted as a consensus policy. Significant progress on the EPDP was made during ICANN62, and I'd like to express my gratitude to the GNSO Council and everyone in the community who has been involved in this process. We look forward to hearing about the EPDP's work in the coming months.

In the coming weeks, we will ask the ICANN Board to consider reaffirming the Temp Spec, as required by the process for adopting temporary policies or specifications. In the meantime, I encourage you to continue moving forward with these important discussions.

Starting in August, as part of our efforts to ensure the continued sharing of information in addition to formal updates made through blogs and other communications, we will also begin having monthly update calls on data protection and privacy issues with ICANN community leadership. These calls will be posted as well.

I invite you to review that report and visit our Data Protection/Privacy page to follow the latest updates on this issue.


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