Dear EPDP Team: Please find below the notes and action items from EPDP Meeting #44 on Thursday, 27 February 2020. The next plenary meeting will be Thursday, 5 March 2020 at 14:00 UTC. The Legal Committee will meet on Tuesday, 3 March at 14:00 UTC. Thank you. Best regards, Marika, Berry, and Caitlin Action Items The EPDP Team expressed no objections to EPDP Support Staff’s proposal on data retention to reconfirm its Phase 1 Recommendation #15.2, which was adopted on an interim basis, and provides that registration data must be retained for a period of fifteen months following the life of the registration plus three months to implement the deletion, i.e., 18 months. Any EPDP Team members who cannot live with this proposal to provide a rationale and proposed alternative by Wednesday, 4 March. Following the deadline, Support Staff to develop proposed language by Friday, 6 March. EPDP Support Staff to create and distribute a table, detailing the board-approved purposes from Phase 1, Recommendation 1, and allowing EPDP Members to identify any gaps or additional purposes (if any) that may be needed as a result of the Board not adopting Purpose 2. EPDP Team members to use the table to identify gaps and additional purposes by Wednesday, 4 March. Volker and Brian to start a discussion on reformulating “Purpose 2” to ensure it is fit for purpose for the SSAD by COB Monday, 2 March. Following the receipt of Volker and Brian’s message, EPDP Team Members to respond, discuss the necessity of an updated “Purpose 2”, and discuss the corresponding processing activities on-list by COB Monday, 9 March. EPDP Phase 2 - Meeting #44 Agenda Thursday, 27 February 2020 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) Meeting with Belgian DPA – feedback from Janis Janis participated to brief the officials on the Initial Report The DPAs took the document and listened very carefully In terms of the Belgian DPA providing a public comment on the Initial Report, there was no conclusive answer, but the likely answer is no Questions from EPDP Team: Members of the Team have requested more details on the meeting. Is there anything actionable for the EPDP Team re: this meeting? The Team should not rely on any feedback of the Belgian DPA – the Team is working under the assumption of joint controllership This was a very good meeting, but there is nothing actionable out of it. The Belgian DPA is not in the position to make a decision on something that has global impact. The EC could send questions to the EPDB, which could give authoritative opinions. The DPA was answering and clarifying the initial questions and the answers. The Belgian DPA is not the authority to give an authoritative answer and cannot dictate a preference towards a model, but they could speak about what could work. They mentioned that automation is not something they can opine on without more details. The EPDP Team has to decide how to move forward. We’ve heard that automation is not forbidden but they cannot provide guidance until there are more details. The Team may have to be more aggressive and test the waters. If we only provide the safe examples, we will not learn. The DPAs are separate and make their own decisions. With the amount of info even in the Initial Report, there is not enough information for them to make a comment. It’s good to hear that centralization is still possible. Is there something in the policy work that we could concentrate on that would help the DPAs provide further detail? If the EPDP Team tried to talk to the EDPB, what is stopping the DPA from seizing the conversation? During the meeting, the question ICANN was asking re: controllership and liability had not been understood. The Belgian DPA thought it was being asked to bless the Strawberry model, but that is not what ICANN was asking – it was just testing a hypothesis. If the EC can ask the EDPB for the answer – what is the process to do this, and when is the appropriate time to do this? The Belgian DPA volunteered to engage with ICANN. The EDPB is a body made out of 27 data protection authorities of member states. One is preparing the topic for consideration by the board on behalf of DPAs. There is a competent national DPA to deal with the issue, and a technical board. In the meeting, the Belgian DPA referred to a direct request from the part of the Commission that is dealing with GDPR – DG Justice. The question needs to be formulated very clearly so that the board will have all of the elements to give a useful answer. Is the Team prepared to formulate questions to the Board in the timeframe allocated to us? If the Team decides to go for another year, then asking the EDPB may make sense and suspend activities until an answer is given. What question can be asked to whom, by whom, and what kind of answer would we get under what kind of timeframe? Suggest that a call be made to the chair of the EDPB or to the secretary of the EDPB. ICANN org knows very well who to speak with. ICANN cannot call up the chair of the EDPB – that is against process. With respect to if it would be possible to receive an answer by June – the answer is yes, it’s just a matter of the question. This third-track interaction with data protection authorities has just been a source of confusion and delay. The only thing the Team can do is develop a policy within the stated timeframe. ICANN67 Virtual Meeting – current state of planning / discussions Proposing two meetings per week – during normal hours, and possibly leaving time to the legal committee There may be a need for a period of more intensive work based on how we progress on Priority 2 items, for public comment review EPDP Team Reactions: GDD Summit, if it’s going forward, starts on 3 May and will be in Paris – this should be considered as a location. Disappointed that we are not discussing a F2F earlier – the Team needs serious discussions around automation The new schedule has picked up five 2-hr meetings – five extra meetings are now on the schedule. Concerned that the Team will not be able to close out all of the public comments and come to consensus on the Final Report. The work would greatly benefit from a potential F2F. 4. Timeline review and priority 2 worksheet compilation (10 minutes) a) Consider any input provided by EPDP Team by Tuesday 25 February b) Confirm next steps 5. Data retention (priority 2) (30 minutes) EPDP Team to review ICANN Org feedback (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-November/002747.html and https://mm.icann.org/pipermail/gnso-epdp-team/attachments/20191102/e8cd309e/... Consider Support Staff proposed recommendation: EPDP Team to consider whether updates are needed to phase 1 data retention recommendation (EPDP Team meeting - 27 Feb 2020). At a minimum, the EPDP Team would need to reconfirm its original recommendation, which was adopted on an interim basis, that registration data must be retained for a period of fifteen months following the life of the registration plus three months to implement the deletion, i.e., 18 months. No objections Confirm next steps Action: The EPDP Team expressed no objections to EPDP Support Staff’s proposal on data retention to reconfirm its Phase 1 Recommendation #15.2, which was adopted on an interim basis, that registration data must be retained for a period of fifteen months following the life of the registration plus three months to implement the deletion, i.e., 18 months. Any EPDP Team members who cannot live with this proposal to provide a rationale and proposed alternative by Wednesday, 4 March. Following the deadline, Support Staff to develop proposed language by Friday, 6 March. 6. Feasibility of unique contacts (priority 2) (30 minutes) EPDP Team to review Legal Committee proposal Confirm next steps 7. Purpose 2, Phase 1 (30 minutes) As a reminder, the EPDP Team recommended in phase 1 the following purpose ICANN Purpose for processing gTLD Registration Data: “Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission through enabling responses to lawful data disclosure requests”. “ICANN Purpose” _is used to describe purposes for processing personal data that should be governed by ICANN Org via a Consensus Policy. The ICANN Board did not adopt this purpose noting that: “The Board does not adopt this Recommendation at this time in light of the EPDP Team’s characterization of this as a placeholder and the need to consider recent input from the European Commission. Based on the views presented in the recent letters from the European Commission, Purpose 2, as stated in the EPDP Team’s Final Report, may require further refinement to ensure that it is consistent with and facilitates ICANN’s ability to deliver a predictable and consistent user experience compliant with applicable law. The Board’s concern is that if the wording of purpose 2 is deemed inconsistent with applicable law, the impact might be elimination of an ICANN purpose. There are clear ICANN purposes that ICANN should be able to employ under existing legal frameworks to deploy a unified method to enable those with a legitimate and proportionate interest to access non-public gTLD registration data, although such purposes may need to be restated or further refined based on additional legal, regulatory or other input. The Board directs ICANN org to continue to evaluate this proposed purpose and to request additional guidance from the DPAs, regarding the legitimate and proportionate access to registrant data and ICANN’s SSR mission”. To review the European Commission letter on this topic, see https://www.icann.org/en/system/files/correspondence/odonohue-to-marby-03may... In a recent motion concerning the non-adoption of purpose 2, the GNSO Council noted that: “The GNSO Council has concluded that concerning Recommendation 1, Purpose 2, this is firmly within the scope of the EPDP Team to address as part of its phase 2 deliberations as the original language was already flagged as a placeholder pending further consideration during phase 2.” Brian King has proposed that the EPDP Team consider recommending the following ICANN purpose: “Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission”. Brian to introduce proposal New proposal attempts to de-conflate the Purpose 2 issue Important to keep some formulation of Purpose 2 – agree with Brian’s reformulation of the purpose Not fundamentally opposed to this, but if this wording was presented to a registrant, that would be confusing and may need additional clarity If a registrant was to look at this as a statement of purpose, how would they know their data is being processed for whom and for what reason? There is still scope within the existing purposes to deal with security/stability. This purpose should speak to the very first purpose in making registration data public before there was an ICANN – to deal with technical problems with the DNS. If the Team could work on something along those lines, that would work. Could include a disclaimer such as this purpose could result in the disclosure of data to third parties Agree that what Brian has proposed is overly broad – it does not tell the data subject how their data will be used. Rec. 1 contains 6 ICANN purposes for the processing of registration data. These are clear and cover the use cases we’ve discussed. The contactability purpose is already covered in Purpose 3. What processing activity is not accounted for in the other 6 purposes? Do not see a reason for Purpose 2 – we need confirmation on what gap (if any) the absence of purpose 2 would leave Still need a purpose 2 for ICANN – keep it in Many of the third parties that are requesting data are doing work for ICANN. The operation of the SSAD itself may include processing user data and is one of things that should be included in this purpose. The Team is missing, in the purposes, anything about the SSAD or anything that looks like it’s within ICANN’s realm of possibility to do in SSAD. The closest one is to enable communication with the RNH, but that’s not the only potential use of the SSAD. Remove the part that conflates and leave the rest. Is the role ICANN will be playing in the hybrid model currently reflected in Purpose 2? Proposal - “To exercise its role as data controller in the SSAD, contributing to the security, stability, and resiliency of the Domain Name System in accordance with ICANN's mission” This is not removing the previous issue of conflation – disclosing data is not part of the purpose of ICANN – suggest deleting Purpose 2 The Team is operationalizing disclosure. If this is an issue, the Team would have had a major crisis at the beginning of Phase 2, but no one raised this issue because it isn’t one. Third party purposes are conflated, and that is the problem. If a third party is helping ICANN achieve SSR, that is the third party’s purpose. If ICANN required the third party, then ICANN would enter into contractual relationships with them. Consider preparing a table with existing purposes from Phase 1 and see if the Team can identify any gaps The Team spent a long time on this back in Phase 1 – security and stability is not a purpose for collecting information in this instance. The creation of this instrument does not need a specific purpose to make it happen. There seems to be some hints of agreement as the first statement as a purpose statement, but the Team may need to define the processing activities behind the SSAD. The Team could further define the processing activities: we don’t need to identify collection b/c that is identified in purposes, but there would need to be a processing activity of the transfer of data from CP to requestor and perhaps retention of that data. Documenting this would help with the framework and in showing how the DPA might view it. Do not understand why the Team needs to go down this road. BC/IPC seems to believe SSAD will be created and before it’s turned on, there will be cries of no purpose, and therefore, no SSAD. This is a mischaracterization of BC/IPC’s position – ICANN conducting research, ICANN implementing policies are other purposes that are not currently identified. The Team is talking about two different aspects: is a specific purpose needed in relation to ICANN’s role in SSAD? The second question: is there a purpose for additional ICANN purposes like research. For the second question, the group may want to consider in context of the OCTO question – the EPDP Team needs to review that response. Does it make sense to take that issue separately? EPDP Team needs to get on with a DPIA EPDP Team feedback Confirm next steps Support Staff to create a table where Phase 1 purposes are identified and identify what gaps exist to make the precise formulation of a new purpose (if necessary) Action: Brian and Volker to lead the online conversation of the possible formulation of Purpose 2 8. Wrap and confirm next EPDP Team meeting (5 minutes): Thursday 5 March 2020 at 14.00 UTC (topics: City field redaction and Automation Use Cases – small team recommendations) Confirm action items Confirm questions for ICANN Org, if any