Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Tuesday, 11 September, 13:00UTC. Best regards, Marika, Berry, and Caitlin EPDP Team Meeting #11 6 September 2018 High-level Notes/Actions The Triage report will be sent to the GNSO Council tomorrow, absent any comments that would cause a group discussion. Feedback on the triage report, if any, is due today. Applications for travel support to ICANN63 in Barcelona are due Thursday, 13 September. Please note the document that was sent with the meeting slides today. A GDPR training vendor has been selected, which will provide a self-paced, online GDPR introduction course. All EPDP Team Members will be required to complete this course, and details on how to take the course will be distributed when available. Following the online training, there will be an additional in-depth presentation(s) by EPDP Leadership-selected GDPR experts. During today’s meeting, Registrar EPDP Team Members presented an edited version of Temporary Specification §4.4, which focused on registrar purposes for data processing. Following the explanation, EPDP Team Members provided constructive feedback, by group, on the proposed edits. Many Team Members indicated that the lack of time to comprehensively review the edits in advance of the meeting will cause them to adjust their initial feedback later. EPDP Team Members may continue providing feedback to the list. The Support Team will provide an organized description of the comments to indicate the progress toward consensus on each section and where commenters pointed the way toward additional discussion. To aid in the Team’s discussion at the next meeting, Thomas and Benedict will develop a sub-divided §4.4 into: (1) where ICANN acts as a sole controller; (2) where ICANN acts as a joint controller with registrars / registries; (3) where ICANN facilitates or enables a third-party framework. It will be delivered by Monday, September 10. The next meeting will cover the reformatted and edited §4.4 as described above, input describing edits to §§4.4.2, 4.4.8 and 4.4.9. Assuming acceptance (at some level) of the edited §4.4 introduction that was described at the end of the meeting, each “editor” will also include the GDPR basis listed in the introduction as the justification for inclusion as a legitimate purpose for processing data. EPDP Team Members provided the following two links for further reading: (1) an eight-year old Article 29 Working Party Opinion on the concepts of "controller" and "processor" https://iapp.org/media/pdf/resource_center/wp169_concepts-of-controller-and-... and (2) The SIDN purposes for data processing under GDPR: https://www.sidn.nl/downloads/terms-and-conditions/About_SIDNs_Privacy_Polic... 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 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 Triage report will be sent to the GNSO Council tomorrow, so please provide additional feedback (if any) by COB today. Update on status of GDPR training Proposal to use IT Governance, self-paced online training Followed by sessions by additional experts with opportunities to ask questions Update on travel to ICANN63 Travel requests are generally duu 90 days before the meeting. EPDP Team will be funder of last resort, so if you are eligible for other funding (through your SO/AC/company, or partial funding, please use that. The application form notes 14 September as the deadline, but please send in the form by Thursday, 13 September, so decisions can be made by Friday, 14 September. The ICANN63 sessions will most likely be open sessions, but the group needs to consider if these will be real working sessions. (Observers will be allowed in the room, but may not be invited to speak/contribute.) If the group could receive closure on whether these sessions are open or closed as soon as possible so that SO/ACs can plan their schedules. Other issues or concerns re: ICANN63 can be raised via the list. Other updates, if applicable Are there any suggestions on how to move forward with Section 4.4.8? Suggestions that the current method for drafting of sections may be problematic Registrars were asked to draft sections that pertain to their use of the data, and others volunteered for other sections. These drafts are used for discussion purposes, so members that disagree may speak up in the meeting and/or on the list. 3. Proposed modifications to section 4.4 - Registrar / Registry / ICANN processing of data a. Review proposed modifications put forward by the Registrar Team The registrars will present their findings, and then we will "go around the room" and discuss. Registrar overview: This proposed text was developed by Registrar members and alternates, under the supervision of the RrSG Excom. In section 4.4, we took out the reference to GDPR since there are other applicable data protection laws. Section 4.4.1 has no proposed changes. Proposal to delete Section 4.4.2 entirely. 4.4.3 - removal of identification since identification may be a broader footprint of personal information. Proposal to remove section 4.4.4 since registrars do not use WHOIS for payment/invoice purposes Proposal to remove 4.4.6 because registrars use other facilities to communicate technical changes in a domain name. 4.4.7 - proposal to eliminate entirely as this is a redundant point of contact 4.4.8 - cybercrime is folded into law enforcement. This is an area where registrars had divergent opinions re: IP interests. 4.4.9 - proposal to remove as this may belong in an access discussion 4.4.10 - proposal to remove this as registrars are not aware of a registrar purpose for publication of zone files. 4.4.11 - proposal to remove as this is covered in registrar data escrow 4.4.12 - updated to specify URS and UDRP 4.4.13 - included a provision regarding linking between obligations and sanctions under data protection laws with how to invoke contractual provisions which may be in conflict with data protection laws. b. Consider input from EPDP Team members on proposed modifications ALAC The whole section was written only with the perspective of registrar purposes and did not include ICANN purposes. We are discussing this as if they are definitive changes when they are only drafted with the registrar point of view. The intro text needs to be more clear regarding the various events that occur over the domain name lifecycle. 4.4.2 - no problem with removing this if appropriate caveats are made in the intro text 4.4.3 - BC is correct that identification needs to be included here. 4.4.5 - this is generally OK, but there needs to be more clarity on "content" - why was that added? (question for ICANN org) 4.4.6 - reference to registry is still relevant 4.4.7 - technical and administrative contacts may be necessary in certain circumstances 4.4.8 - we cannot ignore addressing cybersecurity issues 4.4.9 - we do not provide a framework for law enforcement needs, but we need to support it. 4.4.12 - we cannot leave just these two DRPs 4.4.13 - we should not conflate the compliance use of the data NCSG These edits are real progress, and most are acceptable. These are ICANN purposes, these are not third party legitimate interests. The group appeared to agree to separate ICANN purposes from third party legitimate interests a few meetings ago. 4.4.2 - support removal as this does not belong because it is not a purpose 4.4.3 - support eliminating "identifying" a registered name holder 4.4.4 - support removal - WHOIS is not needed to contact the registrant 4.4.8 - what is a tailored mechanism? if based on the registrar description, this is a framework to address these issues and that is not an ICANN purpose - this is a door through which legitimate interests can enter the process, it indicates what they are and what they are not: consumer protection is correctly removed, law enforcement proposed change is correct - law enforcement needs to use WHOIS to investigate more crime than just cybercrime. Consumer protection is correctly removed as ICANN is not a consumer protection agency. Processing of gTLD registration data for the purposes of law enforcement investigation is not an ICANN purpose. It is not correct that ICANN requires registrars/registries to collect registration data for the purpose of law enforcement. 4.4.9 - this is an access issue, not an ICANN purpose. IPC We talked about whether these are registry/registrar purposes or ICANN purposes. There are several ICANN purposes missing from this list, so there may be additions required. This is a list of purposes for all definitions of processing, and when we decide that access mechanisms should be discussed at a later time, this is a mistake. 4.4.8: what does tailored access mean? If this is an access to 4.4.12, that is a narrow definition of IP interests/rights, and this will need to be addressed. The IPC needs more time to digest this. It is within ICANN's mission to include IP protection and to limit this within 4.4.8 is incorrect. It is unclear what tailored mechanism means. Consumer protection should be added back in as this is part of ICANN's mission. With respect to ICANN purposes that are missing, there are a lot of requirements and obligations there that define the need to collect, use, and process data above and beyond this list - cybersecurity, law enforcement, intellectual property, et.al. Purposes include as part of ICANN's mission - accountability - IP rights holders, etc. 4.4 - with respect to removing specific GDPR language, this is too vague. The purpose of this EPDP is to discuss the temp spec in the context of GDPR. While we may not need to cite GDPR sections repeatedly, we could add "or future applicable laws" 4.4.2 - this shouldn't be removed. This is an important purpose. 4.4.12 - this is too broad - dispute resolution can be used in other contexts. 4.4.13 - we need to keep adequate procedures in place. There is not enough information here re: non-binding and other procedures is too vague. BC The BC needs more time to review these changes. The redlines make the purposes far too narrow from what ICANN's purposes should be. The intro to 4.4 ignores consensus policies that fulfill the mission ICANN has. 4.4.3 - the removal of identifying is not correct. It is important to know who to sue for IP purposes. It is not just the URS and UDRP that we are concerned about. 4.4.8 - GDPR requires specificity on the purposes so taking out consumer protection goes against what the GDPR requires. 4.4.13 - this needs to be broader than monitoring contractual compliance requests. A specific purpose needs to be added here. ICANN uses the information in the security department, and that purpose is not mentioned here. We should look at things from a joint controller perspective. GAC Are we discussing registrar purposes or lawful purpose of processing gTLD data? This group has no mandate to interpret the ICANN mission. 4.4.8 - while not perfect, it could be a potential basis to build upon. Is there a problem putting law enforcement together with other issues - need to confer with other GAC colleagues on this. This section should not be talking about the interests of third parties and what they need for access. This will be discussed at a later date. However, what is appropriate is how it pertains to ICANN's mission. The edits for the intro text is too narrow. RySG The proposed 4.4 is an improvement, but the RySG needs more time to review in order to provide substantive feedback. ISPCP We should not see this as carving in stone a list of purposes. This is a living document and we need to get back to the list of purposes as we move on. ICANN received a letter from the EDPB about conflating ICANN’s purposes with other purposes. One processing activity – the collection of data, for example, may have different purposes pursued by different parties. These purposes need to be supported by a legal basis. One processing activity can have a one purpose for the registrar and a different purpose for ICANN. We should remove the opening clauses and those who think we need to cover additional items need to explicitly state what they shall be. As a starting point, let’s make explicit reference to which clauses in the GDPR we are referring to. We could ask staff to work on a more general version of the text. The overarching purpose of making available domain name registration, making domain names work will fall into the bucket of registrar purposes and ICANN purposes. SSAC Divide 4.4 into three sections: (1) where ICANN acting as a sole controller; (2) where ICANN acts as a joint controller; (3) where ICANN facilitates or enables a third-party framework. An example of an ICANN sole controller purpose is the UDRP c. Agree on next steps EPDP Team Members may continue to send feedback via the list. To aid in the Team’s discussion at the next meeting, Thomas and Benedict will work together on dividing §4.4 into three tranches: (1) where ICANN acting as a sole controller; (2) where ICANN acts as a joint controller; (3) where ICANN facilitates or enables a third-party framework by Monday, September 10. Closing Comments: There is apparent confusion regarding where we are going. With respect to registrar-related purposes in 4.4, the group made several concrete suggestions. Thomas and Benedict to work together on dividing 4.4 into three sections: (1) where ICANN acting as a sole controller; (2) where ICANN acts as a joint controller; (3) where ICANN facilitates or enables a third-party framework by Monday, September 10. 4. Proposed modifications to section 4.4 – introductory paragraph a. Review proposed modification put forward by Alex Deacon and Thomas Rickert b. Consider input from EPDP Team members on proposed modifications c. Agree on next steps 5. Status update on modifications to section 4 – Third Party Legitimate Interests a. revised language for §4.4.2 (Amr Elsadr) b. revised language for §4.4.8 (Alex Deacon & Amr Elsadr) c. revised language for §4.4.9 (Ashley Heineman) 6. Review data matrix formed from RDS work and Thomas’s chart a. High-level overview of chart b. Discuss proposed amendments to Chart c. Agree on next steps 7. Introduction to Appendix A 8. Confirm action items and questions for ICANN Org, if any Feedback on triage survey, if any, is due today. Applications for travel support to ICANN63 in Barcelona are due Thursday, 13 September. Thomas and Benedict to work together on dividing 4.4 into three sections: (1) where ICANN acts as a sole controller; (2) where ICANN acts as a joint controller; (3) where ICANN facilitates or enables a third-party framework by Monday, September 10. Question for ICANN org: 1.Why did ICANN include the term content in 4.4.5? 9. Wrap and confirm next meeting to be scheduled for Tuesday 11 September at 13.00 UTC.)