Diploma Thesis
to be awarded the degree of Magister Juris at the University of Graz, Austria
submitted by Ing. Matthias Markus Hudobnik
Name of the supervisor: Univ.-Prof. i.R. Mag. Dr. Wolfgang Benedek Department: Institute of International Law and International Relations
Graz, June 2019
Authors Declaration Unless otherwise indicated in the text or references, or acknowledged above, this diploma thesis is entirely the product of my own scholarly work. Any inaccuracies of fact or faults in reasoning are my own and accordingly I take full responsibility. This thesis has not been submitted either in whole or part, for a degree at this or any other university or institution. This is to certify that the printed version is equivalent to the submitted electronic one.
______Ing. Matthias Markus Hudobnik Graz, June 2019 Preface and Acknowledgements
The idea to write about WHOIS1 and the GDPR started in March 2017 during my participation in the NextGen@ICANN program at the ICANN58 meeting in Copenhagen, where I was first confronted with this topic. I have remained interested ever since. Subsequently I participated in further meetings: as a Fellow in the European Dialogue on Internet Governance (EuroDIG) 2017 in Tallinn and the 11th European Summer School on Internet Governance (EuroSSIG) in Meissen; as an Ambassador in the NextGen@ICANN60 program in Abu Dhabi; as a Fellow in the EuroDIG 2018 in Tbilisi, as well as the ICANN63 meeting in Barcelona, and the RIPE77 meeting in Amsterdam. Furthermore, I have joined all the relevant working groups and mailing lists, and also participated in ICANN’s GDPR webinars, as well as ICANN’s online courses to get a wealth of insight into this complex policy process within the Internet ecosystem. In June 2019, I will present a paper relating to my diploma thesis about the future of WHOIS, at the 34th International Conference on ICT Systems Security and Privacy Protection in Lisbon.
First of all, I would like to express my sincere gratitude to Univ.-Prof. i.R. Mag. Dr. Wolfgang Benedek for being my supervisor and supporter for many years. His professional guidance, passion, patience, and immense knowledge have been a tremendous support through my personal journey.
Besides my supervisor, I would like to thank Matthias C. Kettemann for questioning my ideas, providing constructive feedback, and pushing me forward. It has been a great honor and pleasure discussing Internet Governance issues with him!
I also would like to thank Clément Genty, not only for the strong connection, but also for his useful feedback, the numerous talks, and discussions about Internet Governance and important topics beyond as well as my dudes from the GFW & Könige – I love you guys!
A special thank you goes to Jess including M & D for always enduring my moods, nagging and providing me with both feedback and moral support over the course of drafting this diploma thesis. Talking with her about matters related to the topic of this diploma thesis helped me immensely to keep on track, and she always found time to proof-read my thesis and gave me valuable feedback. Thank you so much for everything!
Last but certainly not least, I would like to thank my family. Your endless love and support have made me who I am today!
1 Is pronounced as ‘who is’ e. g., the domain holder or in charge of it and is not seen as an ‘acronym.’ Table of contents 1 Introduction ...... 1
1.1 Outline of the diploma thesis ...... 3
1.2 Methodology of the diploma thesis ...... 3
2 Definitions and background ...... 5
2.1 What is ICANN? ...... 5
2.2 What is the WHOIS system? ...... 6
2.2.1 History ...... 8
2.2.2 Technical overview ...... 12
2.2.3 Policy agreements ...... 13
2.3 Definitions of the parties involved ...... 16
2.3.1 Generic Top-Level Domain registry operator ...... 17
2.3.2 Registrar ...... 18
2.3.3 Registrant...... 18
2.3.4 Reseller ...... 18
2.3.5 Internet Corporation for Assigned Names and Numbers ...... 18
2.3.6 Registry/Registrar Data Escrow Agent ...... 18
2.3.7 Emergency Back-End Registry Operator ...... 19
3 Description and application of the General Data Protection Regulation ...... 19
3.1 General provisions and principles ...... 19
3.1.1 Territorial scope ...... 19
3.1.2 Definitions of various terms ...... 20
3.1.3 Data processing principles ...... 21
3.1.4 Legal grounds and lawfulness of processing ...... 22
3.2 European Data Protection Board/Article 29 Data Protection Working Party ...... 24
4 Compliance Models ...... 25
4.1 GDPR Compliance Models and community input ...... 25
4.1.1 Data collection, processing, and retention ...... 26
4.1.2 Scope of applicability ...... 32
4.1.3 Layered/tiered access to public WHOIS data ...... 34
______i 4.1.4 Layered/tiered access to non-public WHOIS data ...... 40
4.1.5 Conclusion ...... 44
4.2 Temporary Specification for gTLD Registration Data ...... 49
4.2.1 Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data ...... 52
4.2.2 Conclusion ...... 61
5 Case, ICANN v. EPAG Domainservices GmbH ...... 64
5.1 ICANN’s Motion for the Issuance of a Preliminary Injunction ...... 64
5.1.1 EPAG’s protective letter ...... 68
5.2 Court Order from the Regional Court of Bonn on Application for Preliminary Injunction 70
5.3 ICANN’s Immediate Appeal ...... 72
5.3.1 Lawfully collection of Admin-C and Tech-C data as well as lack of obligation to collect personal data ...... 72
5.3.2 Lawfully collection of Admin-C and Tech-C data even if it is personal data ...... 73
5.3.3 EPAG’s Comments on ICANN’s Immediate Appeal ...... 77
5.4 Court Order from the Regional Court of Bonn in the Preliminary Injunction Proceedings ...... 83
5.5 ICANN’s Supplemental Submission to the Higher Regional Court of Cologne ...... 84
5.5.1 EPAG’s Comments on ICANN’s Supplemental Submission ...... 87
5.6 Order from the Higher Regional Court of Cologne Regarding ICANN’s Immediate Appeal 88
5.7 ICANN’s Plea of Remonstrance ...... 89
5.7.1 EPAG’s Comments on ICANN’s Plea of Remonstrance ...... 90
5.8 Order from the Higher Regional Court of Cologne Regarding ICANN’s Plea of Remonstrance ...... 92
5.9 Conclusion ...... 93
5.9.1 Is the further collection and storage of personal data - of the administrative and technical contact so-called Admin-C and Tech-C - besides the data of the registrant as stipulated via the 2013 RAA, lawful under the GDPR? ...... 94
5.9.2 Are the processing purposes in the Temp Spec for the data of the Admin-C and Tech-C sufficiently specified? ...... 95
______ii 6 General conclusion and outlook ...... 96
Bibliography ...... i
Primary Sources ...... i
Table of legal frameworks, agreements, resolutions, and recommendations ...... i
Table of cases ...... ii
Secondary Sources ...... iii
Books ...... iii
Background papers, research papers, and working papers ...... iv
Other sources and documents ...... ix
______iii Table of figures Figure 1: A DNS-tree example of www.hudobnik.at...... 5 Figure 2: The four nodes and the ARPANET in December 1969 ...... 8 Figure 3: The ARPANET in June 1970 ...... 9 Figure 4: The ARPANET in March 1972 ...... 9 Figure 5: The ARPANET in July 1977 ...... 9 Figure 6: Logical map of the ARPANET in March 1977 ...... 10 Figure 7: A simple WHOIS query structured in four stages...... 13 Figure 8: The principal journey of data and the involved parties...... 17 Figure 9: Domain name registration process and the involved parties...... 17 Figure 10: Overview of the different GDPR Compliance Models ...... 26
______iv Table of tables Table 1: Data collection, processing, and retention ...... 27 Table 2: Scope of applicability ...... 32 Table 3: Public WHOIS...... 35 Table 4: Non-Public WHOIS ...... 41 Table 5: Calzone Model v. Temp Spec ...... 50 Table 6: Recommendation 5, the registrars collected data elements ...... 54 Table 7: Recommendation 7, transfer of data elements from registrar to registry ...... 55 Table 8: Recommendation 8, transfer registrars to the data escrow agent ...... 56 Table 9: Recommendation 8, transfer registries to the data escrow agent ...... 56 Table 10: Recommendation 10, requirements for processing personal data in public RDDS .. 57 Table 11: Recommendation 20, purposes, processing activities, parties, and lawful basis ..... 58
______v List of Abbreviations AFRINIC African Network Information Centre ALAC At-Large Advisory Committee APNIC Asia Pacific Network Information Centre APWG Anti-Phishing Working Group ARIN American Registry for Internet Numbers ARPANET Advanced Research Projects Agency Network ASN Autonomous System Numbers BC Business Constituency ccTLDs country code Top-Level Domains CNNIC China Internet Network Information Center DEA Data Escrow Agent DNS Domain Name System DNSSEC Domain Name System Security Extensions DPA Data Protection Authority EBERO Emergency Back-end Registry Operator EC European Commission EDPB European Data Protection Board EDPS European Data Protection Supervisor EEA European Economic Area EPDP Expedited Policy Development Process EuroDIG European Dialogue on Internet Governance EuroSSIG European Summer School on Internet Governance gTLDs generic Top-Level Domains GAC Governmental Advisory Committee GDPR General Data Protection Regulation GNSO Generic Names Supporting Organization HTTP(S) Hypertext Transfer Protocol (Secure) IANA Internet Assigned Numbers Authority ICANN Internet Corporation for Assigned Names and Numbers IETF Internet Engineering Task Force IP Internet Protocol IPC Intellectual Property Constituency IRT Implementation Review Team IWGDPT International Working Group on Data Protection in Telecommunications LACNIC Latin American and Caribbean Network Information Centre NTIA National Telecommunications and Information Administration, United States Department of Commerce
______vi NSI Network Solutions Inc. RA Registry Agreement 2013 RAA 2013 Registrar Accreditation Agreement RDDS Registration Data Directory Services RFC Request For Comments RIPE NCC Réseaux IP Européens Network Coordination Centre RIR Regional Internet Registry RDAP Registration Data Access Protocol RNAP Restored Name Accuracy Policy SRI-NIC Stanford Research Institute - Network Information Center TDRP Transfer Dispute Resolution Policy Temp Spec Temporary Specification for gTLD Registration Data TLDs Top-Level Domains TTCI Translation and Transliteration of Contact Information TWPD Thick WHOIS Policy Development UDRP Uniform Domain Name Dispute Resolution Policy WDRP WHOIS Data Reminder Policy WMRP WHOIS Marketing Restriction Policy WP29 Article 29 Data Protection Working Party WWW World Wide Web
______vii
1 Introduction 2019 marks the 30th anniversary of the Internet, and without doubt, the Internet has become an impactful and influential medium in the context of social and economic changes worldwide, with a user increase of nearly 900 percent, from 400 million in 2000 to more than 4 billion today.2 The reason that a user reaches a website on the Internet is the globally-unique address, and the standardized technical communication between the Internet devices via the Internet protocol suite (e. g., application, transport, Internet and link layer).3 In short, the Internet Protocol (IP) is in the Internet layer; the Transmission Control Protocol (TCP) is in the transport layer; and the Domain Name System (DNS) is in the application protocol layer. In a nutshell, the DNS is crucial in order to translate domain names into IP addresses and vice versa. Thus, IP addresses identify an Internet device e. g., a computer on the Internet and are necessary to find websites, but these IP addresses are inconvenient to remember and are not personalized. The result was the establishment of the DNS as a name structure.4 The WHOIS protocol is a “TCP-based transaction-oriented query/response protocol that is widely used to provide information services to Internet users,”5 including inter alia, personal information of registered domain names. Previously, the public WHOIS databases were a primary instrument for personal information gathering across different professions (e. g., journalists, law enforcement agencies, IP rights holders, and cyber security researchers/investigators) and for various reasons. Currently, data protection laws have become more public and influential in the debate over the regulation of the Internet, not least because of the increased effort at a European level, through the General Data Protection Regulation (GDPR). Previously, the general publication of the personal information of registered domain names in the public WHOIS databases was common practice, but since the GDPR came into force on 25 May 2018, this practice has become unlawful. The main aim of this diploma thesis is to assess the legal challenges under the GDPR concerning the registration directory services for generic top-level domains (gTLDs), the so- called WHOIS databases and the present WHOIS database Policy Development Process. The Internet Corporation for Assigned Names and Numbers (ICANN), gTLD registry operators, and registrars offer services through domain registration, WHOIS lookup services, and domain- name dispute settlement mechanisms to subjects in the European Union and are either individual or joint data controllers or processors. However, the GDPR also applies to controllers and processors who are not established in the European Union when their data processing activities are related to “(a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or (b) the
2 Cf Internet Society, ‘Global Internet Report 2019’, pp. 13-14, available at
6 See Art.3 (2) lit. a) and b) of the Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), 33, available at
1.1 Outline of the diploma thesis In addition to the introduction, this diploma thesis is divided into five major parts. The chapter- structure is bottom-up and content-based. The starting point is the theoretical part e. g., the relevant definitions, and background to the more complex practical issues of the Compliance Models in conjunction with the related legal questions of the policy documents and the lawsuit. Chapter 2 will explain essential backgrounds e. g., ICANN’s mission and purpose, “to ensure a stable, secure, and unified global Internet.”7 Furthermore, it will clarify the WHOIS system, its history, technical overview, usage, and policies. Moreover, it will describe the essential parties in the Internet ecosystem e. g., what a registry operator and registrar is, as well as registrant, reseller, ICANN, data escrow agent, and EBERO. Chapter 3 will cover the application of the GDPR, the general provisions, and principles and the role of the Article 29 Data Protection Working Party, which is the present European Data Protection Board. Chapter 4 will address the different legal analyses and Compliance Models of the various community stakeholders in the multistakeholder ecosystem of ICANN, and will highlight their advantages and disadvantages. Also, it will explore the following policy documents: the Temporary Specification for gTLD Registration and the Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data. Chapter 5 will comment on the current legal litigation between ICANN and the German registrar EPAG Domainservices GmbH, where ICANN asked the court for assistance in interpreting the GDPR concerning ICANN’s agreements with the registrar. ICANN filed legal action to preserve the WHOIS data collection, so that such data is still available to parties that demonstrate legitimate reasons to access it. Finally, the diploma thesis will draw a line between the Compliance Models, the EPDP on the Temp Spec and the litigation, and will give an outlook based on the current EPDP on the Temp Spec. Finally, the author will refer to the three hypotheses and demonstrate whether they are fulfilled or not, and will debate future issues related to this topic.
1.2 Methodology of the diploma thesis This diploma thesis analyzes the current WHOIS directory Policy Development Process under the GDPR and presents the key arguments and parties involved. The primary resources are the policy documents of various stakeholder groups in the context of the WHOIS system, that were involved in the Policy Development Process, available on ICANN’s website. Thus, the Policy Development Process of the WHOIS directory services is still ongoing. Therefore, the present diploma thesis does not claim to be exhaustive in terms of the content and structure of the
7 See ICANN, ‘Welcome to ICANN!’, available at
______Matthias Markus Hudobnik 3
______Matthias Markus Hudobnik 4
2 Definitions and background In order to recognize the WHOIS system as a whole, it is essential to know some of the background and the definitions beforehand. Firstly, this chapter explains ICANN’s mission and purposes as well as some historical milestones of the organization itself. Secondly, it declares the WHOIS system as a whole, including the history, technical overview, and the crucial policy agreements related to it. Thirdly, it defines the essential involved parties in the Internet ecosystem, namely registry operator, registrar, registrant, reseller, ICANN, data escrow agent, and EBERO.
2.1 What is ICANN? Nowadays, the Internet Corporation for Assigned Names and Numbers (ICANN) has become fundamental in the Internet ecosystem for the Internet’s stability, security, as well as the coordination and support of the Internet’s unique identifiers e. g., names and numbers to find anyone on the Internet.8 ICANN’s mission plays a vital role in supporting and promoting the consensus-based bottom-up policy process overall Internet communities in the various stakeholder groups.9 ICANN, a worldwide multistakeholder organization, was established in 1998 by the Department of Commerce National Telecommunications and Information Administration (NTIA).10 The internationally structured and not-for-profit corporation has various tasks e. g., the management of generic (dot com, dot info, dot org, dot net) and country code (dot at, dot de, dot fr, dot nl) Top-Level Domains including the management of the Domain Name System (DNS) Root Server functions, address space allocation for the Internet Protocol, and protocol identifier assignment. The nature of the DNS is to convert the typed-in domain name into an Internet Protocol (IP) address.11
Figure 1: A DNS-tree example of www.hudobnik.at.
8 Cf ICANN, ‘Welcome to ICANN!’ (n 7). 9 Cf ICANN Archive, ‘ICANN | Archives’, available at
Until March 2014, the NTIA was contractually bound by Internet Assigned Numbers Authority (IANA) and their related bodies to maintain these critical technical capabilities.12 The essential IANA functions are the DNS root zone management, the protocol registries, the allocation of IP addresses and the Autonomous System Numbers (ASN) in the form of blocks to the Regional Internet Registries (RIRs). They are e. g., American Registry for Internet Numbers (ARIN), Réseaux IP Européens Network Coordination Centre (RIPE NCC), Asia Pacific Network Information Centre (APNIC), Latin America and Caribbean Network Information Centre (LACNIC), and African Network Information Centre (AFRINIC).13 In the history of ICANN, the IANA functions transitions to the global Internet community by not renewing the contract obligations with NTIA on 30 September 2016 have been thought of as a significant factor and strong statement for improving the multistakeholder model.14 Central to the transitions is the fact that ICANN is globally, and solely, coordinating the DNS as well as being the only contractor of the IANA functions and organization to foster the multistakeholder model of the various global stakeholders.15 Even so, the reformation of the WHOIS system under the GDPR has received considerable attention and critical discussions within the community. This consideration could be seen as another milestone in the history of ICANN when the ongoing Policy Development Process will be accomplished in the future. ICANN organization has assessed the potential impacts of the GDPR based on their bylaws with the global stakeholder community and their contracted parties, including registries and registrars. The main aspects reviewed are: the purposes of the processing, displaying, and retention of the registrant’s data in the WHOIS directory services and different Compliance Models.16
2.2 What is the WHOIS system? The term WHOIS (means also Who is?) is widely associated with various services e. g., the WHOIS protocol for network-exchange via client and server or the common WHOIS databases of registries or registrars or the collection and processing of WHOIS data of registrants by registries and registrars under ICANN’s agreements.17 This subchapter focuses on the WHOIS registration directory services as a whole, which are utilized to query databases in order to gain information about the registration of a domain name and other information regarding the domain holder.18 In short, the registrant of the
12 Cf NTIA Office of Public Affairs, ‘NTIA Announces Intent to Transition Key Internet Domain Name Functions’, available at
19 Cf ibid. 20 Cf ICANN WHOIS, ‘Technical Overview’, available at
Board reaffirmed the Temporary Specification for a fourth time, which is required every 90 days, stated in the RA and 2013 RAA until the process of adopting final policies is finished.27 However, these rapid changes based on the GDPR are having a severe effect on ICANN’s contractual compliance with registries and registrars under their existing consensus policies and agreements.28
2.2.1 History
In December 1969, the US Department of Defense’s Advanced Research Projects Agency (ARPA) connected four computer network nodes, the so-called ‘ARPANET’ at the University of California, the Stanford Research Institute, the UC Santa Barbara, and the University of Utah.29
Figure 2: The four nodes30 and the ARPANET in December 196931
27 Cf ICANN, ‘ICANN Board Reaffirms Temporary Specification for gTLD Registration Data’, available at
Figure 3: The ARPANET in June 197032
Figure 4: The ARPANET in March 197233
Figure 5: The ARPANET in July 197734
32 See ibid. 33 See Fibel, ‘ARPANET’, available at
Figure 6: Logical map of the ARPANET in March 197735
At this time, the ‘Internet’ (ARPANET) consisted merely of multi-user mainframes or mini- computers operated by the universities or research institutions interconnected with dedicated telecom lines to each other. Therefore, all users in this minor network knew each other, and there was no necessity for a database to preserve contact information e. g., names, telephone numbers, and postal addresses. The researchers themselves wrote these details more or less on a paper or spreadsheet. One of the main obstacles of this early stage was the frequent loss of connectivity as outages, which were easily solvable by looking up in the list of network users and initiating a telephone call to solve the connectivity problems. As the graphic above shows, the network grew rapidly in 1977, but academia and research institutions still dominated it; furthermore, connectivity problems were still prominent. As a result, there was a mitigation process of the devices in the network from IP addresses to hostnames, where each specific device related to a hostname.36 This circumstance led to challenges in preserving the contact information of all users with the previous contact information system.37 The result of this was the development of a reverse telephone book maintained by the Stanford Research Institute - Network Information Center (SRI-NIC) which translated the received IP address - which contained of the source and
35 See Computerhope, ‘ARPANET LOGICAL MAP, March 1977’, available at
38 Cf Conrad, ‘What is Whois’ (n 36) 6. 39 See Ken Harrenstien and Vic White, ‘RFC 812 - NICNAME/WHOIS’, 1 March 1982, available at
2.2.2 Technical overview
Chapter 2.2 illustrates the general explanation of the WHOIS system itself. As previously described in Chapter 2.2.1 the WHOIS protocol is a client-server query-response protocol initially established in RFC 812 as “NCP/TCP transaction based query/response server, running on the SRI-NIC machine, that provides netwide directory service to ARPANET users”46 in 1982 and updated in RFC 954 in 1985.47 A key aspect in the context of the WHOIS service is that it is commonly classified into four categories: clients, servers, databases, and registration data.48 It is noteworthy that the WHOIS service is often spuriously seen as a single central maintained database, which is wrong.49 In fact, the domain name system includes approximately 2,500 different WHOIS databases in various locations stored with WHOIS registration data administered via multiple autonomous parties (e. g., registries and registrars) linked to the WHOIS protocol finally updated in RFC 3912 as “TCP-based transaction-oriented query/response protocol that is widely used to provide information services to Internet users”50 in 2004.51 These WHOIS databases are divided into several groups of databases: a) WHOIS databases for the root zone, b) WHOIS databases related to TLDs and, c) WHOIS databases related to second-level domains where their distribution is done by the DNS namespace via a hierarchical order.52 For the sake of completeness, it should be mentioned here that the category of distributed databases of IP addresses and autonomous system numbers are principally operated by the RIRs, not directly related to the WHOIS databases of the domain name system and out of the scope of this subchapter. There are several significant distinctions in the WHOIS databases to make: Firstly, there are a) the WHOIS databases for the root zone and, b) the WHOIS databases related to the TLDs.53 The WHOIS databases for the root zone contains the referral contact information of the Top-Level Domain names. The WHOIS databases related to the TLDs can be divided into the category of ccTLDs, where ccTLD-operators maintain the databases under the national policies without any impact of ICANN and gTLDs.54 In terms of the gTLDs, the registries and registrars are contractually bound by ICANN to make a specific set of registration data available in the WHOIS databases. Secondly, the WHOIS databases provide two types of WHOIS registration data information: a) technical information
45 Cf Verisign, ‘The Verisign Domain Name Industry Brief’, Q1 2019, available at
(e. g., name of the name servers, IP addresses, necessary information for Domain Name System Security Extensions (DNSSEC), the general domain name information as the date of creation, modification and expiry, and the name of the registrar which retains the domain name from the registry), b) registrants contact information (e. g., commonly the administrative and technical contact information related to the supporting registrar and the registration status information).55 This system of classification provides a basis for ‘thin’ and ‘thick’ WHOIS registries.56 In the world of gTLDs, thin registry data only consist of the technical information and only refer to the registrar who operates the (registrants) contact information data, (e. g., dot com and dot net) while thick registry includes the technical and the (registrants) contact information data. Examples of this classification are dot info and dot biz. Since the GDPR came into force, the model of the thick WHOIS registries is undergoing a redacting process.57
Figure 7: A simple WHOIS query structured in four stages.58
2.2.3 Policy agreements
Nowadays, the amount of policy documents related to the WHOIS service is tremendously high. The most significant documents are: WHOIS Data Reminder Policy (WDRP), The Restored Name Accuracy Policy (RNAP), WHOIS Marketing Restriction Policy (WMRP), Thick WHOIS Policy Development (TWPD), Translation and Transliteration of Contact Information (TTCI), ICANN Procedure for Handling WHOIS Conflicts with Privacy Law, Registry Agreements, Registrar Agreements, Registrar Advisories, 2013 RAA - Registrant Benefits and Responsibilities. The author will very briefly discuss the essential WHOIS policy agreements and will go into depth when essential to the topic of this diploma thesis and the litigation ICANN v. EPAG.59 Nevertheless, the ICANN Board adopted Temporary Specification for gTLD Registration Data and the Expedited Policy Development Process (EPDP) Team on the
55 Cf ICANN, ‘Technical Overview’ (n 20). Cf also ICANN WHOIS, ‘What are thick and thin entries?’, available at
Temporary Specification for gTLD Registration Data (Temp Spec) started their first meeting in August 2018 to finalize a particular policy document for the existing WHOIS service to be compliant with the GDPR.60
2.2.3.1 Registry Agreement The term Registry Agreement (RA) refers to any agreement between registry operators of gTLDs over their rights and obligations and ICANN. In July 2017, the RA was updated due to some changes to the 2017 Global Amendment to the Base New gTLD Registry Agreement.61 Under the RA, registries are obliged to store registration data of the registrants and make this domain name registration data openly available in the WHOIS databases. These contracted parties, mostly registrars under the 2013 RAA but also registries under the RA that are processing and collecting personal data of registrants, need to be compliant with the consent requirements of the GDPR.62 The requirement for consent is the obligation of the gTLD registry operator to the registrar to receive the particular publication-consent of the registrant to make the registration data publicly available in the WHOIS database. For the sake of completeness, the EDPB’s/WP29’s list of general concerns in terms of the unlimited publication of the domain name registration data in the WHOIS databases will be discussed in Chapter 2.2.3.2 and the litigation related issues of the case ICANN v. EPAG in Chapter 5.63 For the aim of GDPR conformity, the ICANN Board adopted Temporary Specification for gTLD Registration Data, which apply to all gTLD registry operators, to modify and in some particular circumstances to replace the existing requirements of the RA which are not in line with the GDPR. Without this modification process of the RA, gTLD registry operators would neither be compliant with ICANN’s contractual obligations nor the GDPR. As a result, this would lead to instability and insecurity of the operation of the Internet as a whole and will be a risk of the DNS as well as will lead to a fragmentation of the worldwide WHOIS databases because of the specific in-house rules of each registry operator. In short, the following sections are essential for gTLD registry operator’s e. g., lawfulness and purposes of processing gTLD registration data, requirements applicable to registry operators and registrars and requirements applicable to registry operators only. Chapter 4.2 comprehensively analyzes the Temporary Specification for gTLD Registration Data requirements.64
60 Cf ICANN, ‘Keep Up with EPDP on the Temporary Specification for gTLD Registration Data’, available at
2.2.3.2 2013 Registrar Accreditation Agreement The term 2013 Registrar Accreditation Agreement (2013 RAA) refers to an agreement between accredited registrars over their rights and obligations and ICANN.65 Comparatively, under the 2013 RAA, the registrars are obliged to store registration data of the registrants. Furthermore, registrars make this domain name registration data - with the exception of anonymous WHOIS - openly available in the WHOIS databases and therefore need to be compliant with the consent requirements of the GDPR same as for the gTLD registry operators. Similarly, the consent requirement process, as above stated for gTLD registry operators under the RA.66 The author will briefly illuminate on the following two aspects of registrars under the 2013 RAA of a) the collection of domain name registration data, b) the unlimited publication of the domain name registration data in the WHOIS databases. Chapter 4 comprehensively analyzes further issues in this context. Before the litigation ICANN v. EPAG and the Temporary Specification for gTLD Registration Data came into force registrars were obligated under the 2013 RAA to collect as follows: 1. “The name of the registered name 2. The names of the primary name server and secondary name server(s) for the registered name 3. The identity of registrar (which may be provided through registrar’s website) 4. The original creation date of the registration 5. The expiration date of the registration 6. The name and postal address of the registered name holder 7. The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the registered name; and 8. The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the registered name”67 which is not GDPR-compliant to any further extent. This condition is also confirmed by German courts e. g., the Regional Court of Bonn and the Higher Regional Court of Cologne in the litigation named above.68 Furthermore, this result is also in line with the recommendations of the WP29/EDPB regarding the purpose specification
65 Cf ICANN, ‘Registry Agreement’ (n 61). 66 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) pp. 3-4. 67 See ICANN Board of Directors, ‘Section 3.3.1.1-8 of the 2013 Registrar Accreditation Agreement’, 27 June 2013, 7, available at
2.3 Definitions of the parties involved The main aim of this subchapter is to define the parties involved in a domain name registration process and their relevant stakeholders in the Internet ecosystem related to the topic of this diploma thesis.
69 Cf European Data Protection Board, ‘Letter from Andrea Jelinek to Göran Marby in reply to his 10 May 2018 letter’, 5 July 2018, pp. 2-3, available at
Figure 8: The principal journey of data and the involved parties.73
Figure 9: Domain name registration process and the involved parties.74
2.3.1 Generic Top-Level Domain registry operator
As ICANN defines the designation, a generic Top-Level domain (gTLD) registry operator is responsible for maintaining the Top-Level Domain (TLD)-database, supplying name servers to create the root zone file for the localization of the domain name, to facilitate the Internet routing process through the TLDs and handling registrant’s domain name services.75 There are also country code Top-Level Domain (ccTLD) registry operators (e. g., nic dot at, denic dot de) which are responsible for country code Top-Level Domains and are not under ICANN’s contractual obligations. Chapter 2.2.3.1 further explains the responsibilities of the (gTLD) registry operator under the Registry Agreement (RA).76
73 See Thomas Rickert and others, ‘GDPR Domain Industry Playbook’, V. 1.0, Eco Internet Industry Association, 11 January 2018, available at
2.3.2 Registrar
A (domain name) registrar is an under the 2013 Registrar Accreditation Agreement (2013 RAA) with ICANN, accredited (mostly) legal entity or individual person who is selling generic domain names and their registration service to registrants.77 The contractual obligation between the registrant and the registrar is determined in the registration contract between them. Chapter 2.2.3.2 further analyzes responsibilities of the registrars under the 2013 RAA.78
2.3.3 Registrant
ICANN’s definition of a (domain name) registrant is “a person or entity that holds the rights to a domain name”79 via the registration of this domain name. The registration procedure is feasible through the service of an accredited registrar or a reseller under their separate registration procedure policies so-called ‘Registration Agreement’ which is compulsory for the registrant and the accredited registrar.80 In exceptional cases, a registrant can also register a domain name through a registry operator (e. g., dot gl). This ‘Registration Agreement’ comprises rights and obligations for both parties e. g., all information rights for the domain holder related to the (registration of the) domain name itself, but also all information rights for the registrar of the domain holder information in a manner of integrity, actuality, and accuracy.81
2.3.4 Reseller
The term (domain name) reseller is a third party (mostly) a legal entity or individual person with no accreditation by ICANN, who is reselling domain name registration services via a contract with an (ICANN-accredited) registrar, but also other services e. g., web hosting, e-mail to an Internet user.82 The (ICANN-accredited) registrar is liable for the domain name sale of the reseller, but then again the reseller is contractually tied by the agreement with the registrar.83
2.3.5 Internet Corporation for Assigned Names and Numbers Chapter 2.1 provides details about ICANN.
2.3.6 Registry/Registrar Data Escrow Agent
The Data Escrow Agent (DEA) as a third party tied via an obligatory contractual agreement with ICANN (e. g., RA84 or 2013 RAA85) and a gTLD registry operator (e. g., registry data escrow) or a registrar (e. g., registrar data escrow) stores data for the eventuality of a gTLD registry operator
77 Cf ICANN, ‘Information for Registrars’, available at
2.3.7 Emergency Back-End Registry Operator
Since April 2016, there are three Emergency Back-End Registry Operator (EBERO) providers in contractual obligations with ICANN (e. g., CNNIC, CORE Internet Council of Registrars, and Nominet). They are established from the EBERO program within the new gTLD program because of the growing number of new gTLD registry operators. EBEROs are responsible for securing critical gTLD registry operator functions e. g., domain name registration services, in case of a gTLD registry operator breakdown to guarantee ICANN’s core mission of a secure and stable Internet.88
3 Description and application of the General Data Protection Regulation The main aim of this chapter is to assess the relevant Articles of the General Data Protection Regulation (GDPR) related to the involved parties of a domain name registration process and the topic of this thesis in general. Firstly, it explains the general provisions and principles of the GDPR, and secondly, it defines what the European Data Protection Board/Article 29 Data Protection Working Party is.
3.1 General provisions and principles
3.1.1 Territorial scope
The complete title is “Regulation (EU) 2016/679 of the EU Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation),”89 which is in effect in all EU member states regardless of any domestic legislation implementation - except for some member state level implementations - and entered into force on 25 May 2018. Both, the GDPR and the previous Directive 95/46/EC share several crucial aspects with the exemption of a stronger focus on protecting individual rights in general, as well as a more comprehensively sanction regime with severe penalties, and more specific roles in the context of rights and obligations for controllers, but also processors in the GDPR legislation.90 In contrast to the Directive 95/46/EC, the GDPR has no territorial limitation, since the applicability of the GDPR is based on the processing of personal data of EU residents independently of the location of the data controller or processor. Therefore any organization (e. g., registries or registrars offering services to natural persons
86 Cf ICANN Wiki, ‘Data Escrow’, available at
3.1.2 Definitions of various terms
Article 4 of the GDPR defines various necessary terms for the whole regulation and refers to the following articles: Personal data94 as defined in (1) leg cit. “means any information relating to an identified or identifiable natural person ‘data subject’; an identifiable natural person is one who can be identified, directly or indirectly, in particular, by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”95 e. g., the name and address of the natural person as registrant (previously) publicly available in the WHOIS database.96 Processing97 as defined in Article 4 (2) GDPR “means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise
91 Cf Ivan Klekovic, ‘EU GDPR vs. European data protection directive’, Advisera, EU GDPR Academy, 30 October 2017, available at
3.1.3 Data processing principles
Article 5 (1) lit. a) GDPR states that the processing of personal data must be107 “lawfully, fairly and in a transparent manner in relation to the data subject.”108 In accordance with b) leg cit.109 the collection of personal data shall be “for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes,”110 c) leg cit.111
98 See Article 4 (2) GDPR of the Regulation (EU) 2016/679 (n 6) 33. 99 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) 8. 100 Cf Thomas Petri, ‘Begriffsbestimmung „Verantwortlicher“’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 325-330. Cf also Klabunde, (n 94) pp. 177-178. Cf also Rücker, ‘Scope of application of the GDPR’ (n 94) pp. 24-30. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) pp. 21-24. 101 See Article 4 (7) of the Regulation (EU) 2016/679 (n 6) 33. 102 See Article 26 (1) of the Regulation (EU) 2016/679 (n 6) 48. 103 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) pp. 9-10. 104 Cf Thomas Petri, ‘Begriffsbestimmung „Auftragsverarbeiter“’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 330-331. Cf also Klabunde, ‘Begriffsbestimmungen’ (n 94) 178. Cf also Rücker, ‘Scope of application of the GDPR’ (n 94) pp. 30-36. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) 24. 105 See Article 4 (7) of the Regulation (EU) 2016/679 (n 6) 33. 106 See Article 28 (1) of the Regulation (EU) 2016/679 (n 6) 49. 107 Cf Roßnagel, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 97) pp. 369-375. Cf Horst Heberlein, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 192-193. Cf also Sebastian Dienst, ‘Lawful processing of personal data in companies under the GDPR’ in Daniel Rücker and Tobias Kugler, New European General Data Protection Regulation (1st edn, C.H.Beck, Hart, Nomos 2018) pp. 50-53. Cf also Voigt and Bussche, EU- Datenschutz-Grundverordnung (n 91) pp. 113-114. 108 See Article 5 of the Regulation (EU) 2016/679 (n 6) 35. 109 Cf Roßnagel, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 97) pp. 376-385. Cf also Heberlein, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 107) pp. 193-197. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) pp. 53- 65. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) pp. 115-116. 110 See Article 5 of the Regulation (EU) 2016/679 (n 6) 35. ______Matthias Markus Hudobnik 21
“adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed,”112 d) leg cit.113 “accurate and, where necessary, kept up to date,”114 e) leg cit.115 “kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed”116 and f) leg cit. the processing shall be ensured in an integrity and confidentiality manner.117 Under Article 5 (1) lit. c) GDPR and in the context of the WHOIS system, the question arises if the general publication of all registration data in the WHOIS databases is specified, explicit and necessary to the legitimate purpose. Furthermore, this processing needs to fulfill the principle of data minimization to be compliant with the GDPR, but this question in connection with the litigation ICANN v. EPAG is further discussed in Chapter 5.118
3.1.4 Legal grounds and lawfulness of processing
As stated above in Article 5 (1) lit. a) GDPR processing of personal data must be lawful, fair, and transparent; this might be the case and also permitted if at least one of the legal grounds stipulated in Article 6 (1) GDPR is applicable. In the context of the WHOIS system, the following conditions of Article 6 (1) GDPR are to be considered: a) consent, b) necessity for the performance of a contract, and f) legitimate interest.119 According to Article 6 (1) lit. a) GDPR, the data subject needs to give “consent to the processing of his or her personal data for one or more specific purposes”120 e. g., registrars are contractually obliged by ICANN to currently obtaining the consent from registrants of the domain name.121 The data processing based on the legal ground of consent is grounded on rigorous conditions defined in Article 7 GDPR.122 In accordance with (1) leg cit. “the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data,”123 and if the consent is given for e. g., as written arrangement “the request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible
111 Cf Roßnagel, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 97) pp. 386-389. Cf also Heberlein, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 107) pp. 197-198. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) pp. 65- 67. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) pp. 117-118. 112 See Article 5 of the Regulation (EU) 2016/679 (n 6) 35. 113 Cf Roßnagel, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 97) pp. 389-391. Cf also Heberlein, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 107) pp. 198-199. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) pp. 67- 69. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) 118. 114 See Article 5 of the Regulation (EU) 2016/679 (n 6) 35. 115 Cf Roßnagel, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 97) pp. 392-394. Cf also Heberlein, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 107) pp. 199-200. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) pp. 70- 72. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) pp. 118-119. 116 See Article 5 of the Regulation (EU) 2016/679 (n 6) 35. 117 Cf Article 5 of the Regulation (EU) 2016/679 (n 6) 35. Cf also Roßnagel, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 97) pp. 394-395. Cf also Heberlein, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 107) 200. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) 72. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) 119. 118 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) pp. 8-9. 119 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) pp. 8-10. 120 See Article 6 (1) lit. a) of the Regulation (EU) 2016/679 (n 6) 36. 121 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) 10. Cf also Peter Schanz, ‘Rechtmäßigkeit der Verarbeitung’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 404-407. Cf also Heberlein, ‘Rechtmäßigkeit der Verarbeitung’ (n 107) pp. 209-211. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) pp. 90-94. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) 126. 122 Cf Jan Hendrik Klement, ‘Bedingungen für die Einwilligung’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 555-563. Cf also Dirk Heckmann and Anne Paschke, ‘Bedingungen für die Einwilligung’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 250-251. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) 99. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) pp. 120-122. 123 See Article 7 (1) of the Regulation (EU) 2016/679 (n 6) 37. ______Matthias Markus Hudobnik 22
124 See Article 7 (2) of the Regulation (EU) 2016/679 (n 6) 37. 125 See Article 7 (3) of the Regulation (EU) 2016/679 (n 6) 37. 126 Cf Article 7 (3) of the Regulation (EU) 2016/679 (n 6) 37. 127 Cf Article 7 (4) of the Regulation (EU) 2016/679 (n 6) 37. 128 Cf Rickert and others, ‘GDPR Domain Industry Playbook’ (n 73) 11. 129 See Article 6 (1) of the Regulation (EU) 2016/679 (n 6) 36. 130 Cf Schanz, ‘Rechtmäßigkeit der Verarbeitung’ (n 121) pp. 407-415. Cf also Heberlein, ‘Rechtmäßigkeit der Verarbeitung’ (n 107) 212. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) pp. 77-78. Cf also Voigt and Bussche, EU-Datenschutz- Grundverordnung (n 91) pp. 130-131. 131 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) 11. 132 Cf Schanz, ‘Rechtmäßigkeit der Verarbeitung’ (n 121) pp. 421-428, 430, 431, 434. Cf also Heberlein, ‘Rechtmäßigkeit der Verarbeitung’ (n 107) pp. 215-220. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) pp. 82-90. Cf also Voigt and Bussche, EU- Datenschutz-Grundverordnung (n 91) pp. 132-137. 133 See Article 6 (1) of the Regulation (EU) 2016/679 (n 6) 36. 134 See (47) of the Regulation (EU) 2016/679 (n 6) 33. 135 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) 13. 136 Cf Article 21 (1) of the Regulation (EU) 2016/679 (n 6) 45. Cf also Johannes Caspar, ‘Allgemeines Widerspruchsrecht’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 696-699. Cf also Hans-Georg Kamann and Martin Braun, ‘Widerspruchsrecht’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 446-453. Cf also Joachim Schrey, ‘General conditions for data processing in companies under the GDPR’ in Daniel Rücker and Tobias Kugler, New European General Data Protection Regulation (1st edn, C.H.Beck, Hart, Nomos 2018) pp. 147-149. Cf also Voigt and Bussche, EU- Datenschutz-Grundverordnung (n 91) pp. 236-237. ______Matthias Markus Hudobnik 23
3.2 European Data Protection Board/Article 29 Data Protection Working Party As articulated in the EDPB-endorsement, the European Data Protection Board (EDPB) “is an independent body with legal personality, responsible for ensuring the consistent application of the GDPR”137 consisting of the European Data Protection Supervisor (EDPS) and the European Union member state data protection authority-officials, generally the head of the national Data Protection Authority (DPA). The national DPA in the respective member state itself undertakes the control of the compliance and the enforcement of the GDPR. The EDPB is regulated in Section 3 of the GDPR, and when the GDPR enters into force on 25 May 2018, the EDPB replaces the Article 29 Data Protection Working Party (WP29) and its areas of responsibility entirely. Over the last few years, the WP29 has played a significant advisory role for various parties in assisting them to be compliant with the GDPR and has composed guidelines on numerous GDPR-related issues (e. g., Opinion 03/2013 on purpose limitation (WP 203), Guidelines on the application and setting of administrative fines for the purposes of the Regulation 2016/679 (WP 253), Guidelines on Consent under Regulation 2016/679 (WP 259)).138 The same applies for the WHOIS system and ICANN’s policy process; the EDPB/WP29 plays a crucial advisory role in the consultation of the applicability of the GDPR in general, but also in terms of the interpretation of the legal principals in the framework of the WHOIS regime. However, EDPB’s guidelines leave no room for appeal and are not legally binding to the involved advising parties. Therefore, there is a factor of uncertainty with regards to these assumptions as a whole. Moreover, it is the decision of the domestic DPAs in the individual EU member states to interpret and enforce their GDPR compliant implemented domestic privacy laws in their respective countries, but they are usually in line with the WP29/EDPB’s opinions.139 The same applies to ICANN and its correspondence with the WP29/EDPB regarding the adaptation of the WHOIS system, where a layered access model was already advised by the WP29 in 2003. Chapter 3 provides details about the description and application of the GDPR.140
137 See European Data Protection Board, ‘THE EUROPEAN DATA PROTECTION BOARD’, Endorsement 1/2018, available at
4 Compliance Models In this chapter, the author compares the Compliance Models and points out their advantages and disadvantages. Subsequently, the different characteristics of the models are matched, analytically assessed, and partially potential solutions are already delivered in this chapter. Additionally, the author descriptively reflects on the Temporary Specification for gTLD Registration Data and the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data (Temp Spec). The author proves the hypothesis in the several conclusions of the subchapters, but also in the general conclusion. Firstly, the GDPR was the catalyst for the adoption of the Compliance Models and subsequently, the modification process of the previous WHOIS database publication practices. Secondly, the litigation ICANN v. EPAG has potentially influenced the EPDP on the Temp Spec, especially, in the context of Admin-C and Tech-C data. Thirdly, there is a necessity for a system of standardized access to non-public registration data, adjusted with the technical implementation process, which is also lawful under specific data protection laws. An overview of the detailed analysis of potential final answers in the context of the litigation in line with the GDPR and the general outlook is presented in Chapter 6.
4.1 GDPR Compliance Models and community input The various Compliance Models are comparatively and analytically examined on three widely community accepted essential criteria: ‘data collection, processing and retention,’ ‘scope of applicability’ and ‘layered/tiered access to WHOIS data.’ This chapter further discusses the similarities and differences between them. The figure below illustrates an overview of the twelve different Compliance Models of the community and ICANN (e. g., ECO Internet Industry Association, Electronic Frontier Foundation, ICANN Model from 1-2A-2B to 3, Appdetex, Governmental Advisory Committee, Intellectual Property Constituency, iThreat Cyber Group, Coalition for Online Accountability, Feldman Mode) and their varying impact on the WHOIS system. For the sake of completeness, it should be mentioned that the Policy Development Process of Phase 2 is still in progress, and there might be updates and changes in the future. According to the ‘Interim GDPR Compliance Model’ document dated 08 March 2018, there are some fundamental criteria addressed and previous, as well as ongoing, domain registration practices are questionable: The registrar’s collection of registrant’s personal data (e. g., administrative and technical contacts) and transfer to registry and data escrow agent Anonymization and replacement of current e-mail addresses of the registrant, as well as administrative and technical contacts in the public WHOIS database Globally permission of the application of the Compliance Model for registries and registrars
______Matthias Markus Hudobnik 25
Application of the Compliance Model to contact information provided by registrants who are legal persons The requirement of registries and registrars to supply full access to the public WHOIS database even though the implementation of a layered/tiered access via an accreditation program141
Figure 10: Overview of the different GDPR Compliance Models142
4.1.1 Data collection, processing, and retention The first essential category ‘data collection, processing, and retention’ of all below named Compliance Models is divided into the following subcategories: collection from the registrant to the registrar, data transfer from registrar to the registry, data transfer to escrow agents, and data retention. Before discussing and comparing the different data fields in the chart, it is crucial to define the purpose of the processing activities.143 The purpose of ICANN is stated in Section 4.6 (e) ICANN Bylaws as the following: “Subject to applicable laws, ICANN shall use commercially reasonable efforts to enforce its policies relating to registration directory services and shall work with Supporting Organizations and Advisory Committees to explore structural changes to improve accuracy and access to generic top-level domain registration data, as well as consider safeguards for protecting such data”144 and in (d) leg cit. “adequately address issues of competition, consumer protection, security, stability and resiliency, malicious abuse
141 Cf ICANN, ‘The Cookbook’ (n 16) pp. 2-3. 142 See ICANN, ‘Proposed Interim GDPR Compliance Models and Selected Community Input (Working Draft)’, 1 February 2018, available at
Table 1: Data collection, processing, and retention147
Electro Coalitio nic ICANN ICANN ICANN ICANN n for Fronti AppDe iThrea Felma ECO Model Model Model Model IPC GAC Online er tex t n 3 2B 2A 1 Account Found ability ation Data collection, processing and retention Unclea r, but implie s full Minimal collect data ion of collecte Full thick Collec d from thick data. tion registra data, ICANN from r. No except org or regist collecti Full thick data* no its rant on of registra agent to admin nt e- would regist and mail have rar tech address some contact role in informa redacti tion** on of person al data. Unclea r, but implie s full Must transf transfer er of thin thick Data data. data. transf Permits ICANN er , but org or from does Full transfer of thick data* N/A its regist not agent rar to require, would regist transfer have ry of some registra role in nt redacti data** on of person al data. Registr Regist ar rants transfer who minimal are Data data natura transf collecte l er to d. person escro Registry Full transfer of existing registration data* N/A s w transfer would agent thin have s data + data registra transf r data if erred receive by d from ICANN
145 See ICANN, ‘Section 4.6 (d) of the BYLAWS FOR INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS | A California Nonprofit Public- Benefit Corporation’, 18 June 2018, available at
registra to r** data escro w agent Life of registr ation + 2 years* (Note: Eliminat As long existin e ICANN Life of Life of Life of as Life of Life of Life of g 1- Life of data registr registr registr needed Data registr registr registr year registr retentio ation ation ation to fulfil retent ation ation ation waiver ation N/A N/A n + 60 + 60 + at specifie ion + 1 + 1 + 2 s for + 2 require days* days* least 2 d year year years* Europ years* ments* * * years* purpose ean * s registr ars would be preser ved) ** = More substantial change from status quo, * = Greater preservation of status quo
4.1.1.1 Collection from the registrant to the registrar The first chart in this subcategory shows that almost all – except the Coalition for Online Accountability model with no collection of the registrant e-mail address and the Feldman model where it is unclear, but it implies a full collection of thick WHOIS data – community models completely follow the full thick WHOIS data collection regime. Only the ECO model pursues a different approach with a minimal data collection from the registrar and no collection of administrative and technical contact information of the registrant. Although the vast majority of community commenters support the concept of full thick WHOIS data collection, others e. g., ECO thought that there is a need for a holistic approach with a proper privacy impact assessment and a precise determination of the respective data fields in line with the principle of data minimization and a revised purpose specification. With regards to full thick WHOIS, there would, therefore, seem to be a definite need for a further purpose description to justify the requirement for registrars to transfer that data to the registries.148 According to Article 5 (1) lit. b) GDPR (further discussed in Chapter 3.1.3), the collection of personal data is only allowed for “specified, explicit and legitimate purposes.”149 Concerning the principle of data minimization, a determination of the particular purposes for the current WHOIS system generally is an essential first step and should not be granted in conjunction with the original purpose of registrar’s collection of registrant’s personal data through the domain registration process under contractual obligations between these parties. The main question is whether the original purpose is sufficient enough or whether a separate legal principle is required?150 Whereas the original purpose for processing registrant’s personal data is based on the legal principle “processing is necessary for the performance of a contract”151 according to Article 6 (1) lit b) GDPR.152
148 Cf ibid. 149 See Article 5 (1) lit. b) of the Regulation (EU) 2016/679 (n 6) 35. 150 Cf ICANN, ‘The Cookbook’ (n 16) pp. 7-9. 151 See Article 6 (1) lit. b) of the Regulation (EU) 2016/679 (n 6) 36. 152 Cf Article 6 (1) lit. f) of the Regulation (EU) 2016/679 (n 6) 36. ______Matthias Markus Hudobnik 28
In contrast to that, the purpose of the current WHOIS system is based on the legal principle “processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party”153 according to Article 6 (1) lit f) GDPR. There would, therefore, seem to be a definite need for a review of the purpose descriptions and expansion of the registration data processing activities beyond the original purpose description in connection with the operation of the WHOIS system. Another possible area of investigation concerning the principle of data minimization and data collection will be whether if it is necessary to collect the same amount of registrant’s personal data under 2013 RAA or if a reduction of data elements is requisite in order to be compliant with the GDPR.154 Additionally, it appears that there are outdated data fields (e. g., fax numbers and the physical addresses), which may no longer necessarily be collected. Under Article 5 (1) lit. c) GDPR it must be “adequate, relevant and limited to what is necessary concerning the purposes for which they are processed”155 which might not be the case in this particular circumstance anymore.156
4.1.1.2 Data transfer from registrar to registry Following the ‘Thick WHOIS Transition Policy’ dated 01 February 2017, registrars are contractually obligated to transfer full thick WHOIS data to registries.157 The data of chart number one for this subcategory is like the first subcategory. It demonstrates that there is an almost holistic view of all Compliance Models – except the Coalition for Online Accountability model which do not address this issue and the Feldman model which is unclear but, it implies a full transfer of thick WHOIS data – to support the approach of a full thick WHOIS data transfer. Here again, only the ECO model suggests a different path while the transfer must contain thin WHOIS data, it permits registrars to transfer registrants data to the registries, but it is not necessarily required to do so.158 As the ‘Final Report on the Thick WHOIS Policy Development Process’ dated 21 October 2013 insists that thick WHOIS data transfer supports a further accessible and more stable domain name system through the mutual data distribution on the registrar level as well as on the registry level. The result is, in case of a technical defect, the registry has the full registrant’s data set and may transfer it to an additional registrar to foster the data redundancy, which is a data quality improvement as a whole.159 Furthermore, it has also been illustrated in the ‘Interim GDPR Compliance Model’ document dated 08 March 2018, that there are not sufficient legal principles - in light of the GDPR - to justify the conditions for the registrar’s transfer of data to the registry.160 According to Article 6 (1) lit. f) GDPR, the transfer of registrant’s personal data from a registrar to a registry must be
153 See Article 6 (1) lit. f) of the Regulation (EU) 2016/679 (n 6) 36. 154 Cf ICANN, ‘The Cookbook’ (n 16) pp. 9-11. 155 See Article 5 (1) lit. c) of the Regulation (EU) 2016/679 (n 6) 35. 156 Cf ICANN, ‘The Cookbook’ (n 16) 11. 157 Cf ICANN Board of Directors, ‘Thick WHOIS Transition Policy for .COM, .NET and .JOBS’, 1 February 2017, available at
4.1.1.3 Data transfer to escrow agents As explained in Chapter 2.3.6 and determined in the 2013 RAA and the RA, all gTLD registry operators, as well as accredited registrars, are currently contractually obligated to back up their whole gTLD registration data via an autonomous data escrow agent. The transfer of the full existing registration data (e. g., thick registration data including personal data) to the data escrow agent is protection for the registrant and guarantees gapless processing via a data backup in the event of a business mistake or technical break down of a gTLD registry operator or accredited registrar. The data fields in this subcategory of chart number one are analogical to the second subcategory, only with the minor difference of the full transfer of existing registration data to the data escrow agent instead of the transfer from a registrar to a registry. It also illustrates here the integrally view of all model commentators – except for the Coalition for Online Accountability model, which does not address this issue, and the Feldman model in which registrants who are natural persons would have data transferred by ICANN to the data escrow agent – to retain the concept of the full transfer of existing registration data to the data escrow agent. Here again, as in the second subcategory, only the ECO model believes in another notion, namely that the registrar transfers the minimal collected data to the registry. The registry, in turn, then transfers the registrars received registrant’s data and the thin data set to the escrow agent.163 Preferably, the data escrow agent would be located in Europe to prevent an outside escrowing of the full thick registration data, since most of the risks of the registries and registrars are mainly based in Europe.164 Similar to the second subcategory and according to Article 6 (1) lit. f) GDPR, the transfer of full thick registration data from a gTLD registry operator or accredited registrar to the data escrow agent is also based on the principle of legitimate interests165 of the named parties and who are therefore interested in a stable and accessible domain name system. The data escrowing
161 Cf Article 6 (1) lit. f) of the Regulation (EU) 2016/679 (n 6) 36. 162 Cf ICANN, ‘The Cookbook’ (n 16) 14. 163 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 164 Cf ICANN, ‘The Cookbook’ (n 16) pp. 15-16. 165 Cf Article 6 (1) lit. f) of the Regulation (EU) 2016/679 (n 6) 36. ______Matthias Markus Hudobnik 30
4.1.1.4 Data retention According to data retention, there is no separate provision in the RA to regulate this particular issue. Nevertheless, under Specification 2, Part B) lit. 4) RA, the escrow agent, which must be utilized by every registry, is contractually forced to deposit and safeguard the registration data for at least one year.167 Following the Data Retention Specification lit. 1.1) 2013 RAA, it is stipulated that registrants are obligated to collect all personal data of the registrant through the domain name registration and “shall maintain that information for the duration of registrar’s sponsorship of the registration and for a period of two additional years.”168 The fourth subcategory in chart number one illustrates that the majority of the Compliance Models prefer a retention period during the life of the registration, but shows a different range for the retention period beyond the registration between a minimum of 60 days (e. g., Electronic Frontier Foundation model and the ICANN Model 3) to one (e. g., ICANN Model 2A, and 2B) or even two years (e. g., ICANN Model 1, AppDetex, IPC, and GAC model), depending on the respective model. Particularly notable is the ECO model once again with the elimination of the ICANN data retention requirement. Both, the iThreat and Feldman model do not address this issue, and the Coalition for Online Accountability model is for data retention as long as needed to fulfill specified purposes, even if it is not entirely clear what is meant by this wording.169 According to Article 5 (1) lit. e) GDPR, the principle of storage limitation states that personal data needs to “kept in a form which permits the identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed,”170 which is fulfilled by the respective Compliance Models. The crucial question is, whether the lawfulness of processing under Article 6 GDPR is in the context of the particular purposes for processing under Article 5 GDPR in any cases of the data retention elements fulfilled. From this follows the adequate lengths of the retention periods. As a result, ICANN compiled a list in the ‘Interim GDPR Compliance Model’ document dated 08 March 2018, in which the legal basis for data retention requirements for every data element was formulated in line with the exact legitimate purpose for the collection and the lawful basis for the retention to be compliant with the GDPR. This issue will not be further discussed, as it is not directly related to the central questions of this thesis.171
166 Cf ICANN, ‘The Cookbook’ (n 16) 16. 167 Cf ICANN, ‘Specification 2, Part B) lit. 4) of the Registry Agreement’, 31 July 2017, pp. 50-51, available at
4.1.2 Scope of applicability The second category ‘scope of applicability’ of all below named Compliance Models is divided into two subcategories: territorial applicability implies global, or EEA (European Economic Area) and ‘legal entities’ are addressed as natural and legal persons.
Table 2: Scope of applicability172
Electro Coaliti nic ICANN ICANN ICANN ICANN on for Frontie AppDe Felma ECO Model Model Model Model IPC GAC iThreat Online r tex n 3 2B 2A 1 Accoun Found tability ation Applicability Territo Unclea rial r, but applic seems ability: to Global Global Global EEA EEA EEA EEA EEA EEA EEA EEA Global imply ** ** ** only* only* only* only* only* only* only* only* ly or global only to applic EEA ability. Legal Registr Registr Registr Registr Registr Registr Registr Registr Registr Registr Registr Registr entitie ations ations ations ations ations ations ations ations ations ations ations ations s: of of of of of of of of of of of of Regist natura natura natura natura natura natura natura natura natura natura natural natura rant l and l and l and l and l and l l l l l and l and types legal legal legal legal legal person person person person person legal legal affect person person person person person s s s s s person person ed s** s** s** s** s** only* only* only* only* only* s** s** ** = More substantial change from status quo, * = Greater preservation of status quo
4.1.2.1 Territorial applicability (global or EEA) According to the territorial applicability in connection with ICANN’s contractual agreements (e. g., 2013 RAA, RA) with the respective parties (e. g., registries, registrars, and registrants) is to highlight that there is no territorial differentiation necessary because of the unified contractual clauses. The encompassing question is whether the Compliance Models should be applied globally to the location of the respective parties as previously mentioned or only to the EEA, namely where the nexus of the parties exists.173 Chart number two of this subcategory demonstrates that the majority of the – except for the Electronic Frontier Foundation model, the ICANN Model 3 and 2B which apply globally, and the ECO model where it is unclear, but it seems to imply global applicability – community models apply only to the EEA.174 Nevertheless, there are some communities in favor of stronger protection and harmonization in the context of the registration data separately from the location debate, whether the parties are inside or outside of the EEA, and irrelevant of the data flows and processing activities. Further consequences of global applicability are the fact that this creates foreseeability, interoperability, and transparency strengthens the domain name system as a whole and is also in the interest of the public internet community. An additional concern of a non-global application is the fear that some parties would not be compliant with the GDPR. In contrast, it is interesting to note that there are commentators who criticize global applicability, namely because it would be an overestimation in terms of the application of the
172 See ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 173 Cf ICANN, ‘The Cookbook’ (n 16) 19. 174 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). ______Matthias Markus Hudobnik 32
GDPR and would violate ICANN’s purposes to preserve the current WHOIS system while only modifying the uncompliant sections to the minimum required extent. Furthermore, some commentators recommend the realization of the Compliance Model via a new self-registered WHOIS data field for registrants to be verified as living in the EU; therefore, results that the applicability of the GDPR would be minimized to a great extent due to where it would be required to be compliant.175 From a legal point of view, there is no way through Article 3 (1) GDPR, (further details in Chapter 3.1.1) which stipulates that “the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not.”176 Under Article 3 (2) GDPR, a data controller or processor which is not located in the EU but processing personal data of EU residents through their activities e. g., a) leg cit. “the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or b) leg cit. the monitoring of their behavior as far as their behavior takes place within the Union”177 is held accountable under this regulation. The guidance and determination for (2) leg cit. is stipulated in (23) GDPR or further details explained in Chapter 3.1.1. Taking all of this into account results in the following applicability of the GDPR, namely that registries and/or registrars based in the EEA that process personal registration data are liable under Article 3 GDPR. As well as for registries and/or registrars who are not based in the EEA, but are providing services to registrants based in the EEA containing personal registration data processing from EEA based registrants. The same principles shall apply for non-EEA based registries and/or registrars who process personal registration data of registrants not based in the EEA, where registries and/or registrars are obliged by EEA-based processors to process personal registration data as such. The idea of the extra-territoriality of the GDPR is to ensure a maximum level of protection for EU data subjects in circumstances in which data controllers and/or processors are located outside of the EEA, but are linking their business cases to EU data subjects.178
4.1.2.2 Legal entities addressed as natural or legal persons (registrant types affected) Under ICANN’s contractual agreements (e. g., 2013 RAA, RA) with the respective parties (e. g., registries and registrars) it is to portray that there is no contractual distinction noted in the domain registration process, whether the registrant is addressed as a natural or legal person.179 The second subcategory of chart two shows that seven out of twelve Compliance Models are supporting registrations of natural and legal persons, whereas, five of them only provide registrations of natural persons.180 Under Article 4 (1) GDPR, “an identifiable natural
175 Cf ICANN, ‘The Cookbook’ (n 16) pp. 19-21. 176 See Article 3 (1) of the Regulation (EU) 2016/679 (n 6) 32. 177 See Article 3 of the Regulation (EU) 2016/679 (n 6) pp. 32-33. 178 Cf ICANN, ‘The Cookbook’ (n 16) pp. 20-21. 179 Cf ICANN, ‘The Cookbook’ (n 16) pp. 22. 180 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). ______Matthias Markus Hudobnik 33
4.1.3 Layered/tiered access to public WHOIS data The third category ‘layered/tiered access to WHOIS data’ of all below named Compliance Models is divided into public and non-public WHOIS data; whereas, the section public WHOIS is separated into nine subcategories: registrant name, registrant postal address, registrant e- mail, registrant phone and fax, admin and tech contact names, admin and tech contact postal addresses, admin and tech contact e-mail addresses, admin and tech contact phone, and registrars offering to opt-in to publish additional data.
181 See Article 4 (1) of the Regulation (EU) 2016/679 (n 6) 33. 182 Cf ICANN, ‘The Cookbook’ (n 16) pp. 22-23. ______Matthias Markus Hudobnik 34
Table 3: Public WHOIS.183
Electron ICAN ICAN ICAN Coalition ic ICANN N N EC AppDe N IP for Online Frontier Model Mod Mod GAC iThreat Felman O tex Mod C Accounta Foundat 3 el el el 1 bility ion 2B 2A Layered/tiered access to WHOIS data Public WHOIS Yes, but registra Yes, nts may except Yes, apply to natural Registrant except Yes, ICANN persons name in No no No* No* Yes Ye except no for No** No** Yes* may opt- public ** perso * * * s* personal approva out of WHOIS? nal data* l to publishing data* redact personal person data* al data* Yes, except Yes, but natural registra persons nts may may opt- Yes, apply to Registrant out of except Yes, ICANN postal publishing No no No* No* Yes Ye except no for address in No** No** Yes* personal ** perso * * * s* personal approva public data. nal data* l to WHOIS? However, data* redact must person publish al state/provi data* nce and country* Yes, but registra Yes, nts may except Yes, apply to natural Registrant except Yes, ICANN Ye persons e-mail in No no No* No* No* except no for No** No** s* Yes* may opt- public ** perso * * * personal approva * out of WHOIS? nal data* l to publishing data* redact personal person data* al data* Yes, but registra Yes, nts may except Yes, Yes, apply to Registrant natural except except Yes, ICANN phone and N persons No no No* No* No* no except no for fax in No** No** o* may opt- ** perso * * * person personal approva public * out of nal al data* l to WHOIS? publishing data* data* redact personal person data* al data* Yes, but registra Yes, nts may Administra except Yes, Yes, apply to tive and natural except except Yes, ICANN technical N persons No no No* No* No* no except no for contact No** No** o* may opt- ** perso * * * person personal approva names in * out of nal al data* l to public publishing data* data* redact WHOIS? personal person data* al data* Yes, except Yes, but natural registra Administra persons nts may tive and Yes, Yes, may opt- apply to technical except except out of Yes, ICANN N contact No no No* No* No* no publishing except no for No** No** o* postal ** perso * * * person personal personal approva * addresses nal al data. data* l to in public data* data* However, redact WHOIS? must person publish al state/provi data* nce and
183 See ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). ______Matthias Markus Hudobnik 35
country* Yes, but registra Administra nts may tive and Yes, apply to technical except Yes, ICANN contact e- No no Yes Yes Yes Ye except no for No** No** Yes* Yes* mail ** perso * * * s* personal approva addresses nal data* l to in public data* redact WHOIS? person al data* Yes, but registra Yes, nts may Administra except Yes, apply to tive and natural except Yes, ICANN technical persons No no No* No* Yes Ye except no for contact No** No** Yes* may opt- ** perso * * * s* personal approva phone in out of nal data* l to public publishing data* redact WHOIS? personal person data* al data* Registrars offering to opt-in to publish No Yes Yes Yes Ye Yes* Yes* Yes* N/A Yes* Yes* Yes* additional ** * * * s* data in public WHOIS? ** = More substantial change from status quo, * = Greater preservation of status quo
4.1.3.1 Public WHOIS According to Article 5 (1) lit c) GDPR and in the context of the public WHOIS system, the question arises, whether the general publication of all the registration data in the WHOIS databases is specified, explicit, and necessary for the legitimate purpose. The data processing principles of the GDPR applied here were comprehensively explained in Chapter 3.1.3, as the principle of lawfulness, fairness, and transparency, the principle of purpose limitation and data minimization which may be relevant in the context of the WHOIS system.184 Furthermore, this processing needs to fulfill the principle of data minimization to be compliant with the GDPR.185 Under the Specification 4 RA and the Registration Data Directory Service (WHOIS) Specification 2013 RAA, registries and registrars are contractually obliged to “providing free public query-based access to”186 the primary domain name registration data fields of the registrants. However, the existing consensus policies fail to resolve the compliance issues with the GDPR, and obviously, the former or (present) situation of entirely open and unlimited access to the full thick WHOIS data will, under no circumstances, be appropriate and lawful under the GDPR. A detailed analysis of the respective data fields is further discussed in the relevant subcategories below.187
184 Cf ICANN, ‘The Cookbook’ (n 16) 23. 185 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) pp. 8-9. 186 See ICANN Board of Directors, ‘Registration Data Directory Service (WHOIS) Specification of the 2013 Registrar Accreditation Agreement’, 27 June 2013, 51, available at
4.1.3.1.1 Registrant name The first subcategory of the third chart illustrates that generally, seven out of twelve community models are supporting the fact that the registrant’s name should be published in the public WHOIS database; whereas, five of them are against this open publication.188 In addition, that four out of the seven community models are in favor publication with slight modifications as follows: The iThreat model has the exception that natural persons may opt- out of publishing personal data, the Feldman model states that registrants may apply to ICANN for approval to redact personal data, and the ICANN Model 3 and the Coalition for Online Accountability model support the publication in the public WHOIS database as long as it contains no personal data.189 Although some of the community commenters believe in a proper privacy impact assessment, an accurate determination of the individual data elements to ensure that they are in line with the processing principles of the GDPR. In short, whether the utilized data field includes personal data and if so, is public access necessary, proportionate, and limited to the purpose of the processing activity.190
4.1.3.1.2 Registrant postal address The data of the chart third for this subcategory is similar to the first subcategory. It shows that generally, seven out of twelve community models are supporting the fact that the registrant’s postal address should be published in the public WHOIS database; whereas, five of them are against open publication. It is also the same situation here as stated above that four out of the seven community models are in favor of publication with the following slight modifications: The iThreat model has the exception that natural persons may opt-out of publishing personal data but must publish state/province and country, the Feldman model states that the registrants may apply to ICANN for approval to redact personal data, and the ICANN Model 3 and the Coalition for Online Accountability model support publication in the public WHOIS database as long as it contains no personal data.191 Additionally, some community commenters advocate preserving the postal address field with the particular information of the state/province/country and others insist on keeping the city and/or postal code field of the registrant in the public WHOIS database for the reason that the jurisdiction of the registrant may be identified more easily.192
4.1.3.1.3 Registrant e-mail address The data fields in this subcategory of chart three are analogic to the second subcategory, but with the minor distinction that the resulting data is equally allocated between the twelve Compliance Models because of the changes in the particular data field of ICANN Model 1. Six out of twelve community models support the fact that the registrant’s e-mail address data field
188 Cf ibid. 189 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 190 Cf ICANN, ‘The Cookbook’ (n 16) pp. 24-25. 191 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 192 Cf ICANN, ‘The Cookbook’ (n 16) pp. 24-25. ______Matthias Markus Hudobnik 37
4.1.3.1.4 Registrant phone and fax Similarly, in the fourth subcategory of the third chart, five out of twelve community models support the fact that the registrant’s phone and fax should be published in the public WHOIS database; whereas, seven of them are against their publication. All of the five community models in favor would publish with the following small modifications: The iThreat model has the exception that natural persons may opt-out of publishing personal data, the Feldman model states that registrants may apply to ICANN for approval to redact personal data, and the ICANN Model 3, the Coalition for Online Accountability model and the GAC model support the publication in the public WHOIS database as long as it contains no personal data.195 It seems possible that these results are coherent with some commentator’s views that the fax number is outdated and should no longer be relevant in the WHOIS system.196
4.1.3.1.5 Administrative and technical contact names In the context of administrative and technical contact data, it should be articulated that some Compliance Model commentators suggest having at least the e-mail addresses of the administrative and technical contacts published as public WHOIS data. This publication would
193 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 194 Cf ICANN, ‘The Cookbook’ (n 16) 25. 195 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 196 Cf ICANN, ‘The Cookbook’ (n 16) 26. ______Matthias Markus Hudobnik 38
4.1.3.1.6 Administrative and technical contact postal addresses The sixth subcategory is identical to the fifth subcategory of the third chart, as five out of twelve community models support the notion that administrative and technical contact postal addresses should be published in the public WHOIS database; whereas, seven of them are against this publication. All of the five community models in favor of this would publish with the following small modifications: The iThreat model has the exception that natural persons may opt-out of publishing personal data but must publish state/province and country, the Feldman model states that registrants may apply to ICANN for approval to redact personal data, and the ICANN Model 3, the Coalition for Online Accountability model and the GAC model support the publication in the public WHOIS database as long as it contains no personal data. Here again, Chapter 5 further analyzes details of the administrative and technical data related to the case ICANN v. EPAG 199
4.1.3.1.7 Administrative and technical contact e-mail addresses The seventh subcategory of chart number three shows that the majority of the Compliance Models prefer that the administrative and technical contact e-mail addresses should be published in the public WHOIS database; whereas, three of them are against publication. Three out of the nine community models that are in favor will publish with the following small modifications: In the Feldman model, the registrants may apply to ICANN for approval to redact personal data, and the ICANN Model 3, as well as the Coalition for Online Accountability model
197 Cf ICANN, ‘The Cookbook’ (n 16) pp. 26-27. 198 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 199 Cf ibid. ______Matthias Markus Hudobnik 39
4.1.3.1.8 Administrative and technical contact phone The eighth subcategory is similar like the seventh one of the third chart, namely that the majority of the Compliance Models prefer that the administrative and technical contact phone should be published in the public WHOIS database; whereas, five out of them are against publication. Four out of the nine community models that are in favor would publish with the following small modifications: The iThreat model has the exception that natural persons may opt-out of publishing personal data, the Feldman model states that registrants may apply to ICANN for approval to redact personal data, and the ICANN Model 3 and the Coalition for Online Accountability model support the publication in the public WHOIS database as long as it contains no personal data. Chapter 5 further analyzes details of the administrative and technical contact data related to the case ICANN v. EPAG.201
4.1.3.1.9 Registrars offering to opt-in to publish additional data The data field in this subcategory of chart number three shows that ten out of twelve Compliance Models support the fact that registrars must offer registrants an opt-in to publish additional data in the public WHOIS database; whereas, only the ECO model is against publication and the GAC model does not address this issue in its model.202
4.1.4 Layered/tiered access to non-public WHOIS data The fourth category ‘layered/tiered access to WHOIS data’ of all Compliance Models is divided into public and non-public WHOIS data; whereas, the section non-public WHOIS is separated into two subcategories: self-certification access and accreditation program for access.
200 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 201 Cf ibid. 202 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). ______Matthias Markus Hudobnik 40
Table 4: Non-Public WHOIS203
Electr Coaliti onic ICA on for Fronti NN ICANN ICANN AppDete ICANN iThre Online Felma ECO er Mo Model Model IPC GAC x Model 1 at Accou n Foun del 2B 2A ntabilit datio 3 y n Layered/Tiered Access to WHOIS data Non-Public WHOIS Yes, on Yes, on Yes, Yes, interim interim Yes, for on basis, basis, subject blank interi subject subject to Yes, No, et m to to registry/ subject create No, acce basis, registry/ registry/ No, registrar to anony Acc ss for Self- registrar registrar create balancin registr mized No, ess (no blanke certific balancin balancin anonymi g of ant’s e-mail acces via balan t ation g of g of zed e- request right to addre s via leg cing acces acces request request mail or’s object ss or a legal al requi s (no s to or’s or’s address legitimat N/A to No* web due due red) balanc non- legitimat legitimat or a web e providi form proce pro unles ing public e e form to interest ng to ss ces s requir WHOI interest interest contact against Non- contac only* s limite ed) S? against against registran data Public t only d unless data data t* subject’ WHOIS registr * exce limited subject’ subject’ s data* ant* ption except s s rights/fr * s ions rights/fr rights/fr eedoms apply apply* eedoms eedoms ** ** * ** ** Yes, accredita Yes, tion accred program itation Yes, No, similar to progra accred Yes, Yes, Accred acc Expert m to itation Yes, accredit accredit itation No, ess Working be progra accred ation ation progra acces via Group develo m itation program program m for s via leg recomme ped in based progra to be to be acces legal al ndations Yes* consul on m for develop develop No* N/A No* s to due due (access * tation existin limited ed in ed in non- proce pro given at with g user consulta consulta public ss ces level the proces groups tion with tion with WHOI only* s appropri GAC ses of ** the the S? only ate for and EU GAC** GAC** * each other ccTLD user and stakeh s** stated olders purpose) ** ** ** = More substantial change from status quo, Green = Greater preservation of status quo
4.1.4.1 Non-public WHOIS The non-public WHOIS regime can be categorized into a (self)-certification approach, accreditation approach, and legal due process approach.204 ICANN’s current contractual agreements (e. g., 2013 RAA and RA) with the respective parties (e. g., registries and registrars) and their requirement of public-query based access to WHOIS data will not be in line with the GDPR. Therefore, the current system requires modifications, and the encompassing question is: Who should be able to access non-public WHOIS data and under which procedures? The ‘Interim GDPR Compliance Model’ document dated 08 March 2018, discusses some of the main aspects of potential procedure models and highlights the advantages and disadvantages of the (self)-certification approach, the accreditation approach, and the legal due process approach of the respective models. The concepts of (self)- certification and accreditation are central for the layered/tiered access to non-public WHOIS data; nonetheless, the implementations must be compliant with the GDPR. The compliance
203 See ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 204 Cf ibid. ______Matthias Markus Hudobnik 41
4.1.4.1.1 Self-certification access The first subcategory of the fourth chart demonstrates that six out of twelve community models support the fact that a self-certification access to non-public WHOIS data should be performed; whereas, five of the whole Compliance Models are against this procedure and one does not even address this issue. ICANN Model 2A and 2B are in favor of a self-certification access to non-public WHOIS data with a slight modification on an interim basis, subject to registry/registrar balancing of requestor’s legitimate interest against data subject’s rights/freedoms. ICANN Model 1 has the same procedure but with the minor difference that there is no ‘interim basis.’ The IPC model is for blanket access where no balancing is required unless limited exceptions apply to it. Similarly, the GAC model supports the interim basis for blanket access, and there is also no balancing required unless limited exceptions are applicable. The Coalition for Online Accountability focuses on the subject to registrant’s right to object, to prove non-public WHOIS data access and the iThreat model does not address this issue at all. There are several significant differences between the Compliance Models mentioned above and the others who are not in favor of a self-certification access to non- public WHOIS data. Specifically, ICANN Model 3 and the Electronic Frontier Foundation model do not support the self-certification access procedure to non-public WHOIS data and are in favor of access via legal due process only. It is of note that the legal due process is the prevailing concept to grant access based on the respective legal frameworks or jurisdictions procedure (via an e. g., subpoena, warrant or court order for the relevant third party request)
205 Cf ICANN, ‘The Cookbook’ (n 16) 27. 206 See Article 41 (1) of the Regulation (EU) 2016/679 (n 6) 58. 207 Cf ICANN, ‘The Cookbook’ (n 16) 29. ______Matthias Markus Hudobnik 42
4.1.4.1.2 Accreditation program for access The second subcategory of the fourth chart shows that, overall, seven out of twelve community models support the implementation of an accreditation program for access to non-public WHOIS data; whereas, four of the Compliance Models are against this program and one does not address this issue. ICANN Model 2A and 2B in consultation with the GAC model are in favor of developing an accreditation program for access to non-public WHOIS data but do not provide more specific details about this particular program. The ECO model only focuses on an accreditation program for limited user groups as well as the AppDetex model; however, with the minor difference that the AppDetex model believes in an accreditation program similar to the expert working group recommendations where access is given at an appropriate level for each user and stated purpose. The Feldman model supports the accreditation program for access to non-public WHOIS data based on existing processes of EU ccTLDs. The IPC model is
208 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 209 Cf ICANN, ‘The Cookbook’ (n 16) pp. 28-29. 210 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 211 Cf ICANN, ‘The Cookbook’ (n 16) pp. 27-28. ______Matthias Markus Hudobnik 43
4.1.5 Conclusion The main aim of this subchapter is to address interim results of the first part of the research question, which generally focuses on how can access to crucial information and protected data in the WHOIS system be ensured? Specifically, the thesis focuses on the Compliance Models and whether the data fields of the essential criteria, such as: ‘data collection,’ ‘processing and retention,’ ‘scope of applicability’ and ‘tiered/layered access to non- public/public WHOIS’ data are compliant with the GDPR. The above data proves the first hypothesis; that the GDPR was the catalyst for the adoption of the Compliance Models and subsequently the modification process of the previous WHOIS database publication practices. In March 2017, ICANN started taking the WHOIS compliance issues seriously by holding a session called ‘Cross-Community Discussion with Data Protection Commissioners’ within the scope of ICANN58.214 From that time on, ICANN figured out their crucial role and regularly came under legal pressure because of the fast-approaching enforcement date of the GDPR. Subsequently, ICANN asked the various communities for input and the adoption of the
212 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 213 Cf ICANN, ‘The Cookbook’ (n 16) pp. 27-30. 214 Cf ICANN, ‘Panel on ICANN and Data Privacy issues’, Cross-Community Discussion with Data Protection Commissioners, ICANN58 meeting, 13 March 2017, available at
Compliance Models in line with the GDPR (this is further explored in Chapter 4). ICANN, even recognized the potential risk of incurring severe penalties if they fall under the application of the GDPR (further considered in Chapter 3.1.1) and had various conversations with the W29/EDPB (as previously emphasized in Chapter 2.2.3.1, 2.2.3.2, 3.2, 5.1.1 and 5.3.3) which already raised this compliance issue in 2003215 as well as 2006216 - without any success. The interim result was that the ICANN Board adopted Temporary Specification for gTLD Registration Data (further explained in Chapter 4.2) approved on 17 May 2018. This came into force briefly with the GDPR on 25 May 2018, followed by the EPDP on the Temp Spec. That these compliance issues were already highlighted in 2003/2006 was also part of the correspondence in the litigation, and criticized by the defendant (further details in Chapter 5.1.1 and 5.3.3). As a result, the present research results show that the GDPR was the catalyst for the adoption of the Compliance Models, as well as setting the procedure in motion. Starting with the detailed research questions on the Compliance Models of the charts in Chapter 4.1, this is analyzed as follows:
4.1.5.1 How can the purpose and lawfulness of processing activities be determined, and which data of the registrant is specifically collected? As pointed out in Chapter 4.1.3 and 4.1.1.1, and in line with EDPB’s guidelines, it is crucial to separate the various processing activities that are completed in the context of the WHOIS system and the exact purpose of the different parties that are implicated.217 The results of the investigation of the various Compliance Models show that there is generally a lack of accuracy in terms of the previously mentioned separation in almost all of the models, with the minor exception of the ECO model which very accurately explains their holistic approach, whilst also fulfilling the processing principles and the legal grounds of the GDPR. The research has also demonstrated that the vast majority of the Compliance Models stand behind the concept of full thick WHOIS data collection: they have no proper privacy impact assessment, no precise determination of the respective data fields in line with the principle of data minimization, and no revised purpose specification. The following conclusions can be drawn from the present study that there seems to be a definite need for a review of the purpose descriptions and expandability of the registration data processing activities beyond the original purpose description, in connection with the operation of the WHOIS system. A reasonable approach to tackle this issue could be to investigate the relationship of the principle of data minimization and data collection, and consider whether it is still necessary to collect the same amount of registrant’s personal data under the 2013 RAA, or if a reduction of data elements is requisite in order to be compliant with Article 5 (1) GDPR. These findings suggest that there are outdated data fields e. g., fax numbers, and physical addresses, which may no longer
215 Cf WP29, ‘Letter from Isabelle Falque-Pierrotin to Cherine Chalaby and Göran Marby regarding GDPR’ (n 63) 3. 216 Cf Article 29 Data Protection Working Party, ‘Letter from Peter Schaar to Vinton G. Cerf regarding WHOIS’, 22 June 2006, pp. 1-2, available at
4.1.5.2 What data can be transferred from the registrar to the registry and the data escrow agent? Initially, it should be mentioned that under the ‘Thick WHOIS Transition Policy’, registrars are contractually obligated to transfer full thick WHOIS data to registries.220 The results of Chapter 4.1.1.2 indicate that there is an almost holistic view of all Compliance Models – except two models – to support the approach of a full thick WHOIS data transfer. The parties involved justify this with the argument that, in case of a technical defect, the registry has the full registrant’s data set, and may transfer it to an additional registrar to foster the data redundancy, which is a data quality improvement as a whole.221 From a legal point of view, the transfer of registrant’s personal data from registrants to registries must be based on a legal principle, which may be, in this context, the principle of legitimate interests.222 The most prominent finding to emerge from this study is that the legal principles under the GDPR are currently not sufficient enough to justify the registration data transfer from registrars to registries.223 The results are equal in the context of the data escrow agent, where the transfer of full thick registration data from a gTLD registry operator or accredited registrar to the data escrow agent is also based on the principle of legitimate interests.224 The following conclusion can be drawn from the present study: that ICANN may also extend the purpose description transfer (further details concerning the purpose description explained in Chapter 4.1.3) with regards to the full thick WHOIS data processing activities, in order to be compliant with Article 5 GDPR.225
4.1.5.3 How long should the period of data retention for the registrar, registry, and the escrow agent be? The findings in Chapter 4.1.1.4 convey that, in general, the majority prefer a retention period during the life of the registration. However, the data shows a different range for the retention period beyond the registration from a minimum of 60 days to one or two years, depending on the respective model. The question raised by this study is whether the lawfulness of processing is in line with the particular processing purposes, and whether the particular data retention elements fulfill the criteria of the GDPR in any case. The adequate lengths of the retention period might be concluded from this question. This information can be used to develop a list, with the legal basis for data retention requirements for every data element
218 Cf ICANN, ‘The Cookbook’ (n 16) 10. 219 See Article 5 (1) lit. c) of the Regulation (EU) 2016/679 (n 6) 35. 220 Cf ICANN, ‘Thick WHOIS Transition Policy’ (n 157). 221 Cf ICANN, ‘The Cookbook’ (n 16) pp. 13-14. 222 Cf Article 6 (1) lit. f) of the Regulation (EU) 2016/679 (n 6) 36. 223 Cf ICANN, ‘The Cookbook’ (n 16) pp. 13-14. 224 Cf Article 6 (1) lit. f) of the Regulation (EU) 2016/679 (n 6) 36. 225 Cf ibid. ______Matthias Markus Hudobnik 46
4.1.5.4 What is the scope of applicability for the different possible Compliance Models? Initially, the encompassing question is whether the Compliance Models should apply globally; autonomous of the location of the respective parties mentioned above, or only to the EEA, namely where the nexus of parties exist.227 The current data in Chapter 4.1.2.1 highlights that the majority of the community models apply only to the EEA.228 Nevertheless, there are some respectable arguments for both approaches comprehensively analyzed in Chapter 4.1.2.1 and in terms of the legal perspective in Chapter 4.1.2.2. The most prominent finding to emerge from this study is a discussion of whether the scope of this extra-territoriality is convincingly applicable on the WHOIS system, and in terms of data processing activities on a global scale, given the obstacles regarding the exact scope of where the GDPR applies. However, there is a strong possibility that the recent signs of progress will improve in the long term, and the WHOIS system may be a more uniform and consistent system for a broader range of jurisdictions.229
4.1.5.5 How is the access to public/non-public WHOIS data to be organized, for example via accreditation program or a tiered/layered access model? The aim of the first part of this research question is to examine in general: How can access to crucial information and protected data in the WHOIS system be ensured? Specifically, the thesis focuses on the Compliance Models concerning the public WHOIS data and draws a line between the legitimate interests of the involved parties, and the data subject’s rights and freedoms, as it is their data that is processed in the WHOIS databases. The following conclusions of public WHOIS data can be drawn from the present data of Chapter 4.1.3.1. There should be: No publication of the name data field of the registrant with the exception of the organization/legal entity of the registrants, in case the name of the legal entity includes personal data via the link to the natural person (e. g., registrant) No publication of the address data field of the registrant (e. g., city, postal code, street) with the exception of the country and state/province. As a result, a general identification/localization of the registrant is possible, but personal details will only be provided to accredited users No publication of the registrant’s e-mail address data field, meaning that general contact is possible without the identification of the registrant via a web form or an anonymized e-mail address (e. g., forwarded to the registrants one)
226 Cf ICANN, ‘The Cookbook’ (n 16) pp. 16-18. 227 Cf ICANN, ‘The Cookbook’ (n 16) 19. 228 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 229 Cf ICANN, ‘The Cookbook’ (n 16) pp. 19-21. ______Matthias Markus Hudobnik 47
No publication of the registrant’s phone and fax number data field No publication of the registrant’s administrative and technical contact details data field. As a result, general contact is possible without the identification of the registrant’s administrative and technical contact via a web form or an anonymized e-mail address (e. g., forwarded to the registrant’s administrative and technical contacts one).230 The aim of the second part of the present research question is to scrutinize the Compliance Models concerning the non-public WHOIS data and the results of the self-certified access, as well as the accreditation program for access to non-public WHOIS data. A closer examination of the data in Chapter 4.1.4.1 concerning the access to full non-public WHOIS data for third party interests provides the following: The ‘self-certification approach’ of the third party means that the respective party is declaring their specific legitimate purpose and the access to full WHOIS data is only lawfully permitted under the limitation of this particular purpose The ‘certification approach,’ which is the same as above, applies and, additionally, a code of conduct must be approved to be compliant The ‘accreditation approach’ means that only third parties selected and certified or accredited via an accredited program, are permitted to access the full WHOIS data set The ‘legal due process approach’ is based only on the respective applicable law or jurisdiction e. g., a subpoena or an order from a court or tribunal of the third party which permits the access to full WHOIS data for this respective party.231 Taken together, these results from Chapter 4.1.4.1.1 highlight that generally, six out of twelve community models support the fact that self-certified access to non-public WHOIS data should be performed; whereas, five of the whole Compliance Models are against this procedure and one does not address this issue. There are several significant differences between the various Compliance Models and procedures which are comprehensively analyzed in Chapter 4.1.4.1.1. In the context of an accreditation program for access to non-public WHOIS data, the results of Chapter 4.1.4.1.2 illustrate that the majority of the community models are supporting the implementation of an accreditation program. There may not be definite conclusions drawn from the present data because there is a diverse range of potential methods to solve the non- public WHOIS data access debate. Possible solutions include: a case-by-case assessment regarding self-certified access; access via legal due process; the implementation of anonymized e-mail addresses or a web form to contact the registrant; and an accreditation program for access to non-public WHOIS data.232 This research has generated many questions regarding how can access to crucial information and protected data in the WHOIS system be ensured? This may potentially not be sufficient to
230 Cf ICANN, ‘The Cookbook’ (n 16) pp. 26-27. 231 Cf ICANN, ‘The Cookbook’ (n 16) 27. 232 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). ______Matthias Markus Hudobnik 48
4.2 Temporary Specification for gTLD Registration Data This section descriptively reflects the Temporary Specification for gTLD Registration Data (Temp Spec) approved on 17 May 2018 by the ICANN Board, effective on 25 May 2018, which allows ICANN and the gTLD registry operators and registrars to continue their current work under temporary rules to fulfill the existing ICANN agreements and community-developed policies in light of the GDPR.234 Additionally, the Temp Spec may remain effective for up to one year, and the ICANN Board must reaffirm these interim rules every 90 days from their validity, namely from the 25 May 2018. The Temp Spec applies to all involved parties (e. g., registry operators and registrars) via the contractual agreements and the temporary policy specifications in the 2013 RAA and the RA, but does not alter contracted parties data collection, data retention, data transfer, and escrow obligations. The implementation of the Temp Spec is mandatory for all contracted parties regardless of the territoriality. Furthermore, there is a scope of applicability, as there is no distinction of legal entities, and whether the registrant is a natural or legal person as such.235 A closer examination of the Temp Spec document conveys that there are several similarities with ICANN’s Compliance models from e. g., ICANN Model 1 to 2A, 2B, 3 to the final ‘Interim Model,’ the so-called ‘Calzone Model’. Furthermore, ICANN is trying to bridge the gap between ICANN’s mission stated in their bylaws and the GDPR compliance, while trying to retain the current WHOIS system to the greatest extent possible. Taking this into account, the author demonstrates below in chart number five, the alteration of ICANN’s final Compliance Model so- called ‘Calzone Model’ and the Temp Spec. This data is also comparable to the other Compliance Models analyzed in Chapter 4.1; whereas, the data set structure is the same as the following: ‘data collection, processing, and retention,’ ‘scope of applicability and ‘layered/tiered access to WHOIS data.’ Consequently, this allows the reader of this diploma thesis to quickly acquire a clear understanding of the different Compliance Models and the Temp Spec, as well as their focus in the context of the WHOIS system in compliance with the
233 Cf ICANN, ‘The Cookbook’ (n 16) pp. 28-29. 234 Cf ICANN, ‘Temporary Specification for gTLD Registration Data’ (n 64) pp. 1-2. 235 Cf ICANN, ‘Summary of the Temporary Specification for gTLD Registration Data’, Webinar, Global Domains Division & Contractual Compliance, 6 June 2018, pp. 4-6, available at
GDPR. Thus, the author will point out the significant change of the state of the art situation and the differences between these two models.236
Table 5: Calzone Model v. Temp Spec237
Temporary Specification for gTLD Registration ICANN Interim Model (Calzone Model) Data (Temp Spec) Data Collection, processing and retention Collection from registrant to Full thick data Full thick data** registrar Data transfer from registrar to Full transfer of data collected Full transfer of data collected** registry Data transfer to escrow agents Full transfer of data collected Full transfer of data collected** Life of registration + 2 years (note: Life of registration + 2 years** (note: existing Data retention existing waivers for European registrars waivers for European registrars would be preserved) would be preserved) Applicability Must be applied to EEA, may be applied Must model be applied globally globally, subject to a data processing Must be applied to EEA, may be applied beyond EEA or only to European economic agreement between ICANN and the where it is commercially reasonable to do so area? contracted parties Registrations of natural and legal Registrant types affected Registrations of natural and legal persons persons Layered/tiered access to WHOIS data Public WHOIS Registrant name in public Only registrant organization (if applicable) Only registrant organization (if applicable) in public WHOIS? in public WHOIS (not registrant name) WHOIS (not registrant name) Only registrant state/province and Registrant postal address in Only registrant state/province and country in public country in public WHOIS (not registrant public WHOIS? WHOIS (not registrant street, city, postal code) street, city, postal code) Registrar is required to create anonymized e-mail or Registrant e-mail in public Create anonymized e-mail or a web form a web form to contact registrant WHOIS? to contact registrant Registry is required to direct user to registrar for method to contact registrant Registrant phone and fax in No No public WHOIS? Administrative and technical No No contact names in public WHOIS? Administrative and technical contact postal addresses in No No public WHOIS? Registrar is required to create anonymized e-mail or a web form to contact administrative and technical Administrative and technical Create anonymized e-mail or a web form contacts contact e-mail addresses in to contact administrative and technical registry is required to direct user to registrar for public WHOIS? contacts method to contact Administrative and technical contacts Administrative and technical No No contact phone in public WHOIS? Registrar must offer opt-in to publish additional Registrars offering to opt-in to registrant data; registrar may (but is not required) to publish additional data in public Yes offer opt-in to publish additional Admin and Tech WHOIS? contact data Non-public WHOIS No. Create anonymized e-mail address or Self-certification access to non- a web form to contact registrant or due No public WHOIS? process Yes, in consultation with the Yes, registrar and registry required to provide Governmental Advisory Committee, data reasonable access to non-public data to 3rd parties protection authorities and contracted with legitimate interests, except where overridden by parties with full transparency to the interests or fundamental rights and freedoms of data ICANN community. User groups with a subject; also required to provide access where Unified access model for access legitimate interest and who are bound to WP29/European Data Protection Board, relevant to non-public WHOIS? abide by codes of conduct requiring court, applicable legislation or regulation provides adequate measures of protection could guidance that provision of data to specified classes access non-public WHOIS data based on of users is lawful. Further community discussion will pre-defined criteria and limitations under result in standardized unified access model to be the unified access model. implemented. ** Means no change needed in Temp Spec because already required by existing provisions.
Chart number five from this subchapter shows that the first category ‘data collection, processing, and retention’ of the above named two models is divided into four subcategories of collection from registrant to registrar, data transfer from registrar to registry, data transfer to
236 Cf ICANN, ‘Comparison of Calzone Model and Temporary Specification Requirements’, 17 May 2018, available at
238 Cf ICANN, ‘Comparison of Calzone Model and Temporary Specification Requirements’ (n 236). 239 Cf ICANN, ‘ICANN Board Approves Temporary Specification for gTLD Registration Data’, 17 May 2018, available at
4.2.1 Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data It should be noted for this subchapter that the Policy Development Process is still in progress and not finalized. The author aims to provide the reader with an overview of the recommendations of the Generic Names Supporting Organization (GNSO) EPDB on the Temp Spec, but the focus of this work is on the Compliance Models as well as the litigation ICANN v. EPAG. As already stated in the introduction of Chapter 4.2, the Temp Spec was approved on 17 May 2018 by the ICANN Board, enter into force on 25 May 2018, which allows ICANN and the gTLD registry operators and registrars to continue their current work under temporary rules
241 Cf ICANN, ‘Comparison of Calzone Model and Temporary Specification Requirements’ (n 236). 242 See ICANN, ‘Comparison of Calzone Model and Temporary Specification Requirements’ (n 236). 243 Cf ICANN, ‘Comparison of Calzone Model and Temporary Specification Requirements’ (n 236). 244 Cf EDPB, ‘Letter from Jelinek to Marby’ (n 69) pp. 1-4. ______Matthias Markus Hudobnik 52
245 Cf ICANN, ‘ICANN Board Approves Temporary Specification’ (n 239). 246 Cf ICANN, ‘How to Get Involved: Launch of the EPDP on the Temporary Specification for gTLD Registration Data’, available at
Table 6: Recommendation 5, the registrars collected data elements256
Data elements (collected & generated*) Collection logic Domain name Required Registrar WHOIS server* Required Registrar URL* Required Registrar registration expiration date* Optional Registrar* Required Registrar IANA ID* Required Registrar abuse contact e-mail* Required Registrar abuse contact phone* Required Reseller* Optional Domain status(es)* Required Registrant fields -Name Required -Organization Optional -Street Required -City Required -State/province Required -Postal code Required -Country Required -Phone Required -Phone ext Optional -Fax Optional -Fax ext Optional -E-mail Required Tech fields -Name Optional -Phone Optional -E-mail Optional Name server(s) Optional DNSSEC Optional Name server IP address(es) Optional Additional data elements as identified by registry Optional operator in its registration policy, such as (i) status as registry operator affiliate or trademark licensee [.MICROSOFT]; (ii) membership in community [.ECO]; (iii) licensing, registration or appropriate permits (.PHARMACY, .LAW] place of domicile [.NYC]; (iv) business entity or activity [.BANK, .BOT]
As shown in the table above, the collection logic ‘optional’ means that registrars may offer this collection optionally or registrants may provide these data elements optionally, and if so, in
251 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 5. 252 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 5. 253 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 6. 254 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 6. 255 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 7-8. 256 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 7-8. ______Matthias Markus Hudobnik 54
Table 7: Recommendation 7, transfer of data elements from registrar to registry260
Data elements (collected & generated*) Transfer logic Domain name Required Registrar WHOIS server* Required Registrar URL* Required Registrar registration expiration date* Optional Registrar* Required Registrar IANA ID* Required Registrar abuse contact e-mail* Required Registrar abuse contact phone* Required Reseller* Optional Domain status(es)* Required Registrant fields -Name Optional -Organization Optional -Street Optional -City Optional -State/province Optional -Postal code Optional -Country Optional -Phone Optional -Phone ext Optional -Fax Optional -Fax ext Optional -E-mail Optional Tech fields -Name Optional -Phone Optional -E-mail Optional Name server(s) Optional DNSSEC Optional Name server IP address(es) Optional Additional data elements as identified by registry Optional operator in its registration policy, such as (i) status as registry operator affiliate or trademark licensee [.MICROSOFT]; (ii) membership in community [.ECO]; (iii) licensing, registration or appropriate permits (.PHARMACY, .LAW] place of domicile [.NYC]; (iv) business entity or activity [.BANK, .BOT]
Recommendation 8 deals with data processing policies among the data escrow providers and ICANN, and endorse ICANN to focus on “legally-compliant data processing agreements”261 with the respective data escrow providers. The EPDP team also suggests refreshing the contractual specifications – for the transfer of the processed data to the data escrow provider – of the involved parties (e. g., registries and registrars). This approach will foster the consistency and
257 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 7. 258 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 8. 259 See ibid. 260 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 9-10. 261 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 10. ______Matthias Markus Hudobnik 55
Table 8: Recommendation 8, transfer registrars to the data escrow agent263
Data elements (collected & generated*) Collection logic Domain name Required Registrar registration expiration date* Optional Registrar* Required Reseller* Optional Registrant fields -Name Required -Street Required -City Required -State/province Required -Postal code Required -Country Required -Phone Required -Phone ext Optional -Fax Optional -Fax ext Optional -E-mail Required Tech fields -Name Optional -Phone Optional -E-mail Optional
Table 9: Recommendation 8, transfer registries to the data escrow agent264
Data elements (collected & generated*) Collection logic Domain name Required Registry domain ID* Required Registrar WHOIS server* Required Registrar URL* Required Updated date* Required Creation date* Required Registry expiry date* Required Registrar registration expiration date* Optional Registrar* Required Registrar IANA ID* Required Registrar abuse contact e-mail* Required Registrar abuse contact phone* Required Reseller* Optional Domain status(es)* Required Registry registrant ID* Required Registrant fields -Name Optional -Organization Optional -Street Optional -City Optional -State/province Optional -Postal code Optional -Country Optional -Phone Optional -Phone ext Optional -Fax Optional -Fax ext Optional -E-mail Optional Tech fields -Name Optional -Phone Optional -E-mail Optional Name server(s) Optional DNSSEC Optional Name server IP address(es) Optional Additional data elements as identified by registry Optional operator in its registration policy, such as (i) status as registry operator affiliate or trademark licensee [.MICROSOFT]; (ii) membership in community [.ECO]; (iii) licensing, registration or appropriate permits (.PHARMACY, .LAW] place of domicile [.NYC]; (iv) business entity or activity [.BANK, .BOT]
262 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 10. 263 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 10-11. 264 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 11-12. ______Matthias Markus Hudobnik 56
Recommendation 10 suggests a reduction of processed personal data in the public Registration Data Directory Service (RDDS) already utilized in the Temp Spec (e. g., the registry domain ID, the registry registrant ID, the registrant’s data fields, and the tech fields), as well as the publication and access via the query service of such data fields if they are neither redacted nor anonymized as can be seen in Table 10.265
Table 10: Recommendation 10, requirements for processing personal data in public RDDS266
Data elements (collected & generated*) Redacted Disclosure logic Domain name No Required Registry domain ID* Yes Required Registrar WHOIS server* No Required Registrar URL* No Required Updated date* No Required Registry expiry date* No Required Registrar registration expiration date* No Optional Registrar* No Required Registrar IANA ID* No Required Registrar abuse contact e-mail* No Required Registrar abuse contact phone* No Required Reseller* No Optional Domain status(es)* No Required Registry registrant ID* Yes Required Registrant fields -Name Yes Required -Organization Yes Required -Street Yes Required -City Yes Required -State/province No Required -Postal code Yes Required -Country No Required -Phone Yes Required -E-mail Yes Required Tech ID* Yes Required Tech fields -Name Yes Required -Phone Yes Required -E-mail Yes Required Name server(s) No Optional DNSSEC No Optional Name server IP address(es) No Optional Last update of Whois database* No Required
In a nutshell, Recommendation 12 suggests that the registrant’s information in the organization data field is subject of a further confirmation process of the respective registrant, namely whether the registrant confirms the further publication or not. A negation of the publication results in redaction or deletion of the respective data field. The recommendation also clarifies that there will be a transition period for the registrars to handle current and past registrations, as well as to implement a procedure for future registrations. During this phase, it will be permitted to redact the organization data field. A registry operator may redact or publish the respective data field in the RDDS.267 Recommendation 13 endorses the registrar - which is also in line with Section 2.5.1 of the Temp Spec - in the context of the e-mail communication to facilitate an e-mail address or a web form to reach the appropriate point of contact. An identification or publication of the contact or the e-mail address is just with the consent of the registrant lawful. Moreover, the EPDP recommends at the registrars level to store log files anonymously to certify the
265 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 49-50. 266 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 49-50. 267 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 51-52. ______Matthias Markus Hudobnik 57
Table 11: Recommendation 20, purposes, processing activities, parties, and lawful basis272
ICANN purpose1 As subject to Registry and Registrar terms, conditions and policies, and ICANN Consensus Policies: - To establish the rights of a Registered Name Holder in a Registered Name; to ensure that a Registered Name Holder may exercise its rights in the use and disposition of the Registered Name; and - To activate a registered name and allocate it to a Registered Name Holder. Processing activity Responsible party2 Lawful basis3 ICANN Article 6 (1) lit. b) GDPR for registrars Collection Registrars Article 6 (1) lit. f) GDPR for ICANN and registries Registries Certain data elements (domain name and name servers) would be Transmission from Registrars required to be disclosed. The lawful basis would be Article 6 (1) lit. b) registrar to registry Registries GDPR should personal data be involved for registrars and Article 6 (1) lit. f) GDPR for registries. For other data elements Article 6 (1) lit. f) GDPR. Certain data elements (domain name and name servers) would be Registrars required to be transferred from the registrar to registry. The lawful basis Disclosure Registries would be Article 6 (1) lit. b) GDPR should personal data be involved for registrars and Article 6 (1) lit. f) GDPR for registries. Data retention ICANN Article 6 (1) lit. f) GDPR 1) The term ICANN purpose is used to describe purposes for processing personal data that should be governed by ICANN organization via a Consensus Policy. Note there are additional purposes for processing personal data, which the contracted parties might pursue, but these are outside of what ICANN and its community should develop policy on or contractually enforce. It does not necessarily mean that such purpose is solely pursued by ICANN organization. 2) Note, the responsible party is not necessarily the party carrying out the processing activity. This applies to all references of ‘responsible party’ in these tables. 3) In relation to the application of Article 6 (1) lit. b) GDPR, input provided by external legal counsel. ICANN purpose Maintaining the security, stability and resiliency of the Domain Name System In accordance with ICANN’s mission through the enabling of lawful access for legitimate third-party interests to data elements collected for the other purposes identified herein. Processing activity Responsible party Lawful basis ICANN Collection Registrars Article 6 (1) lit. f) GDPR Registries Transmission from N/A N/A
268 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 52-53. 269 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 57. 270 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 57. 271 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 67. 272 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 67-71. ______Matthias Markus Hudobnik 58
registrar to registry Disclosure ICANN Article 6 (1) lit. f) GDPR Data retention ICANN N/A ICANN purpose Enable communication with and/or notification to the Registered Name Holder and/or their delegated agents of technical and/or administrative issues with a Registered Name Processing activity Responsible party Lawful basis Registrar Article 6 (1) lit b) GDPR for registrars Collection Registries Article 6 (1) lit f) GDPR for registries Transmission from ICANN Article 6 (1) lit. f) GDPR registrar to registry Registries Disclosure TBD N/A Data retention ICANN N/A ICANN purpose Provide mechanisms for safeguarding Registered Name Holders’ Registration Data in the event of a business or technical failure, or other unavailability of a Registrar or Registry Operator Processing Activity Responsible party Lawful basis Collection ICANN Article 6 (1) lit. f) GDPR Transmission from ICANN Article 6 (1) lit. f) GDPR registrar to registry Disclosure ICANN Article 6 (1) lit. f) GDPR Data retention ICANN Article 6 (1) lit. f) GDPR ICANN purpose Handle contractual compliance monitoring requests, audits, and complaints submitted by Registry Operators, Registrars, Registered Name Holders, and other Internet users. Processing Activity Responsible party Lawful basis Collection ICANN Article 6 (1) lit. f) GDPR5 Transmission from ICANN Article 6 (1) lit. f) GDPR registrar to registry Disclosure N/A N/A Data Retention ICANN Article 6 (1) lit. f) GDPR ICANN purpose Coordinate, operationalize and facilitate policies for resolution of disputes regarding or relating to the registration of domain names (as opposed to the use of such domain names), namely, the UDRP, URS, PDDRP, RRDRP and future-developed domain name registration- related dispute procedures for which it is established that the processing of personal data is necessary Processing Activity Responsible party Lawful basis ICANN Article 6 (1) lit. b) GDPR for registrars Collection Registrars Article 6 (1) lit. f) GDPR for registries ICANN Transmission from Article 6 (1) lit. b) GDPR for registrars Registries registrar to registry Article 6 (1) lit. f) GDPR for registries Registrars ICANN Registries Transmission to dispute Registrars dispute Article 6 (1) lit. b) GDPR for registrars resolution providers resolution provider - Article 6 (1) lit. f) GDPR for registries and ICANN processor or independent controller Disclosure N/A N/A Data retention N/A N/A ICANN purpose Enabling validation to confirm that Registered Name Holder meets optional gTLD registration policy eligibility criteria voluntarily adopted by Registry Operator. Processing Activity Responsible party Lawful basis Collecting specific data for Article 6 (1) lit. b) GDPR for registrars RA-mandated eligibility Registries Article 6 (1) lit. f) GDPR for registries requirements Collecting specific data for Article 6 (1) lit. b) GDPR for registrars Registries registry operator-adopted Article 6 (1) lit. f) GDPR for registries
______Matthias Markus Hudobnik 59
eligibility requirements Transmission from registrar to registry RA- Article 6 (1) lit. b) GDPR for registrars Registries mandated eligibility Article 6 (1) lit. f) GDPR for registries requirements Transmission from registrar to registry Article 6 (1) lit. b) GDPR for registrars Registries registry-adopted eligibility Article 6 (1) lit. f) GDPR for registries requirements Disclosure Registries N/A Data retention Registries Article 6 (1) lit. f) GDPR
Recommendation 22 determines the significance of data processing agreements of ICANN organization with disputed resolution providers to determine the data retention period, as well as other items and fosters the possibility to release these decisions in public.273 Recommendation 26 refers to the provisions of joint controllers in Article 26 GDPR, processors in Article 28 GDPR, and furthermore, portrays the eligibility of ICANN organization to complete contractual agreements (e. g., Data Processing Agreement, Joint Controller) with data escrow providers and EBERO providers. These non-contracted parties are a crucial part of the registration data processing chain and are essential for establishing the requirements, and processes concerning the various data processing parties in general.274 Recommendation 27 suggests updating the relevant and necessary policy documents and procedures within the framework of the WHOIS system as the following documents: “Registry Registration Data Directory Services Consistent Labeling and Display Policy, Thick WHOIS Transition Policy for dot com, dot net, dot jobs, Rules for Uniform Domain, Name Dispute Resolution Policy, WHOIS Data Reminder Policy, Transfer Policy, Uniform Rapid Suspension System Rules.”275 Pursuant to Recommendation 28, the final gTLD Registration Data Policy shall be effective on 29 February 2020 and both, registries and registrars should be compliant - either via this final gTLD Registration Data Policy or the modification of the current practices to be in line with the Temp Spec, which expires on 25 May 2019 - until this date. Furthermore, the modifications of registries and registrars - to fulfill the (expired) Temp Spec - will not be sanctioned, particularly those modifications till 29 February 2020.276 Recommendation 29 focuses on remaining domain registrations with an administrative contact but with no or incomplete contact information of the registrant. Therefore, the recommendation is that previously to the removal of the “administrative contact fields, all registrars must ensure that each registration contains registered name holder contact information”277 required before 29 February 2020.278
273 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 72. 274 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 75. 275 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 75-76. 276 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 76. 277 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 76. 278 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 76. ______Matthias Markus Hudobnik 60
4.2.2 Conclusion The EPDP Final Report on the Temporary Specification for gTLD Registration Data dated 20 February 2019 is the Phase 1 of the EPDP-charter, established by the GNSO, which summarizes and modifies several significant policy provisions (e. g., data processing purpose, data elements for collection, transfer, retention and redaction) out of the 29 total recommendations. The final report sets out new arrangements to be compliant with the GDPR, especially, in the Temp Spec but also with other relevant policy documents and procedures (e. g., 2013 RAA, RA). On 04 March 2019, the GNSO approved the final report, which is now open for public comments from the members of the ICANN community until 17 April 2019. After the public comment period, the ICANN Board must decide whether or not to adopt the report as an ICANN Consensus Policy and implement it before 25 May 2019.279 The author analyzes only the most important of a multitude of recommendations. Firstly, Recommendation 1 is linked to Recommendation 20, which defines the respective purpose description for every processing activity in a very accurate manner, and connects them with the relevant lawful bases of the responsible parties for the gTLD registration data, which is the basis for the whole collection and transfer process of the personal data. In short, there are seven defined purposes but it is debatable whether the second purpose - “contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission through enabling responses to lawful data disclosure requests”280 - is adequate for the collecting and processing of personal data in the context of WHOIS?281 From a legal point of view, this seems to be more of a processing activity than a purpose as such. Furthermore, this ‘purpose’ might not be in line with the principle of data minimization. The precise articulation of the second purpose is also very general, and it is possible to subsume nearly every meaning under it. In short, it is crucial to distinguish between a purpose and a particular processing activity.282 Moreover, Article 6 (1) lit. f) GDPR stipulates that “processing is necessary for the purposes of the legitimate interests pursued by a third party.”283 Therefore, third parties with a legitimate interest can, in any case, lawfully access or disclose (redacted) personal data. The result of the final report shows that the business caucus, together with the governments, won this battle of purposes against the non- commercial group, and that is the reason why this purpose was determined.284 Secondly, Recommendation 5 defines the data elements that are required to be collected by registrars, which confirms the final results of the litigation further examined in Chapter 5. This
279 Cf ICANN, ‘GNSO Council Adopts EPDP Final Report on the Temporary Specification for gTLD Registration Data’, 04 March 2019, available at
285 Cf ibid. 286 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 14-15. 287 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 17-18. Cf ICANN, 'The Cookbook' (n 16) pp. 22-23. Cf Mueller, ‘Whois Reform, at Last’ (n 284). ______Matthias Markus Hudobnik 62
Chapter 4.1.2.2 further discusses whether legal entities should be addressed as natural or legal persons. Phase 2 of the EPDP-charter includes a set of issues and an ICANN Implementation Review Team (IRT), which is instructed to develop operational and contractual specifications for the policy implementation process. Taking this into account, the contracted parties need to decide whether to follow the Temp Spec or the new ICANN Consensus Policy, between the expiration date of the Temp Spec and the final policy document of the IRT. These matters include: a system for standardized access to non-public registration data, technical standards for access to non-public registration data, the territorial applicability of the GDPR in non-EU areas, legal entities as legal v. natural persons and credentials for access and terms of access e. g., certification v. accreditation.288 The results of the investigation show that there is an urgent need to develop access agreements to non-public registration data as well as develop technical standards for access to non-public registration data.289 Recommendations 5, 7, 8 and 10 prove that the second hypothesis - namely that ICANN v. EPAG has potentially influenced the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data (Temp Spec), especially in the context of Admin-C and Tech-C data - is correct. In short, almost all tech fields are optional to collect (e. g., this applies for the collected data of the registrars, the transfer of data elements from registrars to registries, transfer registrars/registries to the data escrow agent or redacted in the public RDDS) as was argued by the defendant in the litigation ICANN v. EPAG. The third hypothesis, which states that there is a necessity for a system of standardized access to non-public registration data, adjusted with the technical implementation process, which is also lawful under specific data protection laws, cannot be finally proven because this matter is part of Phase 2 of the EPDP on the Temp Spec. However, as described above it can be concluded that ICANN established a so-called ‘Technical Study Group on Access to Non- Public Registration Data’ which may work together with the EPDP team to find an appropriate solution to this issue. A comprehensive analysis of the non-public WHOIS regime categorized into a (self)-certification approach, accreditation approach, and legal due process approach is further explained in Chapter 4.1.4.1. An outlook on future issues is further discussed in the general conclusion in Chapter 6 .
288 Cf Olivier Crepin-Leblond, Kurt Pritz and Keith Drazek, ‘ICANN, the GDPR and WHOIS’, Notes of Nigel Hickson, WSIS Forum, 11 April 2019, available at
5 Case, ICANN v. EPAG Domainservices GmbH This chapter emphasizes the first litigation since the GDPR came into force on 25 May 2018.290 The case proves the hypothesis in the respective conclusion of the subchapter, but also in the general conclusion, namely that the litigation ICANN v. EPAG has potentially influenced the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data (Temp Spec), especially, in the context of Admin-C and Tech-C data. This chapter compares and analytically assesses the arguments of the court claims of the respective parties (e. g., ICANN as the applicant and EPAG, an ICANN-accredited registrar, as the defendant) and analyzes them in their different litigation stages of the involved German courts (e. g., Regional Court of Bonn and Higher Regional Court of Cologne). ICANN’s initial intention was to file a claim against EPAG to get further insights from the courts regarding the interpretation of the GDPR. In order to defend the personal data collection practices of registrants in the WHOIS databases to a maximum extent possible, but still being compliant under the GDPR. ICANN’s main aim was to guarantee the current data collection practices of the involved parties and retain GDPR compliant access to the data in the WHOIS databases for parties, which can prove that they have a legitimate purpose. EPAG as a future defendant in the trail clearly stated that they would no longer collect personal data – in other words, administrative and technical contact information via a new domain name registration process even if they are contractually obligated by ICANN through the 2013 RAA to do so. As an ICANN- accredited registrar, EPAG was convinced that particular provisions – in 2013 RAA replaced by the Temp Spec – to collect the administrative and technical contact information might not be compliant with the GDPR any longer.291 ICANN approved Temp Spec, which allowed ICANN and the gTLD registry operators and registrars to continue their current work under temporary rules to fulfill the existing ICANN agreements and community-developed policies in light of the GDPR. The detailed analyses of the various litigation stages of the involved German courts are further discussed in the relevant subcategories below.292
5.1 ICANN’s Motion for the Issuance of a Preliminary Injunction On 25 May 2018, ICANN hereinafter ‘applicant’ ordered by way of a preliminary injunction EPAG hereinafter ‘defendant’ located in Germany to “cease and desist, as an ICANN accredited registrar with regard to any generic Top-Level Domain”293 shown on a listing of the Top-Level Domains for which EPAG serves as a registrar, “from offering and/or registering second level domain names without collecting the following data of the registrant that registers that second level domain name through the defendant: The name, postal address, e-
290 Cf ICANN, ‘ICANN v. EPAG Domainservices, GmbH’, 25 May 2018, available at
294 See ibid. 295 Cf Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 3. 296 See Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) pp. 3-4. 297 See Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 4. 298 Cf ICANN, ‘ICANN Board Approves Temporary Specification’ (n 239). 299 Cf Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 14. ______Matthias Markus Hudobnik 65
300 See ICANN Board of Directors, ‘Section 4.4.1 of the Temporary Specification for gTLD Registration Data’, 17 May 2018, pp. 7-8, available at
309 Cf Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) pp. 18-19. 310 See Article 6 (1) lit. f) of the Regulation (EU) 2016/679 (n 6) 36. 311 Cf Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 19. 312 See Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 19. 313 Cf Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 19. 314 See Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 20. 315 Cf Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) pp. 21. ______Matthias Markus Hudobnik 67
5.1.1 EPAG’s protective letter Firstly, the defendant demonstrates in their protective letter that they would no longer collect personal data e. g., Admin-C and Tech-C data via a new domain name registration process because these data elements are not required. The defendant further states in the protective letter that the data of the domain holder permits an explicit allocation of a domain name to the holder as well as a contact to the domain holder if required. The applicant considers that the legal task can be effortlessly fulfilled without a further collection of Admin-C and Tech-C data and that there is no danger for the security and stability of the domain name system as a whole in acting as such. Additionally, the defendant advocates that if a further collection of data fields is required, then this is disputed and must be explicitly proven in connection with the enforcement of claims under trademark law as well as criminal prosecution.318 It is essential to mention that in the majority of the domain registrations, the customer data is identical with the domain holder. The Admin-C and Tech-C data which substantiated the defendant with data of “10 million registered domain names of the registrar Tucows Domains lnc, an ICANN-accredited registrar belonging to the Tucows group like the defendant”319 where they illustrated that “in significantly more than half of all registered domains the e-mail address of the domain holder is identical to that of Admin-C and Tech-C.”320 The defendant also outlines in the protective letter that “in more than three-quarters of all cases, all information for the first name, last name, organization, address, and e-mail is completely identical between owner and Admin-C”321 this strongly supports the argument of the defendant not further collect any Admin-C and Tech-C data elements. The defendant’s protective letter further states that in the event of technical and/or administrative queries, the defendant contacts the domain holder or the holder of the customer account if necessary but there is no Admin-C or Tech-C in this procedure explicitly required. Therefore, no collection of this particular data fields compulsory for the domain name registration process as such. Lastly, the defendant denies the general disadvantage argued by the applicant through the less collection or non-collection of the Admin-C or Tech-C data sets and clarifies that there is even the possibility to collect such data elements if it is particularly obligated to do so at a later date. Secondly, the defendant refers to Section 3.7.2 of the 2013 RAA and warns that the applicant cannot force the defendant to act unlawfully against this respective provision where the registrar is required not to act against applicable laws and state regulations. Consequently, to
316 See Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) pp. 21. 317 See ibid. 318 Cf Thomas Rickert, ‘EPAG Protective Letter’, Rickert Rechtsanwaltsgesellschaft mbH, 28 May 2018, 5, available at
322 Cf Rickert, ‘EPAG Protective Letter’ (n 318) pp. 6-8. 323 Cf WP29, ‘Letter from Peter Schaar to Vinton G. Cerf regarding WHOIS’ (n 216) pp. 1-2. Cf also Rickert, ‘EPAG Protective Letter’ (n 318) 8. 324 See International Working Group on Data Protection in Telecommunications, ‘Working Paper on Privacy and Data Protection Issues with Regard to Registrant data and the WHOIS Directory at ICANN’, 27-28 November 2017, 4, available at
5.2 Court Order from the Regional Court of Bonn on Application for Preliminary Injunction On 29 May 2018, the Regional Court of Bonn from now on ‘court’ denied the application for a preliminary injunction because in its view it was unfounded as well as not substantiated. The court points out that it is factual that there is the formally contractual obligation via the Section 3.4.1 related to 3.3.1.7 to 3.3.1.8 of the 2013 RAA between the applicant and the defendant, which obligates the defendant to further storage and collect Admin-C and Tech-C contact data. This procedure is also in line with the previous domain name registration process and practices of the defendant.333 Nevertheless, the defendant must also fulfill the applicable laws in connection with their services as a registrar and the court advocates that “the [applicant] can only claim loyalty to
325 See ibid. 326 See IWGDPT, ‘Working Paper on Privacy and Data Protection Issues’ (n 324) 4. See also Rickert, ‘EPAG Protective Letter’ (n 318) 9. 327 See IWGDPT, ‘Working Paper on Privacy and Data Protection Issues’ (n 324) 7. See also Rickert, ‘EPAG Protective Letter’ (n 318) 10. 328 Cf Rickert, ‘EPAG Protective Letter’ (n 318) 11. 329 See Rickert, ‘EPAG Protective Letter’ (n 318) 11. 330 See ibid. 331 See Rickert, ‘EPAG Protective Letter’ (n 318) 11. 332 Cf Rickert, ‘EPAG Protective Letter’ (n 318) pp. 11-12. 333 Cf Germany: Regional Court of Bonn (n 68) pp. 4-5. ______Matthias Markus Hudobnik 70
334 See Germany: Regional Court of Bonn (n 68) 5. Cf § 242 of the Performance in good faith in the Civil Code, Bürgerliches Gesetzbuch (BGB), available at
5.3 ICANN’s Immediate Appeal The applicant’s legal assessment in the immediate appeal dated 13 June 2018 is based on the following two arguments: Firstly, the defendant can fulfill the contractual requirements through the collection of administrative and technical contact data and is even not obligated to collect them as a personal data set. Secondly, the collection of personal data of a natural person is feasible as it is required under the contractual obligations between the applicant and the defendant.344
5.3.1 Lawfully collection of Admin-C and Tech-C data as well as lack of obligation to collect personal data The applicant points out that the collection of Admin-C and Tech-C data is lawfully as well as that there is the contractual obligation under the 2013 RAA and the Temp Spec to collect personal data of natural person’s e. g., Admin-C and Tech-C data. According to (14) GDPR, only the processing of personal data in connection with natural persons is obligated. The applicant further claims in the immediate appeal that ”the application for a preliminary injunction is not directed at the collection of personal data, but rather the collection of Admin-C and Tech-C data.”345 In the view of the defendant generally, no collection of Admin-C and Tech-C data is performed neither if it is personal data or not nor a differentiation is done if the data subject is a legal or natural person. Nevertheless, the chamber rejected the injunctive relief of the applicant due to the conflict of the data collection (e. g., Admin-C and Tech-C) with the GDPR as a whole, and therefore the applicant made an alternative application for relief.346 The alternative application for relief of the applicant states the following: “only if the consent of the Admin-C and Tech-C for the collection of this data has been obtained for the purpose of enabling contact for administrative and technical matters or if no personal data of a natural person is concerned in the first place.”347 The applicant further conducts that regardless of the interpretation method of the GDPR, the chamber of the court must accept this limitation as well as an alternative application for relief.348 The final argument in the alternative application of the applicant is that “even after the strictest reading of the GDPR imaginable, it can and must be lawful to provide your contact
342 See Germany: Regional Court of Bonn (n 68) 6. 343 Cf Germany: Regional Court of Bonn (n 68) 6. 344 Cf Jakob Guhn, ‘Immediate Appeal’, JONES DAY Rechtsanwälte, 13 June 2018, 18, available at
5.3.2 Lawfully collection of Admin-C and Tech-C data even if it is personal data In the applicant’s view, the collection of Admin-C and Tech-C data of natural persons is lawful for the reason that the binding obligations are fulfilled under the GDPR. As these obligations are the following: Article 5 (1) lit. b) GDPR, Article 5 (1) lit. c) GDPR as well as Article 5 (1) lit. a) GDPR and Article 6 GDPR.351 Firstly, the applicant highlights in the immediate appeal that in the decision of the Regional Court of Bonn on the application for preliminary injunction “the chamber has neither correctly understood the legitimate purpose of data collection for the Admin-C and Tech-C, nor has it examined the principle of data minimization in relation to this actual purpose.”352 The applicant further refers to the purposes of Section 4.4.5, 4.4.6 (e. g., to fulfill the established communication) and 4.4.7 (e. g., management of domain names via a request of the domain name holder). As well as the Section 4.4.8 (e. g., consumer protection, investigation of cybercrime) and 4.4.9 (e. g., law enforcement requirements) of the Temp Spec and examines again that these purposes are specified, explicit and legitimate according to Article 5 (1) lit. b) GDPR. In other words, the registrant may delegate the task to a third person where the information of the Admin-C and Tech-C is necessary to perform the task as well as for law enforcement and trademark purposes to determine the registrant or if the activity is delegated to a third person. Further details regarding the applicant’s submission for the preliminary injunction discussed in Chapter 5.1 and the purpose limitations under Article 5 GDPR in Chapter 4.1.3.353 Secondly, the applicant once again assesses that the processing is adequate and limited to what is necessary under Article 5 (1) lit c) GDPR. The applicant claims that the court fails to “recognize the specified and explicit purposes in its decision and does not strike the right balance between the question of the need to collect the data and legitimate purposes.”354 According to the decision mentioned above, the chamber’s view is that the data collection is not essential for preventing domain name security difficulties, which is against the applicant’s view. The applicant argues that the court’s conclusion is incorrect and denies that the collection does not prevent the security of the domain name system and refers to the
349 See Guhn, ‘Immediate Appeal’ (n 344) 32. 350 Cf Guhn, ‘Immediate Appeal’ (n 344) 32. 351 Cf Guhn, ‘Immediate Appeal’ (n 344) 19. 352 See Guhn, ‘Immediate Appeal’ (n 344) 19. 353 Cf Guhn, ‘Immediate Appeal’ (n 344) pp. 19-21. 354 See Guhn, ‘Immediate Appeal’ (n 344) 22. ______Matthias Markus Hudobnik 73
355 Cf Guhn, ‘Immediate Appeal’ (n 344) 22. 356 Cf Guhn, ‘Immediate Appeal’ (n 344) pp. 23-24. 357 See (40) of the Regulation (EU) 2016/679 (n 6) 23. Cf Guhn, ‘Immediate Appeal’ (n 344) 24. ______Matthias Markus Hudobnik 74
358 Cf Guhn, ‘Immediate Appeal’ (n 344) pp. 24-26. 359 See Guhn, ‘Immediate Appeal’ (n 344) 26. 360 See (44) of the Regulation (EU) 2016/679 (n 6) 25. 361 Cf Guhn, ‘Immediate Appeal’ (n 344) 27. 362 See Guhn, ‘Immediate Appeal’ (n 344) 28. ______Matthias Markus Hudobnik 75
363 Cf Guhn, ‘Immediate Appeal’ (n 344) pp. 28-29. 364 Cf Article 7 and Article 8 of the Charta of Fundamental Rights of the European Union (2000/C 364/01), 18.12.200, 10, available at
5.3.3 EPAG’s Comments on ICANN’s Immediate Appeal In the defendant’s comments on the applicant’s immediate appeal dated 10 July 2018, the defendant at first-hand points out that the proceedings are “the applicant’s inability to assess and adapt its practices to comply with European data protection law.”370 The defendant criticizes the since 2003 from data protection authorities assessed compliance issues of the applicant as well as the intention to change the existing WHOIS system to the minimum extent feasible to be compliant with the GDPR, as stated in the Temp Spec. Additionally, the defendant highlights that “the result is inconsistent, contradictory and ultimately does not comply with applicable law”371 and illustrates that the GDPR is more extensively than a minimal change of the publication of personal data in the WHOIS system as such. The defendant advocates again that with the review process of their data protection policies and the effect of the GDPR they will no longer collect Admin-C and Tech-C data - because it is not necessary and in line with the principle of data minimization - to be compliant with the GDPR.372 Furthermore, the defendant refers to the letter of the EDPB dated 05 July 2018 and notes that the guidance of the EDPB is in line with their view, namely that it is essential to differentiate between the different purposes for data processing and collection of the various involved parties and not lump them together. Moreover, the defendant points out that the applicant has an inconsistent data protection assessment, and the defendant is forced to violate the GDPR when transferring or processing personal data and is incapable of fulfilling the respective agreements. Firstly, the defendant examines that the applicant violates various GDPR principles e. g., the principle of purpose limitation according to Article 5 (1) lit. b) GDPR, as well as the principle of data minimization under Article 5 (1) lit. c) GDPR and the legal basis for the lawfulness of processing, namely necessary for the performance of a contract under Article 6 (1) lit. b) GDPR which is not appropriate. Secondly, the applicant advocates that there are suitable alternative legal basis’s applicable and that the data collection of Admin-C and Tech-C
367 Cf Guhn, ‘Immediate Appeal’ (n 344) 31. 368 See Guhn, ‘Immediate Appeal’ (n 344) 31. 369 See ibid. 370 See Thomas Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’, Rickert Rechtsanwaltsgesellschaft mbH, 10 July 2018, 2, available at
373 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) pp. 4-5. Cf also EDPB, ‘Letter from Jelinek to Marby’ (n 69) 2. 374 See Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 5. 375 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) pp. 7-14. ______Matthias Markus Hudobnik 78
376 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) pp. 7-8. 377 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 10. 378 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 11. Cf also Germany: Federal Court of Justice (Bundesgerichtshof BGH), I ZR 150/09, 09 November 2011, 24, available at
382 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 12. 383 See ICANN Board of Directors, ‘Specification 3.18.2 of the 2013 Registrar Accreditation Agreement’, 27 June 2013, pp. 21-22, available at
388 See Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) pp. 14-15. 389 See Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 16. 390 Cf Article 7 (4) of the Regulation (EU) 2016/679 (n 6) 37. 391 See Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 17. 392 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 17. 393 See Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 17. ______Matthias Markus Hudobnik 81
394 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) pp. 17-19. 395 See Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 20. 396 See ibid. See also C-203/15 Tele2 Sverige [2016] (ECJ, 21 December 2016), para. 103, 110, 120, available at
5.4 Court Order from the Regional Court of Bonn in the Preliminary Injunction Proceedings On 16 July 2018, the Regional Court of Bonn ordered that “the applicant’s immediate appeal of 13 June 2018 against the decision of the chamber of 29 May 2018 will not be remedied and the case will be referred for a decision to the Higher Regional Court of Cologne as the court of appeal.”399 The court further points out that “there was no basis for granting relief, either in view of the original (main) application or in view of the submitted alternative application.”400 The court claims that it currently not sees the necessity for an additional collection of administrative and technical contact data, and it is evident that the collection of more data elements leads to a plainer clarification process of whom the data is stored as well as provides stronger, and more broaden opportunities to gain the data subject’s stored information. The essential point is that the court examines that also before the GDPR came into force the data collection of Admin-C and Tech-C was not compulsory and depended on a free will of the domain holder to provide the personal data or not. Taking this into account, the court argues that this proofs that the further collection of e. g., Admin-C, and Tec-C data elements is not necessarily because the domain name system worked in the past also without any further potential collection of these data elements. Subsequently, this illustrates that the argumentation of the applicant, namely to force the defendant collecting Admin-C and Tech-C data for the reason that these data elements are indispensable necessary seems to be mistaken.401 Moreover, the court was not convinced by the argument of the applicant “justifying the necessity of storing the data of third parties in the Admin-C and Tech-C categories with the corresponding needs of the registrant itself”402 and concludes that from a legal point of view it has no decisive relevance for the contractual connection among the defendant and applicant. The court also recognizes that the applicant might be correct that the defendant is contractually obligated to collect administrative and technical contact data via the agreement - based on consent if a person might be involved - with the applicant, but this does not apply to the alternative application in the immediate appeal.403 In short, the chamber criticizes that “it is too vague to determine how consent is to be secured or recorded in the registration process in the future and what specific action is therefore requested from the applicant.”404
398 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 22. 399 See Germany: Regional Court of Bonn in the Preliminary Injunction Proceedings (n 68) 2. 400 See ibid. 401 Cf Germany: Regional Court of Bonn in the Preliminary Injunction Proceedings (n 68) pp. 2-3. 402 See Germany: Regional Court of Bonn in the Preliminary Injunction Proceedings (n 68) 3. 403 Cf Germany: Regional Court of Bonn in the Preliminary Injunction Proceedings (n 68) 3. 404 See Germany: Regional Court of Bonn in the Preliminary Injunction Proceedings (n 68) 3. ______Matthias Markus Hudobnik 83
Moreover, the court assesses that defendant’s current collection practices gathering personal data are not in line with data protection law because the registration procedure cannot guarantee that the registrants have lawfully obtained the consent of the third party - if so there is currently no verification evaluation implemented to recognize it - for the data collection as such. The court highlights that the data collection and processing may be lawful if the defendant seeks the consent of the affected party e. g., data subject for the particular purposes, but it must stick to particular period time. The chamber concludes that the same applies for the alternative application of the claim in which the applicant emphasizes on exceptional cases where - related to administrative and technical contact data - elements are not falling under the scope of personal data under the GDPR. It is the case in the context of a legal person connected to a registrant’s delegation of the Admin-C and Tech-C tasks. Lastly, the court is referring to the above stated and concludes that the evaluation can only be effective and successful in connection with the implementation of an ex-post assessment by the defendant. This procedure may be utilized to evaluate if personal data is processed concretely, and this assumes that there are already (personal) data elements of the domain holder available; otherwise, it is not conceivable.405
5.5 ICANN’s Supplemental Submission to the Higher Regional Court of Cologne The applicant negates the justifiability of the court remedy order in the supplemental submission dated 27 July 2018 and illustrates the two following arguments:406 Firstly, the legal assessment of the remedy order lacks on the pertinent facts and secondly, the main, as well as the alternative claim, are legally well-founded.407 Starting with the first argument, the applicant states that the defendant is “still in the position to collect such data but is in the process of changing the system,”408 and the suggestion of the remedy order negates that the voluntary possibility for the registrant to still provide the defendant with the administrative and technical contact data is out of dispute. The applicant further claims that the defendant is still able to gain administrative and technical contact data from the registrant. Also, the applicant refers to the remedy order of the court to emphasize in the context of the consent verification process where the court argues that this was not possible within the respective framework, but the applicant represents the opposite view. In short, the decision of the court is misinterpreted, as the court has focused the responsibility on the wrong party for seeking the necessary explicit consent as such.409
405 Cf Germany: Regional Court of Bonn in the Preliminary Injunction Proceedings (n 68) pp. 3-4. 406 Cf Jakob Guhn, ‘Supplemental Submission’, JONES DAY Rechtsanwälte, 27 July 2018, 2, available at
The applicant claims that “the defendant as registrar is responsible for establishing its own domain name registration process”410 and if this process is not compliant with the GDPR, it is the registrar’s responsibility to adapt the procedure to be compliant with the GDPR. Taking this into account the applicant notes that neither the Temp Spec nor the 2013 RAA prevents the defendant from seeking the legal consent of the data subject for the registration process to be in line with the GDPR. Moreover, the applicant highlights that the court wrongly assumes that processing and collection of Admin-C and Tech-C data are optionally and not necessary. Subsequently, the applicant assesses that it makes very well sense to act as above mentioned if the data set is different from the domain holder’s data or the domain holder is instructing tasks of the Admin-C and Tech-C to third persons.411 According to Article 5 (1) lit. b) GDPR and the processing of administrative and technical contact data the applicant refers once again to the immediate appeal and their certain clarifications (further details emphasized in Chapter 5.3) which are in line with the guidance of the EDPB dated 05 July 2018 as well as that the concerns of the court are unfounded.412 In short, the EPDP indirectly approves the argumentation of a legitimate purpose if the registrant is voluntarily delegating tasks of an Admin-C or Tech-C to a third person.413 Finally, the applicant evaluates that the remedy order “does not even mention the criteria of legitimate purpose according to Article 5 GDPR; however, the applicant assumes that the regional court appears to no longer maintain the position that the data processing lacks a legitimate purpose according to Article 5 GDPR.”414 Furthermore, the applicant points out that the court even “does not cite any provision of the GDPR that is allegedly violated by collection the Admin-C and Tech-C data.”415 Concerning the main claim and under Article 6 GDPR the court states that the collection of administrative and technical contact data is not justified in terms of the consent verification of the data subject as well as the storage and collection of the administrative and technical contact data. Contrarily, the applicant contends that the “court’s reasoning is flawed”416 and that “the GDPR neither requires a ‘verification of consent’ from every entity relying on consent for its processing activities nor does the GDPR foresee an absolute imperative under which the ‘necessity’ criterion is applied.”417 In short, the applicant’s view is that the GDPR does not require a ‘verification of consent’ and argues that it “is merely a burden of proof rule” rather than “a condition for the validity of the consent”418 rule. In other words, the applicant illustrates that under Section 3.7.7.6 2013 RAA, the domain holder as usually the first controller has the contractual obligation to seek the consent of the third person involved, which is usually the Admin-C and Tech-C. The applicant
410 See Guhn, ‘Supplemental Submission’ (n 406) 3. 411 Cf Guhn, ‘Supplemental Submission’ (n 406) pp. 3-4. 412 Cf Guhn, ‘Supplemental Submission’ (n 406) 6. 413 Cf EDPB, ‘Letter from Jelinek to Marby’ (n 69) 4. 414 See Guhn, ‘Supplemental Submission’ (n 406) 6. 415 See ibid. 416 See Guhn, ‘Supplemental Submission’ (n 406) 7. 417 See ibid. 418 See Guhn, ‘Supplemental Submission’ (n 406) 7. ______Matthias Markus Hudobnik 85
419 Cf Guhn, ‘Supplemental Submission’ (n 406) 8. 420 See Guhn, ‘Supplemental Submission’ (n 406) pp. 8-9. 421 See Guhn, ‘Supplemental Submission’ (n 406) 9. 422 See ibid. 423 Cf Guhn, ‘Supplemental Submission’ (n 406) pp. 10-12. 424 See Guhn, ‘Supplemental Submission’ (n 406) 12. ______Matthias Markus Hudobnik 86
5.5.1 EPAG’s Comments on ICANN’s Supplemental Submission The defendant contradicts in the comments on the applicant’s supplemental submission dated 01 August 2018 that the guidelines of the EDPB solely confirm that there is a more substantial adaptation - more sufficient than the applicant’s former modifications - of the Temp Spec as well as the WHOIS model required to be compliant with the GDPR. The defendant clarifies that the EDPB explicitly states that the registrant should generally not be forced to seek personal data. Contradictory, to the EDPB’s guidance the Temp Spec as well as the 2013 RAA - which are the legal grounds - oblige the registrant to provide personal data for the administrative and technical contact (further details in Chapter 5.3.3).426 The defendant points out that “the applicant has not yet taken the necessary steps to be able to collect data based on consent in a legally unobjectionable manner and to transfer it to the applicant and other parties involved.”427 The defendant further acknowledges the EDPB’s advice to strictly distinguish the lawfulness of collection from the publication of the personal data and adds the fact that the EDPB’s letter is only dealing with the publication of personal data, and this does not (automatically) presume that the preliminary collection is lawfully and compliant with the GDPR. Taking this into account the defendant refers to their comments on the applicant’s immediate appeal (further details in Chapter 5.3.3) were the defendant already stated that a lawful collection of personal data is the precondition for a later publication of such respective data. Furthermore, the defendant is referring to the guidelines of the EDPB, which examines that the applicant’s necessary data collection practices – as pointed out in the applicant’s main submission - are unlawful and not enforceable.428 Moreover, the defendant summaries that the alternative claim of the applicant – to optionally process and collect personal data - is not within the scope of the contractual agreement. Presumably, this would be the case; there are still the “legal and factual preconditions”429 missed “to enable the defendant to collect the data on this basis.”430 Finally, the defendant highlights that the “applicant is subject to a misconception”431 and further concludes that “it is not a question of finding a legal basis for the fact that the data processing requested by the applicant is not possible, but rather of finding legal bases which allows data processing.”432
425 See ibid. 426 Cf Thomas Rickert, ‘EPAG’s Comments on ICANN’s Supplemental Submission’, Rickert Rechtsanwaltsgesellschaft mbH, 01 August 2018, pp. 1-2, available at
5.6 Order from the Higher Regional Court of Cologne Regarding ICANN’s Immediate Appeal On 01 August 2018, the Higher Regional Court of Cologne ordered that “the applicant’s immediate appeal of 13 June 2018 against the order of the Regional Court of Bonn of 29 May 2018, in the version of the non-remedy order of 16 July 2018, is rejected.”433 The court further assesses in the application of the main claim that “the granting the sought interim injunction fails in any case because the applicant has not sufficiently explained and made credible a reason for a preliminary injunction.”434 Furthermore, the basis of the claim focuses on the formulation rather than on the content, which results in cessation and desistance. Taking this into account, the court examines that the main application of the claim as well as the alternative application - with the minor difference of limitations at the alternative one - have similar intentions. The main application safeguards the applicant the collection of Admin-C and Tech-C data via the defendant who needs to fulfill the contractual agreements, namely offering the expected contractual promised services.435 The court points out “that a preliminary injunction is required in order to avoid substantial disadvantages”436 and is not convinced by the applicant’s argumentation of these substantial disadvantages. Also, for the applicant’s argumentation in the interim relief, that there are irreparable harm and the concern of the irretrievable data-loss in the case of a non-collection, applies the same. The court argues that a later data collection of the registrant’s personal data would also be feasible, and the technical change of the defendant does not hinder these practices.437 The court state that it is “not clear to what extent the storage of the data of the so-called Tech- C and the so-called Admin-C is necessary for the applicant’s purposes and, consequently, why failure to collect the data would result in substantial disadvantages.”438 Subsequently, the court analyzes that the collection of administrative and technical contact data is not necessary for the applicant’s purpose because until now it was up to the free will of the domain holder to delegate tasks to a third person - through the technical or administrative contact - or not. Taking this into account, the applicant states that a non-collection of administrative and technical contact data would result in a slower and less effective cybercrime investigation procedure and subsequently points out that, even if this would be the case, it does not justify the additional data collection, in the legal view of the court.439 Lastly, the court highlights that “irrespective of the fact that only the abstract danger of delays in a case of abusive practices cannot justify the sought preliminary injunction”440 and adds that defendant’s previous data set – which is undisputed by the applicant and further emphasized in Chapter 5.3.3 - supports the court’s legal decision. Finally, the court concludes
433 See Germany: Higher Regional Court of Cologne (n 68) 1. 434 See Germany: Higher Regional Court of Cologne (n 68) 2. 435 Cf Germany: Higher Regional Court of Cologne (n 68) 2. 436 See Germany: Higher Regional Court of Cologne (n 68) 3. 437 Cf Germany: Higher Regional Court of Cologne (n 68) pp. 3-4. 438 See Germany: Higher Regional Court of Cologne (n 68) 3. 439 Cf Germany: Higher Regional Court of Cologne (n 68) pp. 3-4. 440 See Germany: Higher Regional Court of Cologne (n 68) 3. ______Matthias Markus Hudobnik 88
5.7 ICANN’s Plea of Remonstrance It should be noted for this subchapter, that the content of the applicant’s plea of remonstrance is heavily based on procedure argumentations (e. g., violation of the applicants right to be heard and that the appellate court failed to give the applicant proper notice concerning Section 139 ZPO) of the applicant. Therefore, the author focuses on the most relevant arguments to the topic and the research questions. Firstly, the applicant once again analyzed the decision of the appellate court dated 01 August 2018 and submitted a plea of remonstrance with the request “to continue the immediate appeal proceedings according to Section 321a para. 5 ZPO”442 and further referred to the primary and alternative claim in the initial motion for issuance of the preliminary injunction (further emphasized in Chapter 5.1). Within the plea of remonstrance, the applicant demonstrates that the appellate court missed dealing with fundamental facts of the case as well as legal issues. The applicant negates the fact that a later collection of administrative and technical contact data is conceivable, but more astonishing is the fact that even the defendant was not arguing this approach as such. Secondly, the applicant refers to the application of the immediate appeal (further discussed in Chapter 5.3) where it is comprehensively explained that a later collection will be opposing the process in terms of the delegation of tasks to third parties since the data is not collected. The applicant states that the result would be an irreversible loss of these crucial data elements and forces the registrant to maintain these tasks - which were before (potentially) delegated to third parties via the administrative and technical contact - by them self. Additionally, the applicant highlights the risk that due to the legal uncertainty and the ongoing litigation, it may potentially take years without a final decision. In the end, this leads to a non-collection of these data elements and may result in the complete elimination of the previous collection practices of the administrative and technical contact data.443 Finally, the applicant claims that the appellate court has “fundamentally misunderstood the immediate consequences of its decision.”444 Lastly, the applicant assesses that the court is subject to a wrong legal assumption concerning the only abstract danger. In short, the applicant negates the court’s view and states that an only abstract danger is very well enough to justify the preliminary injunction.445
441 Cf Germany: Higher Regional Court of Cologne (n 68) pp. 3-4. 442 See Jakob Guhn, ‘Plea of Remonstrance’, JONES DAY Rechtsanwälte, 17 August 2018, pp. 1-2, available at
For example, in the case of fraud or cybercrime “the legally protected interests involved”446 are vitally important, have a profound impact and fall under the scope of applicability to justify also only on a theoretical danger approach. Furthermore, the applicant refers to the submission of the preliminary injunction and underscores that the administrative and technical contact is the key person to communicate and advice fraud or cybercrime victims, which is essential to mitigate the abusive behavior and react efficiently. Thirdly, the applicant highlights that the defendant is forced by contractual agreements (e. g., 2013 RAA, RA, Temp Spec) to collect and storage administrative and technical contact data, especially concerning the alternative claim, which does not force the defendant to collect and store personal data sets of the Admin-C and Tech-C. Also, the procedure in doing so is under the free will of the defendant, in either seeking the consent of the data subject or not. Lastly, the applicant refutes that “the defendant cannot argue that such cease and desist claim unfairly affects its interests.”447 Contradictorily the defendant’s practice of non-collection of administrative and technical contact data through the domain name registration is their independent decision and even when the collection is lawfully under the seeking consent from the particular data subject. Taking this into account, the applicant concludes that, the defendant is even in the situation to decide whether providing their domain registration services to registrants – through the collection practices as mentioned above - as contractually stipulated or breaching the agreement.448 Finally, the applicant points out that there is a matter of urgency related to the present case and criticizes that “the appellate court had wrongly applied stricter requirements on urgency and assumed that the Admin-C and Tech-C data can be collected at a later stage.”449 Subsequently, the appellate court would not have “wrongly rejected a concrete danger from the delays in collecting Admin-C and Tech-C data”450 and in conclusion, “it would not have rejected the urgency of the applicant’s claim.”451
5.7.1 EPAG’s Comments on ICANN’s Plea of Remonstrance In the defendant’s comments on the applicant’s plea of remonstrance dated 30 August 2018, the defendant at first-hand points out that it is unfounded as well as that there is no violation of the applicant’s right to be heard in the appellate court’s decision dated 01 August 2018.452 Contradictorily, the applicant attempts to newly roll up the case, which is not in line with the purpose of the plea of remonstrance and argues that the appellate court’s decision is reprehensible from a procedural point of view. Under Section 139 para. 2 ZPO is to highlight
446 See Guhn, ‘Plea of Remonstrance’ (n 442) 10. 447 See Guhn, ‘Plea of Remonstrance’ (n 442) 13. 448 Cf Guhn, ‘Plea of Remonstrance’ (n 442) pp. 11-13. 449 See Guhn, ‘Plea of Remonstrance’ (n 442) 14. 450 See ibid. 451 See Guhn, ‘Plea of Remonstrance’ (n 442) 14. 452 Cf Thomas Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’, Rickert Rechtsanwaltsgesellschaft mbH, 30 August 2018, 2, available at
453 See Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’ (n 452) 3. 454 Cf Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’ (n 452) pp. 4-5. 455 See Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’ (n 452) 6. 456 Cf Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’ (n 452) 7. ______Matthias Markus Hudobnik 91
5.8 Order from the Higher Regional Court of Cologne Regarding ICANN’s Plea of Remonstrance On 03 September 2018, the 19th Civil Senate of the Appellate Court of Cologne ordered: “that the plea of remonstrance of 17 August 2018 filed by the applicant concerning the order of the Senate of 01 August 2018 is rejected.”461 The Senate highlights that the applicant’s right to be heard is not violated and the Higher Regional Court of Colognes decision dated 01 August 2018 was nor unlawfully, neither surprisingly for the applicant, but somewhat foreseeable as well as the applicant could comment on it.462 Furthermore, the Senate points out that “in the absence of a violation of the right to be heard there is no possibility for a ‘new decision,’ weighing of interests or holding an oral hearing, ‘in order to clarify any ambiguities in this case.’”463 The court examines that the reasoning of the preliminary injunction is not similar to the Senate’s decision dated 01 August 2018 and therefore a further assessment has no right to exist. Moreover, the court does not see the matter of urgency in the context of the preliminary injunction which is in contrast to the consideration of a (potential) ECJ referral – where a timely decision is unforeseeable – as stipulated by the applicant cannot be approved by the Senate.464 Apart from that, the Senate examines that the issues comprehensively pointed out in the decision dated 01 August 2018, are inappropriate to solve the objections of the applicant. The Senate finally points out that “there are no reliable indications for its assumption that a temporary non-collection of data on the so-called Admin-C and Tech-C could not be rectified or that in such case such damage was caused to the applicant that the disadvantages associated with the requested injunction caused to the defendant and third parties are
457 Cf Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’ (n 452) pp. 8-9. 458 See Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’ (n 452) 9. 459 See ibid. 460 Cf Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’ (n 452) 9. 461 See Germany: Higher Regional Court of Cologne in the Plea of Remonstrance (n 68) 1. 462 Cf Germany: Higher Regional Court of Cologne in the Plea of Remonstrance (n 68) 2. 463 See Germany: Higher Regional Court of Cologne in the Plea of Remonstrance (n 68) pp. 2-3. 464 Cf Germany: Higher Regional Court of Cologne in the Plea of Remonstrance (n 68) 3. ______Matthias Markus Hudobnik 92
5.9 Conclusion This litigation has shown both the practical relevance of the WHOIS system and the GDPR, and that a reform of the current situation is necessary and indispensable in order to be compliant with data protection laws. The defendant consistently referred to the data collection practice of the applicant, and emphasized that this procedure was neither necessary nor GDPR compliant. At the same time, the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data (Temp Spec) was still in full progress. Already the ‘Initial Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’467 (initial report), dated 21 November 2018, stated that the data collection of Admin-C and Tech-C was not necessary and if it were to be collected, then it must be optional. On 03 September 2018, the Higher Regional Court of Cologne decided in the final judgment of the litigation, that the previous data collection practices were unlawful under the GDPR. This final decision was made whilst the EPDP on the Temp Spec was in process, and proves that the second hypothesis, namely that ICANN v. EPAG has potentially influenced the EPDP on the Temp Spec especially in the context of Admin-C and Tech-C data, is correct. The ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’468 (final report), dated 20 February 2019, reconfirms the above legal perspective within their 29 policy recommendations. As a result, almost all tech fields are either optional to collect (e. g., this applies for the collected data of the registrars, the transfer of data elements from registrar to registry, transfer registrars/registries to the data escrow agent) or redacted from the public RDDS, as was argued by the defendant in the litigation ICANN v. EPAG.
465 See Germany: Higher Regional Court of Cologne in the Plea of Remonstrance (n 68) 3. 466 Cf Germany: Higher Regional Court of Cologne in the Plea of Remonstrance (n 68) pp. 3-4. 467 Cf ICANN GNSO, ‘Initial Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’ (n 247). 468 Cf ICANN GNSO, ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’ (n 250). ______Matthias Markus Hudobnik 93
The following subchapter provides answers to the research questions raised in relation to the litigation at hand:
5.9.1 Is the further collection and storage of personal data - of the administrative and technical contact so-called Admin-C and Tech-C - besides the data of the registrant as stipulated via the 2013 RAA, lawful under the GDPR? The final decision of the comprehensively analyzed litigation ICANN v. EPAG (further details explained in Chapter 5.1 to 5.8) through the various procedural court stages, is that the collection of administrative and technical contact data is unlawful under the GDPR. The results of the final decision support the previous prediction that the WHOIS system was modified to be compliant with the GDPR as well as to restrict the current data collection practices of the different stakeholders involved to the maximum extent possible in order to make them compliant with the GDPR. Data collection is only lawful under particular purposes and legal grounds stipulated in the GDPR. For a better understanding, the author provides a brief chronological overview of the various procedural stages, starting with the decision of the Regional Court of Bonn. Firstly, the court decided that the application for a preliminary injunction was unfounded as well as unsubstantiated and concluded that there was no collection and storage of Admin-C and Tech-C required, which is also in line with the GDPR’s principle of data minimization. Finally, the court referred to the defendant’s clearly illustrated number of previous registrants, who had not stored or collected contact details, and did not even have any implications with their domains at all, which again strongly supports the court’s decision (further details emphasized in Chapter 5.2).469 Secondly, the Regional Court of Bonn referred to the applicant’s immediate appeal to the Higher Regional Court of Cologne without remedy. The Regional Court of Bonn underlines that it currently does not see any necessity for the collection of administrative and technical contact data. Furthermore, the court also argues that before the GDPR came into force, the data collection of Admin-C and Tech-C was not compulsory, and depended on the free will of the domain holder to provide their personal data or not. Finally, the Regional Court of Bonn highlighted that the data collection and processing may be lawful if the defendant seeks the consent of the data subject for their particular purposes, but must only retain the data for a particular period of time (further details explained in Chapter 5.4).470 Thirdly, the Higher Regional Court of Cologne rejected the applicant’s immediate appeal against the order of the Regional Court of Bonn. Also, the Higher Regional Court of Cologne advocated the legal view that the collection of administrative and technical contact data was not necessary for the applicant’s purpose, because previously it was up to the free will of the domain holder whether they made their data generally available, supplied personal data to a third party or withheld it. Another important practical implication – stated by the Higher Regional Court of Cologne - is that even if not collecting administrative and technical contact
469 Cf Germany: Regional Court of Bonn (n 68) pp. 4-6. 470 Cf Germany: Regional Court of Bonn in the Preliminary Injunction Proceedings (n 68) pp. 2-3. ______Matthias Markus Hudobnik 94
5.9.2 Are the processing purposes in the Temp Spec for the data of the Admin-C and Tech-C sufficiently specified? It must be highlighted that the Temp Spec in particular is not sufficiently determined, as was already assessed in the guidelines of the EDPB, dated 05 July 2018, as well as in the submissions of the defendant. The EDPB specifically pointed out that it is essential to differentiate between the various purposes (e. g., the purposes of controllers and third parties) for data processing and the data collection of the various involved parties and not lump them together.473 In the litigation ICANN v. EPAG, the defendant underlined the fact that the Temp Spec fails to provide a correct guideline in the context of the processing purposes. The results illustrate that there are Sections in the Temp Spec (e. g., Section 4.4.8 and 4.4.9 Temp Spec), which are imprecise, as the wording of various terms are too general (e. g., issues, needs of law enforcement authorities) in the respective sections, and subsequently it is not feasible to properly subsume.474 The results of this investigation show that ICANN’s interests regularly outweigh the interests of the affected parties.475 These findings suggest that ICANN needs to fundamentally modify the Temp Spec, as may currently be the case in the ongoing EPDP on the Temp Spec in order to make it compliant with the GDPR. Thus, there is a definite need for the realization of the recommendations stipulated in the ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process,’ dated 20 February 2019.476
471 Cf Germany: Higher Regional Court of Cologne (n 68) pp. 3-4. 472 Cf Germany: Higher Regional Court of Cologne in the Plea of Remonstrance (n 68) pp. 3-4. 473 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 4. Cf also EDPB, ‘Letter from Jelinek to Marby’ (n 69) 2. 474 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) pp. 7-8. 475 Cf Rickert, ‘EPAG Protective Letter’ (n 318) 11. 476 Cf ICANN GNSO, ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’ (n 250). ______Matthias Markus Hudobnik 95
6 General conclusion and outlook The main aim of this diploma thesis is to give a scientific analysis of the future of WHOIS and a perspective on the Policy Development Process under the GDPR, with a focus on the first significant litigation in this context, namely ICANN v. EPAG. Besides this, the diploma thesis summarizes the current situation and future expectations of the WHOIS system under the GDPR via general assessment of the analyzed Compliance Models on the one hand and, the previous Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data (Temp Spec) on the other. The author established three hypotheses in the Introduction. Two of them were fulfilled, namely the first and second, with the third unable to be finally proven, because the matter is part of the ongoing Phase 2 of the EPDP on the Temp Spec. The data in Chapter 4.1 and the conclusion of Chapter 4.1.5 prove that the first hypothesis, which states that the GDPR was the catalyst for the adoption of the Compliance Models and subsequently, the modification process of the previous WHOIS database publication practices, is correct. The WP29/EDPB already highlighted these compliance violations in connection with the WHOIS system since 2003477 - without any success in convincing ICANN and the stakeholders involved to modify the WHOIS system. After ICANN58, ICANN figured out their fundamental role in the context of WHOIS and the GDPR, and regularly came under legal pressure because of the encroaching date of the GDPR being enforced, which resulted in them seeking community input, and subsequently adopting various Compliance Models developed by the community. Consequently, the Temp Spec was adopted, and came into force on the same date as the GDPR, thus beginning the EPDP process. As a result, the application of the GDPR with its severe penalties was the reason for the adoption of the Temp Spec, which would otherwise never have been created. Also, the fact that these compliance violations, in connection with the WHOIS system, have been on the table since 2003, but never seriously been dealt with to make the WHOIS system complaint under the previous data protection laws, proves the validity of the first hypothesis. According to the second hypothesis, the analysis in Chapter 4.2 and the conclusion in Chapter 4.2.2 prove that the litigation ICANN v. EPAG has potentially influenced the EPDP on the Temp Spec, especially, in the context of Admin-C and Tech-C data. Firstly, the litigation ICANN v. EPAG, happened in parallel with the ongoing EPDP and was finally decided before the ‘Initial Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’478 (initial report), as well as the ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’479 (final report) was completed. Secondly, both reports fulfill precisely the criteria to be compliant
477 Cf WP29, ‘Letter from Isabelle Falque-Pierrotin to Cherine Chalaby and Göran Marby regarding GDPR’ (n 63) 3. 478 Cf ICANN GNSO, ‘Initial Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’ (n 247). 479 Cf ICANN GNSO, ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’ (n 250). ______Matthias Markus Hudobnik 96
______Matthias Markus Hudobnik 97
480 Cf ICANN GNSO, ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’ (n 250). 481 Cf ICANN, ‘GNSO Council Adopts EPDP Final Report on the Temporary Specification for gTLD Registration Data’ (n 279). 482 Cf Crepin-Leblond, Pritz and Drazek, ‘ICANN, the GDPR and WHOIS’ (n 288). ______Matthias Markus Hudobnik 98
Credentials for access and terms of access e. g., certification v. accreditation483 A reasonable approach to cope with this, is the future issue of standardized access to non- public registration data. ICANN established a so-called Technical Study Group on Access to Non-Public Registration Data (TSG), which is responsible for assessing the current status quo to find potential technical implementation solutions for the verification and permission of third party access to non-public registration data, where there is a legal and legitimate interest.484 On 04 April 2019, the NTIA commented on the EPDP and Phase 2 and highlighted the significance of creating a system which lawfully (e. g., through legitimate interest) allows access and the disclosure of non-public registration data for third parties (e. g., law enforcement, IP rights holders and cyber security researchers) to adequately follow their previous investigations.485 On 22 April 2019, ICANN responded and confirmed the NTIA’s statement and referred to the TSG, who finished a potential Technical Model for Access to Non-Public Registration Data. The model is planned to be shared with the EDPB in order to get further guidance on whether this model minimizes the “legal liability for ICANN gTLD contracted parties who provide access to non-public gTLD registration data.”486 On 17 April 2019, the European Commission (EC) analyzed Phase 1, highlighted the main concept of the GDPR and which elements needed to be fulfilled (e. g., a purpose for the data processing under a specific processing activity related to the specific personal data set) so that the result is a lawful processing of personal data. The EC confirmed the EDPB’s guidelines, regarding how to accurately differentiate between a purpose and a particular processing activity, and expressed their concern in the context of purpose two in Recommendation 1 (further explained in Chapter 4.2.2). In short, they analyzed that this is not the case for this particular purpose. Taking this into account, the differentiation of purposes between the various parties involved (e. g., ICANN, contracted parties) does not hinder or limit the access to non-public registration data by third parties with a legitimate purpose. The EC also stressed Article 6 GDPR, specifically, in terms of legitimate interest as a legal basis for disclosure of personal data to third parties (further developed in Chapter 3.1.4). The EC further underlined that legitimate interest as a legal basis for the processing of personal data, needs to outweigh the interests and fundamental rights of the data subject - as the result of a balancing test done by the data controller - to be compliant with the GDPR. In the author’s view, this means in practice that a registrar, as a potential data controller, may be forced to handle the procedure on a case by case basis. In the future, this may result in delays,
483 Cf ibid. 484 Cf ICANN, ‘ICANN’s Technical Study Group on Access to Non-Public Registration Data’, available at
487 Cf European Commission, ‘Comments on the Temp Spec for gTLD Registration Data Policy Recommendations’ (n 282) pp. 1-3. Cf also Farzaneh Badii, ‘European Commission Weighs in on the Side of Privacy in WHOIS’, 22 April 2019, available at
Allow parties claiming legal, legitimate purposes for accessing non-public gTLD registration data to access it in a uniform way Provide sufficient logging in order to enable auditing Ensure the integrity of the delivered data Enable trust in the proposed system by way of regular transparency and performance reports Require adherence to established, deployed standards, allowing for a design that supports wide interoperability Exhibit a relatively simple design that enables high availability, redundancy, and scalability Further assure public trust by identifying procedures for handling deviations from policy or regulation.”494 By March 2015, the IETF had already developed the RFC 7480 for the HTTP usage in the RDAP. Several questions (e. g., standardized access to non-public registration data, the establishment of the RDAP in place of the WHOIS protocol, the estimated costs for ICANN, registry operators and registrars for implementing the changing procedures of the WHOIS system) remain unanswered.495 Finally, the reduction of particular data fields in the public WHOIS database has definitely led to a severe decrease of more than 50% in global e-mail and spam volume, in the last year, based on the figures of Cisco Talos. According to the Anti-Phishing Working Group (APWG), the number of phishing sites has also declined.496 At least the end of 2019 will prove whether the (never-ending) story of the WHOIS modification process will finally come to a successful end. It will also show whether Phase 2 of the EPDP on the Temp Spec finalizes in time, as well as delivering a holistic solution for compliance with the GDPR that is respected by the wide range of stakeholder groups involved.
494 See Technical Study Group, ‘TSG01: Technical Model for Access to Non-Public Registration Data’ (n 493) 30. 495 Cf Andrew Lee Newton, Byron J. Ellacott and Ning Kong, ‘RFC 3912 - HTTP Usage in the Registration Data Access Protocol’, March 2015, available at
Primary Sources
Table of legal frameworks, agreements, resolutions, and recommendations
ICANN ICANN Board of Directors, ‘Temporary Specification for gTLD Registration Data’, 17 May 2018, 1, available at
______i ICANN, ‘Specification 4 lit. 1) of the Registry Agreement’, 31 July 2017, 63, available at
EU Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), available at
Germany § 242 of the Performance in good faith in the Civil Code, Bürgerliches Gesetzbuch (BGB), available at
Table of cases
Germany Germany: Regional Court of Bonn (Landesgericht LG) 10 O 171/18, 29 May 2018. Germany: Regional Court of Bonn (Landesgericht LG) 10 O 171/18, 16 July 2018. Germany: Higher Regional Court of Cologne (Oberlandesgericht OLG) 19 W 32/18, 01 August 2018. Germany: Higher Regional Court of Cologne (Oberlandesgericht OLG) 19 W 32/18, 03 September 2018.
______ii Germany: Federal Court of Justice (Bundesgerichtshof BGH), I ZR 150/09, 09 November 2011.
European Court of Justice (ECJ) • Case C-203/15 Tele2 Sverige [2016] (ECJ, 21 December 2016).
Secondary Sources
Books Hornung G, ‘Räumlicher Anwendungsbereich’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 265-266. Zerdick T, ‘Räumlicher Anwendungsbereich’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 159-167. Schumacher P, ‘Scope of application of the GDPR’ in Daniel Rücker and Tobias Kugler, New European General Data Protection Regulation (1st edn, C.H.Beck, Hart, Nomos 2018) pp. 37-41. Karg M, ‘Begriffsbestimmung „Personenbezogenes Datum“’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 282-293. Klabunde A, ‘Begriffsbestimmungen’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 172-175. Rücker D, ‘Scope of application of the GDPR’ in Daniel Rücker and Tobias Kugler, New European General Data Protection Regulation (1st edn, C.H.Beck, Hart, Nomos 2018) pp. 12-21. Roßnagel A, ‘Begriffsbestimmung „Verarbeitung“’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 298-304. Petri T, ‘Begriffsbestimmung „Auftragsverarbeiter“’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 330-331. Heberlein H, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 192-193. Dienst S, ‘Lawful processing of personal data in companies under the GDPR’ in Daniel Rücker and Tobias Kugler, New European General Data Protection Regulation (1st edn, C.H.Beck, Hart, Nomos 2018) pp. 50-53.
______iii Schanz P, ‘Rechtmäßigkeit der Verarbeitung’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 404-407. Klement J H, ‘Bedingungen für die Einwilligung’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 555-563. Heckmann D and Paschke A, ‘Bedingungen für die Einwilligung’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 250-251. Caspar J, ‘Allgemeines Widerspruchsrecht’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 696-699. Kamann H-G and Braun M, ‘Widerspruchsrecht’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 446-453. Schrey J, ‘General conditions for data processing in companies under the GDPR’ in Daniel Rücker and Tobias Kugler, New European General Data Protection Regulation (1st edn, C.H.Beck, Hart, Nomos 2018) pp. 147-149. Schiedermair S, ‘Europäischer Datenschutzausschuss’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 1157-1161. Albrecht J P, ‘Europäischer Datenschutzausschuss’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 867-877. Voigt P and von dem Bussche A, EU-Datenschutz-Grundverordnung (Springer Berlin Heidelberg 2018).
Background papers, research papers, and working papers ICANN organization, ‘Interim Model for Compliance with ICANN Agreements and Policies in Relation to the European Union’s General Data Protection Regulation – WORKING DRAFT FOR CONTINUED DISCUSSION’, The “Cookbook”, 08 March 2018, 6, available at
______iv ICANN, ‘WHOIS High-Level Technical Brief’, 20 April 2018, available at
______v Genty C, ‘Gouvernance de l’Internet et Économie Mondiale : Proposition d’un Modèle d’Évaluation de la Valeur d’un Nom de Domaine en tant qu’Actif Immatériel’, 23 April 2019, 81, available at
______vi ICANN, ‘ICANN Board Reaffirms Temporary Specification for gTLD Registration Data’, available at
______vii ICANN Wiki, ‘Data Escrow’, available at
______viii Cisco’s Talos, ‘Total Global Email & Spam Volume for March 2019’, available at
Other sources and documents Conrad D, ‘What is Whois’, GAC: Technical Seminar on WHOIS and Data Protection/Privacy Issues, ICANN63 meeting, 21 October 2018, pp. 5-6, available at
______ix European Data Protection Board, ‘THE EUROPEAN DATA PROTECTION BOARD’, Endorsement 1/2018, available at
______x Article 29 Data Protection Working Party, ‘Letter from Peter Schaar to Vinton G. Cerf regarding WHOIS’, 22 June 2006, pp. 1-2, available at
______xi ICANN, ‘Panel on ICANN and Data Privacy issuess’, Cross-Community Discussion with Data Protection Commissioners, ICANN58 meeting, 13 March 2017, available at
______xii