Dear All, Please find below the notes and action items from today’s meeting. If you are interested in signing up for tomorrow’s small team meeting regarding the applicability of data processing requirements and if the contracted parties should have the ability to differentiate on a geographic basis, please sign up here: https://docs.google.com/document/d/1ChEYy-cZmT3qTD62-HsoVmddD96m6cbkSOv5dmAj.... As a reminder, our next plenary call will be Tuesday, 9 October at 1300 UTC. Best regards, Marika, Berry and Caitlin EPDP Team Meeting #17 4 October 2018 High-level Notes/Action Items Action Items At the ICANN meeting in Barcelona, there is a High-Interest Topic Session for the EPDP on Monday, 22 October from 15:15 - 16:45 in Room 111/112. Leadership’s current thinking is to include on the panel a number of Team Members to present during this session. If any Team Members have suggestions for this session, please provide them to the list. ICANN Compliance to provide a general overview regarding how data escrow files are used in the course of an audit. Included within the overview, ICANN Compliance should include more information around the potential decryption of data escrow deposits during the course of an audit. ICANN Compliance to provide more specificity regarding necessary retention periods, and the rationale for retention after the domain registration is deleted. This information is necessary to justify any retention period to a DPA. Providing use cases where registration data is needed after the registration expiration would be helpful to explain relevant retention periods. Questions for ICANN Org ICANN org should have a general retention policy. As part of its GDPR-compliant data processing regime. If so, can this be provided to the EPDP Team? We have spent most of this meeting exploring the role of compliance at ICANN, in order to support a proposal that ICANN has an implicit contract with the registrant and that therefore 6 1 b applies as a grounds for processing. This would also facilitate ICANN operating a UAM on behalf of those who want the data. It might also explain Goran’s initiative in seeking some kind of recognition by EU authorities that ICANN has a kind of quasi-regulator status, as the authority vested with the responsibility to manage the DNS. Given that all of this is outside the current configuration of ICANN as data controller, which would be more clear had we done a DPIA and had we adequate data maps to work with….can we either get back to our Charter questions that we were mandated to address by the GNSO, or get a full explanation of what is going on and why we continue to be focused on the access question. Is there a date limit for ICANN accepting a complaint or request to audit regarding a registration that has been deleted? If not, what is the case of the longest period of a deleted registration that was accepted and acted upon? Notes 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 (5 minutes) 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 We need to change the agenda slightly, as we did not receive the homework for Purpose E (Registry data escrow). Please review the recent answers received from ICANN org re: data retention. https://community.icann.org/display/EOTSFGRD/Input+from+ICANN+Org ICANN org will present on Purpose F, and Kristina R. will present on Purpose N. There is a High Interest Session in Barcelona. If any EPDP Team Members have suggestions for this session, please provide them to this list. To quickly recap action items, add a second processing activity to Purpose C workbook. Please read Alan Greenberg’s recent email regarding Purpose C. Question: Re: ICANN Leadership to consider ICANN contracting directly with registrants -- when did this become an action item? Answer: After discussion on this, Leadership is to look into this further. 3. Review data elements workbook for Purpose E (Ry Escrow, EBERO) Objective of discussion: (1) Review data elements workbook for purpose E as completed by registries (2) Agree on data elements needed for this purpose as well as responses to different questions in data elements workbook a. Review data elements workbook for purpose E b. Discuss any outstanding items / questions c. Finalize data elements workbook for purpose E Taken off agenda as no homework was received. 4. Review data elements workbook for Purpose F (ICANN Compliance) Objective of discussion: (1) Review data elements workbook for purpose F as completed by ICANN org (2) Agree on data elements needed for this purpose as well as responses to different questions in data elements workbook a. Review data elements workbook for purpose F ICANN Compliance filled out the workbook. Is this lawful against GDPR? Yes. Article 6(1)(f). This is not in violation of ICANN bylaws as compliance function is within ICANN bylaws. Responsible parties: Compliance will collect data associated with the third party complainant - it may include name, email, postal address, org info. Fax # is generally not collected. Depending on the nature of the issue and how much info is provided, ICANN Compliance may request further personal information, such as copies of emails. Following receipt of this information, the complaint will be forwarded to the contracted party (provided it is within ICANN's scope and remit). In doing so, ICANN may ask the contracted party to provide information that may contain personal data. In the processing of these complaints, ICANN may look at registration data, provided it is publicly available. This data is not shared with anyone else, including the complainant unless consent is given. Pro-active monitoring such as audits - there are typically two audits per year for Rrs/Rys. During this process, several questions are asked, and Rrs/Rys may be asked to provide personal data as part of the audit. Data escrow files are also collected during audits - this is done to cross-reference information that is recorded elsewhere. Question 4: is processing necessary to meet the purpose? Yes. Is transfer necessary? Yes. Publication by Rr/Ry required? No. However, Compliance would need access to non-public data upon request. Are there any picket fence questions? No. Data retention requirements to meet the purpose? How long is the data needed after expiration of a domain name? Additional information to adequately document the purpose? No. EPDP Team Questions/Feedback Re: two audits per year, does that mean two per contracted party, or two in total? Answer: contracts allow two audits per CP per year. Generally speaking, compliance does not audit the same contracted party twice per year, unless there is a remediation issue and then the contracted party may be retested on a limited scope. Does Compliance perform validation/verification during an audit? How does Compliance clarify inaccuracies? The 2013 RAA has a Whois Accuracy Program Specification, which requires Rrs to perform validation and verification of WHOIS contact information. Verification comes from the registrant to ensure that email/phone is responded to affirmatively; validation is something the Rr conducts to ensure the format of the WHOIS info matches certain specified standards, i.e., does the postal address conform to the postal address standards for that location? As part of complaint processing, Compliance asks Rrs to confirm they properly validated and verified. Verification could include asking the Rr to provide evidence of how this verification occured. For validation, Compliance will ask for information of how it was validated - how does this conform to certain standards. Does ICANN Compliance as part of an audit pull a segment of data escrow data and decrypt or otherwise make that information in plain text to compare against public records? This may be an area where Rrs would not be comfortable with that type of use. This is limited to the Ry audit space, so the request is only for Ry DEAs to provide a sample of domain names. Primarily, the use is to confirm the same domain name numbers are contained in the zonefile and BRDA. Regarding the answer to question 1, who does the balancing test? What if a registrar denies ICANN Compliance access to data? Action Item: ICANN Compliance to gather more information regarding how data escrow files are used in the course of an audit. For example, are escrow files decrypted? If a CP was challenging ICANN based on a lawful basis, this would be reviewed on a case-by-case basis and collaborate with the CP to better understand the issue. There may be other information that could be asked or provided to ICANN. Is there any work being done on other departments within ICANN re: other departments' use of data? Please see: https://community.icann.org/display/EOTSFGRD/Input+from+ICANN+Org Re: data collected from reporter/complainant, that data is out of scope of this EPDP. There are two areas where this team may be interested: (1) in following up on a complaint, how does ICANN Compliance use registration data? (2) in the response to an audit, how does Compliance use registration data? How does ICANN access registration data to follow up on the ARS system before 25 May and after 25 May? Pre-May 25, the information was publicly available, so Compliance would query a registrar's WHOIS server and compare with the ARS testing. Post-25 May, if the data is still publicly available, the same process would work. If the data is redacted, Compliance now uses an inquiry vs. a notice. An inquiry is used when information is still being gathered and is used to ask the registrar if the data has changed since the ARS reporting issue. In thinking about lawful basis, this purpose protects the registrant to ensure the contract is properly performed, so the processing is necessary for performance of the contract, so 6(1)(b) is more appropriate than a 6(1)(f). Is this the right purpose, and is there an implication that a 6(1)(f) is used here? Re: lawful basis of this purpose, ICANN is taking responsibility for the processing of the data for the compliance purpose. 6(1)(f) is the correct purpose here. Question 8 talks about data retention requirements. 6(1)(f) makes more sense for the compliance purpose. Whatever retention period after expiration is decided is what Compliance will enforce based on, so this is a better question for contracted parties. How long does Compliance keep the data after a matter is closed? Data is purged after audit is closed. In terms of complaint processing, that timing could vary. It is not possible to make a clear-cut determination, so whatever is decided is how Compliance will enforce against. Re: lawful basis, are there any additional thoughts to share? Should this be a 6(1)(f)? 6(1)(b) is a high bar, so it will be interpreted quick strictly. Putting something in a contract does not make it lawful. 6(1)(f) seems to be the appropriate legal basis for the compliance purpose. The group needs to take into account how a DPA would look at this. A DPA will likely say this is not necessary for performance of a contract. Is 6(1)(f) a legitimate lawful basis? It may be a 6(1)(b) basis for some. How can the concern be addressed that ICANN cannot get access to the data – is there anyone who could suggest a path forward? There should be a clear legitimate interest here – if there isn’t, there is something wrong with the process. What would compliance do if a contracted party decides to withhold information under 6(1)(f)? Compliance would work with the contracted party and try to understand the issue. For example, is the contracted party concerned with publication? Compliance may ask for other data that could fulfill the complaint/issue. Is this a stumbling block for every purpose that has a 6(1)(f) legal basis? Are there any circumstances where everyone will be comfortable with 6(1)(f) with a legal basis for the processing activity? Conclusions: 6(1)(f) is an appropriate legal basis for the compliance purpose. Some believe it may be a 6(1)(b). There are concerns that 6(1)(f) may cause issues where the complainant says the privacy rights outweigh the legitimate interest and therefore data cannot be provided. This is a way to move forward with this issue, but everyone should do their homework. How should the group move forward with the data retention question? Compliance will enforce whatever the retention requirement is. The compliance activity is not giving a specific reason to retain data beyond the life of the registration, except in cases where this is ongoing compliance activity, so perhaps the group can make note of retaining data in case of an ongoing compliance activity. There is retention beyond the registration and retention beyond compliance complaints about that registration. There may be an interplay b/w these two things – there may be an expired registration, but there is a complaint open about that registration – the data may need to be retained after the expiration. Compliance will work with whatever the retention period is. It would be better for Compliance to propose relevant retention periods – the EPDP Team cannot set arbitrary limits for the team. There are several things that could happen post-expiry, such as required notices, redemption, etc., where the data would need to be held. This group needs a full explanation from ICANN or go back to the Charter questions that exist at the moment. Is there any data on how many complaints use expired data – if so, how often does Compliance have to go back and the average length of time they go back? This type of data does not exist and this would likely be a very large undertaking, but Compliance has not run into issues of not having data be available under the current policies (two years), and any time period b/w six months and two years should be OK. Is there anything else that needs to change on this sheet? b. Discuss any outstanding items / questions c. Finalize data elements workbook for purpose F 5. Review data elements workbook for Purpose N (registry eligibility requirements) Objective of discussion: (1) Review data elements workbook for purpose N as completed by registries (2) Agree on data elements needed for this purpose as well as responses to different questions in data elements workbook a. Review data elements workbook for purpose N b. Discuss any outstanding items / questions c. Finalize data elements workbook for purpose N The view within RySG is that this is a Ry purpose, and registrars do not think this is a Rr purpose. Because the group is still going through the lawful basis discussion, 6(1)(b) and 6(1)(f) are both mentioned, though registries think this is most likely a 6(1)(f). Is the purpose in violation of ICANN’s bylaws? No. Questions/Concerns re: this overview: This is a legitimate registry purpose, but a conversation with Kristina may be necessary to better understand why it might be desirable to add new data elements to the RDDS to fulfill these requirements. 6. Review data elements workbook for new purpose (research) Objective of discussion: (1) Review data elements workbook for research purpose as completed by Benedict/Farzaneh (2) Agree on data elements needed for this purpose as well as responses to different questions in data elements workbook a. Review data elements workbook for research purpose b. Discuss any outstanding items / questions c. Finalize data elements workbook for research purpose 7. Wrap and confirm next meeting to be scheduled for Tuesday, 9 October at 13.00 UTC. Confirm action items Confirm questions for ICANN Org, if any