Page History
...
The Board reaffirmed the Temporary Specification with no changes on 21 August 2018.
Temporary Specification Terminology ClarificationClarifications
1. When ICANN refers to “security” as part of its mission - can ICANN describe what types of security are included??
...
Yes, access to gTLD registration data generally is one of the allowed topics for consensus policy as set forth in ICANN Bylaws and registry and registrar agreements. (That list of topics is referred to by some as “the picket fence”). Please refer to AnnexG-1 and G-2 of the ICANN Bylaws as well as Specification 1 Section 1.3.4 of the Base Registry Agreement and the Consensus Policies and Temporary Policies Specification of the Registrar Accreditation Agreement, which provide that: “maintenance of andaccess to accurate and up-to-date information concerning domain name registrations” is one of the topics on which ICANN may enforce consensus policies.
EPDB Advice
...
10. The Temporary Specification for gTLD Registration Data
...
EPDP Team is currently considering language on a “Purpose M” regarding ICANN’s role in coordinating the development and implementation of policies concerning ICANN’s dispute resolution processes in the context of domain name registrations. Two of the processes currently being considered within scope of this purpose are the PDDRP (Post Delegation Dispute Resolution Process) and the RRDRP (Registry Restrictions Dispute Resolution Process). It would particularly be very helpful and important to the EPDP Team if ICANN could provide clarification on any point within the processes of PDDRPs and RRDRPs where processing of gTLD Registration Data is necessary for the dispute resolution processes to be completed. This clarification should identify which (if any) data elements within gTLD Registration Data are necessary, as well as all parties involved in the processing activities.
The PDDRP rules and the RRDRP rules each require the complainant (a trademark holder in PDDRP proceedings; an established institution in the relevant community in RRDRP proceedings) to “provide the name and address of the current owner of any at-issue domain name registration related to the dispute, to the best of the Complainant’s knowledge[.]” See PDDRP Rules, Section 3(b)(iv); RRDRP Rules, Section 3(b)(iv). The dispute resolution provider is required to serve the respondent (the registry operator) with a copy of the complaint, and to retain information related to the provider’s transmission of the complaint. Thus, these procedures may result in the complainant, provider, and/or respondent’s processing of gTLD registration data.
It should be noted that neither of these procedures have been used yet.
ICANN org would not process gTLD registration data in proceedings of either of these procedures because they are administered by independent dispute resolution service providers. However, if either procedure is used and ICANN org receives a panel’s decision, then that decision would include gTLD registration data.
On another note, the current wording of Purpose M states: “coordinating the development and implementation of policies concerning ICANN’s dispute resolution processes in the context of domain name registrations.” It is unclear how developing and implementation of policy would involve processing of gTLD registration data or personal data.
11. What is the rationale for not redacting organization field in the Temporary Specification?
Including the registrant organization field was determined to be consistent with ICANN org’s stated goal of complying with the GDPR while maintaining the WHOIS system to the greatest extent possible. The name of an organization refers to a legal person and not a natural person and therefore is arguably not covered under the GDPR. Additionally, the organization field is an optional field for registrants so to the extent that the registrant provides the organization name, the Temp Spec allows for publication of that information.
Leading up to the development of the Temporary Specification, ICANN org consulted with the community and the DPAs to determine which data elements should continue to be made publicly available. Through the data matrix exercise where ICANN org asked contracted parties and interested stakeholders to identify user types and purposes of data elements required by ICANN policies and contracts, 40 user purposes for the registrant organization field were identified.
For reference, Section 5.5.16(i) of the Interim Model for Compliance with ICANN Agreements and Policies in Relation to the European Union’s General Data Protection Regulation (also called the Cookbook) states that “the registrant “organization” would be required to be published (if applicable) so that registrations of legal entities would readily include the name of the entity.”
12. Has ICANN given any thought to scenarios where the „Organization“ field might contain personal information? 2.) As the Organization field shall be populated on an optional basis, has ICANN given any thought to a consent requirement or, where another legal basis than Art. 6 I a GDPR was considered, what legal basis shall be applicable based on what rationale?
The organization field, which is an optional field, was one of the topics of discussion among the community during the development of the Cookbook. See sections 5.4 and 5.5 of the Cookbook.
Additionally, the 5 July 2018 letter from the European Data Protection Board states: “The GDPR does not apply to the processing of personal data which concerns legal persons and in particular undertakings established as legal persons, including the name and the form of the legal person and the contact details of the legal person.” Recital 14 of the GDPR states: “This Regulation does not cover the processing of personal data which concerns legal persons and in particular undertakings established as legal persons, including the name and the form of the legal person and the contact details of the legal person.”
Registrars have always been obligated to inform and obtain consent from the registrants regarding what data elements are collected, what data elements are published, what data elements are optional, and the intended uses and recipients of the data. (See for example Section II.J.7.b in the 1999 RAA and Section 3.7.7.4 of the 2013 RAA.)
The Temporary Specification relies on 6(1)(f) as the legal basis for the mandatory publication of certain fields, including registrant organization. As noted in our original response, the registrant organization field refers to a legal person and not a natural person. The registrant may give consent for publication of additional fields, for example, the registrant name field.
In considering the applicability of the possible legal bases and after consultations with the community, it was determined that 6(1)(f) was the most appropriate legal basis to support the stated goal of complying with the GDPR while maintaining the existing WHOIS to the greatest extent possible.
13. What is the rationale for the bolded wording in this Temporary Specification section: As soon as commercially reasonable, Registrar MUST provide the opportunity for the Registered Name Holder to provide its Consent to publish the additional contact information outlined in Section 2.3 of Appendix A for the Registered Name Holder.
The “As soon as commercially reasonable” language was added in Section 2.3 of Appendix A of the Temporary Specification because Implementation of this requirement would take development time on the part of the contracted parties. However, due to the timing of the Board adoption of the Temporary Specification, there was recognition that additional time would be needed to implement the requirement.
The “MUST” language goes back to our stated objective of preserving the existing WHOIS to the greatest extent possible while complying with the GDPR. Giving as many registrants as possible the ability to have their full contact information published was in keeping with this stated objective.
14. What was the community input into this Temporary Specification section that, in each of the two cases, led to the wording, “as soon as commercially reasonable,” and “MUST“?
As far back as the development of the Calzone model, various parts of the community communicated to ICANN that registrants should be afforded the ability to have their full contact information published. See the Working Draft Non-Paper -- Selected Interim GDPR Compliance Models & Comments dated 07 Feb 2018.
During development of the Temp Spec, contracted parties pointed out that this requirement would require development time to implement in their platforms.
15. Why city field is redacted in the Temporary Specification:
Regarding the EPDP Team’s question about why the City field is redacted in the Temp Spec, the Cookbook provides the following rationale: "The registrant’s state/province and country will be published, but the address fields that could be used to more specifically identify the registrant would not be included in the public WHOIS (e.g. street, city, postal code). This would enable non-accredited users to determine the registrant’s general location and likely jurisdiction but would generally not enable identification of the registrant”. The link to the Cookbook:https://www.icann.org/en/system/files/files/gdpr-compliance-interim-model-08mar18-en.pdf. The above quote is on page 26.
EPDB Advice
Can ICANN summarize in some searchable form the contacts and engagements with the EDPB and/or other DPAs in relation to the Temporary Specification for gTLD Registration Data?
ICANN org has been open and transparent with our engagements with the EDPB and DPAs. All of the formal written communications from EDPB and DPAs are published on ICANN correspondence. In addition, we’ve had informal verbal conversations with the EDPB and DPAs to educate, inform, and ask for guidance. Summaries of those informal conversations are published in blogs. To assist the EPDP Team in its work, ICANN org will provide the EPDP Team with a compiled list of correspondence received and blogs published thus far, including the topic of each correspondence/blog.
2. Can ICANN summarize in some searchable form the contacts and engagements with the EDPB and/or other DPAs in relation to the Temporary Specification for gTLD Registration Data?
ICANN org has been open and transparent with our engagements with the EDPB and DPAs. All of the formal written communications from EDPB and DPAs are published on ICANN correspondence. In addition, we’ve had informal verbal conversations with the EDPB and DPAs to educate, inform, and ask for guidance. Summaries of those informal conversations are published in blogs. To assist the EPDP Team in its work, ICANN org will provide the EPDP Team with a compiled list of correspondence received and blogs published thus far, including the topic of each correspondence/blog. See DPA Advice Summary-DRAFT.xlsx.
3. Is there any further information that can be provided in relation to the discussions that have been held with the EDPB and/or DPAs in addition to the blog posts and correspondence that have been shared, such as briefing notes and summaries of meetings?
Aside from the blog posts and correspondence that have already been shared, and consistent with ICANN Publication Practices, ICANN org has not identified any additional notes or summaries of meetings that are suitable for publication.
ICANN org has previously stated that having clear guidance may increase legal certainty for ICANN and the contracted parties as well as assist the community in the Expedited Policy Development Process (EPDP) to consider the Temporary Specification for gTLD Registration Data (Temp Spec). Our commitment to transparency in publishing summaries of our interactions with the EDPB supports this stated purpose.
In this regard, we’ve posted summaries of our conversations with the EDPB and DPAs on ICANN’s Data Protection/Privacy Issues page. The purpose of these conversations has been to educate, inform, and request guidance. In these discussions, we have also relayed to the EDPB the concerns and questions that we have solicited from the community.
Additionally, in the Work and Tools section of the EDPB website, the EDPB states that: “We issue general guidance to promote a common understanding of European data protection laws, both across the European Union and around the world. We clarify data protection provisions, advise the European Commission and provide the general public and stakeholders with our interpretation of their rights and obligations. We can issue guidelines, recommendations and best practices about the GDPR and the Law Enforcement Directive, as well as other documents.” Accordingly, guidance from the EDPB to ICANN is publicly posted on their website and ICANN’s website so that the guidance is available for all interested parties and can help inform the work of the community
...
ICANN org has been open and transparent with our engagements with the EDPB and DPAs. All of the formal written communications from EDPB and DPAs are published on ICANN correspondence. In addition, we’ve had informal verbal conversations with the EDPB and DPAs to educate, inform, and ask for guidance. Summaries of those informal conversations are published in blogs. To assist the EPDP Team in its work, ICANN org will provide the EPDP Team with a compiled list of correspondence received and blogs published thus far, including the topic of each correspondence/blog.
2. Can ICANN summarize in some searchable form the contacts and engagements with the EDPB and/or other DPAs in relation to the Temporary Specification for gTLD Registration Data?
ICANN org has been open and transparent with our engagements with the EDPB and DPAs. All of the formal written communications from EDPB and DPAs are published on ICANN correspondence. In addition, we’ve had informal verbal conversations with the EDPB and DPAs to educate, inform, and ask for guidance. Summaries of those informal conversations are published in blogs. To assist the EPDP Team in its work, ICANN org will provide the EPDP Team with a compiled list of correspondence received and blogs published thus far, including the topic of each correspondence/blog. See DPA Advice Summary-DRAFT.xlsx.
ICANN org's GDPR Compliance
...
The presentation for the webinar is posted here, and the Adobe Connect recording is here. The question and response start at 0:27:00 in the Adobe Connect recording.. The question and response start at 0:27:00 in the Adobe Connect recording.
4. During the 19 September 2018 EPDP Q&A Session with Becky Burr, there was a request for more information regarding what ICANN org does with personal data as it relates to ICANN contractual compliance. Additionally, on 4 October 2018, ICANN org received a question from the EPDP Team regarding data retention procedures. In response to these two items, please see the attached a summary of ICANN org’s contractual compliance personal data processing activities: Summary-Contractual-Compliance-Data-Processing-Activities.pdf.
ICANN Org Liaisons Role
1. The Council envisioned, via the EPDP Charter, to have direct participation of ICANN org liaisons, within the EPDP Team. As we leave the Triage and head into substantive detail, do the ICANN liaisons see a role or specific set of actions for ICANN supporting the team?
...
Input from ICANN Compliance
Contractual Compliance responses to EPDP_25jan19.pdf
Summary-Contractual-Compliance-Data-Processing-Activities5oct18.pdf
OUTSTANDING QUESTIONS
- Is indemnification provided by ICANN through a joint controller agreement an option? If EPDP agrees on policy that requires ICANN to indemnify, would the ICANN legal team and Board oppose it?What is the rationale for not redacting organization field in the Temporary Specification?
- When will the ICANN be released memorandum concerning the roles and responsibilities in processing data. The EPDP team encourages ICANN to issue the memo within 48 hours so its position can be referenced in the Initial Report.