Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Thursday, 20 September, 13:00 UTC. Best regards, Caitlin, Berry, and Marika =============== EPDP Team Meeting #14 Tuesday, 18 September 2018 Notes and Action Items High-level Notes/Actions: Action item #1: Please complete GDPR Training Course by Tuesday 18 September All EPDP Team Members, Alternates and Liaisons should have received an email with login credentials from noreply@grcelearning.com on Monday, 10 September. Action item #2: EPDP Team to submit any questions / topics for the upcoming session with Becky Burr to the google doc: https://docs.google.com/document/d/1QBy9YhdoaQ2yBmPicUSJai9YaNPZWrRywFJVlJAF... Action item #3: Staff to review principles document and aim to identify where Appendix C data processing principles are already covered in other parts of the Temporary Specification and suggest a way to integrate the required materials.. Action item #4: EPDP Team leadership to see if certain comments made in relation to this discussion on 4.4 can be translated into principles that would guide the EPDP Team's discussion on purposes. Questions for ICANN Org from the EPDP Team: None Notes & Action items 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 from Adobe Connect * Please remember to mute your microphones when not speaking, and state your name before speaking for transcription purposes. * Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Welcome and Updates from EPDP Team Chair (5 minutes) a) Reminder to complete GDPR Training Course by Tuesday, 18 September Action item #1: Please complete GDPR Training Course by Tuesday 18 September b) Reminder of GDPR Q&A session with Becky Burr on Wednesday, 19 September, scheduled for 13.00 UTC. Action item #2: EPDP Team to submit any questions / topics to the google doc: https://docs.google.com/document/d/1QBy9YhdoaQ2yBmPicUSJai9YaNPZWrRywFJVlJAF... c) ICANN63 Travel Support * 4 applications received which were all granted d) Recap CBI Open House Session * Session held yesterday to allow EPDP Team members to provide input on do's and don'ts for a F2F meeting. Will guide development of the agenda and approach for F2F meeting next week. * Session was recorded and transcribed for those interested. * Draft agenda expected to be shared shortly. There may a need for iteration. Likely to be shared with EPDP Team for input. e) Other updates, if applicable * Use of DSIs - one stop shop for all documentation that supports a certain subject. Slides are to a certain extent a duplication of this information. Going forward rely much more heavily on those to serve as a reference for the deliberations. * CBI - has invited teams to reach out to provide further guidance as needed. CBI to provide status update on outreach. * See timeline - 8 meetings left to ICANN63, which includes 3 days of F2F 3. Appendix C (30 minutes) Objective: Reach Preliminary Agreement on how to move forward with Appendix C a. Review additional input provided by RySG b. Agree on next steps * Original proposal provided by RySG (see email from Alan Woods) to remove Appendix C * Modification by BC (see email from Margie Milam) - some principles outlined in the document should be kept * Support for modification as suggested by BC by IPC (see email from Diane Plaut) * Redline of Appendix C shared with the mailing list which aims to apply the modifications suggested by Margie. Proposal to use that as a starting point. Transformation to principles so no longer an appendix. * Note that additional input was received from RySG in response to BC proposal. * Proposals are diametrically opposed as RySG proposed to eliminate all of Appendix C. Views are coming from very different perspective - focus from RySG is on what absolutely has to get done to assure GDPR compliance, while others seem to focus on broader issues and topics that go beyond that narrow remit. Need to agree on what the scope of work and EPDP Team deliverable is. * Need to make GDPR requirements enforceable vis a vis those that might not be governed by GDPR. However, the policy EPDP Team needs to come up with has to adhere to the named principles, so they will (hopefully) be baked into our policy. For other areas, it may be better to just state that GDPR principles need to be followed and maybe have an explanatory document along with the Policy (but not part of it) that quotes the text of the law? * Would removing Appendix C be taking a step back? Provides data subject with the information necessary to ensure compliance with GDPR. * Significant part of appendix C is reciting GDPR - is that really necessary? There shouldn't be a need to replicate. But need to focus on defining legitimate interests as outlined in Appendix C. * Need to review if there are operational aspects that should be retained and achieve the aims that were stated by BC/IPC. * Reasons for keeping Appendix C are not what appendix C actually does so it does not seem to add value. Encourage to re-read the input provided by the RySG as to why Appendix C is not needed and how the important principles are already covered in other areas. * Review data processing principles document and determine which aspects already appear in the temp spec and as such may not be needed. Also make sure that exact wording and/or reference of GDPR is used. * Some of the aspects referenced may not be relevant for the policy - contracted parties have certain obligations that they have to follow regardless, putting certain principles in a policy is not the task of the EPDP and shouldn't be the focus. Need to agree on the scope of EPDP Team's work. EPDP Team will have to apply its judgement to ensure that recommendations have the right level of specificity. Broad remit for how specific group can be. Action item #3: Staff to review principles document and aim to identify where Appendix C data processing principles are already covered in other parts of the Temporary Specification. 4. Section 4.4 (80 minutes) Objective of discussion: (1) begin formulating answers to Charter questions: 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? (2) begin formulating answers to EDPB advice re: ICANN not conflating its own purposes with the interests of third parties. a. Review input received on Registrar purposes (see https://docs.google.com/document/d/1IinDj9isH6uU-KYIVPPu2GyT0-Q3urTXXIW1Hhr_...) b. Agree on next steps c. Review input received on overview of purposes (see https://docs.google.com/spreadsheets/d/1RivZFrPQpJ_bgDlOI6yfhhYaSs2oYgS1n4TO...) d. Agree on next steps New format of 4.4: * Registrar purposes for processing data * Registry purposes for processing data * ICANN purposes for processing data * Purposes for processing data by third-party interests * There would likely be repetition of purposes in these categories. * Consider separating between first and third party purposes - need to establish who wants what. Or should focus be on who needs what, not who wants what. * Next step following matrix would be what kind of data is processed. May be difficult to itemize each use, but may be able to approach this in a more general way and base it on ICANN Bylaw provisions. * ICANN purposes and registrars/registries are not necessary the same thing. Looking here only at ICANN purposes. Third parties do not have purposes, it is their interest - these are separate things. * The aim of this table is ONLY to establish who is pursuing what purposes. Let's work on legal basis, rationale and other questions in the data matrix and then link back to this document to match (if possible) the processing activities in the data matrix with the purposes (which might need to be refined or narrowed as the case may be). Hence, the language in this list of purposes is provisional only. * Need to conduct a privacy impact assessment on the framework EPDP Team is looking at. ICANN Bylaws may not comply with data protection law. * Detailed and specific interests of third parties are separate and need to be dealt with elsewhere, but ICANN's Bylaws do fit in within ICANN's purpose as outlined in 4.4.8 and 4.4.9. It is to recognize what is within ICANN's Bylaws (see for example email Laureen sent to the list). * Is there conflation between the purposes of ICANN and those of registries and registrars? * Registries and registrars have purposes for processing data and this is separate from ICANN Org purposes. CP will try to limit their liability. Where is the voice of ICANN? Would ICANN take responsibility for requiring the processing of certain data? Isn't this for the EPDP Team to determine? Or is ICANN Org expected to provide this input? Bylaws are the result of community work and recommendations, not staff. * Could some of the points made be translated into principles that should guide the EPDP Team's discussion on purposes. * Who is pursuing what purpose? This is separate from the exercise of whether the purpose is lawful, is there a legal basis to support a certain purpose? * Review overview of purposes chart - note proposed modifications in red. Goal is to get clarification for why additional interests for processing where added for certain groups. At later stage assessment would be made in relation to legitimacy. * Need to make sure that purposes for access are listed, even if details of access are dealt with at a later stage - agree that first need to talk about the other purposes and only then focus on third party interests. The access and disclosure question is an important one, but may get lost and tied up in that discussion if deliberations are started now. Even though some may want to put a marker down and spelling out a purpose for why data needs to be collected for an access purpose, but you cannot discuss the legality of collection of data without answering the question of the legality of access. Need to determine first what can be collected - if there are additional purposes that justify collection these could be added later on. There will be iteration, let's not get hung up on how this iteration is done. * 4.4.3 - ICANN purpose as it aims to address abuse. Disagreement - identification or contacting is not a purpose for ICANN. But it is probably a purpose for other registrars, not necessarily the original registrar. Giving the registrant a right to transfer the name from one to another - important for registrant interests. * Enabling a mechanism for identifying a registered name holder - for example, UDRP - identifies the registrant so that dispute can continue. Compliance processes - could ask ICANN Compliance whether they ever need to verify the identity of a registrant to determine whether a complaint is valid. ICANN has obligation in relation to accuracy of WHOIS - need to have access to registrant information. Need to identify that a registrant is linked to a certain registration (not necessarily verify that the registrant is who he/she says they are). * For UDRP, it is actually a registrar purpose not ICANN - they do not have a necessity to see that data. Separate processing of data when data subject complains to ICANN as data is provided directly. Accuracy is invoked through audit, not through access. Need to ask the question of necessity - what is necessary? If it is not necessary to fulfil that function, it should not be included. * May need to clarify what is meant with 'identifying'? Is it just to link registrant to a certain domain name registration or is something else meant here? * Transfers are now solely reliant on auth info codes - no longer dependent on WHOIS data. * Note that this clause is further limited as it references purposes identified below. * 4.4.4 - to be removed as no one is identified as pursuing this purpose. * 4.4.10. - not clear on how this works in practice, does access to zone files require facilitation? Do zone files contain personal data? No, unlikely. Maybe this should be discussed together with ICANN purposes as it is not clear who is pursuing this purpose? May be put in in relation to the centralized zone data service (CZDS)? Data has nothing to do with the registration of the domain name - is completely separate data processing activity so does not belong here and not within scope for EPDP Team. Agreement that zone files do not contain personal data and as such this purpose should not be further considered by the EPDP Team. Action item #4: EPDP Team leadership to see if points made in relation to this discussion on 4.4 can be translated into principles that would guide the EPDP Team's discussion on purposes. 5. Confirm action items and questions for ICANN Org, if any (5 minutes) 6. Wrap and confirm next meeting to be scheduled for Thursday 20 September at 13.00 UTC. Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-e...>.