Dear EPDP Team, Below, please find notes and action items from today’s EPDP Team meeting. As a reminder, the next EPDP Team meeting will be Thursday, 29 August at 20:00 UTC. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #16 Thursday, 28 August 2019 at 14.00 UTC Action Items SSAC EPDP Team Members to make agreed to changes and notify EPDP Support Staff when complete. Action: Support Staff to input LEA-2 use case into a Google Doc for feedback. Please see: https://docs.google.com/document/d/1bm8sdjrNHvNgftMK4f8s-U81FlNSIe2TVNlQKCXZ.... Action: EPDP Team members to submit comments for LEA-2 use case by tomorrow, Friday, 30 August. Please use the following link: https://docs.google.com/document/d/1bm8sdjrNHvNgftMK4f8s-U81FlNSIe2TVNlQKCXZ... Action: GAC colleagues to update the LEA-2 use case based on comments received by Tuesday, 3 September. 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/ZwPVBQ. EPDP Phase 2 - Meeting #16 Proposed Agenda Thursday, 29 August 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) Attendance will be taken from Zoom Remember to mute your microphones upon entry to Zoom. Please 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. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from Legal Committee · Questions from batch 1 were submitted to the list yesterday for plenary team review. · If there are no objections from the Team, these questions will be submitted to outside counsel. · EPDP Leadership gave a heads up to Bird & Bird that a set of questions will be forthcoming this week, noting that the EPDP Team would like to receive feedback in advance of its F2F meeting, scheduled on 9-11 September. · With respect to the 6(1)(b) question, some members of the Legal Committee will be refining the question and will be reverting to the EPDP Team with the updated question when available. · With respect to Question 3, the Team should not waste money on this question - as there is already advice on this topic in the city field memo. · The Legal Committee has concluded that it is important to ask this question, so if there is no objection, the Legal Committee will send these questions to Bird & Bird. · Raising this issue as a question that could be shaved off · The Legal Committee is looking for guidance in this specific case b) Reminder – contribute to google doc with questions for ICANN CEO / Strawberry Team in preparation for LA F2F meeting (see https://docs.google.com/document/d/1Q_0smZv58- rQ4RF9buAMBmt4PGVSk6gAYyLiPIOlyQU/edit [docs.google.com]) · If any EPDP Members would like to add any questions or comments to the document, please do so using the above link. · It might be worth reaching out to the Strawberry Team to see if they have any updates since Marrakech for the EPDP Team. If any updates can be shared in advance, this will help the EPDP Team in formulating its questions to ICANN org. · The Strawberry Team is aware the EPDP Team is preparing questions and wishes to engage during the Strawberry Team. 4. Use case – second/final reading: When a network is undergoing an attack involving a domain name, and the operator(s) of that network need to contact the domain owner to remediate the security issue (DDOS, Botnet, etc.) [docs.google.com] (SSAC1) a) Overview of updates made in response to input received (SSAC) · The SSAC agreed with most suggestions provided in the document. · As a clarification, this is intended for network operators and not for third parties, unless the third party is designated as the operational security team. · The changes in Section B - “may be” is OK instead of “is required” · Administrative contact information was an oversight, so that should not have been included, and, as such, has been removed. · Section D - agree that 6(1)(f) is the appropriate basis in 99.9% of the cases, but there may be rare situations where critical infrastructure like hospitals have been taken down by botnets, which is why 6(1)(d) is included here. · Section E - highlighting that Recital 49 takes into account this situation, and this was one of the core purposes of RDS data · Section F - suggested add to the safeguards added to requestor - this has now been added · Section H - suggested additional safeguard applicable to data subject - agree to this add · Section J - there is no adequate accreditation body that currently accredits network operators b) Feedback from EPDP Team · Agree that legal basis will be declared by individual/entity making the request. If someone thinks it is a 6(1)(d), they will be free to do that and it will be up to the responding party to determine the validity of the claimed basis. · Why would you eliminate "high-volume automated" if you are concerned about DDoSing the SSAD? · Propose to keep both by adding “or” · The notion of accreditation occurring through distinct user groups is problematic - no such thing exists at the moment - this is calling for the formation of a global body. All of the use cases need to have and must develop a coherent notion of who does accreditation, where it comes from, and the idea of separate stakeholders doing it is not viable. · Interested in the lawful basis of the disclosing entity, not the requestor. Have a hard time with 6(1)(d) being included here. · Some EPDP Team members are arguing for high-volume queries. Does this use case require high volumes of automated requests for non-public registration data? · High volume does need to be accommodated within reason - with respect to this language - the same entity may need to make requests based on on a botnet that implicates hundreds of domain name · If an attack is ongoing, this would be a case where data is needed quickly. · SSAC to tighten up language in reference to high-volume requests. · There is a difference b/w accreditation and authentication. · Accrediting security practitioners is something that can be done by people in the industry so long as the appropriate framework is put into place by this Team. This topic should be further discussed in Los Angeles. · With respect to accreditation, individuals who want more liberal access to WHOIS data, are asking for sectoral access to data. You do not have to go to a global bureaucracy to investigate. You have a right to make an inquiry regardless of who you are if you have a lawful basis. It is odd that folks are asking for accreditation that does not guarantee anything. · Accreditation was not included as a hill to die on. It is something that could potentially be used down the line to speed up some speed bumps in this process. It is a possible avenue of identifying the requestor. It is not a guarantee of access or an elimination of the balancing test. · The IPC does not want a world where only accredited persons can request disclosure of RDS data. Accreditation is an important part of the discussion and is included in the EPDP Team’s charter. · If the responses are partially automated, it would be useful to look over the work the data commissioners have done over the years. · Action: SSAC to make agreed to changes and notify EPDP Support Staff when complete. c) Confirm next steps · Action: SSAC to make agreed to changes and notify EPDP Support Staff when complete. 5. Use case – final reading: Online buyers identifying and validating the source or services/ Internet users validating the legitimacy of an email or a website to protect themselves (ALAC1) a) Overview of updates made in response to input received (ALAC) · There has been a lot of traffic on this list. In summary, one issue is whether consumer confidence is within ICANN’s mission. It does not matter. This is not an ICANN purpose; this is a 6(1)(f) case. Whether it is in ICANN’s mission or not is irrelevant. Whether it is a website or not is an issue that may have triggered the request by the user, but this is not an ICANN issue - it is a business practice of the contracted party. · Any user can submit a request. Whether or not we call it a use case or not will not stop this type of request. · With respect to automation, this will be changed to no, but if the Ry/Rr wants to automate this, it would be up to them. b) Feedback from EPDP Team · Does this particular use case intend to create policy recommendations? If not, can the Team park this and move on? · Rationales provided may belong in other use cases. · Isn’t WHOIS about the only place the internet user could go to identify who the registrant is for the phishing email? Individual users, particularly within a company that is being spear-phished - argues in favor of keeping this use case. The use case describes a situation and it may normatively recommend what we should with it. c) Confirm next steps 6. Use case – first reading: Investigation of criminal activity against a victim in the jurisdiction of the investigating EU LEA requesting data from a local data controller. (LEA 2) a) Intro to use case and overview of how/where this use case is different from LEA 1 (GAC) · Reason for having two similar cases is to help look at how different jurisdictions could affect policy recommendations the Team will make and how this could affect legal basis. · The investigating body and data controller are in the same jx. · Why non-public data is necessary -same reason as other use case. · Data needed is the same as LEA-1. · Changes to safeguard section - attempted to firm up the language and make it more encompassing · Action: Support Staff to input LEA 2 into a Google Doc for feedback. b) Feedback from EPDP Team · Is this a law enforcement use case for the same jurisdiction? But this understanding is incorrect? This use case is being looked at to tease out challenges when requesting data both inside and outside the jurisdiction? · Comparing the two LEA use cases will show how different jurisdictions are handled. c) Confirm next steps · Action: Support Staff to input LEA 2 into a Google Doc for feedback. · Action: EPDP Team members to submit comments by Friday, 30 August. · Action: GAC colleagues to update the use case based on comments received by Tuesday, 3 September. 7. Any other business (5 minutes) 8. Wrap and confirm next EPDP Team meeting (5 minutes): a) Thursday 29 August 2019 at 20.00 UTC (extraordinary meeting – intro to and initial feedback on zero draft) b) Thursday 5 September 2019 at 14.00 UTC c) Confirm action items d) Confirm questions for ICANN Org, if any