This is the third post in our series on the ICANN 63 conference that was held in Barcelona in October 2018. You can also take a look back at our recap of the EPDP team’s work leading up to and during the conference, and our discussion of the Unified Access Model, which will eventually govern how access to Whois data is provided.

Although it may seem that the GDPR is the only thing that matters in the domain industry right now, it wasn’t the sole focus of ICANN 63, and we don’t want to lose sight of the other valuable work that came out of the conference.

Tucows is an active participant in the ICANN community: the Chair of the Registrar Stakeholder Group (RrSG) is our Analytics and Policy Director; some of our staff are members of the RDAP Pilot Project and PPSAI Working Group, and observers of the EPDP; and Tucows representatives collaborate with the RrSG’s Compliance and TechOps sub-teams to help develop and implement policies and processes that will benefit our customers and the community at large.

Privacy and Proxy Service Accreditation

One significant work track within the ICANN community is around accreditation for providers of Privacy and Proxy services. Right now, any registrar can offer a Privacy or Proxy (“P/P”) service — our version is called Whois Contact Privacy —  for domains registered with them. However, one of the requirements in the 2013 RAA is that if ICANN adopts a policy establishing accreditation for P/P services, registrars must comply with that policy and become accredited to continue providing those services. Such a policy does not yet exist, but work towards one has been underway ever since that 2013 RAA requirement came into effect.

Back in December 2015, the Privacy & Proxy Services Accreditation Issues (“PPSAI”) PDP Working Group provided policy recommendations for how P/P Accreditation could work. Their Final Report included requirements for providers of P/P services and defined eligibility standards for users of P/P services.

An Implementation Review Team (IRT) was then convened in January 2016, in order to “assist [ICANN Org.] staff in developing the implementation details for the Privacy and Proxy Services Accreditation Program, to ensure the implementation conforms to the intent of the Final Recommendations” (reference). In the two and a half years that followed, the PPSAI IRT worked hard to transform the recommendations into actual accreditation agreement language.

One significant part of their implementation work was focused on the question of when underlying registration data is to be revealed. Another was related to the cost of accreditation; even now there remains unresolved conflict between the IRT members and ICANN staff resulting from ICANN setting the P/P accreditation fees extremely high — on par with ICANN’s actual registrar accreditation fee — without being able to justify this price-point.

We said this post would be focused on the non-GDPR meetings at ICANN 63, but the effects of that data privacy regulation are so far-reaching, it’s hard to avoid. Because of the GDPR, the ICANN community is now working to standardize how access to non-public Whois data will be provided. As a result, the PPSAI IRT work will be “slowed down” until the EPDP is complete and the full landscape of the GDPR’s effects on our Registrar Accreditation Agreement obligations is understood.

This is important for our resellers and registrants, because once the IRT resumes regular work and the Privacy/Proxy Accreditation Agreement is finalized, we’ll need to sign on and pass the requirements along to our resellers. The significant area of concern here is the fees that we mentioned previously, and so when the IRT reconvenes we’ll be pushing to understand the justification for those fees as well as reduce them as much as possible.

RDAP

RDAP, the Registration Directory Access Protocol, is the technical successor to Whois. As we’ve mentioned previously, Tucows is part of the RDAP Pilot Working Group, which met several times at ICANN63 in Barcelona to supplement the team’s regular weekly online meetings.

Since we’ve participated in the pilot project and already implemented an RDAP service (Tiered Access) for Tucows domain registration data, we’re a step ahead of many other registrars, who still operate solely on the Whois protocol. Using RDAP as the technical back-end allows us to define user access options at a very granular level. We can restrict access by the number of domains a user can query in a given time period, the data elements returned in response, and even which specific domains can be queried. We can also set the specific duration for which a user’s account remains active. These options were not available on the old Whois protocol, which would always return the same results to any query.

Participating in the RDAP Pilot has given us the unique opportunity to provide input towards the RDAP “profile,” which tells registrars and registries what an RDAP domain lookup response needs to look like from a technical perspective. Put another way, the RDAP profile is the technical underpinning that supports ICANN’s registration data policy requirements. We’re working to make sure the final required profile is aligned with what we believe to be legally compliant and appropriate, in accordance with ICANN policy. The draft profile has been released and the comment period is now complete. Currently, the RDAP team is analyzing the comments and considering modifications to the final RDAP profile.  

The other big piece of work remaining for the RDAP team is determining how users will authenticate. There are two main options: OAuth, or using an SSL Certificate to identify the user, although more consideration may determine that the ability to choose one or the other depending on the use case might make the most sense. Whatever option the Working Group settles on, it’s important to keep in mind that this team will not determine who gets access to what data, and when — that’s not within the RDAP Working Group’s scope. Instead, this group is focused on creating the technical mechanisms to facilitate that access, which will need to coordinate with the work from the EPDP and whatever Unified Access Model is ultimately adopted.

Transfer Policy Changes

The inter-registrar transfer process has changed significantly since personal data has been redacted from the public Whois. This change is formalized within the Temp Spec, and some of the work done at ICANN63 focused on this process.

The TechOps team is working on a proposed new transfer process, which is quite similar to what registrars are already doing post-GDPR. The general goal is to make transfers happen immediately instead of after the current 5-day waiting period, while also protecting the registrant with heightened security requirements. There are some very interesting open questions, such as: Who creates and controls the auth code, should it be the registrar or the registry? Should an auth code have a TTL, essentially a “use-by date”, or should it remain valid indefinitely? In what other ways can the strength and security of an auth code be improved? The team is also considering what an effective emergency transfer reversal process might look like.

In Barcelona, the group present at the TechOps meeting split into smaller work groups, each taking a section of the proposed new process to examine at a very granular level. I led the group working on how the losing registrar might verify the request to get the auth code. The proposal we reviewed allowed a third party other than the registrant to obtain the auth code, such as (for example) when an account holder wants to get the auth code for a domain that’s in their account but registered in someone else’s name.

Our team added in requirements to ensure that the requestor is verified sufficiently to prevent unauthorized transfers; we also opted to keep the notification to the registrant mandatory, ensuring they aren’t surprised by the transfer request and have a chance to contact their registrar if the request was improper. Our group agreed that even when bolstered with increased requirements around verification and notification to reduce the risk of domain hijacking, the option to allow someone other than the registrant to obtain the auth code should only be included in formal policy if there is an expedited transfer reversal process to go with it.

There was a shared dedication among participants in this session to ensuring that any new transfer policy is balanced — it needs to be a streamlined process that’s easy for the registrant to use, while also being secure enough to protect against domain theft.

ICANN Org has now put out a Policy Status Report and has solicited public comments on the transfer policy. Members of the TechOps group have submitted a comment, which will be included in the ICANN Staff Report that is due out on February 1 2019. We don’t yet know exactly how the changes to the transfer policy will unfold, but there’s certainly work to be done on how domain transfers are handled, and we’ll be a part of that work, representing our clients’ best interests.

We’ll keep our resellers posted as the various policy work we’ve discussed today progresses. Overall, we’re pleased with the level of cooperation we’re seeing among all those involved, and encouraged that our registrant-centric approach is being echoed by others working in policy development.

This is the second post in our series on the ICANN 63 conference that was held in Barcelona in October 2018. Before diving in, we recommend taking a look at our recap of the EPDP team’s work leading up to and during the conference. You can watch this space for the final post in the series, which will cover ICANN work unrelated to the GDPR.

---

ICANN’s Temporary Specification requires registrars to provide a means for third parties (such as law enforcement agencies) to access a registrant’s personal data when there is a legitimate legal reason to do so. Enom met this requiring by introducing our Tiered Access directory, but we remain hopeful that an industry-wide solution will be developed.  

Over the last several months, the idea of a unified access model, or “UAM,” has been floating around the ICANN community. With a UAM, the process for accessing registration data would be standardized, with a defined set of eligible users and rules for what data they may obtain. This could be handled at the credentialing level, with registrars and registries required to respect the accreditations provided by a central governing body, or it could go as far as to require that all Whois data is held by and accessed through ICANN itself.

The advantage to a unified model is that parties with legitimate reasons to access registration data could do so in a streamlined manner, and registrars would (in theory) be able to trust the credentials of any user working within this model.

This contrasts the current reality: today, in order to access registration data for domains, third parties must each independently obtain credentials from the appropriate registrar or registry.  There is no central authority that we can trust to accredit eligible users, and no single source that a third party can work with to obtain registration data for domains registered with different providers.

Ongoing discussions

Two ICANN stakeholder groups, the Intellectual Property Constituency (IPC) and the Business Constituency (BC), have been pushing the EPDP team to develop a UAM, as they are concerned that the current decentralized situation is confusing to users, wastes time, and ultimately hinders their constituents’ ability to protect and assert their legal rights. For example, let’s use the case of a commercial litigator trying to send a cease and desist letter for an instance of trademark violation. The IPC and BC groups claim that the attorney needs to start by using the Whois record to determine who owns the offending domain name, but navigating and managing credentials for various registrar portals is a nuisance.

The wider ICANN Community acknowledges the benefits of a unified access model, but also raised significant concerns about implementation. Holding all registrant personal data in a central repository creates a single point of failure for data breaches — if someone gains access to that central source, they can access the contact data for every gTLD domain. This may also put ICANN themselves at risk of liability if such a breach were to occur.

Even if the data itself were decentralized, remaining held by each individual registrar, we’re left with concerns about having a single organization (such as ICANN) control accreditation. Registrars and registries are legally accountable for how and why the data they hold is shared, but in using a UAM, they’d be relying on the credentialing body to require demonstration of legal basis for accessing registration data (hopefully every time data is requested for a given domain, since the legal basis must be specific to each piece of data). And, as illustrated by examples like our own litigation with ICANN over the collection of technical contact data, what is acceptable as a legitimate legal basis can be somewhat subjective. If ICANN’s new contractual requirements require participation in a UAM, registrars and registries may be obligated to provide registration data to third parties in cases where they are not satisfied that a sufficient legal basis has been demonstrated. This is similar to the difficult balancing of more general GDPR requirements against ICANN contractual obligations — the registrar or registry is put in the difficult position of needing to choose between breaching their contract or potentially violating the law.

What happens next?

One of the core requirements in the EPDP team charter is to create a system for providing access to registration data. There are “gating questions” laid out in the charter, which will allow the team to “establish a baseline set of data that is collected for each domain name registration,” determine who should hold this data, and how it can be shared and processed. These gating questions must be answered before the EPDP team can consider the question of how third-party access to data will be granted. So until recently, discussions about the “how” had been pushed down the road when they came up during EPDP meetings. But now the EPDP Initial Report is out and, unfortunately, there is no formal consensus on the answers to the gating questions. In light of this, some members of the team have resumed pushing to discuss access as soon as possible, specifically before the Final Report is issued.

The EPDP team will be meeting in person at the end of January 2019, and we’re eagerly watching to see what happens there, as well as how they respond to the feedback that we and other members of the ICANN community provide in response to their Initial Report. And as this post went to “press,” ICANN announced the assembly of a ten-man “Technical Study Group on Access to Non-Public Registration Data” (Domain Incite has a solid summary of this development). It’s unclear how ICANN selected the members of this team or how their work will fit into or align with the current technical work and in-progress policy development process. Both of these unknowns are extremely worrying. This type of group is unprecedented and their remit and charter are currently opaque. We remain committed to the multi-stakeholder process and will continue to hold ICANN Org accountable to it.

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.