After almost 6 years of the EPDP process to address EU GDPR compliance, the ICANN community unlocked a milestone, and the Registration Data Consensus Policy was (finally) published on 21 February. Is the work on data protection vs access to registration data over? Can a sparkling wine from a certain French region be opened (not mentioning a protected geographical indication to be on the safe side)? Not quite yet. New expectations are raised and future work for the community is on the horizon.
The Registration Data Consensus Policy
On 21 February, ICANN published its Registration Data Consensus Policy (RDCP), a culmination of almost 6 years of work by the ICANN multistakeholder community within the Expedited Policy Development Process (EPDP) to respond to data protection obligations on collection and publication of domain name holders’ data. The RDCP modifies requirements in the Registrar Accreditation Agreement and Registry Agreement in light of data protection laws, such as the EU General Data Protection Regulation (GDPR). ICANN contracted gTLD registries and registrars must continue to implement measures consistent with the Temporary Specification for gTLD Registration Data and must not implement the new policy just yet. At this time, gTLDs and registrars should use this period to prepare for the implementation of the RDCP but not make any changes before the beginning of a transition period on 21 August 2024. The RDCP will be effective and mandatory for all ICANN contracted parties starting from 21 August 2025.
The previously deemed contentious issue of “urgent requests” (see our previous blogpost on this here) was excluded from the RDCP, in order to avoid further delays in its publication. The ICANN Board responded to the concerns raised by governments in the Governmental Advisory Committee (GAC) by promising to raise the issue with the GNSO council, with the aim of potentially revisiting Policy Recommendation 18 in the context of data access requests regarding situations that pose an imminent threat to life, serious bodily harm, infrastructure, or child exploitation, and the manner in which such emergencies are currently handled. The GAC is convinced that community work on the urgent requests needs to be resumed as soon as possible.
The RDRS Pilot - first usage reports are out
Closely linked to the RDPC and the matter of (urgent) access requests, are also the first usage reports of the Registration Data Request Service (RDRS) pilot - a centralised system for registration data access requests from third parties targeting ICANN accredited registrars. According to the statistics, the RDRS has currently 75 participating registrars (around 45% of all gTLD domains covered) and more than 2000 requestors. Out of all requests submitted so far, 17% of access requests are approved. According to the many discussions around the RDRS during ICANN79, the use of the system has been deemed “clunky” by all participating parties, both requestors (LEAs, IP lawyers) and registrars themselves. However, the pilot is still being considered a valuable resource, informing the future work on a System for Standardised Access and Disclosure (SSAD), a more ambitious goal for one-stop-shop for all (and verified?) registration data access requests. At the moment, the RDRS simply offers a possibility to gather all data access requests in one place (and via standard template), while the data disclosure itself is being decided upon and performed by each participating registrar outside of the system.
The RDRS stats also show that only 1.7% of all requests are flagged for “expedited-review” (read: “urgent requests”). According to the participating registrars, the majority of “expedited” requests are flagged wrongly as such by the requester.
Requesters (majority of whom are IP holders) are also asking to include ccTLDs in scope of the RDRS, to include more complete portfolios of participating registrars. The Public Safety Working Group (PSWG) suggested reaching out to ccTLDs and see if they are willing to participate, ignoring the fact that the RDRS is open for registrars only, and possibly overstretching the mandate of the pilot. Including ccTLDs in the usage of the RDRS, that is supposed to gather data and inform the future of ICANN policy development process, contradicts the designed separation between ccTLDs and gTLDs policy-making. At the same time, registrars are already serving the data access requests across all their portfolios (irrespective of a TLD in question), without the need to add ccTLDs to the RDRS.
What about accuracy?
Short answer: unclear.
To specify further, work on the “accuracy” issue within the ICANN community has been paused since November 2023. The GAC has continuously stressed the importance of holding ICANN contracted gTLDs and registrars accountable for their compliance with the existing accuracy requirements under ICANN contracts. An apparent stumbling block is how to measure accuracy of registration data across ICANN contracted parties without ICANN Org needing an access to personal data. In the meantime, ICANN Org has promised to conduct a “comprehensive assessment of what activities it may undertake to study accuracy”, while the OCTO is working on a report analysing the relationship between accuracy of registration data and mitigation of malicious activities across TLDs. As stated during ICANN79, there is an appetite across the ICANN community to restart discussions on accuracy. The time is ripe, as EU Member States are in the process of implementing the EU NIS 2 Directive and its Article 28, obliging all TLDs and registrars active in the EU to keep accurate and complete domain registration data, including via verification procedures of both identity and contact means of domain name holders.
… and NIS 2 Directive?
To add complexity to the data protection compliance discussions within the ICANN community, the response to the NIS 2 Directive across ICANN accredited registrars has been rather surprising, as evident from ICANN79 discussions. After previously expressing concerns during the negotiations on NIS 2 accuracy provisions, including verification obligation, members of the Registrar Stakeholder Group (RrSG) are now convinced that existing ICANN accuracy requirements are in perfect alignment with the NIS 2 Directive requirements. According to RrSG, accuracy under ICANN contracts (and as an extension of this interpretation also under NIS 2) means a simple syntax check. Verification of data, according to RrSG, can also be performed by the registrar sending an email to a provided contact email address and the email being delivered.
According to the survey conducted amongst RrSG members, 60% of respondents are already performing or considering performing additional ID checks. According to the ICANN Org assessment, identity checks cost in the range of 10-20 dollars per verification, which makes them quite a costly endeavour. RrSG members are also questioning the purpose of stringent verification measures beyond ICANN contracts, citing .cn, the ccTLD for China, as one of the examples where an intense identification policy in place for all domain name holders has not avoided .cn being one of the most abused TLDs globally.
Conclusion
We can celebrate the ICANN community for having unlocked a new level in compliance and addressing EU GDPR impact on domain name registration databases across gTLDs. It is a significant milestone, showcasing the power of the multistakeholder model in moving towards a solution that, despite all criticisms, does address conflicting interests to the best of its abilities. Unfortunately, the NIS 2 Directive and its accuracy measures were proposed and negotiated in a rush, largely due to impatience and dissatisfaction with the EPDP process within the ICANN community. It does not offer solutions, but it raises new challenges for the ICANN community and ccTLDs outside of ICANN contracts. Accuracy and questions of access to non-public registration, driven by regulatory (and not contractual) compliance, will most likely spearhead new policy development processes in the future, as we cannot share the optimism of RrSG that existing syntax checks are enough to comply with verification obligation under the NIS 2 Directive. Time will show if the community will be able to rise to the occasion again.
