There is a lot of discussion about the Expedited Policy Development Process (EPDP) Phase 2 report on evaluating a System for Standardized Access/Disclosure (SSAD) to non-public gTLD registration data after the decisions taken by the GNSO Council on September 24th. Notably, the Business Constituency (BC) and the Intellectual Property Constituency (IPC) have voted against the adoption of the Final Report of the EPDP team. But the IPC and the BC were not the only groups that were not supportive of some key recommendations the EPDP team came up with. In particular, the Governmental Advisory Committee (GAC) and At-Large Advisory Committee (ALAC) objected to some core recommendations to make the System for Standardized Access / Disclosure (SSAD) work, such as the recommendation on financial viability and the Generic Names Supporting Organization (GNSO) standing committee that is meant to help evolve the SSAD. I happened to be one of the representatives of the ISPs and Connectivity Providers Constituency (ISPCP) in the EPDP and had the—perhaps doubtful—privilege of witnessing and actively contributing to the discussions of the EPDP team over the last 2+ years.

Notably, the groups that raised concerns represent those who allegedly have the biggest interest in obtaining non-public registration data. That begs two questions, namely:

1. Why build a system that is not supported by those for whom we primarily designed it?
2. Why is there such lack of support?

With this article, I will try to shed some light on the above questions.¹ These are my thoughts, not the ISPCP’s, not eco’s members, and certainly not the EPDP team’s. Let’s get to it.

1. Why build a system that is not supported by those for whom we primarily designed it?

Maybe an understandable reaction to the opposition and minority statements “against” the EPDP report could be to just forget about the entire project. If those who should primarily benefit from the SSAD don’t support it, it’s not worth spending time and effort in building it.

That is shortsighted for various reasons.

• The outcome of ICANN’s policy development processes is rarely something that everyone loves. The interests in the ICANN community are diverse by design, and therefore we should not be shocked if there are minority statements or opposition. Unlike other organizations, the GNSO does not require unanimity for consensus, and we are used to accepting and respecting divergent views.
• Throwing the work of the community overboard would show a lack of respect for both community resources and the multi-stakeholder model.
• We are entering unchartered territory. The “old” Whois system was simply illegal in the context of modern data privacy regulations. The “new” system is something that required us to re-imagine the approach to lawfully disclosing data at the global level. Remember, there are two routes to obtaining data or exercising rights. First, contracted parties can always be approached directly by requestors. This is difficult in a global environment, but rights of data subjects in particular, such as the right of access, right to rectification or erasure, are not truncated by the SSAD at all. The second route is what we have been working on. A system that goes above and beyond what can be found in other industries. Therefore, we could not just replicate or adjust any service that is already out there, but we had to build from scratch something that—if we don’t get it right—holds a massive legal risk for ICANN, contracted parties, and—most importantly—the data subjects concerned.
• The system is meant to evolve. The benefits might not be apparent to everyone, but if you need to obtain non-public registration data regularly, there are huge benefits for both the requestor and the disclosing party. You only get accredited once (the disclosing party therefore knows the requestor exists), there are clear rules on what you can and what you cannot do, and there are rules to kick out bad actors. Indeed, there is not a lot of automation at the beginning, but it can be added. Some have said that the proposed SSAD is just an expensive ticketing system, but that is an unfair assessment. The SSAD is quite powerful and a thoughtful reflection of the rights and requirements of all parties. I trust it would become more and more valuable over time when more automation is possible.
• Not supporting the ICANN policy process is as good as begging for legislation. Some in the community are even publicly announcing that they intend to do just that. That is not only doing the multi-stakeholder model a disservice, but it also does not really help. Asking for regulation will not lead to a global response as an outcome, but will lead to fragmentation of approaches across various jurisdictions.
• Some say that the ICANN way is “only” contractual, but that argument does not pass a reality check. It is exactly the beauty of the ICANN model that you can create global policy and enforce it at the global level. ICANN consensus policies immediately become binding for all contracted parties. Where else can you make thousands of companies—in fact, all companies active in the gTLD world—abide by new rules without changing their contracts?

2. Why is there such lack of support?

A false premise

In the minority statements, as well as in some opinion pieces published, several parties addressed their disappointment at the outcome of the EPDP. They claim that it falls short of what should have been achieved. That view is symptomatic of a systemic error in the EPDP’s work. The expectations were, and obviously are, the biggest issue: namely, the expectation that an illegal system—what Whois used to be—or a slight variation thereof can continue to be offered.

To give an example, Fabricio Vayra started his CircleID piece thus: “ICANN’s two-year effort to purportedly preserve the Whois public directory to the greatest extent possible while complying with GDPR has failed.”.

It is correct that ICANN’s Temporary Specification read: “Consistent with ICANN’s stated objective to comply with the GDPR, while maintaining the existing WHOIS system to the greatest extent possible, the Temporary Specification maintains robust collection of Registration Data (including Registrant, Administrative, and Technical contact information), but restricts most Personal Data to layered/tiered access.”

However, this goal did not make it into the EPDP’s charter. The sentence which resembles the above statement most in the “Mission and Scope” of the Temporary Specification is this: “This EPDP Team is being chartered to determine if the Temporary Specification for gTLD Registration Data should become an ICANN Consensus Policy, as it is or with modifications, while complying with the GDPR and other relevant privacy and data protection law.”

The goal established by ICANN in the Temporary Specification, rightfully, neither made it into the EPDP’s charter nor was it upheld when the EPDP team tested all aspects of the Temporary Specification to determine whether they could be kept or needed to be changed.

The GDPR dictates the principle of data minimization and privacy by design, so the EPDP team’s approach could never be to make as few changes to the existing WHOIS system as possible—instead, the question had to be what data is necessary to deliver on the purposes for data processing where a legal basis for the processing exists. As this is not a legal article, I am simplifying things a bit, but in essence, the EPDP team could only justify such processing that was necessary and not what’s desirable for some.

Additionally, please note that—while the EPDP team was working—ICANN lost a court case in which it unsuccessfully tried to force a registrar to collect the full set of registration data. That is just to say, even if the EPDP team had wanted to preserve the “old” Whois system, it could not do that in the light of the court decision. The consequence of this is that the new regime by nature had to be different from the old regime, from collection to deletion of all data elements. (For full disclosure, I was one of the lawyers defending the registrar.)

Based on this, I hope we can agree that ICANN’s original goal was a false premise.

Data Accuracy

A lot of opposition against the EPDP work product was based on the fact that the issue of data accuracy was not resolved. There are different views on the question of data accuracy. Some think that the contracted parties have to make sure all registration data is accurate, while others say that the accuracy requirement in the GDPR is just to ensure that the data given by the data subject is accurately processed and not altered by the controller or processor. Regardless of what position you take: This very topic was taken off the EPDP’s agenda by the GNSO Council after long discussions did not show a sign of a possible compromise. So the EPDP team was no longer permitted to work on this, even if it had had the time and resources to do so.

While I understand that it is disappointing for those that saw the accuracy question as an integral part of the EPDP’s work product, it is disingenuous to hold this against the work of the EPDP team.

Controller / Responsibility

The work of the EPDP was hampered by the fact that ICANN Org—for the most part—refused to take responsibility for data processing. Even in a recent letter to GAC Chair Manal Ismail, ICANN CEO Göran Marby stated: “The issue of controllership of the processing of personal data cannot be determined as a matter of policy: This is determined by the application of the law to the facts of a given processing operation. In ICANN org’s view, this must be assessed after we know the specifics of the processing: who performs what processing, by what means, and for which specific purposes. In the SSAD, for example, we don’t yet know exactly how/where/when/and by whom personal data will be processed (or even what personal data will be processed) because the system hasn’t been designed yet.”

This statement is a good representation of ICANN’s position since the GDPR discussion started. At best, it can be characterized as evasive. In fact, this very topic would warrant a dedicated article, but those who followed the discussion will remember that there have been legal papers and correspondence from the Art. 29 Group / European Data Protection Board and others that either implicitly or explicitly stated that ICANN is a joint controller with the contracted parties for certain processing activities. It was ICANN Org that actively pushed for the deletion of any language making a determination of joint controllership.

The lack of willingness to accept responsibility for its role / its share of responsibility in the overall concept I am sure contributed to the unwillingness of contracted parties to accept responsibility. You might think this was or is a “who blinks first” situation, but even when the contracted parties blinked, there was little to no movement at ICANN Org. You might also want to check the status of a task stemming from phase 1 of the EPDP, namely for ICANN Org to negotiate and enter into the appropriate data protection agreements with contracted parties. As I am not part of that group, I will leave it to others to comment on or provide an update on the status of these negotiations.

In sum, we could have achieved more if there had been an early acceptance of the respective roles and responsibilities of all parties involved.

Uneven distribution of risks / automation

It is striking, but not surprising, that those who would benefit from an SSAD, namely the groups representing likely requestors, are now lamenting the loudest that the EPDP recommendations should have gone further and allowed for more automated decision-making leading to disclosure of data.

The reason for that is simple: These groups are not the ones against which registrants that might be aggrieved by an unlawful disclosure will raise claims. These groups are not the ones that will suffer financial or reputational risks in the case that the system is more liberal in disclosing data than it should be. These groups are not the ones exposed to the massive fines that the GDPR holds for breaches.

Given the above, it is quite understandable that the contracted parties want to play it safe—at least initially. However, the system allows for more decisions to be centralized over time and the EPDP report includes a recommendation that enables the evolution of the SSAD. Ironically, this recommendation has been amongst those that received the most opposition.

What to make out of this?

Let’s step back and relax for a moment.

The question of what to do with Whois is one of the most controversial—if not the most controversial—in ICANN’s history. So far, all attempts to really tackle Whois have failed, but the EPDP is not one of them.

A wide-open Whois was great for many, but it could not be sustained as it was in open conflict with existing and newly emerging data privacy regulations. The issue had been known for many years and the Art. 29 Group first wrote to ICANN about 15 years ago, but it took the deterring threat of sanctions of the GDPR to force ICANN to move. Let’s accept that there is no way back.

Let’s also accept that there are diverging positions in the ICANN community and that cannot be reconciled. But, as in all good compromises, all parties involved in the EPDP working group had to make significant sacrifices and the EPDP recommendations are painful for all sides.

But most importantly, let us realize that the SSAD has all the building blocks necessary for a global system facilitating lawful disclosure of data to those who can lawfully obtain it. That is unprecedented and quite affordable, if you do the math as Milton Mueller did. Is it as good as it can or should be? Certainly not, at least not yet. But it is a better starting point than anything we have ever had to make it a great tool.

Maybe with a little help from our currently skeptical friends, we can overcome the hurdles to swiftly evolve the system closer to what they want it to be—while protecting the rights of hundreds of millions of innocent registrants, who will hopefully never have to read all the papers we produced.