Skip to main content

Data Protection/Privacy Activity Recap

Data protection privacy recap 750x425 17nov17 en

We have just returned from a very busy ICANN60 meeting in Abu Dhabi, where there were many productive community discussions focused on the European Union's General Data Protection Regulation (GDPR). We want to provide you with a brief recap of these dialogues, recent developments and what's next in terms of the legal analysis. As you'll recall from previous blogs on this topic, we are taking the following steps to determine the GDPR's scope of impact: We published a Personal Data Use Matrix based on contributions from stakeholders, and we commissioned a legal analysis from European law firm Hamilton to assess the data in the matrix and answer other questions related to the legislation's impact.

At ICANN60 we published a statement from Contractual Compliance on the ability of registries and registrars to comply with their WHOIS and other contractual requirements. Moving forward, we shared in Abu Dhabi our plan for the next phase of the Hamilton legal analysis, which will incorporate questions from the community, and will inform the publication of 2-3 models for compliance with the GDPR, as well as our contracts. We plan to solicit your input on these models in the coming months.

Also at ICANN60, at the cross-community session on the GDPR many of the discussions revolved around the continued availability of WHOIS, including changes that may be required in light of the legislation. We also heard concerns from registries and registrars about their ability to comply with contractual agreements with ICANN and the GDPR, as well as topics such as looking beyond WHOIS to include registration data more broadly, including data required to be escrowed and retained under ICANN's contracts. If you weren't able to attend, you can listen to an audio recording of the session.

Given that enforcement of the GDPR will become effective on 25 May 2018, these discussions and progress on the legal analysis are important to the contracted parties' ability to comply with GDPR from that day onwards without breaching their agreements with ICANN.

Göran Marby, our president and chief executive officer, made it clear during the meeting, including at several stakeholder sessions, that finding a path forward to ensure compliance with the GDPR while maintaining WHOIS to the greatest extent possible is a high priority. In this regard, as was also shared at ICANN60, the ICANN org is working with external legal counsel, Hamilton, on the next iteration of the legal analysis. This includes ultimately identifying potential models that address both GDPR and ICANN compliance obligations. 

As also noted above, at ICANN60 ICANN Contractual Compliance published a statement indicating that it would defer taking action against any registry or registrar for noncompliance with contractual obligations related to the processing of personal data under certain conditions. We encourage you to read the full statement here.

To be clear, we will defer enforcement on a temporary basis during this period of uncertainty. We also want to clarify that submission of a model does not mean that it will qualify for deferral or that any deferral granted will be permanent. ICANN is currently considering the process for reviewing deferral submissions.  The sharing of models is also an important contribution to feed into subsequent iterations of analysis from the Hamilton law firm.

In parallel the Registration Directory Services Policy Development Process (PDP) Working Group is working on the next generation of WHOIS, which includes privacy requirements. The outcome of this PDP will be the long-term solution to ensure consistency with the GDPR as well as other local data privacy laws. If you are interested in participating in the Registration Directory Services PDP, or follow the progress of the Working Group, please visit their wiki page.

We also have heard that you want to understand what the ICANN org is doing to make sure it complies with the new regulation. We continue to assess the data we collect from internal and external sources as we determine how to comply with the GDPR as an organization. This includes data from community members such as statements of interest, funded traveler requests and other non-registration information. We will continue to apprise the community of our efforts on our Data Protection/Privacy Issues page, just as we know that many of you are already working on your own efforts to address compliance with the law, just like ICANN org.

What's Next

Here's where we are now:

  • At ICANN60, we listened to the discussions and captured questions that were posed by the community. We will provide these questions, along with questions based on our own understanding of the issues, to Hamilton to help inform the next iteration of the legal analysis [PDF, 253 KB]. As a part of this, we will ask Hamilton to tailor and supplement the questions as needed to help ensure the scope of the analysis is appropriate. A list of those questions is published here.

    As noted above, we anticipate that the next phase of the Hamilton analysis will help clarify possible models for compliance by all parties.

  • As noted in the contractual compliance statement, we strongly encourage contracted parties to submit their models so we can also share them with Hamilton to incorporate in their follow-up legal analysis. Other stakeholders in the community may also propose models to be considered as part of the discussion.

    This feedback is essential to helping inform next steps and how to move forward, including finding a model or models that fulfill obligations for both the GDPR and ICANN compliance. We will provide additional information including detailed guidance regarding the process and eligibility as it evolves. To submit a model, email globalsupport@icann.org.

    On a related note, we are encouraged to know that various contracted parties are discussing the possibility of aligning models prior to submission. We commend this effort. Fewer models will ease the impact on end-users and operational processes for all of us including the contracted parties themselves.

  • We will continue to engage with the multistakeholder community, data protection authorities, and other parties including law enforcement and the intellectual property community.

In closing, we understand that there is more work to be done, including understanding the precise impact of the GDPR on ICANN's contracts. Let's keep the lines of communication open and work together towards a solution.

Comments

    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""icann.org"" is not an IDN."