Skip to main content

Data protection/privacy issues: ICANN63 wrap-up and next steps

Gdpr icann63 wrap up 3125x1771 08nov18 en

With ICANN63 now behind us, I want to take this opportunity to provide an overview of some of the important discussions and feedback we received at the meeting. I would also like to share with you some next steps as they relate to continued work to seek guidance and clarity for a possible unified access model for third parties with legitimate interests to request and receive non-public registration data. We are also looking forward to sharing with you the next steps on the formation of a technical study group to explore how to operationalize a possible access model. This input will be key to continue conversations with the European Commission and European data protection authorities (DPAs), as we seek to diminish the legal risks associated with the European Union's General Data Protection Regulation (GDPR) for ICANN's contracted parties.

Before providing these updates, though, I want to thank the community for its feedback and constructive input during the ICANN63 meeting in Barcelona via multiple correspondence, the two public forums and many other sessions. Many of you expressed support as ICANN continues to explore a possible unified access model, with a particular goal of diminishing the legal risks for contracted parties. In particular, we heard a general acceptance and shared goal that there is benefit to all stakeholders to determine whether a model is feasible, while also diminishing the legal risk for contracted parties. Our plan is to build on a possible model taking into account the community feedback in order to continue our discussions with DPAs and to ensure that any model is in compliance with the law. We will continue engaging with the European Data Protection Board (EDPB) to seek guidance and clarity. It is also important to note that this work is not intended to replace the multistakeholder policy development process, but to inform it.

As the community makes progress in its discussion, we are also moving forward with an idea I raised during the first public forum at ICANN63. I have asked Ram Mohan, as the former Security and Stability Advisory Committee liaison to the ICANN Board, to coordinate a technical study group that will focus on exploring technical solutions for providing access to non-public registration data. The group will be supported by John Crain, ICANN Chief Security, Stability and Resiliency Officer, and Francisco Arias, Senior Director of Technical Services for the Global Domains Divisions (GDD). Technical representatives from registries and registrars with expertise in RDAP and authentication/authorization technologies will be invited to participate. We will share more information on this group as it forms.

The work of this group will help to inform our ongoing discussions with the European DPAs, including the EDPB. We plan to continue this dialogue with the aim of determining whether any of the proposed technical solutions are in line with the GDPR.

Finally, I will note here that on 6 November the ICANN Board reaffirmed the Temporary Specification for gTLD Registration Data for another 90 days from 21 November 2018, in line with the procedures for Temporary Policies as outlined in the Registry Agreement and the Registrar Accreditation Agreement. The Temporary Specification will continue to remain in effect until the Board again considers its reaffirmation.

As always, I urge you to remain engaged in the conversation about these important issues. Please feel free to share your ideas or questions with us at gdpr@icann.org and to follow the latest developments on our Data Protection/Privacy Issues page.

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