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.