Colleagues – The RrSG has submitted our comments on the SSAC Operational Security use case, and send our thanks to Ben, Greg and SSAC for their work. Additionally, the RrSG appreciated the opportunity to comment on the IPC use case, and the IPC team’s responses to our comments. But upon review of the IPC responses, we recognize a divergence of opinion exists between our two teams. However, in the absence of clear and specific legal advice, from an appropriate data protection authority, we’re confident that our assessment of the legal risks is correct, and maintain our original feedback. Thank you, J. From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen@icann.org> Date: Thursday, August 22, 2019 at 10:32 AM To: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Notes and action items from EPDP Phase 2 Meeting #15 - 22 August 2019 Notice: This email is from an external sender. Dear EPDP Team, Please find the notes and action items from today’s EPDP Team meeting below. As a reminder, the EPDP Phase 2 Legal Committee will meet on Tuesday, 27 August. The plenary team will meet twice on Thursday, 29 August: at 14:00 UTC and 20:00 UTC. Thank you. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #15 Thursday, 22 August 2019 at 14.00 UTC Action Items 1. ALAC EPDP Team members to review comments received on ALAC 1 (Online buyers identifying and validating the source of goods or services/ Internet users validating the legitimacy of an email or a website to protect themselves) and distribute updated version of the use case by Tuesday, 27 August in preparation for final reading on Thursday, 29 August. 2. Brian King to consider comments made today regarding legal basis and amend the IP use case accordingly. 3. Greg Aaron to update the SSAC use case<https://docs.google.com/document/d/1iK9ygUOo8ntLWC_7dx3bS195W2ivkqHH/edit?ts...> on crime and abuse investigation by non-law enforcement parties to reflect today’s conversation. For the moment, the Team will park this use case and can revisit in the future when going through the zero draft. 4. EPDP Team Members to add comments from today’s discussion of SSAC use case on operational security in the corresponding Google Doc<https://docs.google.com/document/d/1eLcD6TpQCW029qgi05BQHGwDA9PW29jM3e9ZhPEF...> by tomorrow, Friday, 23 August. SSAC EPDP members to review comments and distribute updated version of the use case by Tuesday, 27 August in preparation for final reading on Thursday, 29 August. 5. Support Staff to create and distribute a Google Doc for EPDP Team members to contribute questions for the face-to-face session with Göran and the Strawberry Team. 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 #15 Proposed Agenda Thursday, 22 August 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) · Attendance will be taken from Zoom room 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Confirm timeline for publication of zero draft and planning for F2F meeting: · Circulation of zero draft to the EPDP Team: Tuesday 27 August · Extraordinary EPDP Team meeting to present zero draft and get initial reactions from EPDP Team: Thursday 29 August at 20.00 UTC (note, this meeting will be in addition to the regular EPDP Team meeting at 14.00 UTC) · Conduct survey to assess which aspects of the zero draft are of most concern and as such should be prioritized for the F2F meeting: Monday 2 – Wednesday 4 September. · Confirm priority items for F2F meeting and confirm ‘homework’ for F2F meeting: Thursday 5 September (regular EPDP Team meeting) b) Update from Legal Committee · Legal Committee met on Tuesday to discuss the SSAD legal questions · Legal Committee made progress on questions to be sent to outside counsel - the first batch is awaiting an anchor question · The questions will be sent to the plenary team as soon as available · The questions appear to be very specific and have a lot of qualifiers - caution against too much specificity - the questions should be more general and overarching. Answers to overly specific questions will likely be unhelpful. · Question 3 seems to be vague -- would it be possible to shed more light on this question. · There was a letter from the European Commission that came in after Bird & Bird’s memo. · What within the EC letter needs to be highlighted in the memo? The question is open and vague. The LC may want to consider highlighting specific points that may warrant an updated an answer from the memo. · Questions refer to accreditation and accredited parties - there are significant differences within the team with respect to what those terms mean - is the Legal Committee aware of this? 4. Use case – second/final reading: Providers requesting access required to facilitate due process in the UDRP and URS [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_documen...> (IP 5) (45 minutes) a) Review updates made to use case to reflect input received (IPC) · Authors of use cases - please remember to alert the EPDP Team when updates have been made to a Google Doc. A summary of the updates made in response to comments will help facilitate discussions. · 6(1)(a) was removed as a lawful basis · 6(1)(b) was kept · 6(1)(c) was kept, but this would be a rare instance · NCSG noted 6(1)(f) is the only appropriate basis, but IPC disagrees and noted the disagreement b) Feedback from EPDP Team · Subsection A · Subsection B · Subsection C · Subsection D and E · This is a 6(1)(f). The contractual obligation does not apply to third parties - registrars do not have a contract with the individual who is requesting the data. · What is the rationale of including 6(1)(c) here? · General comment on all use cases: when EPDP Team members have commented, it appears that use case drafters disagree with the points and do not propose edits or compromises. This would amount to wasted time. · The reason 6(1)(c) was included is because UDRP and URS cases can be appealed - if this appeal happens, processing the data may be necessary to participate in the court proceeding. · 6(1)(f) should be included here. It is important for the Team to do this review. Regarding 6(1)(b), and the Bird & Bird memo - it doesn’t appear 6(1)(b) would apply with the current legal advice. · It’s unacceptable for 6(1)(f) to not be included at all. · Subsection F · Subsection G · Subsection H · Subsection I · Subsection J · “Or” should not be used in the accreditation criteria. If there is going to be processing of gTLD registration data, a combination of this criteria would be needed. · With respect to number 4, why would an entity seeking accreditation or disclosure have to affiliated with a DRP? What does it mean to be affiliated with? · What is the vision of accreditation - who is the accreditation for - URS or UDRP providers? Is the accreditation for entities seeking to file a UDRP or URS complaint? · There are two things happening in this box - one is the points made as “or” b/c you may not have an IP right, but you may work for someone who does, which is why not everything is “and”. Number 4 is the real problem that accreditation can help to fix. Maybe a UDRP provider could be accredited to receive data once a complaint has been filed. · It appears the use case is meant to apply to DRPs and TM holders. These are different user groups, and it should not be conflated into one use case. · This is a good point, and this could be divided into two use cases. The 6(1)(b) processing basis still applies to the Complainant since the data subject is a party to the contract. · Why is there is a 6(1)(b) basis for UDRP providers, but not complainants? · Registrants have signed a contract with registrars that commits them to submit to a DRP. Complainant is an unaffiliated party with a legitimate interest in the data, but there is no contract with complainants. · The Complainant may obtain data with 6(1)(b), but the contract b/w ICANN and DRPs would likely trigger 6(1)(f). Leave two legal bases in and it would be OK. · Subsection K · Subsection L · Subsection M · Subsection N · Subsection O c) Confirm next steps · Action item: Brian to consider comments made today regarding legal basis and amend the case accordingly. 5. Use case – final reading: Investigation of criminal activity where domain names are used. Typical specific example: phishing attack [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_documen...> (SSAC 3) a) Review updates made to use case to reflect input received (SSAC) · SSAC made a number of edits based on comments received. · If there is a disagreement, how should that be reflected in the use case? · Disagreements need to be bridged through compromise, or, at a minimum, documented within the use case · In some instances, the SSAC use case invokes recitals that NCSG disagrees with. · Safeguard requirements are applicable to the entity that is protecting the data subject · Contracted parties have noted their discomfort with the combination of criminal activity and abusive activity in outlining this use case. There is significant overlap b/w this as written and the previous use case by the GAC. · How do the use cases fit into the final report? The Team understands that these are exercises that allow us to confront issues. The problem comes when including these use cases in the Final Report - if documents are included in the Final Report, there needs to be consensus. Authors cannot use these to be advocates and/or wishlists. The penholder cannot arbitrarily decide that they do not agree with something and arbitrarily decide what the legal basis is. Disagreements, at a minimum, need to documented in the Final Report. · This use case covers criminal use cases and abuse cases, and these need to be separated. · The use cases will not be attached to the Final Report. · It will be helpful to include as much detail in the policy was possible. · This use case does not conflate crime and abuse since these two aspects of the same thing. · Crime and abuse are not disambiguated b/c they cannot be. Phishing is a crime. What can make a difference is which party is dealing with it when. Law enforcement has different bases than private parties. · Regarding safeguards, this is a chicken or egg situation - safeguards may be the same no matter which type of party is making the request. The Team will have to talk about safeguards as a separate subject. Accreditation comes out of safeguards. · It is SSAC’s assumption that entities that get into an accreditation scheme have to meet some sort of bars. · These documents are the only place to capture thoughts and ideas. The parts of the Initial Report that are consensus-based are the recommendations, so it would make sense in places where there are disagreements. · Re: legal bases - the SSAC team looked at the bases from the comments. 6(1)(f) will represent most of the requests here. However, it would be inadvisable to rule other legal bases out. Additional commentary will be added to these legal bases. · The legal basis discussion is what is causing the group to stumble. Suggestion: perhaps the use case could be separated based on the legal basis. · Action item: SSAC to reflect today’s conversation in the use case. For the moment, the Team will park the use case and can revisit in the future when going through the zero draft. b) Feedback from EPDP Team c) Confirm next steps 6. Use case – first 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.)<https://community.icann.org/download/attachments/111386876/Use%20Case%20-%20...> (SSAC1) a) Introduction to use case (SSAC) · Domain names are often used either maliciously in DNS-based attacks, DDOS being the most common. · The use case is about a network operator, who is under attack, and needs to contact the domain owner to remediate the security issue. · Pseudonymized data is unlikely to help the issue · Most of the time, these situations need immediate contact - therefore, registrant contact, admin contact, tech contact, phone and email would be required here. · 6(1)(d) - sometimes critical infrastructure like hospitals or power grids could be brought down by network attack, which is why this legal basis was included in the list · In Subsection E, Recital 49 is added b/c this is exactly what Recital 49 is meant for. · Subsection F - Requestor will comply with all GDPR aspects · As far as disclosing the data, same standard safeguards should be applied. · If automation is possible, the hope would be that info could be disclosed in a few seconds. If manual, same-day response would be desirable. b) Feedback from EPDP Team · Consternation with 6(1)(d) as a lawful basis - it would be easier to walk through 6(1)(f) as a contracted party · Urgency of the request is something that should dictate the response and speed of the response. · This is the original purpose of collecting and displaying WHOIS data. 6(1)(d) may make registrars nervous. · Issue with 6(1)(d) - that legal basis is very limited in scope. · It would be helpful for anyone making comments in today’s meeting in the Google Doc itself. c) Confirm next steps 7. Any other business (5 minutes) · In preparation for the Los Angeles F2F, Janis suggested having CEO present during F2F. In order to structure that conversation, Support Staff will create a Google Doc with a few initial questions and EPDP Team members may contribute additional questions. 8. Wrap and confirm next EPDP Team meeting (5 minutes): a) Thursday 29 August 2019 at 14.00 UTC (5 minutes) b) Confirm action items c) Confirm questions for ICANN Org, if any