Home / Blogs

Privacy, Legal vs. Natural Persons, and the Never-Ending ICANN EPDP

It has been just over 3 years since the General Data Protection Regulation (GDPR) came into effect, and the work within ICANN (type "EPDP 2a" into your acronym decoder ring) to develop a permanent Registration Data policy is progressing at a snail's pace. At issue is a proposed mandatory requirement for Contracted Parties (really just Registrars), to differentiate between "legal persons" (a fancy way of saying corporations and similar organizations) and "natural persons" (the kind that eat and breathe and schedule Zoom calls).

This topic is a leftover from earlier Phases of the EPDP, which left this to the discretion of individual registrars. And it's true that the GDPR makes this distinction in the regulation, but the data of natural persons contained within the data provided by legal persons would still need to be protected.

The DNS has not supported this since its inception. And so, throughout the work of Phase 2a, several groups have asked some version of this question: "Why can't Registrars make this simple change, when the benefits are so obvious?"

The answer, as we'll see below, is because this change isn't simple at all. And the benefits are unclear or nonexistent.

First, let's consider the operational challenges. Like any proposed change to the DNS or RDS, we have a legacy problem. Hundreds of millions of domain names are registered and active, and have not been "cataloged" according to the type of entity that registered them. There is no practical way to retroactively clean these up.

Some have suggested Registrars force a choice at expiry, but it's here that we encounter the chief problem. Legal Person vs. Natural Person is an abstract legal question that isn't widely understood and doesn't translate across all jurisdictions. Withholding renewal pending a Registrant response in an otherwise fully automated process would generate a high level of erroneous suspensions of active domains that are otherwise in good standing, and potentially disrupt thousands of active websites. Blogs, small businesses, and email services would be the collateral damage of this approach.

And the same problem exists even if we just apply the rule going forward to new registrations. Our experiences with other checks or tests introduced into the registration process clearly shows that this only creates confusion and frustration. A significant portion — perhaps as high as 10% — of registrations are abandoned before the registration is complete. Registrars will be tasked with recovering missed revenue and salvaging the relationship with their customer.

Forcing differentiation also creates legal risks for Registrars. Consider the scenario where a Registrar mistakenly protects the data of a Registrant that is, in fact, a legal person. Now the Registrar has breached its Accreditation Agreement with ICANN. Alternatively, if a Registrar erroneously publishes the data of a natural Registrant, it could face penalties under the GDPR or other applicable data protection law. It is also entirely possible there could be a mix of both legal person and natural person data within the same contact record associated with a domain name, further complicating this proposed endeavor.

And we must also consider what "data accuracy" means in the context of a forced differentiation. If, as some have proposed, Registrars are responsible for collecting inaccurate data from Registrants, then how does that apply if the Registrant doesn't understand the question being asked? Taken together with the error conditions from the previous paragraph, this paints Registrars and their customers into a no-win legal corner.

Finally, we should recognize that this requirement would, for the first time, create "classes" of Registrants, with distinctly different rights and responsibilities. This would be new territory for ICANN. I know that calling out slippery slopes is the fastest way to get eyes rolling, but it's very apt here. Once we create two Classes of Registrants, the impetus to create more will be irresistible.

Should we identify non-profits versus commercial entities? How about domain investors, versus web developers? Should Registrants be treated differently based upon how much traffic their domain/website receives? And would we need a procedure to convert or transfer a domain registration from one Class to another? The DNS is, and has always been, "flat" and "permissionless". A requirement to start cataloging Registrants violates both principles, and should not be viewed lightly.

Clearly, the obstacles to adopting this requirement are severe. But what about the payoff? If we could automagically impose this distinction on the universe of Registrants, what is the payoff? The answer: not much. The standard response is that this distinction will help combat DNS Abuse (definition TBD), but we shouldn't accept that claim without unpacking it further.

Online abuse, fraud, and crime are very real, and our industry has made substantial investments in combatting it. DNS Abuse, presumably a subset of all "online abuse", is a part of that challenge, but publishing data on corporate Registrants won't make a dent. No individual criminal or bad actor will take the time and expense to create an LLC prior to launching a DDoS or phishing attack. Or are we concerned that there are abusive corporations pretending to be natural people in order to hide their true contact information? Forcing Registrants to identify themselves under the banner of "Fighting Abuse" doesn't fit the facts. In fact, Registrars have seen that publishing this data will directly lead to an increase in spam, robocalls, and other scams directed primarily at small businesses. Ignoring this vulnerability could also run afoul of various cybersecurity acts.

So where does that leave our brave heroes working on EPDP Phase2a? A policy to start differentiating Registrants in an existing TLD has never been done before, alters the flat paradigm of the DNS, is operationally challenging (if not entirely impossible) at scale, and forces Registrars to walk a legal tightrope with no safety net. While providing no benefits or advantages in tackling DNS Abuse. But just because Registrars do not support mandatory differentiation does not mean we should give up.

The current policy allows, but does not require, this differentiation. And for some Registrars, differentiation could make sense. For example, some Registrars serve only corporate customers, and therefore have already segmented their Registrants. Others may want to differentiate in order to serve a particular target market or region. How can we help them? What guidance can we provide for how to adhere to the GDPR or other data protection regulation while doing this differentiation? What standards could be adopted across the industry? How would this distinction be indicated in RDS or SSAD? How can we transmit it to (thick) Registries?

Addressing these questions would yield valuable benefits to Registrars, and are clearly within the scope of EPDP 2a. We've sunk quite a lot of our calendar on the topic of mandates, but there's still time to salvage some benefits in the form of optional guidance. Let's pivot to focus on that.

Note: This piece was a collaborative effort of Registrar Representatives on the ICANN ePDP: James Bladel and Matt Serlin (GoDaddy) Owen Smigelski (Namecheap), Sarah Wyld (Tucows), Theo Geurts (Realtime Register), and Volker Greimann (Key Systems).

By James Bladel, Vice President, Global Policy

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Comments

 Be the first to post a comment!

Add Your Comments

 To post your comments, please login or create an account.

Related

Topics

Brand Protection

Sponsored byAppdetex

IPv4 Markets

Sponsored byIPXO

Domain Management

Sponsored byMarkMonitor

Domain Names

Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

Cybersecurity

Sponsored byVerisign