TL;DR: Much of the ICANN 63 conference focused on the GDPR’s effects on our industry. We’ve recapped the EPDP team’s work, focusing on the possible policy outcomes that could most significantly affect our resellers and registrants: should admin and tech contacts continue to be collected and published? Should domain providers be required to differentiate between different registrant types? What happens next in this policy creation process?
The last full week of October saw a group of Tucows staff attend the ICANN 63 conference in Barcelona. Our team participated in the ICANN policy development process, advocating for industry-wide policies and standards that will benefit our registrants and reseller partners.
Our summaries of the conference may not bring the sights and sounds — or delicious foods — of Barcelona to you, but they will help ensure you’re up-to-date on important developments in the ICANN community. ICANN has also released their own post-meeting policy report, so be sure to take a few minutes to check that out when you’re done with this post.
Resolving the conflicts between ICANN policy and the GDPR is a pressing challenge, and, as expected, the Expedited Policy Development Process (EPDP) team captured most of the attention during the week. Their work will also be our topic of focus for this post; our next will focus on the Unified Access Model.
Background on ICANN’s temporary specification and EPDP
We’ve written previously about ICANN’s Temporary Specification, the modifier to the 2013 Registrar Accreditation Agreement (RAA) which aims to close the gap between the GDPR and the RAA’s contractual requirements. The “Temp Spec” is valid only for one year, expiring in May 2019, at the end of which it must be replaced with a permanent policy. A year may sound like plenty of time to complete the necessary updates to ICANN’s contracts, but the typical turnaround time for a Policy Development Process is more like three to five years; the EPDP team has a very tight timeframe.
Why does this matter to us, our resellers, and domain owners?
ICANN has put together an Expedited Policy Development Process (“EPDP”) team, consisting of members from each of ICANN’s stakeholder groups, to work through the Temp Spec and confirm it (or some modified version of it) as a full Consensus Policy. This is crucially important for domain owners, as well as registrars, registries, and other industry participants, because the policy that emerges from the EPDP will define how people’s personal data are used for domain registrations moving forward. Domain owners may have new requirements for what information they need to provide when buying a domain, and how their data is shared or even published could depend on what they provide at the time of registration — more on that later. Registrars and registries will certainly have changes to make, but the full scope of these changes will only become clear as the EPDP team works through their open issues.
As an ICANN-accredited registrar, we’re in a potentially difficult situation. We have an obligation to adhere to ICANN’s Registrar Accreditation Agreement and Consensus Policies. However, if we don’t believe that the policy resulting from the EPDP work is fully compliant with the GDPR, we’d have to forgo some of our ICANN obligations in order to follow the law — similar to how we currently ignore a few of the Temp Spec’s requirements to ensure we’re compliant with the GDPR.
EPDP work at ICANN 63
At ICANN 63, there were several meetings during which the EPDP members went through a series of data elements workbooks to define purposes for each piece of registrant data that ICANN currently requires registrars to collect; this work began in virtual meetings in early October. Under the GDPR, there must be a legal basis (purpose) for each instance of data collection and processing, so the EPDP team needs to come to agreement about ICANN’s legal basis for requiring the data outlined in the Temp Spec. The workbooks help to accomplish this in a structured manner.
There were also presentations to the broader community, including open meetings where team members presented updates on the project and closed meetings where important groups at ICANN provided input towards the development of a final policy.
In these open presentations, the EPDP team updated the community at large about their work. They recapped the goal of establishing the list of data elements we work with, and the importance of following each element through its whole life (from collection to deletion) and analyzing the legal basis, or purpose, of everything that happens to it, which must be within ICANN’s defined mission. Each of those purposes was documented in a workbook, which the team then debates until the purpose can be accepted by everyone. As one team member described it, each workbook is like performing a Data Protection Impact Assessment for that specific data use, an exercise required under the GDPR for fully-compliant data processing. The team’s initial report is available on their wiki page in draft format, and when it’s updated to be a final (non-draft) version it will either include a policy recommendation itself or open questions that will then lead to a policy recommendation.
Debate over technical and administrative contacts
One of the most-debated topics in EPDP working meetings was the continued collection and publication of technical and administrative contacts for domains, which we have a significant interest in due to the litigation between EPAG (another Tucows-owned registrar) and ICANN.
Some EPDP members argue that this data should be collected. The domain owner may want to designate an alternate contact point, or a reseller may want to list themselves as the tech contact in order to help the registrant to more easily identify their service provider. And, as we know, ICANN has been pushing hard to maintain the requirement to collect the full pre-GPDR set of Whois data.
As they worked through the Purpose C Workbook, the admin contact was quickly agreed to be no longer necessary, and the EPDP team focused their debate on a proposal that registrars should be required to allow domain owners to designate a technical contact. The registrant could then decide whether they want to name an alternate contact point; if they do not, their own data would be copied to that other contact set.
Although this may appear to be a straightforward solution, it brings with it other issues. The purpose of having a tech contact is to provide an alternate point of contact, so we expect that most registrants who opt to do so would be supplying a third party’s info. In these cases, the registrar does not have a valid legal basis on which to process that data, as the alternate contact person would not be party to the registration contract, and the registrar has no clear way to obtain this contact’s specific, informed consent.
Ultimately, the EPDP team has tentatively agreed on a minimized tech contact data set, which the registrar would be required to allow, but would be optional for the registrant to provide. The specific data elements that would be included are yet to be determined, but will rely on the “legitimate interest” legal basis (Art. 6 1(f) of the GDPR), as they are not needed for performance of the contract, but a third party may have a legitimate interest in the data.
Beyond the not-so-simple collection of tech contact data, there is also debate about whether this information should be published. Right now, there is no consensus among the EPDP team as to whether the technical contact data must be provided (unredacted) in public Whois results. But if it is to be displayed, registrants will need to be made fully aware of that fact, because either the alternate contact info or their own registrant data would be published. And if an alternate contact’s data is to be published, finding a way to obtain consent from that individual is all the more important. Otherwise, we’d see situations where personal data is published unexpectedly, a huge privacy concern.
This is a complex situation, where different interests conflict, and there are no easy answers. We don’t see a good legal basis to require that the tech contact be published. If it is required, the registrant’s only choice is between publishing their own info or someone else’s — the “option” to provide a tech contact no longer seems optional.
Our reading of the legal requirement to provide data upon a showing of legitimate interest is that this legitimate interest must be demonstrated in each case. Anyone who has a legitimate interest to know the tech contact of a particular domain must be given that information, but that person doesn’t automatically get access to all other tech contacts, too. This is why we created a gated Whois: so that personal data can be provided when there is a legal basis but protected in situations where there isn’t.
Collecting different data in different situations
Another significant area of discussion among the EPDP members was to which registrants the GDPR protections should be applied. Should registrars differentiate by legal type, providing data protection to natural persons (i.e. actual people) but not to legal persons (i.e. corporations)? Then there’s the question of geographic location — should users local to the EU get GDPR protections while those outside the EU do not? We’ve shared our opinions on the location question already, and we have a similar position regarding the registrant type — we apply our GDPR protections uniformly to all registrants.
It was gratifying to hear our concerns echoed by other registrars and EPDP members. Differentiation by registrant type creates a lot of risk and uncertainty. How do we know if the registrant is a person or a corporation, should we simply rely on the presence or absence of data in the Registrant Organization field? If so, what happens when a natural person puts their own name in the Organization field, perhaps thinking that it must not be left blank, and their personal data is then published? Would we instead need to add a new “person type” field to the registration requirements, and depend on that to determine if the Whois data should be published or redacted? That sounds like a good solution on the surface, but it would be a significant change for our resellers to implement and would make the registration process more cumbersome and confusing for registrants.
Differentiating based on location is also more complicated than it might seem. If the address provided is in the EU but the IP geolocation shows North America, where do we consider them to be? Furthermore, this isn’t just about compliance with the GDPR and the rights of EU-locals. What about data handling laws from other jurisdictions, which may have similar requirements to the GDPR? Would we need to identify the various laws in each jurisdiction and apply them to the clients who we think come from those places?
Minimizing our data collection for all registrant types and keeping things consistent across the board naturally places us more in line with other laws and evolving standards. And, since we use processors in the EU, even if both we and the registrant are located outside the EU the GDPR’s requirements still apply to our data processing practices.
Even if the largest registrars have the resources to accommodate for all these intricacies in an accurate and automated manner, smaller businesses will likely struggle to implement such complex differentiation practices, and the liability risk for publishing personal data that should be redacted is significant enough to concern registrars of every size.
So far, the registrar representatives in the EPDP team have held firm and pushed for only optional differentiation, performed only with the consent of the data subject. In this case, we could continuing applying GDPR protections to all registrants by default, unless the registrant specifically requests otherwise. So, if things go as they have been, we think we’ll be able to accept the part of the policy that comes out of the EPDP.
Next steps for the EPDP
Like other PDPs, the EPDP will include a public comment period, which is the best time for all members of the ICANN community (including interested resellers and domain owners) to give their feedback on the EPDP team’s recommendations. There were questions around the ‘unified access model’ that ICANN has mentioned, (see our upcoming blog post on the topic), but the EPDP team continues (correctly) to focus on determining the legal basis for processing the data ICANN requires to be collected, which must be established before access to that data can be granted.
Work on a unified access model, “the definition and framework for reasonable access to registration data,” is part of what the EPDP is chartered to accomplish, but it must follow the completion of the EPDP’s Initial Report (mentioned above) and their eventual Final Report, which is due to be submitted to the GNSO Council by February 1, 2019. In the end, as Stephanie Perrin said in Barcelona, access itself is not a valid purpose under which to process data. Access may be provided, but the data is not collected specifically because someone might later want access to it.
Moving towards a future policy
Across the industry, there’s a shared commitment to the timely modification of policies and practices that place all ICANN requirements within the bounds of applicable law. In the first public forum of ICANN 63, our own CEO, Elliot Noss, talked about what he views as an encouraging level of collaboration. He said that at this ICANN meeting he’s seen more cooperation towards trying to resolve issues around Whois than he has seen on this issue in the year and a half that it’s been live, and perhaps on any issue this community has taken on. Elliot added that we have a unique opportunity here to demonstrate what the multistakeholder model can achieve.
The GDPR’s impact on our industry is not only about Whois data and the rules governing its disclosure. It’s also about ensuring that people maintain control over how their data is used, that when personal data is entrusted to a service provider it remains secure, and that the data subject’s rights are respected at all times throughout a domain name’s lifecycle. As a registrar, we are committed to these principles; as a community, we need to find a way to move forward with them in mind.