Skip to main content

Data Protection/Privacy Update: Seeking Community Feedback on Proposed Unified Access Model

Gdpr 3126x1767 18jun18 en

Today we’re sharing for discussion the draft Framework Elements for a Unified Access Model for Continued Access to Full WHOIS Data [PDF, 93 KB]. At a high-level, it provides a process for how third parties may access non-public WHOIS data.

I also want to take this opportunity to thank the ICANN community for their hard work and valuable inputs that led us to the adoption of the Temporary Specification for gTLD Registration Data (Temp Spec). The European Data Protection Board (EDPB) also recognized these community efforts and said it “expects ICANN to develop and implement a WHOIS model which will enable legitimate uses by relevant stakeholders, such as law enforcement, of personal data concerning registrants in compliance with the GDPR, without leading to an unlimited publication of those data.” Just as we all worked together to agree on tiered/layered access, which is a major change to the WHOIS services, your contributions here will help us shape this model.

The EDPB also said that it “may engage further with ICANN to ensure that the legal requirements under EU data protection law are properly addressed.” We note the importance of community collaboration as we seek this legal certainty. The ICANN Board of Directors, in the Temp Spec, encouraged continued community work “to develop an accreditation and access model that complies with GDPR.” To further these community discussions, we have also published a chart [PDF, 90 KB] comparing our draft framework elements against those of two models proposed by ICANN community members.

The framework lays out a series of central questions to help frame discussions about how such a model may work, including how and which users with a legitimate purpose, as defined by the law, can gain access to non-public registration data. It builds on the “Calzone Model” (Attachment 2), the Temp Spec, and also incorporates ideas from community members and relevant data protection authorities. This proposed unified access model would provide transparency, uniformity, and most importantly foster discussions that may increase legal certainty and simplify the process for all parties.

Because access to non-public registration data is a public policy concern, and public policy is in the purview of governments, ICANN org’s proposal is to start by engaging with governments in the European Economic Area, which are also members of the Governmental Advisory Committee (GAC). Some of the questions to be discussed with governments include how law enforcement, individual users and other private third parties would be authenticated to access non-public registration data. There remain open questions on this and other issues for which we welcome your input. For example, the scope of data an eligible user group would have access to may be limited to only the fields a user requires, or the full WHOIS record for a particular query.

In addition to sharing this framework with the community, we intend to discuss it with the EDPB to ensure the model is compliant with the European Union’s General Data Protection Regulation (GDPR).

The community has also raised questions about this draft model and other related activities. I want to note that developing a unified access model has been part of our conversations regarding the GDPR from the start, including an approach outlined in both the Calzone and the Cookbook. Part of ICANN org’s role is to facilitate discussions with the data protection authorities (DPAs) to confirm, where possible, that the community’s consensus policy is compliant with the GDPR. ICANN continues to maintain a high level of transparency relating to our role. Our community conversations on these issues will help guide our discussions with the DPAs and we will continue to document these discussions.

I encourage you to review the proposed unified access model and participate in community discussions on this topic, including at ICANN62, where there will be several sessions related to the GDPR and the Temp Spec.  In addition, you can provide your feedback via email to gdpr@icann.org. Be sure to visit our Data Protection/Privacy page for regular updates and an overview of our activities in this area.

Comments

    Volker Greimann  01:23 UTC on 20 June 2018

    Thank you for providing an opportunity to comment on the Unified Access Model Framework. I cannot help but wonder if this top-down approach is the new policy making model for ICANN? Will community input into new policy be reduced to public comments in the future for all topics ICANN Org deems important or urgent enough? Such a model needs to be developed by the entire community with consultation by legal and privacy experts over the course of a fully chartered PDP or ePDP WG, not by ICANN staff. There also is no immediate urgency for the staff-led development of such a model as the currently effective Temporary Specification already requires contracted parties to provide access to parties with legitimate interests. Further, observation of data access requests at multiple registrars suggests a lower than expected volume of such requests since the effective date of the GDPR. Across our affiliated registrars, there have been 11 such requests since May 25. The proposed framework is also deeply flawed as it is based on a legitimate user concept instead of a legitimate interest requirement. In other words, once a user is identified as legitimate, that user would gain access in accordance with its access levels, regardless of whether a legitimate interest to access a certain individual data set is present or not or whether the transfer of data to such a user is legitimate from a data transfer perspective. Such a trust-based system relying solely on a Code of Conduct is not in compliance with the GDPR, which requires a legitimate interest for each individual request. The implementation of such a new system across contracted parties, many of which have already built their own systems and processes, is also a non-trivial undertaking. At current request levels it also appears to add significant costs for little added benefit. Before this is undertaken, we should first look at whether there actually is a need. So far, observed request levels have been low.

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