Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Tuesday, 28 August, 13:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Team Meeting - 23 August 2018 High-level Notes/Actions: Please provide additional input (if any) on the Triage Report by Friday, 24 August at 19.00 UTC. The Triage Report, scheduled for release early next week, will include the following appendices or companion documents: all the survey responses sorted by group and sorted by Temporary Specification section; a print version of the opening statements made by each group; Early Inputs submitted by each group. The Team has now begun substantive discussion of the Temporary Specification. As a tool to aid in these discussions, the support team will distribute discussion summary indexes for each survey section, which provides the relevant Temporary Specification text, related charter question(s), EPDP Team Members’ feedback provided to date (via the triage surveys), related EDPB advice (if any). The discussion summary index also provides a field in which EPDP Team Members may propose modified text. Members of the group raised the utility of performing a privacy impact assessment. Three takeaways were for members to understand the benefits of such an assessment in the work, suggest which elements could be helpful to undertake (given the timeline), and also to ask ICANN if it was planned that an impact assessment will be undertaken. See, https://bit.ly/2OVgeYY. In discussing whether and how other privacy regimes impact our work, the support team pointed out that other privacy regulations can be found at https://bit.ly/2PxFt4I. It was also indicated by Thomas and Alan that, as a generalization, GDPR provides a “high-water mark. I.e., if our work is GDPR compliant, it should be universally compliant. It was suggested that ICANN be asked to perform an assessment to determine if other privacy regimes should be analyzed for possible inclusion into this work. Per the proposed strategy discussed today, the Leadership Team is working together to propose a detailed project plan, which outlines the order in which the EPDP Team will deliberate on the sections of the Temporary Specification. For more detail on the strategy, please refer to the detailed notes. With regard to next steps, there were several recommendations that we examine the purposes of collecting and purposes of accessing data. That input matches with the existing plan to undertake a look at sections 4.4.1-4.4.13 next, which describe the uses of data. The corresponding discussion summary index that will be distributed for this discussion will include the charter questions that might be answered in parallel with this inquiry. As a prerequisite to that discussion, we will discuss the purposes of collecting data. This was discussed in depth in the RDS working group and the support team will document the findings by that working group. All Action Items: Preliminary input on the triage report is due Friday, 24 August. Goal is to submit the triage report early next week. For any groups who plan to respond to the requests to provide early input, please do so as soon as possible. Support Team to provide EPDP Team with output of RDS PDP WG’s work on which data elements are required to register a domain name and maintain that registration. EPDP Team members to look at the discussion summary indexes for Appendix D, E, F and provide recommend redlines (if any) to the email list. We will attempt to address these sections via email rather than take up meeting time with them. Support team to distribute discussion summary index for Section 4.4, as well as RDS findings with regards to the purposes of collecting registrant data. EPDP Team members to review discussion summary index for Section 4.4 in preparation to discuss at next EPDP Team meeting on Tuesday, 28 August at 13.00 UTC These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/2IpHBQ. 1. Roll Call & SOI Updates Attendance will be taken via the Adobe Connect Room. SOIs must be kept up-to-date. All relevant documentation can be found on the EPDP wiki space. Please remember to state your name before speaking. 2. Welcome and Updates from EPDP Team Chair We will be moving from discussing every section of the Temporary Specification in the triage surveys and turning to a substantive review of specific sections. We will spend the first part of the meeting discussing the strategy for moving forward. 3. Preliminary input on Triage Report (deadline for input: Friday, 24 August at 19:00 UTC) Preliminary input on the triage report is due Friday, 24 August. Goal is to submit the triage report early next week. As a reminder, for any group who would like to respond to the early input requests, please do so as soon as possible. The triage report will be updated to include all submitted comments. 4. Proposed approach for moving forward, including review of proposed project plan A GDPR-compliant specification is required by 25 May, requiring a good portion of our work to be completed in October. GDPR-compliance requires, among other things, that the sections specifying processor requirements must have the consensus support of this team Some prioritization is required that takes into account: The time available Sections that require registrar / registry & other processor actions Issue complexity Which sections are already in operation and functioning Availability of EDPB and other guidance Further guidance is possible (dependent on timing) New questions for EDPB or DPAs Clarification requests of existing guidance But case law and standard practices will be lacking EPDP Team feedback: The goal is to comply with GDPR Any successor should take into account emerging privacy law in other jurisdictions. Aiming to tackle the topic of privacy in a more holistic way would be a more efficient use of our time. Examples could include privacy-by-design principles or a privacy impact assessment What is a privacy impact assessment? Generally, a privacy impact assessment would be a systematic process conducted by government agencies or businesses to reflect on privacy and see how various practices impact individuals Is some sort of survey needed of other privacy regimes? A privacy impact assessment has been around in several jurisdictions for years. The only problem in doing a privacy impact assessment is that it's only as good as the framework you apply, and since there are over 100 national laws around the world, you would have to select the leader or come up with a framework that allows you to select other laws. In the context of emerging legislative and regulatory initiatives that may impact on ICANN, please see https://www.icann.org/en/system/files/files/legislative-regulatory-fy18-23ap.... This is something that is actively being tracked. It might not be necessary to select a particular regime for a privacy impact assessment. The GDPR is principle-based, and the principles can be applied broadly. The privacy impact assessment could be based on broad principles. What we are effectively doing in the EPDP is a privacy impact assessment of the temp spec ourselves -- for example, are the purposes connected to a solid legal basis? Doing a privacy impact assessment for ICANN would be a complicated and expensive exercise. Other companies may look at this type of work as a threat assessment -- what are we trying to protect? Who has access to it? Who is using it? Is there a specific question to ask ICANN - whether any of the other regimes create requirements above and beyond the GDPR? Proposed Criteria for Discussion Planning Priority must be assigned to those sections: affected by EDPB advice, i.e., where change is mandated by advice received after the specification was written where the Team has indicated the likelihood that change is required to bring the section into compliance with GDPR Requiring less attention are issues that are not expected to impact the Temporary Specification’s compliance with the GDPR, such as: operations changes to existing consensus policy such as UDRP or Transfers requirements issues that can be settled after the initial report is launched, e.g., SLAs to be negotiated between contracted parties and ICANN, Best practices and reporting requirements where it is thought the Temporary Specification is overly prescriptive Unless a pre-requisite to the issues above, those items that do not direct registry and registrar actions can be considered as time is available such as: background, rationale, justification, administrative sections. Sections affected by EPDB are Category 1. Sections where the Team Indicated Amendment to the Temp Spec is desirable are Category 2. Sections related to transfers, DRPs and require little or no change, are Category 3. Sections involving background, admin are Category 4. For sections where there is pertinent EDPB guidance or where the Team has indicated a likelihood that change is required: Allocate time to ensure a common understanding of: The Temporary Specification section Existing EDPB advice or other authority Previous discussion and the issues raised Deliberate what changes, if any, are required, to ensure that the advice has been addressed. As these are more complex issues the discussion might be plan to extend over (a part of) two or three sequential meetings. If it becomes clear that additional information, research or guidance is necessary, or that progress might be facilitated by offline discussion between two or more parties, then a small group might be assigned work, that will operate based on the task assigned: Populated by interested and necessary parties Working methods (e.g., email, conference) based on the task assigned With delivery set to support a delivery of the initial report This approach is meant to be flexible. For sections that are not expected to impact the Temporary Specification’s compliance with the GDPR, or those items that do not direct registry, registrar and other processor actions: Time will be allocated for a briefing on these items during meetings to review the previous discussion and issues raised. In many cases, attaining consensus might be attained in a brief period. Where addition refinement is necessary an expert group might be asked to provide additional information or recommend an amendment: Ex: where the Temporary Specification recommends content for Privacy Notices to be posted by registrars: a registrar and GDPR expert might be asked to create a better approach Wherever possible, this additional work would be considered and included in the initial report. If not and based on the subject matter, the Team will consider the timing of inserting the new draft into the successor specification for approval. Depending on the review and the approval cycle, inclusion into the successor specification might occur before or after the final report. (This is a ”parking lot” where issues will be recorded and resolved.) EPDP Team Feedback: While not against this approach, using an example - for discussing transfers, you first need to discuss what data goes to a registry. Depending on that outcome, you can then discuss transfers. It's important to have the questions in the correct sequence so that problems don't occur and/or already-proposed changes need to be corrected later in the process. A point of contention between people in the group is whether ICANN has made the legal argument over where information can be collected and later distributed. Who is responsible for building the legal argument? Is it the EPDP team's job or is that ICANN org's job? ICANN may believe it has built the legal argument in the Temp Spec, but there is a question whether that has been satisfied in this group. Perhaps the team can tailor the discussion around the processing of data under GDPR - after doing that, the team can go back and look at ICANN's powers. The EPDP Team needs to deal with the fundamental issues regarding what data needs to be collected and redacted. ICANN org thinks it has already done this, but the team should come to an agreement on the redacted data elements. Purpose and collection is equally fundamental, but it's unlikely the team will come to agreement on that. Agreeing on redacted data elements appears to be a concrete and specific task. Our charter lays out the questions (and the sequence to be used to answer them) quite nicely. Our charter already laid out the sequence, so the team should follow the charter and use that order of how to approach the work. The Team can decide how to tackle the work, but the charter provides a good order to begin with. For example, tackling purposes is critical. If we do not come up with an agreed upon set of purposes for our deliberations, we will never agree on other points. Agree that we need to debate the purposes. The GAC's next meeting is to discuss what data will be provided, and how will the data be transferred. The purpose issue is primary; however, having debated purposes since 2005, there is concern we will never move past that. Some may approach this as what data they would like access to and work backwards to try to get data. What is the plan when we discover we cannot agree on purposes? This EPDP was formed to break this deadlock, and as a group, we have to find a way to move forward. It will be impossible to debate other sections without first agreeing on purposes. People tend to justify data they need and define purposes based on that; however, one thing that we could catch in a privacy impact assessment is what problem are we trying to solve? You may or may not have to collect information to solve a problem. As we discuss purposes, we should come back to the problems we need to solve, like hijacked domain names. The problems may also be a source of contention, but the group may agree on these problems. What the group should aim for is to make sure that the purposes listed do comply with the privacy laws. In terms of going about the work the team needs to do, debates around purpose would happen in category 2, but perhaps the group needs to see the full schedule. Maybe if the group maps the schedule based on the flowchart in the slides, and include the charter questions for each piece of work, the team could see the roadmap and have a better idea of the work going forward. Some members believe the discussion of purpose may be theoretical and abstract, but this is problematic. If purposes of the data to be collected is abstract in theory, the whole Temp Spec is abstract in theory. We are operating in a multi-stakeholder environment – we are trying to retrofit a set of policies and contracts so that it does not violate data protection law and the GDPR. Naturally, we have a hard time determining purpose because many of the stakeholders consider their purpose the same as the registrar’s purpose. The actual purpose for collecting registration data is a very narrow one – it is for the domain name to function. Publishing this data is not a legitimate purpose. The RDS Team raised most of these arguments, and if we have to rehash these arguments, this team will fail. What problem are we trying to solve, and what data do we need? This question is inherently problematic – rather than collecting use cases, we should ask what is ICANN’s purpose. If we continue to focus on what data we need, we lose sight of the problem. If I had a guarantee that if I go to a Ry/Rr and get information in a predictable timeframe, I may never have to see the data (probably unlikely), but this is a possibility. There is a trap for an attractive piece of data and why it should be published, and we should avoid this. Let’s look to the technical people to solve the problems of bulk access. Focusing on the data itself is a bit of a trap. Focusing instead on purposes is very important. ICANN needs to collect data to fulfill its purposes – its purposes are not IP or law enforcement; however, the data is collects may be useful to entities with legitimate purposes. If we recognize the difference between ICANN’s purpose and third-party purposes, the group can make progress. When we confuse third party purpose with the purpose of WHOIS is where we run into trouble. We should first look at what data needs to be collected for domain name registration. Then we can look at what additional data might be required – that could include additional data under consent. Then, you can look at transfer of data to other parties. If we go through that thought process, we can look at what data can be collected in domain name registration. As well as looking at what is necessary for registration contracts, we need to look at ICANN’s mission/coordination role. GDPR recognizes there are legitimate purposes and exemptions – what is missing from our conversation is an assessment of necessity and proportionality. One problem is that we have different opinions on what ICANN’s mission is – one part of ICANN’s mission is to secure a trusted DNS. What does ICANN need to do to achieve that part of our mission – that is where the tie-in to law enforcement and third-party interests lie. The team seems to be confusing several issues – one thing we need to talk about is enforcement of contracts. There is an agreement in the registration agreement that the registrant submits to UDRP disputes. This is squarely within the mission of ICANN and providing a framework for having a trusted DNS. The mission is not that narrow. What the team should do is try to peel the onion. Start by looking at data collected for the registrant – look at what is required to register a domain name and maintain that registration. We are conflating what is required to perform a contract with the overarching goals ICANN has in its mission. The RDS WG already did some of this work. One of the homework assignments is to go back to the RDS WG’s work to look at which data elements are required to register a domain name and maintain that registration. Our future conversations will be guided by discussion summary indexes. For each section (and relevant sub-sections) a scorecard will be prepared to facilitate the deliberations which will include: Current text Identification of category Related charter question(s) Support indicated as result of triage effort DPA/EDPB Advice (if any) Proposed changes / rationale for change (as provided by EPDP Team in response to triage surveys) Information to be completed: Proposed response to charter question(s) High level summary of the deliberations and/or recommendation(s) Proposed modification of text (if appropriate) Level of consensus Data Summary Index to facilitate development of Initial Report The number of meetings we have to get the work done is limited, as displayed on the screen. The leadership team is embarking on how to divide the work in the meetings. 5. Commence deliberations and review of Appendix D – Uniform Rapid Suspension (see discussion summary index) 6. Commence deliberations and review of Appendix E – Uniform Domain Name Resolution Dispute Policy (see discussion summary index) 7. If time allows, commence deliberations and review of Appendix G: Supplemental Procedures to the Transfer Policy (see scorecard attached) 8. Wrap and confirm next meeting to be scheduled for Tuesday 28 August at 13.00 UTC. Action Items: Preliminary input on the triage report is due Friday, 24 August. Goal is to submit the triage report early next week. For any groups who plan to respond to the requests to provide early input, please do so as soon as possible. Support Team to provide EPDP Team with output of RDS PDP WG’s work on which data elements are required to register a domain name and maintain that registration. EPDP Team members to looks at the discussion summary indexes for Appendix D, E, F and provided suggested mark-ups (if any) to the email list Support team to distribute discussion summary index for Section 4.4 EPDP Team members to review discussion summary index for Section 4.4 in preparation to discuss at next EPDP Team meeting on Tuesday, 28 August at 13.00 UTC