This isn’t the blog post I had hoped to write. When I signed up to participate in ICANN’s Expedited Policy Development Process for gTLD Registration Data, I knew we had a lot of work ahead of us, but I was cautiously optimistic that we would, eventually, reach a successful outcome. Today, I find myself looking at things differently.

After hundreds of hours and countless meetings and emails, Phase 2 of the EPDP’s work has wrapped up with the delivery of our final report to the GNSO Council. I’d like to take this opportunity to thank the efforts of all involved, including the members, alternates, leadership group and ICANN staff liaisons who all worked tirelessly to get our work across the proverbial finish line. Regardless of my less than rosy perspective as we finish our work, everyone involved needs to be applauded for the sheer amount of time, energy and effort put forth.

At a high-level, here is what we accomplished (and I fully recognize I am attempting to summarize 171 pages of work into a few bullet points, so this is in NO way an exhaustive list):

• A final report which contains 22 specific recommendations to be presented to the GNSO Council and potentially the ICANN Board to be voted on, which would become binding policy for contracted parties.
• The creation of a central gateway (referred to as the SSAD…Standardized System for Access/Disclosure to non-public gTLD registration data), which would receive requests for non-public data and route them to the appropriate registrar for review and determination if the data requested should be released based on the provided legitimate interest.
• An accreditation authority that would accredit third-parties for use of the SSAD system including accreditation of governmental entities.
• Requirement for the central gateway to provide a response to every submission and must relay the requests to the appropriate registrar of record for the domain in question. The gateway may also provide a recommendation to the contracted party whether to disclose the data or not, but the contracted party is not obligated to follow the recommendation.
• Service Level Agreements which contracted parties must abide by regarding responses to disclosure requests, including a rationale for requests for data which are denied.
• Quarterly reporting to the community which will communicate information regarding the total number of requests received, number approved and denied, response times, any operational issues, etc.

While none of the above exist today, I fully understand that many in the community had envisioned something different when we set off on this journey. There was a strong desire for centralized and automated disclosure of requests. That desire is completely understandable in the sense that it was an attempt to recreate Whois as we had known it prior to GDPR.

What is crystal clear is that domain name registrars collect personal information from their clients as part of the registration process. Under privacy regulations that exist in myriad jurisdictions, the registrar is then responsible for that happens with that data. It is incumbent upon the registrar to take reasonable steps to safeguard that data to avoid potential regulatory issues. It’s also incumbent upon them to provide that data to requestors who demonstrate a legitimate interest in the data.

Because of that potential liability, the decision to disclose the data MUST remain with the registrar and it must afford them an opportunity to review each request to determine whether or not it meets that threshold of legitimate interest. Widespread automation of disclosure decisions could put registrars in a very precarious position with regulators.

Very early on in our Phase 2 EPDP discussions, the registrar and registry teams posed this question to the entire team: “Can we all agree that the party who is legally responsible for the data makes the decision on whether or not to disclose that data?” There was general agreement that, as a principle, those responsible in the eyes of regulators, would make the final decision. If it were deemed permissible for ICANN (or its designee) to take on the liability for data disclosure, I think it’s safe to say contracted parties would gladly hand over that responsibility to them.

Unfortunately, we find ourselves in a position where many in the community appear to be underwhelmed with the final result. What has been proposed in the final report is being referred to as an, “glorified, overly complex and very expensive ticketing system.”

To be clear, the final recommendations represent many compromises on all sides and is a real step forward from where we are today (with requests having to be sent individually to each registrar with no reporting, no SLAs and no obligation to provide any kind of rationale). I argue these recommendations represent a significant change and will ultimately provide for a better experience for those requesting non-public data.

I will also point out, no one should expect that this final report is the end of the story. I anticipate that this proposed system will, over time, be tweaked and updated based on community feedback and more legal certainty. There’s often a sense that these policy discussions are a “one bite at the apple” situation, but we have to get out of that mindset and understand these policies will need to be reviewed over time. For example, if legal guidance was received, which would allow the liability to be shifted from registrars to a third-party, the system proposed today could change dramatically.

Of course, just because the final report has been published does not mean it will be approved. I understand there are groups that are not happy with the final outcome, and that could impact whether the report is approved by the GNSO Council or the ICANN Board. Personally, having spent so much time on this over the past two years, I think failure to approve this report would represent a failure of the multi-stakeholder system and would have serious implications down the road.

The information contained in this blog is provided for informational purposes only and should not be construed as legal or any other type of advice on the subject matter.