For a couple of decades, the Whois has been the who’s who of the Internet. But times change, laws change, and the Internet needs to keep functioning despite this. Cue the so-called Expedited Policy Development Process (EPDP) team at ICANN, which has been very busy since shortly after the General Data Protection Regulation (GDPR) came into effect. The team has been tasked, broadly speaking, with investigating ICANN’s compliance with the European data protection law. As a member of the team, and as the representative for the Internet service provider and connectivity provider constituency (ISPCP), I would like to give you an explanation of what the EPDP is all about, and how the Whois is likely to change as a result.
Registration data in a post-GDPR world
So, let’s go back a few months to get the lay of the land: When the GDPR kicked in on May 25th 2018, the ICANN Board of Directors was eager to get ICANN’s work in the area of gTLDs and the entire industry compliant with GDPR, so that the ICANN board issued the so-called “Temporary Specification” on May 17th 2008. This is a possibility in the ICANN bylaws that allows for the ICANN Board of Directors to adopt an emergency policy in cases where swift action is required but no sufficient time is available for the community to come together and develop a policy.
The Temporary Specification is a document governing registries’ and registrars’ operations with respect to registration data.
Registration data is the data of the registered name holder, the administrative contact, technical contact, and the billing contact, as well as a few more data elements, and it prescribes how in a post-GDPR world the contracted parties have to collect data and how they have to treat that data. This includes what they can publish in the light of GDPR and what data needs to be redacted. ICANN – as a multi-stakeholder-model based organization – is a very democratic global organization, and takes its raison d'être from all the stakeholders coming together and coming up with policy. Therefore, ICANN's bylaws state that in cases where temporary specifications or temporary policies are adopted by the board, the community needs to come together in an Expedited Policy Development Process and either confirm, amend, or reject the temporary specification.
Getting the backing of the community through the Expedited Policy Development Process
This is basically what we’re doing in the EPDP team at the moment. We are looking at all of the component parts of the temporary specification, and checking whether it is, a) compliant with the GDPR, and b) whether the policies are supported by the multi-stakeholder community. This has a range of challenges associated with it, because the representatives on this team, most of whom are experienced in policymaking and the domain industry, are not necessarily known for their expertise in legal compliance or data protection compliance work. And our group needs to take care of both the compliance layer – where we have only a little discretion if at all because we just have to make sure that everything is compliant with applicable law – and the policymaking layer, where there is more flexibility for the community.
Once we are done with our work, the outcome can then be a so-called consensus policy, which will be binding upon all contracted parties – that is, registries and registrars at the global level – without the need for ICANN to actually change its contract with those contracted parties. That’s the beauty of consensus policies, because they immediately become part of the contractual relationship between ICANN and registries and registrars.
But, having said that, we need to get to a consensus position, and that seems to be the hardest part, given the diverging and in part opposing positions held by the team members.
This group has been working very hard since its inception: We typically hold two telcos per week, each of which takes roughly two hours; then there are small team meetings for particular questions that are being worked on that come on top of that. And I think it’s fair to say that we have exceeded the expectations of some who thought that the work of this group would achieve nothing. We actually published our initial report in November 2018, and the public comment period, which solicited feedback from the community on our preliminary recommendations, ended on the 21st December. As I am writing this article, the EPDP team continues to analyze public comment and draw conclusions from them and work on consensus positions. Unfortunately, many in the team are using the comments supporting their positions – which, in part, they have written themselves – to relitigate the questions before us, hoping they can now get their way. As a consequence, we have not only made progress, but we have also moved backwards (not to square one, though) in some areas. As a consequence, it is difficult to predict what positions the group will come up with in its final report, as only a few areas of our draft final report are sufficiently stable.
The clock is ticking. We are due to deliver our final report in early February, so that the GNSO Council and the ICANN Board can review and adopt the recommendations prior to the expiry date of the Temporary Specification upon its 1st anniversary. There is a real risk of failing to achieve that task within the time available, so a lot of thought is being put into plan Bs, as well.
Making Whois GDPR-compliant
So this is where we have got to. What are the findings? What are our recommendations? I think all those who are interested in details should look at the EPDP team website, where all documents relevant to our work can be found. This includes transcripts of our meetings and even a photo, from which you can see that we can still smile together despite all the high-handed debates.
In a nutshell, you will see some changes to the content of the Temporary Specification that have quite some impact on the domain industry, and in particular Whois as we have known it for the past two decades. There is emerging consensus in our group that the administrative contact will disappear – there will be no Admin-C in the future, for example. As our preliminary recommendation stands, we will strip down the data set for technical contact and it is likely that that data will only be collected on an optional basis. We have more or less confirmed that most of the data that you previously found in public Whois will be redacted. We have a recommendation that requires ICANN to enter into contractual relationships or start negotiations on contractual relationships with contracted parties, escrow agents, and the emergency backend operator, which is an emergency backup function for failing registries to make sure that the transfer of data between those parties is governed by GDPR-compliant paperwork.
Perhaps the most important point is that we’ve also redefined the purposes for data processing. Previously there has been a catalogue of purposes for data processing which has been criticized not only by community members but also by the European Data Protection Board. The European Data Protection Board was of the opinion that ICANN unduly conflated its own interests with third party interests when it came to purposes for data processing. As a result, we spent a lot of time in narrowing down the purposes of data processing and aligning them with the actual operations and what’s required and thereby honoring the principle of data minimization.
I will not offer more details here, but leave that to our final report, which – if all goes well – will be published in the next few weeks. I should note, however, that we’ve reviewed all the data flows from collection to deletion, the way personal data travels between registries, registrars, escrow agencies, and other parties and attached to these flows a purpose as well as a rationale, including a legal basis required under the GDPR. There is still a lot of work to be done, but assuming that the concepts that we came up with do not get too much pushback from the community, I think we will soon be able to more or less complete our work on what we call the “gating questions”, so that we can then continue our work with some subsequent questions.
Responding to lawful disclosure requests – gaining access to non-public Whois data
Basically, we have two phases in our work, one of which deals with what data you can collect and how you can process the data (i.e. what can you do with it, how long can you retain it, or do you need retain it).
But we have not yet discussed the question of how third parties can potentially get access to that data, which is covered in the second phase.
Our group has been tasked with looking at questions of “access”, as it’s called in the paper work, and work on a policy / criteria for revealing data or, more precisely, how lawful data disclosure requests can be responded to and whether certain types of requestors can be accredited for certain types of queries to make the handling of requests more efficient.
That’s the question that most people are interested in, and many people that are working with us on this project are eagerly awaiting the second phase, because they are groups that have previously made use of Whois data for a variety of reasons, be it intellectual property enforcement, be it law enforcement, be it IT security companies or researchers that want to look at patterns of abusive behavior or otherwise to access data to improve the security level by including registration data in their work. So, this part of the work is surely the part where we will get some visibility. Also, this is potentially the more legally challenging part of our work to see who, under what circumstances, if at all, can get access to non-public data.
Thomas Rickert, Attorney-at-law and owner of Rickert Rechtsanwaltsgesellschaft mbH, Bonn, Germany (rickert.net) chairs eco’s Names & Numbers Forum. He is one of three co-chairs of the CCWG-Accountability.
Please note: The opinions expressed in Industry Insights published by dotmagazine are the author’s own and do not reflect the view of the publisher, eco – Association of the Internet Industry.