After two years of grueling, complex and contentious debate, the ICANN EPDP team delivered its Phase 2 Final Report on July 31st, 2020. Unfortunately, and disappointingly, the policy recommended for the so-called “System for Standardized Access/Disclosure” (SSAD) fails to meet the needs of the users it supposedly is designed to benefit. Those interested in all of the reasons why this is the case should read the numerous minority statements from the stakeholders representing security practitioners, businesses, brand holders, governments, and end-users across the globe.¹

Before I detail my personal views on the result, here is a quick history for those of you lucky enough not to be following closely over the past two years.

On August 1st, 2018 ICANN kicked off the first phase of a two-phase Expedited Policy Development Process (EPDP) tasked with evaluating the Temporary Specification for generic top-level domain (gTLD) Registration Data (a.k.a. WHOIS data) with the main goal of ensuring compliance with European Union’s General Data Protection Regulation (GDPR). The EPDP Phase 1 Final Report was delivered on February 20, 2019. The EPDP team then moved onto Phase 2 that was focused on developing policy for a system for standardized access to non-public registration data—essentially policy that would enable access to important domain name registration data for legitimate purposes like combating cyberattacks, enforcing intellectual property rights and protecting public safety and welfare online.

Assessing the Value

Since the EPDP team delivered its final report, I’ve spent much time reflecting on both the process and the outcome. Personally, the issue that resonates with me most is the question of value. What value does the SSAD bring to the users of the SSAD? Does that value justify the costs of using the system? Does that value justify the costs of building and maintaining the system?

Put yourself in the shoes of a typical SSAD user, such as a cybersecurity investigator or an intellectual property owner. How much value is there in a system that…

• often delivers inaccurate data.
• misapplies the GDPR by allowing the redaction of legal person data.
• is not timely, especially for issues related to consumer protection where access to data to properly investigate and remediate cybersecurity attacks is required on the order of hours not business days.²
• does not prioritize requests related to consumer protection, such as phishing.
• results in inconsistent and unpredictable access to registrant data—as 2000+ contracted parties (e.g. registries and registrars) will review each request manually and make their own individual decisions as to disclose or not disclose.
• explicitly limits ICANN’s enforcement authority, especially in cases of improper disclosure decisions.
• will, based on analysis of the existing disclosure regime, result in the disclosure of data at most 30% of the time.³⁴
• lacks automated or centralized disclosure decision making resulting in a system that cannot scale. This especially impacts the system’s utility for users involved in large scale global cybersecurity investigations.⁵
• does not support a mechanism for quick and agile improvements to the system, including when required by regulation or supported by legal guidance. Effectively users will be stuck with a system that is difficult if not impossible to evolve and improve over time.⁶

To me, the answer is pretty clear. The value and benefits of the SSAD do not come anywhere close to justifying the costs to build it and maintain it, let alone use it.

A House of Cards

This cost-benefit analysis is further complicated by policy⁷ that mandates that the users of the SSAD pay for all costs of the ongoing operation and maintenance of the SSAD. It’s important to note that the IPC made it clear that they were happy to pay for accreditation and other fees in order to use the system. However, financial sustainability recommendations will result in a funding model that is designed to fail. An SSAD that has little value to requestors will lead to a situation where individuals and organizations don’t sign up to use it (or decide to stop using it) which leads to higher costs to use the system which, I assert, will ultimately lead to a situation where ICANN will have no choice but to close it down. The policy constraints will result in what can only be seen as a sure-to-collapse house of cards.⁸

There is no doubt that the question of value will be at the core of the decision that the GNSO Council and perhaps the ICANN Board (assuming the Council approves the policy) will have to make during their deliberation and vote on the Final Report in the coming months.

A Disturbing Pattern

While the ICANN community waits to see how the GNSO Council and ICANN Board will vote on the Final Report, it is important to step away from looking at the preverbal single “tree” that the EPDP Phase 2 policy represents and look at the “forest” of ICANN policies that have also been impacted by the GDPR. When you do, a disturbing pattern emerges. ICANN’s response to the GDPR will unnecessarily end up invalidating existing policy that was set and approved by the ICANN bottom-up policy development process.

In my short time being involved in ICANN policy development (since 2013), none of the policies I’ve been involved in developing (either directly or indirectly) have seen the light of day. (And yes, I have considered that perhaps I am the root cause!) In summary —

• Thick WHOIS: Policy approved Oct 2013 (seven years ago!), implemented and operationalized, but now paused with no plan on when or if it will continue.
• Privacy Proxy: Policy approved Dec 2015. Implementation paused (work was about 90% complete) with no plan on when it will continue.
• EPDP Phase 1: Policy approved Feb 2019 with Board comments/input, yet the “expedited” IRT is still working after 16 months (!) with much work still to be completed and no concrete schedule or plan to complete it. Even once approved the current timeline indicates it will take up to an additional 18 months to fully operationalize across all contracted parties.⁹

Given the impact not only on the Phase 2 Policy but also on the policies listed above, perhaps it is time to admit that the ICANN policy development process may not be properly suited to address complex legal issues such as the GDPR. The minority statement of the BC and IPC concludes with the following paragraph.

“Despite the IPC and BC’s best intentions, the EPDP experiment has failed. It has proven incapable of handling a purely legal issue created by the GDPR. Regulators and legislators should note that the ICANN multi-stakeholder model has failed the needs of consumer protection, cybersecurity, and law enforcement. As a result, there is a need for clear regulatory guidance for the GDPR, and to pursue alternative legal and regulatory approaches.”

While I do not believe this should be interpreted as an indictment of the multi-stakeholder process as a whole, it does indicate that that model does have its limitations. It also indicates that it would be a mistake for the ICANN community to proceed in developing and deploying an SSAD based on the Phase 2 Policy without additional regulatory guidance from the European Union or alternative regulatory approaches defined elsewhere.

Conclusion

Like many of the participants in this process, I am also extremely disappointed and frustrated with where the EPDP Phase 2 policy ended up. I have no doubt that many of my friends and colleagues will find it difficult to understand why those whose interests the SSAD was designed to serve may decide to reject it in the end. However, it is crystal clear that the SSAD does not sufficiently serve those interests. They may also argue that the policy will ultimately result in a better experience for those requesting disclosure of non-public data. However, other than centralized request tracking functionality, it will not result in additional efficiency above and beyond the fragmented, non-standard, and ineffective method that exists today.

Finally, no one should be shocked that constituencies may not support policy that is not in their interest. The ICANN model of policy development doesn’t exist to define policy simply for the sake of defining policy. It exists to define consensus policy that allows ICANN to maintain the security and stability of the Internet’s system of unique identifiers. It exists to ensure ICANN can meet its obligations laid out in its bylaws—including those related to registration directory services (WHOIS). It exists to ensure consensus policy can be enforced by ICANN compliance. Unfortunately, the EPDP Phase 2 Policy does not meet any of these needs.

So, we must ask ourselves—Is it worth it? I’m convinced it is not.