The Future of Domain Registration Data Requests: Balancing the Priorities of ICANN, the EU and the Legitimate Access Seeker

You’ve found a web store selling the same product as your client and the URL is very similar to the client’s brand name. So, you do a lookup to find out who owns it. The result: REDACTED FOR PRIVACY in 20 different fields. You’re sympathetic to privacy concerns, but you’re no spammer. Somebody is selling counterfeit versions of your client’s products, and you need to shut them down. Shouldn’t there be a special way for people like you to get the information they require? The short answer is “yes, there should be a webform for that.” However, when ICANN and the European Union are involved, nothing is that simple.

Acronyms

Four policies/proposals will be referenced in this article, each by their frequently used acronym. The reader is likely familiar with some of these acronyms, but for the sake of clarity let’s start by identifying them:

GDPR: General Data Protection Regulation: Enacted in 2016, this is a component of EU Privacy Law that, among other things, regulates how and when personal data can be shared.
SSAD: Standardized Access/ Disclosure: Originally proposed in 2020, this is a mechanism to allow for domain data requests to be centralized and standardized.
NIS2: revised Network and Information Security Directive: Published in 2022, this is EU-wide legislation on material of cybersecurity that, among other things, stipulates how and when domain service providers must provide domain registration data.
RDRS: Registration Data Request Service: Directly related to SSAD, this is an active pilot program launched in 2023 where requests for domain data can be requested from a single portal, regardless of which registrar manages the domain in question.

Background

Before GDPR, domain WHOIS data was an essential tool for the intellectual property professional. Whether it be to investigate an infringing website, or to see about acquiring a domain, checking the WHOIS was the logical first step.

After GDRP began to be implemented on a wide scale, intellectual property professionals have noted that the redacted registrant data impedes enforcement on cases of infringement[1] [2] The only remedy available to these IP professionals is to make a request to the domain registrar and hope for a positive result.

SSAD/RDRS

The procedure for making a data request varies between registrars, as does the criteria for determining which requests merit disclosure. Emerging from an ICANN supporting group, the SSAD proposal[3] aimed at bringing order to the process of requesting domain registration data from registrars.

SSAD would represent a huge undertaking and ICANN decided to test the waters with a “proof of concept.” The RDRS is a two-year pilot program, taking the form of a Ticketing System where interested parties can use a single portal to make data requests for a given domain, which are then routed to the registrar managing the domain.[4]

The usage of RDRS will inform the decision on if and how to proceed with the larger-scale SSAD proposal. Statistics on number of requests received, who is making them, and their results are published regularly.[5]

The two years are up this November (although this may be extended[6]) and there’s no consensus on how SSAD will proceed after it’s eventual end. Plenty of IP professionals have weighed in on the utility of the RDRS pilot-program[7][8], but any consensus on the utility of RDRS won’t necessarily correlate to a probability that SSAD proposal will proceed. RDRS is a means for ICANN to gather information on how a data request system would be used, not a finished product that will be given a pass/fail grade. In other words, if users criticize some aspects of RDRS (as they have), that wouldn’t necessarily be a point against proceeding with SSAD, but rather information for ICANN on what needs to improve.

NIS2 and ICANN

The EU didn’t give ICANN much of a rest after GDPR, before releasing another set of laws with ramifications on domain name data: The NIS2 Directive. Similar to GDPR, relevant passages in NIS2 are general and translating them into ICANN policy is not an easy task. Here are the most relevant passages for our discussion:

Member States should require TLD name registries and entities providing domain name registration services to respond without undue delay to requests for the disclosure of domain name registration data from legitimate access seekers.

-AND-

The access procedure could include the use of an interface, portal or other technical tool to provide an efficient system for requesting and accessing registration data.

This didn’t come out of nowhere and ICANN had already weighed in on NIS2 draft proposals in 2021[9], highlighting the time investment required for registry and registrar personnel to conduct a sincere “weighing of interests” in determining if and how they would respond to each individual data request. ICANN’s comments also broach the possibility of automated data request/delivery and question whether this would be prohibited under GDPR, which generally prohibits “automated decision-making” that affects individuals.

A couple of years later, after the publication of the final NIS2 Directive, ICANN sent a letter to an NIS working group[10], referring to existing and future ICANN policies and how they address different elements of the Directive. With RDRS already in development at this point, ICANN more directly identified this tool (or a future version thereof) as the mechanism to be used by legitimate access seekers.

Just a few months away from the end of the RDRS pilot-program, this is where things stand: ICANN independently appeared motivated to establish a portal for interested parties to request domain registration data that is no-longer published and now wants to make sure that the final version of this portal can be a means to satisfy the NIS2 requirements to ensure timely access to this data.

How is this all going to play out?

Having laid out the different interests and priorities involved, we thought it would be interesting to mention how a domain data request portal could operate in a manner both feasible and compliant with legislation originating from NIS2:

Access Credentials: The validation of the “legitimate access seeker” must happen before they make the request. If the task of determining legitimacy falls to a human user for each case, fast responses would be impossible. One way or another, the user needs to logon to the portal as a pre-validated, legitimate access seeker.

As it concerns the IP community, let’s grant that the Head of IP for BMW should be able to request data on the owner of “bmw-cars.net.” But should this same person be able to request the data for “volkswagen.org?’ Probably not. The credentials would need to have attributes defining exactly what the user can request. Perhaps some authorities would be granted almost universal request privileges, but the IP community could have credentials with a more limited scope.

Likewise, access credentials for a member of the IP Community could give a right to the minimum necessary domain data. For example, a police officer that is investigating a website used for illegal drug sale may need access to a physical address to visit for their investigation. However, an IP professional that plans only to ascertain the domain owner’s connection to their client could be given an email or phone number, with the physical address redacted.

Mandatory Registrar Participation: RDRS is completely optional, which goes with the territory as a pilot program. That seems destined to change under any definitive data request system. There will be registrars based outside the scope of NIS2 (established outside the EU, no EU customers) that could feasibly operate under some sort of exception, but ICANN is not viewing this topic exclusively through the lens of NIS2. Mandatory registrar participation makes the most sense.
Automation: Even if Point 1 were resolved so that a data request was immediately tagged as having come from a legitimate access seeker, it could still take time for registrars to query and send this data. We’re with ICANN on this point: Data needs to be stored in a manner that is consistent with GDPR, but also able to be released to a legitimate access seeker immediately upon request. This could be a key to make Point 2 palatable to registrars – If they don’t assume much additional administrative burden, it stands to reason that registrar opposition would be lower.

Conclusion

The scheduled end of the RDRS pilot program later this year is a milestone for SSAD, but much deliberation will follow before a permanent data request portal becomes available. The NIS2 Directive and its “legitimate access seeker” provisions increase the probability that some version of SSAD will materialize and become general ICANN policy.

For members of the IP community frustrated by the lack of available public registration data and unsatisfied with RDRS as a working tool, this is positive news. The tunnel is long, but there is light at the end.

In this context, it makes sense for an IP professional to rethink enforcement strategy for a context in which access to quality data on domain owner is a reasonable expectation. Domain name takedowns and acquisitions are areas that could warrant additional budget, as success rates for these enforcement tasks would naturally benefit from working contact information for domain owners.