Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Thursday, 30 August, 13:00 UTC. Best regards, Caitlin, Berry, and Marika =============== EPDP Team Meeting #8 Tuesday, August 28, 2018 Notes and Action Items High-level Notes/Actions: * Leadership will look into options for training on GDPR Training and report back to the EPDP Team. * EPDP Team encouraged to provide input on proposed approach in relation to triage report as outlined . * EPDP Team encouraged to review Issue Categorization and proposed Project plan. * The Leadership / Support team will revise the framework for considering data processing to: * accommodate additional forms of LEA-type requests for data, e.g., public authorities * clarify the role of ICANN in the eco-system * clearly differentiate between the purposes of collecting data vs disclosing data to third parties * differentiate (“un-conflate”?) the role of ICANN and contracted parties in the processing of data * clearly layout how disclosure of data to third parties is governed through GDPR compliance * Contracted parties are to examine the purposes enumerated in the Temporary Specification (§§ 4.4.1, 4.4.3-4.4.7; 4.11-4.12) and recommend changes * All are asked to consider the broad wording in section 4.4.8 of the Temporary Specification and recommend detailed purposes so that data sets can be deduced from those purposes Questions for ICANN Org from the EPDP Team: None All Action items: Action item #1: EPDP Team to share recommendations for whom or which organization should be considered to provide GDPR training to the EPDP Team. Action item #2: EPDP Team to provide input on path forward for triage report on the mailing list. Action item #3: EPDP Team to review Issue Categorization and proposed Project Plan and provide feedback. Action item #4: Staff to review whether any other policies would need to be called out under Registrar-Registry-ICANN Contract Purposes, in addition to dispute resolution services. 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 (2 min) * 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 (3 min) * Please take note of today's agenda - pretty full, but main objective is to start deliberations on 4.4 * Request for GDPR training from RySG - support expressed from many. Leadership team will work on options to provide a training that would be provided in addition to the regular Tuesday / Thursday meeting. Action item #1: EPDP Team to share recommendations for whom or which organization should be considered to provide GDPR training to the EPDP Team. 3. Reconcile input received on Triage Report, if needed, and confirm report for submission to the GNSO Council (5-10 min) * Comments submitted by BC, IPC, RySG, RrSG and Milton (see https://community.icann.org/x/jxBpBQ) * Comments focused on: * Reinforcement that comments made and recorded in this report are not binding, limiting or prejudicial on any party * Some important points were missed and should have been included * Correction of legal or other terminology * Form of the issue * Question * Some say “A” and others say “not A” * Some advocacy * Policy vs specification * Options going forward: one more draft accepting substantive points from above, or, submit color-coded matrix (and comments) only, use comment summaries to guide substantive discussion. * Consensus policy can include specification so not necessarily correct that GNSO Policy Recommendations cannot affect specifiations. But what is the difference between a policy and a specification? From a contracted party perspective, both are enforceable by Compliance. * Data elements redaction - should positions on current redaction be recorded in the triage report? Maybe better positioned for the substantive discussion that follows? * Important to get triage report done so EPDP Team can move on to substance. Action item #2: EPDP Team to provide input on path forward for triage report on the mailing list. 4. Review of project plan (10 min) (see also section category allocation attached) * See issue categorization table shared prior to the meeting - divided into four sections 1) Sections affected by EDPB, 2) Sections where the Team indicated that amendment is desirable (2a - sections where change is required to bring the section to compliance with GDPR, 2b) sections requiring less attention as issues are not expected to impact compliance with GDPR, 3) Sections related to existing policies / procedures, 4) background, rationale, justification / admin. * This categorization has inspired the proposed project plan for how issues are expected to be considered throughout the remaining meetings. * See project plan. * Will it be possible to keep this level of abstraction as there is interconnectivity between topics - for example what is the data collected for, for what legal basis and agree on certain data subjects being required for certain purposes and take those through the whole lifecycle of the data. * Update should be made to reflect that 4.4. is purposes for collection, not access. Need to focus on how purposes are related to collection, storage and disclosure as they relate to ICANN's mission. Action item #3: EPDP Team to review Issue Categorization and proposed Project Plan and provide feedback. 5. Touch base on comments received on & review status of: (10-20 min) A. Appendix D – Uniform Rapid Suspension (see discussion summary index (DSI) at https://community.icann.org/x/ExxpBQ) B. Appendix E – Uniform Domain Name Resolution Dispute Policy (see DSI at https://community.icann.org/x/ExxpBQ) C. Appendix G: Supplemental Procedures to the Transfer Policy (see DSI at https://community.icann.org/x/ExxpBQ) * No comments / input received to date * Leadership team to consider how to encourage input on how these appendixes may need to be updated, if needed 6. Commence deliberations for section 4.4 – Lawfulness and Purpose of Processing gTLD Registration Data (see DSI at https://community.icann.org/x/ExxpBQ) (50 min) * See slides distributed and discussed during the meeting (https://community.icann.org/download/attachments/90773587/EPDP%20Team%20Meet...) * Take particular note of the EDPB advice: There are processing activities determined by ICANN, for which ICANN, the registrars and registries, require their own legal basis and then there are processing activities determined by third parties, which require their own legal basis and purpose. ICANN should take care not to conflate its own purposes with the interests of third parties. Data legitimately collected by ICANN, registrars and registries would not categorically exclude the subsequent disclosure of personal data to third parties for their own (legitimate) interests and purposes. Personal data disclosure can be made for the purposes of the legitimate interests third parties, provided that those interests are not overridden by the interests or fundamental rights and freedoms of the data subject, i.e., disclosure is proportionate and limited to that which is necessary and the other requirements of the GDPR are met. * See slide 19 - purposes limited to the data necessary to provide services bargained for and required by contract, uses necessary to provide services bargained for and required by policy or contract. However there may be other legitimate purposes for which this data may be accessed for example by LEA or for consumer protection, investigation of cybercrime, DNS abuse, intellectual property protection, contract compliance. * Should be clear that ICANN does not determine the data to be collected alone, especially if Ry and Rr are considered joint controllers. * Overarching concern of the GAC is that there is only reference to the LEA and not references other public authorities and their obligation to carry out their tasks. Also need to clarify whether this also includes cross-jurisdictional requests, but with necessary safeguards on how these are to be handled. * Is this meant to be inclusive or are some purposes missing from slide 19? Performance of contract, consent do not seem to be covered, for example. UDRP is an example of a dispute resolution mechanism that is required by contract and as such, does it need to be subject to the balancing act? * Registars also collect information for its own purposes, on behalf of the account holder, such as invoicing information. Does this need to be controlled by ICANN? ICANN's role should focus on domain name registrations and the agreements it has with contracted parties. Need to be clear and look at the contractual relationships, these can also govern third party interests. Need to look at what data needs to be collected to fulfil contractual obligations and then review how this data can also be accessed for legitimate third party interests. * Need to bring in ICANN's purposes - why does ICANN require collection of data of CPs? Is done through the contract making contracted parties joint controllers. Third party legitimate interests are different from this - it is asking this data from Rr, not a legitimate purpose of Rr. * By whom are purposes pursued - see slide 20. * Slide 21 - proposed categorization of purposes (Registrar-Registry-ICANN Contract Purposes / Third-Party Purposes). Consider whether the breakdown should follow the GDPR (6.1(b), 6.1.(f), 6.1.(a)). * Possible path forward for Registrar-Registry-ICANN Contract Purposes - see slide 22. CP input needed - are there additional legitimate reasons why contracted parties collect data from registrants? Should these purposes be re-grouped to better capture their relevance, list and consolidate data necessary to support all purposes? * Possible path forward for third party purposes - see slide 23. Are the purposes enumerated here valid and legitimate? Do those purposes have a corresponding legal basis? If there are instances where personal data can be made available to third parties under these conditions, then we can retain the purpose in the Specification; Describe the data elements required. * Should ICANN Contractual Compliance move to Registar-Registry-ICANN Contract Purposes. * Registrars collect data for their business purposes that are well out of the ambit of ICANN's control, including the MS process. Need to keep in mind that distinction. Should make a clear demarcation of what data is collected and for what purposes it is collected as registration data in the gTLD world and what data the registrars process for their own purposes. Only the former shall be governed and enforced by ICANN. * What is the purpose of a domain name registration? Start at the basics. This maybe too complex to meet the deadlines that are in place? Most of the purposes outlined on slide 22, apart from 4.4.12 seem to be directly related to domain name registration. * Need to also consider whether there are other means to fulfil the needs identified. For example, for payment and invoicing there may be other ways in which contractual obligations are fulfilled. May be taking on too much. Should focus on essential elements of the temporary specification. * Isn’t that circular: “it’s in our contract, therefore it must be legal because the law allows for service of a contract" * Consider list of purposes and data elements, outlining processing steps. For example, excel sheet with all the data elements collected by the registrar, look at travel from that data from registrar to registry for performance to the contract, what on the basis of a legitimate interest, what on the basis of consent? That may focus on a sub-set of data elements that is collected by registrars. Then follow that for EBERO, escrow, ICANN, etc. See also https://www.icann.org/resources/pages/gtld-registration-dataflow-matrix-2017... which could serve as a potential basis. * Consider adding ‘for the compliance with ICANN policies’ to slide 22. Some may not expressly listed here, so consider making it a stand-alone item. Note that any policies would need to be compliant with GDPR and a separate data protection impact assessment may be needed. * Concern about including purposes that go beyond ICANN’s mission, for example 4.4.8 and 4.4.9. Some noted that it is ICANN’s responsibility to make sure the DNS works and can be trusted. Should this be a rationale that is included as it is the basis for third party access? * If data is collected for the sole purpose of maintaining the registration and compliance with ICANN policies, isn’t third party access for a legitimate purpose not overcome by the rights of the individual, acceptable and consistent with ICANN’s mission? That is not disputed, but making third party purposes part of ICANN’s purposes is the concern as that could broaden what is collected. But focus is on purposes for collection that would focus on ICANN’s purposes so there would not be a risk that data collected is expanded as that cannot be done on the basis of a third party legitimate purpose. Third party purposes do not include collection. * Issue is with the reference to ‘framework’ without it being defined anywhere (in 4.4.8 and 4.4.9). Framework may be further addressed in the access discussion? Could be read as ready and available to support decisions that are made in the EPDP team? * Can an agreement be written up that data collected for domain name registration purposes can then be made available to third parties under certain conditions? Could ask third parties to flesh out which data elements would be needed for those third party access? * Should consider how 4.2 and 4.3 fit with this? Action item #4: Staff to review whether any other policies would need to be called out under Registrar-Registry-ICANN Contract Purposes, in addition to dispute resolution services. 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...>.