Expedited Policy Development Process (EPDP) on the
Temporary Specification for gTLD Registration Data – Phase 2
Input Template, 30 May 2019
To: ICANN Supporting Organizations / Advisory Committees / GNSO Stakeholder Groups / GNSO Constituencies
PLEASE SUBMIT YOUR RESPONSE AT THE LATEST BY 21 JUNE 2019 TO THE GNSO SECRETARIAT ( firstname.lastname@example.org) which will forward your statement to the EPDP Team.
Following the completion of its work on phase 1 related topics, the EPDP Team has now commenced its work on phase 2. The scope of phase 2 includes:
- Items identified in EPDP Team Charter:
◉ System for Standardized Access to Non-Public Registration Data
◉ Annex to the Temporary Specification (Important Issues for Further Community Action)
- Items deferred from EPDP Team phase 1, either requiring further consideration or dependent on input from others
The following mind map provides further detail on these items: EPDP Team Phase 2 - upd 10 March 2019.pdf .
In order to tackle these items, the EPDP Team has agreed on the following approach - see Phase 2 Approach - updated 22 May 2019.pdf .
As required by the EPDP Manual, the EPDP Team is hereby reaching out to all ICANN Supporting Organizations, Advisory Committees and GNSO Stakeholder Groups and Constituencies to request your early input to help inform the EPDP Team’s deliberations for phase 2. The EPDP Team would like to encourage you to focus your input on the questions outlined below as this will facilitate the EPDP Team’s review of the input received. However, you should feel free to add any additional information you deem important to inform the EPDP Team’s deliberations, even if this does not fit into questions listed below. Please try to avoid duplicating input that has already been conveyed through your representatives on the EPDP Team or provided through statements that were included as part of the Phase 1 Final Report.
Submitting Organization Information
- Please identify your SO/AC/GNSO Stakeholder Group / GNSO Constituency:
- Please identify the member(s) of your SO/AC/GNSO Stakeholder Group / GNSO Constituency who is (are) participating in this EPDP Team:
- Please identify the members of your SO/AC/GNSO Stakeholder Group / GNSO Constituency who participated in developing the perspective(s) set forth below:
- Please describe the process by which SO/AC/GNSO Stakeholder Group / GNSO Constituency used to arrive at the perspective(s) set forth below:
- Please identify a primary point of contact with an email address in case any follow-up is needed:
Questions for specific input :
As the GNSO Council and the EPDP Team have identified as a priority the issues related to the System for Standardized Disclosure to Non-Public Registration Data, we would like to encourage you to provide your input to the following charter questions:
● (a) Purposes for Accessing Data – What are the unanswered policy questions that will guide implementation?
● (b) Credentialing – What are the unanswered policy questions that will guide implementation?
In the annex, you will find the detailed charter questions and issues the EPDP Team is expected to address. If in addition to your input to the questions above you want to provide additional information, please feel free to do so focusing on input and information that has not been shared yet with the EPDP Team on previous occasions.
System for Standardized Access to Non-Public Registration Data
(a) Purposes for Accessing Data – What are the unanswered policy questions that will guide implementation?
a1) Under applicable law, what are legitimate purposes for third parties to access registration data?
a2) What legal bases exist to support this access?
a3) What are the eligibility criteria for access to non-public Registration data?
a4) Do those parties/groups consist of different types of third-party requestors?
a5) What data elements should each user/party have access to based on their purposes?
a6) To what extent can we determine a set of data elements and potential scope (volume) for specific third parties and/or purposes?
a7) How can RDAP, that is technically capable, allow Registries/Registrars to accept accreditation tokens and purpose for the query? Once accreditation models are developed by the appropriate accreditors and approved by the relevant legal authorities, how can we ensure that RDAP is technically capable and is ready to accept, log and respond to the accredited requestor’s token?
(b) Credentialing – What are the unanswered policy questions that will guide implementation?
b1) How will credentials be granted and managed?
b2) Who is responsible for providing credentials?
b3) How will these credentials be integrated into registrars’/registries’ technical systems?
c1) What rules/policies will govern users' access to the data?
c2) What rules/policies will govern users' use of the data once accessed?
c3) Who will be responsible for establishing and enforcing these rules/policies?
c4) What, if any, sanctions or penalties will a user face for abusing the data, including future restrictions on access or compensation to data subjects whose data has been abused in addition to any sanctions already provided in applicable law?
c5) What kinds of insights will Contracted Parties have into what data is accessed and how it is used?
c6) What rights do data subjects have in ascertaining when and how their data is accessed and used?
c7) How can a third party access model accommodate differing requirements for data subject notification of data disclosure?
Annex: Important Issues for Further Community Action
The purpose of this Annex is to set forth implementation issues raised during the course of development of this Temporary Specification for which the ICANN Board encourages the community to continue discussing so that they may be resolved as quickly as possible after the effective date of the Temporary Specification. This Annex does not create new or modified requirements for Registrar or Registry Operator, nor is it intended to direct the scope of the Policy Development Process, which will be initiated as a result of the Board's adoption of this Temporary Specification.
- Pursuant to Section 4.4, continuing community work to develop an accreditation and access model that complies with GDPR, while recognizing the need to obtain additional guidance from Article 29 Working Party/European Data Protection Board.
- Addressing the feasibility of requiring unique contacts to have a uniform anonymized email address across domain name registrations at a given Registrar, while ensuring security/stability and meeting the requirements of Section 2.5.1 of Appendix A.
- Developing methods to provide potential URS and UDRP complainants with sufficient access to Registration Data to support good-faith filings of complaints.
- Consistent process for continued access to Registration Data, including non-public data, for users with a legitimate purpose, until the time when a final accreditation and access mechanism is fully operational, on a mandatory basis for all contracted parties.
- Distinguishing between legal and natural persons to allow for public access to the Registration Data of legal persons, which are not in the remit of the GDPR.
- Limitations in terms of query volume envisaged under an accreditation program balanced against realistic investigatory cross-referencing needs.
- Confidentiality of queries for Registration Data by law enforcement authorities.
Phase 1 Recommendations
EPDP Team Recommendation #2.
The EPDP Team commits to considering in Phase 2 of its work whether additional
purposes should be considered to facilitate ICANN’s Office of the Chief Technology
Officer (OCTO) to carry out its mission (see https://www.icann.org/octo ). This
consideration should be informed by legal guidance on if/how provisions in the
GDPR concerning research apply to ICANN Org and the expression for the need of
such pseudonymized data by ICANN.
EPDP Team Recommendation #3.
In accordance with the EPDP Team Charter and in line with Purpose #2, the EPDP Team undertakes to make a recommendation pertaining to a standardised model for lawful disclosure of non-public Registration Data (referred to in the Charter as ’Standardised Access’) now that the gating questions in the charter have been answered. This will include addressing questions such as:
• Whether such a system should be adopted
• What are the legitimate purposes for third parties to access registration data?
• What are the eligibility criteria for access to non-public Registration data?
• Do those parties/groups consist of different types of third-party requestors?
• What data elements should each user/party have access to?
In this context, the EPDP team will consider amongst other issues, disclosure in the course of intellectual property infringement and DNS abuse cases. There is a need to confirm that disclosure for legitimate purposes is not incompatible with the purposes for which such data has been collected.
EPDP Team Recommendation #4.
The EPDP Team recommends that requirements related to the accuracy of registration data under the current ICANN contracts and consensus policies shall not be affected by this policy.6
Footnote: The topic of accuracy as related to GDPR compliance is expected to be considered further as well as the WHOIS Accuracy Reporting System.
EPDP Team Recommendation #11.
The EPDP Team recommends that redaction must be applied as follows to this data element:
City - Redacted
The EPDP Team expects to receive further legal advice on this topic which it will analyze in phase 2 of its work to determine whether or not this recommendation should be modified.
EPDP Team Recommendation #14.
In the case of a domain name registration where an "affiliated" privacy/proxy service used (e.g. where data associated with a natural person is masked), Registrar (and Registry where applicable) MUST include in the public RDDS and return in response to any query full non-personal RDDS data of the privacy/proxy service, which MAY also include the existing privacy/proxy pseudonymized email. Note, PPSAI is an approved policy that is currently going through implementation. It will be important to understand the interplay between the display of information of affiliated vs. accredited privacy / proxy providers. Based on feedback received on this topic from the PPSAI IRT, the EPDP Team may consider this further in phase 2.
EPDP Team Recommendation #15.
1. In order to inform its Phase 2 deliberations, the EPDP team recommends that ICANN Org, as a matter of urgency, undertakes a review of all of its active processes and procedures so as to identify and document the instances in which personal data is requested from a registrar beyond the period of the 'life of the registration'. Retention periods for specific data elements should then be identified, documented, and relied upon to establish the required relevant
and specific minimum data retention expectations for registrars. The EPDP Team recommends community members be invited to contribute to this data gathering exercise by providing input on other legitimate purposes for which different retention periods may be applicable.
2. In the interim, the EPDP team has recognized that the Transfer Dispute Resolution Policy (“TDRP”) has been identified as having the longest justified retention period of one year and has therefore recommended registrars be required to retain only those data elements deemed necessary for the purposes of the TDRP, for a period of fifteen months following the life of the registration plus three months to implement the deletion, i.e., 18 months. This retention is grounded on the stated policy stipulation within the TDRP that claims under the policy may only be raised for a period of 12 months after the alleged breach (FN: see TDRP section 2.2) of the Transfer Policy (FN: see Section 1.15 of TDRP). This retention period does not restrict the ability of registries and registrars to retain data elements provided in Recommendations 4 -7 for other purposes specified in Recommendation 1 for shorter periods. (Footnote: In Phase 2, the EPDP Team will work on identifying different retention periods for any other purposes, including the purposes identified in this Report.)