Questions to ICANN org
Question: 1. Please ask the Implementation Project Team for EPDP Phase 1 to provide an update on the implementation of Recommendations 6 and 13. Have registrars already implemented this recommendation, and if so, please provide more details as to how.
Answer:
The Implementation Project Team was notified of a question from the EPDP Phase 2A Team relating to the status of the implementation of Phase 1 recommendations, particularly recommendations 6 and 13.1.
As Keith noted during the recent EPDP Team meeting, the Phase 1 Implementation Review Team is still working on implementing the Phase 1 recommendations.
The Implementation Review Team has reviewed draft language for both of the aforementioned recommendations, and we are sharing it below for ease of reference. Please note, however, that this language is not yet final as the Implementation Review Team has not performed its final review of the draft policy language. Additionally, this draft policy language (in its entirety) will be posted for public comment when complete, and we invite the EPDP Team to contribute to the public comment proceeding when it opens.
EPDP Phase 1 Recommendation #6.
The EPDP Team recommends that, as soon as commercially reasonable, Registrar must provide the opportunity for the Registered Name Holder to provide its Consent to publish redacted contact information, as well as the email address, in the RDS for the sponsoring registrar.
Draft policy language: Where a Registrar redacts the values of the data elements listed in Sections 10.3.1.1 through 10.3.1.8, Registrar MUST provide the opportunity for the Registered Name Holder to provide its Consent to Publish the data element values. Registrar MUST Publish the value of the data element(s) for which the Registered Name Holder provided its Consent.
EPDP Phase 1 Recommendation #13.1.
The EPDP Team recommends that the Registrar MUST provide an email address or a web form to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address or the contact itself, unless as per Recommendation #6, the Registered Name Holder has provided consent for the publication of its email address.
Draft policy language: Where a Registrar redacts the data element values listed in Section 10.3.1.8 or 10.3.1.12, in lieu of “REDACTED”, Registrar MUST Publish an email address or a link to a web form for the Email value to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address or the contact itself.
We note that the EPDP Team has raised concerns with web forms; however, to date, the IRT has not discussed the issue of possible minimum web form requirements, as no IRT members have raised this as a topic requiring discussion.
We also note that some EPDP Team members have asked how many registrars (if any) have already implemented a similar requirement, despite the fact that Phase 1 recommendations have not yet been implemented. The Implementation Project Team is not in a position to answer this question, as this question is more appropriately directed to registrars.
---------------
Question: 2. How does ICANN org see its liability risk to enforce mandatory differentiation of legal v. natural persons? For example, the risk for a registry is for 1 zone, for ICANN, the risk is likely for thousands of contracted parties.
Answer:
We understand this question about potential liability for differentiation of registration data of legal vs natural persons is being asked from the perspective that a contractual requirement (including a requirement in a consensus policy or a temporary policy that contracted parties must comply with under their agreements with ICANN) for differentiation between data of legal and natural persons would make ICANN a controller with respect to any processing of personal data that might occur as a result of that differentiation. (As a side note, this question asks about “ICANN org” liability in relation to controllership. To clarify, however, such liability would exist for ICANN, the Internet Corporation for Assigned Names and Numbers, a California non-profit, public benefit corporation, and not only for ICANN org, as a part of ICANN.)
The concepts of controller and processor cannot always be clearly differentiated from each other and, in particular, the concept of joint controllership is still developing and in the process of being shaped by court decisions and data protection authority guidance (see Draft Guidelines 07/2020 on the concepts of controller and processor in the GDPR). At the moment, it’s not clear whether a Consensus Policy requirement, alone and absent ICANN’s actual involvement in processing contemplated under any such Policy, would make ICANN a controller for this processing.
ICANN org has been advocating for clarity in this regard. For example, ICANN org’s 19 October 2020 Public Comment to the Guidelines 07/2020[edpb.europa.eu], Feedback Reference 07/2020-0047 stated: “… ICANN org would recommend a further clarification of whether a contract between the parties, alone, would lead to a joint controllership assumption if one party lacks any factual influence on the processing. The Board states that “[i]n line with the factual approach, the word “determines” means that the entity that actually exerts influence on the purposes and means of the processing is the controller.” Building on that, it should be emphasized that a contractual set of rules or a joint code of conduct, without further possibilities of exerting control over the actual processing activities, is not sufficient to assume joint controllership and that independent controllership would need further examination on the basis of the other criteria described for control stemming from factual influence in the Guidelines.” In the same Public Comment document, ICANN org also rejected the notion that requirements stated in policies may lead per se to an assumption of controllership: “…, adherence to international community-based policies by decentralized organizations (e.g., umbrella associations, standardization organizations, global think tanks) should not per se lead to a general controllership assumption of both the members and the organization itself. This is particularly important if the latter merely coordinates the policy-making process, as is the case with many governance models in the digital space.”
Some have asked about how the NIS2 might apply in this scenario, and members of the Phase 2A team have raised questions about whether and how the team could or should account for NIS2 in their current work. Among other things, article 23 (4) of the NIS 2 Directive requires that “Member States shall ensure that the TLD registries and the entities providing domain name registration services for the TLD publish, without undue delay after the registration of a domain name, domain registration data which are not personal data.”
In ICANN org’s view, under the wording of Article 23 (4) as proposed in the NIS 2 Directive, the issue of presumably non-personal data such as the domain name or the legal person’s name containing data that are to be considered personal data under EU data protection rules remains. Therefore, also the question by which means a differentiation between personal and non-personal data shall be accomplished and how liability under EU data protection law is allocated if personal data are mistakenly published in this process. ICANN org intends to highlight that in the contribution it plans to submit to the public consultation on NIS2 and welcomes additional clarification.
In any event, if the EPDP Team develops consensus policy recommendations concerning differentiation, and the Board determines it is in the best interests of the ICANN community and directs ICANN org to implement such recommendations, ICANN org would do so.
ICANN org Materials re: SSAC Follow-up Questions from ICANN org Legal v. Natural Study
ICANN Org Response - EPDP Phase 2A - LNP - 3 March 2021.pdf
Appendix A_ Detailed Overview - 3 March 2021.pdf
