EPDP Team Membership
Who can join the EPDP Team as a member?
Unlike other GNSO PDP efforts, which are open for anyone to join, the GNSO Council has decided to limit the membership composition of this EPDP primarily in recognition of the need to complete the work in a relatively short timeframe and to resource the effort responsibly. GNSO Stakeholder Groups, the Governmental Advisory Committee (GAC), the Country Code Supporting Organization (ccNSO), the At-Large Advisory Committee (ALAC) and the Security and Stability Advisory Committee (SSAC) have each been invited to appoint up to a set number of members and alternates, as outlined in the charter [include link]. In addition, the ICANN Board and ICANN Org have been invited to assign a limited number of liaisons to this effort.
To see who have been appointed to the EPDP Team, please see https://community.icann.org/x/2opHBQ.
If I am not appointed as a member, does that mean I cannot be involved?
No, even if you are not an appointed member, you can follow the deliberations of the EPDP Team by signing up as a mailing list observer as well as follow the meetings via real-time audio cast. In addition, recordings and transcripts of all meetings are expected to be publicly posted. Furthermore, the charter dictates that the EPDP Team should make provisions as part of its work plan to provide regular updates to the broader ICANN community and others interested, for example, through newsletters and/or webinars. Moreover, the EPDP Team is required to reach out at an early stage to GNSO Stakeholder Groups / Constituencies as well as other ICANN Supporting Organizations and Advisory Committees to request input and everyone will be invited to comment on the Initial Report once it is published for public comment.
To sign up as a mailing list observer, please go to: https://goo.gl/forms/iZg5JWHOnERsoEMI2
To review EPDP Team recordings and transcripts, please see: EPDP on the Temporary Specification for gTLD Registration Data.
EPDP Team Scope
What is the scope of the EPDP?
The proposed scope of the EPDP Team’s efforts includes confirming, or not, the Temporary Specification by 25 May 2019 (the date the Temporary Specification will expire). Additionally, the proposed scope includes discussion of a standardized access model to nonpublic registration data; however, the discussion of a standardized access model will occur only after the EPDP Team has comprehensively answered a series of “gating questions”, which will be specified in the EPDP Team’s Charter.
What questions is the EPDP expected to answer?
Terms of the Temporary Specification
Part 1: Purposes for Processing Registration Data
a) Purposes outlined in Sec. 4.4.1-4.4.13 of the Temporary Specification:
a1) Are the purposes enumerated in the Temporary Specification valid and legitimate?
a2) Do those purposes have a corresponding legal basis?
a3) Should any of the purposes be eliminated or adjusted?
a4) Should any purposes be added?
Note: Questions under a) are gating questions for the EPDP Team’s discussion of access, in that they must be answered before work on a standardized access model can commence. They are gating because establishing purposes will inform decisions about how personal data in registration data is processed. Because providing access to non-public Registration Data is a processing activity, there must be a legitimate purpose(s) with a corresponding legal basis(es) established prior to granting such access. Further, as pointed out by the European Data Protection Board (“EDPB”) (letter from Jelinik to Marby, July 5, 2018), the EPDP Team should recognize the distinction between ICANN’s purposes for processing registration data, and the purposes which third parties may present to obtain the disclosure of data.
Part 2: Required Data Processing Activities
b) Collection of registration data by registrar:
b1) What data should registrars be required to collect for each of the following contacts: Registrant, Tech, Admin, Billing?
b2) What data is collected because it is necessary to deliver the service of fulfilling a domain registration, versus other legitimate purpose as outlined in part (A) above?
b3) How shall legitimacy of collecting data be defined (at least for personal data collected from European registrants and others in jurisdictions with data protection law)?
b4) Under the purposes identified in Section A, is there legal justification for collection of these data elements, or a legal reason why registrars should not continue to collect all data elements for each contact?
Note: Questions under b) are gating questions for the EPDP Team’s discussion of access, in that they must be answered before work on a standardized access model can commence. They are gating because the answers to these questions will establish a baseline set of data that is collected for each domain name registration, which will in turn inform what data is made public, as opposed to only made available to accredited users.
c) Transfer of data from registrar to registry:
c1) What data should registrars be required to transfer to the registry?
c2) What data is required to fulfill the purpose of a registry registering and resolving a domain name?
c3) What data is transferred to the registry because it is necessary to deliver the service of fulfilling a domain registration versus other legitimate purposes as outlined in part (a) above?
c4) Is there a legal reason why registrars should not be required to transfer data to the registries, in accordance with previous consensus policy on this point?
c5) Should registries have the option to require contact data or not?
c6) Is there a valid purpose for the registrant contact data to be transferred to the registry, or should it continue to reside at the registrar?
Note: Questions under c) are gating for the EPDP Team’s discussion of access in that they must be answered before work on a standardized access model can commence. They are gating because the answers to these questions will determine which parties hold all registration data (thick WHOIS), and therefore are able to provide access to that data.
d) Transfer of data from registrar/registry to data escrow provider:
d1) Should there be any changes made to the policy requiring registries and registrars to transfer the data that they process to the data escrow provider?
d2) Should there be any changes made to the procedures for transfer of data from a data escrow provider to ICANN Org?
e) Transfer of data from registrar/registry to ICANN:
e1) Should there be any changes made to the policy requiring registries and registrars to transfer the domain name registration data that they process to ICANN Compliance, when required/requested?
f) Publication of data by registrar/registry:
f1) Should there be any changes made to registrant data that is required to be redacted? If so, what data should be published in a freely accessible directory?
f2) Should standardized requirements on registrant contact mechanism be developed?
f3) Under what circumstances should third parties be permitted to contact the registrant, and how should contact be facilitated in those circumstances?
Note: Questions under f) are gating for the EPDP Team’s discussion of access in that they must be answered before work on a standardized access model can commence. They are gating because the answers to these questions will determine what data is made available through a public Registration Data Directory Service (RDDS) record, as opposed to only made available to accredited users.
g) Data retention:
g1) Should adjustments be made to the data retention requirement (life of the registration + 2 years)?
g2) If not, are changes to the waiver process necessary?
g3) In light of the EDPB letter of 5 July 2018, what is the justification for retaining registration data beyond the term of the domain name registration?
h) Applicability of Data Processing Requirements
h1) Should Registry Operators and Registrars (“Contracted Parties”) be permitted or required to differentiate between registrants on a geographic basis?
h2) Is there a legal basis for Contracted Parties to differentiate between registrants on a geographic basis?
h3) Should Contracted Parties be allowed or required to treat legal and natural persons differently, and what mechanism is needed to ensure reliable determination of status?
h4) Is there a legal basis for Contracted Parties to treat legal and natural persons differently?
h5) What are the risks associated with differentiation of registrant status as legal or natural persons across multiple jurisdictions? (See EDPB letter of 5 July 2018).
i) Transfer of data from registry to Emergency Back End Registry Operator (“EBERO”)
i1) Consider that in most EBERO transition scenarios, no data is actually transferred from a registry to an EBERO. Should this data processing activity be eliminated or adjusted?
j) Temporary Specification and Reasonable Access
j1) Should existing requirements in the Temporary Specification remain in place until a model for access is finalized?
If so:
1. Under Section 4 of Appendix A of the Temporary Specification, what is meant by “reasonable access” to Non-Public data?
2. What criteria must Contracted Parties be obligated to consider in deciding whether to disclose non-public Registration data to an outside party requestor (i.e. whether or not the legitimate interest of the outside party seeking disclosure are overridden by the interests or fundamental rights or freedoms of the registrant)?
B. If not:
1. What framework(s) for disclosure could be used to address (i) issues involving abuse of domain name registrations, including but not limited to consumer protection, investigation of cybercrime, DNS abuse and intellectual property protection, (ii) addressing appropriate law enforcement needs, and (iii) provide access to registration data based on legitimate interests not outweighed by the fundamental rights of relevant data subjects?
j2) Can the obligation to provide “reasonable access” be further clarified and/or better defined through the implementation of a community-wide model for access or similar framework which takes into account at least the following elements:
1. What outside parties / classes of outside parties, and types of uses of non-public Registration Data by such parties, fall within legitimate purposes and legal basis for such use?
2. Should such outside parties / classes of outside parties be vetted by ICANN in some manner and if so, how?
3. If the parties should not be vetted by ICANN, who should vet such parties?
4. In addition to vetting the parties, either by ICANN or by some other body or bodies, what other safeguards should be considered to ensure disclosure of Non-Public Personal Data is not abused?
Part 3: Data Processing Terms -- To be concluded during the initial stage of the EPDP work, as part of the Temporary Specification review and initial report.
k) ICANN's responsibilities in processing data
k1) For which data processing activities undertaken by registrars and registries as required by the Temporary Specification does ICANN determine the purpose and means of processing?
k2) In addition to any specific duties ICANN may have as data controller, what other obligations should be noted by this EPDP Team, including any duties to registrants that are unique and specific to ICANN’s role as the administrator of policies and contracts governing gTLD domain names?
l) Registrar's responsibilities in processing data
l1) For which data processing activities required by the Temporary Specification does the registrar determine the purpose and means of processing?
l2) Identify a data controller and data processor for each type of data.
l3) Which registrant data processing activities required by the Temporary Specification do registrars undertake solely at ICANN's direction?
l4) What are the registrar's responsibilities to the data subject with respect to data processing activities that are under ICANN’s control?
m) Registry's responsibilities in processing data
m1) For which data processing activities required by the Temporary Specification does the registry determine the purpose and means of processing?
m2) Which data processing activities required by the Temporary Specification does the registry undertake solely at ICANN's direction?
m3) Are there processing activities that registries may optionally pursue?
m4) What are the registry's responsibilities to the data subject based on the above?
Part 4: Updates to Other Consensus Policies
n) URS
n1) Should Temporary Specification language be confirmed, or are additional adjustments needed?
o) UDRP
o1) Should Temporary Specification language be confirmed, or are additional adjustments needed?
p) Transfer Policy
p1) Should Temporary Specification language be confirmed or modified until a dedicated PDP can revisit the current transfer policy?
p2) If so, which language should be confirmed, the one based on RDAP or the one based in current WHOIS?
q) Sunsetting WHOIS Contractual Requirements
q1) After migration to RDAP, when can requirements in the Contracts to use WHOIS protocol be eliminated?
q2) If EPDP Team’s decision includes a replacement directory access protocol, such as RDAP, when can requirements in the Contracts to use WHOIS protocol be eliminated?
System for Standardized Access to Non-Public Registration Data
Work on this topic shall begin once the gating questions above have been answered and finalized in preparation for the Temporary Specification initial report. The threshold for establishing “answered” for the gating questions shall be consensus of the EPDP Team and non-objection by the GNSO Council.
(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?
(c) Terms of access and compliance with terms of use – What are the unanswered policy questions that will guide implementation?
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?EPDP Team Deliverables
What deliverables is the EPDP Team expected to produce?
The first deliverable of the EPDP Team shall be a triage document of the Temporary Specification, which includes items that have the Full Consensus support of the EPDP Team that these should be adopted as is (with no further discussion or modifications needed). These items need to be:
In the body of the Temporary Specification (not in the Annex)
Within the "picket fence" (per limitations on Consensus Policy as set out in the Contracts)
Not obviously in violation of the GDPR / Assumed to be compliant with GDPR [Presumed to be legal according to the members’ best knowledge of GDPR]
Consistent with ICANN’s Bylaws
Deliberations of this first deliverable should include at least one round of elimination of clauses, if appropriate, and a second round of Full Consensus approval of a whole set of clauses.
The second deliverable shall be the Initial Report which will include the items that received Full Consensus support per the triage document as well as all other items of the Temporary Specification (not including the Annex) that were considered and deliberated upon, followed by a Final Report following review of public comments. Per the illustrative timeline below, this implies that the Initial Report on the items related to the Temporary Specification (excluding the Annex) is expected to be published for public comment shortly after ICANN63 (October 2018) and the Final Report delivered to the GNSO Council for its consideration by the end of January / beginning of February 2019.
The third deliverable of the EPDP Team shall be an Initial Report outlining a proposed model of a system for providing accredited access to non-public Registration Data, followed by a Final Report following review of public comments.
The Team shall not commence work on the aforementioned third deliverable of an Initial Report outlining the proposed model of a system for providing accredited access to non-public Registration Data until all gating questions have been answered.
EPDP Team Work Plan
Where can I find the EPDP Team work plan?
The EPDP Team is expected to produce a work plan as one of its first deliverables. Once developed, it will be posted on the EPDP Team workspace: https://community.icann.org/x/2opHBQ.