An update on the EPDP on the Temporary Specification for gTLD Registration Data
The mere fact that the EPDP team produced its phase 1 report was quite a thing. Many observers in the ICANN community and beyond did not believe that a topic as challenging as Whois and a group with as diverse interests as the EPDP team could get anywhere near consensus. But the group did it. The EPDP Phase 1 report was delivered, adopted by the GNSO Council and greenlighted by the ICANN Board on almost all recommendations.
Can the EPDP team do that again for phase 2, you might ask. Well, we do not know now, but when I travelled to ICANN’s headquarters some two weeks back for a 2.5 day face to face meeting to iron out the wrinkles before the phase 2 initial report is published, I knew it would not be easy to get the job done and hence I was not too optimistic.
With a list of open issues counting more than 60 relatively contentious subjects, we had quite a workload to get through. The first few hours of the meeting did not produce many tangible results and the chair announced later in the meeting that we would need to go into overtime after 8 hours – doing consecutive intervals of 1:45 h of work with 15 min breaks. Needless to say, this did not go down too well with all participants, but sometimes a chair needs to threaten “consensus by exhaustion” to help a group to move, when many participants try to hold their corners.
At the end of the day, we reached agreement on most points and knew that more work was required after the meeting, which was then taken care of on the mailing list and in a 3-hour phone call on February 6th, 2020.
Why was all this so difficult?
It would not add to the reading pleasure if I even tried to comprehensively report on the difficulties our group is facing. I will therefore only highlight a few points:
1. Diverse backgrounds
The group’s efficiency is suffering from the fact that we are supposed to do policy, but in fact a lot of the questions we have to answer are legal in nature and not policy. Given the professional backgrounds of the participants, we sometimes struggle to find a common understanding of legal implications and some have a hard time accepting the legal advice our group is getting as a basis for our policy work. Remember, our group obtained legal advice from an independent global law firm at substantial cost and still the group is struggling to accept the legal truths we are being told.
Different views were and are held on the level of centralization of a System for Standardized Access/Disclosure to non-public gTLD registration data (“SSAD“). Some think that only the accreditation and identification of requestors should be done centrally and that decisions on the disclosure itself should then be made by the contracted party concerned, while others think that decisions should be made centrally as well. This is primarily a trust issue. The central gateway will likely be operated by ICANN Org – and most likely by contractors hired by ICANN Org. However, some do not think that ICANN Org should be entrusted with the decision-making and potentially enforcing disclosure decisions to be implemented by contracted parties, given the risks for contracted parties and – maybe even more importantly – for the data subjects whose data is disclosed. Therefore, this area needs more work and the parameters for decision-making need to be more specific than they are, so that everyone gets a better understanding of where disclosure is warranted and what the limitations are. The fear is that this process is gamed to ultimately result in high volumes of disclosure requests that are not really required to help enforce the requestor’s legal rights, and that these requests would therefore not be permitted by law.
The same issue exists with automation. Some say that responses to disclosure requests should be automated as much as possible, while others object to this as they do not think that automation can go substantially beyond some clerical work, such as verifying the requestor’s identity etc. More discussion is required to really define what can and what cannot be automated and in what scenarios automation can be further explored.
An overarching issue that has been pending since phase 1 and that has not been settled is the question of who is responsible for what. eco has been advocating for a joint controller situation since the eco GDPR Domain Industry Playbook was issued, but in particular ICANN Org has not committed to this concept despite various third party hints (even from the EDPB Board). The fact that (joint) controller and processor roles have not been written up and that no clear demarcation of responsibilities has been agreed hits us when it comes to resolving the points 2 and 3 above, but also beyond. Hence, our hope is that this matter will be sorted before the EPDP team convenes in Cancún as it seems to be a major roadblock for the group to complete its work.
The initial report has now been published for public comment. The public comment period is open until March 23rd, 2020. All details can be found here:
Please take the time to at least read the recommendations and share any feedback you might have with us so we can take it into consideration for eco’s comment. But also file your own comment. Your voice matters in our endeavor to create the best policy we can under the given circumstances.
So you will have work to do between now and Cancún – as will the EPDP team, which needs to further flesh out details of the recommendations to hopefully come up with an acceptable solution at the end of the day. Remember: A good compromise makes everyone equally unhappy. Keep smiling!