- Gnso-epdp-team - lists.icann.org

**Please read** Member wiki page check/SOI check
by Julie Bisland Aug. 1, 2019

Aug. 1, 2019

Dear all, In an effort to ensure accuracy, please take a moment to check your GNSO SOI and make any needed updates (select EDIT CONTENTS at the top of the page). In addition, would all members, alternates and observers kindly visit the WG Members wiki page: https://community.icann.org/x/kBdIBg and verify all information is correctly displayed. For any updates needed to the member wiki page or if assistance is needed with your GNSO SOI, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. As a reminder, staff will be unable to make changes to SOIs. Much thanks to you all, GNSO SO/AC Support -- Julie Bisland GNSO SO/AC Support coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Email: julie.bisland(a)icann.org<mailto:julie.bisland@icann.org> Skype ID: 79613b691cb8a6c1 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> See All SO and AC events on the ICANN Global calendar<https://features.icann.org/calendar>

1 0

GAC Early Input into EPDP Phase 2
by Heineman, Ashley Aug. 1, 2019

Aug. 1, 2019

Dear EPDP colleagues, As just noted on the call, please find attached the GAC early input into the EPDP Phase 2. Our sincerest apologies for the delay in getting you our input. Ashley Heineman GAC Rep 202 482 0298

1 0

Proposed agenda - EPDP Team meeting #11 on 1 August 2019
by Caitlin Tubergen Aug. 1, 2019

Aug. 1, 2019

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Thursday, 1 August at 14.00 UTC. Due to the feedback received by some members of the EPDP Team, EPDP Leadership has chosen to postpone the accreditation discussion and continue to discuss use cases. Thank you. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #11 Proposed Agenda Thursday, 1 August 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) Early input review – next steps 4. Use Cases Categorization (10 minutes) Review results of the survey Confirm review order and schedule 5. Use case – first reading continued: Investigation of criminal activity where domain names are used. Typical specific example: phishing attack (45 minutes) Input from EPDP Team – questions, concerns, proposed modifications Confirm next steps 6. Use case – first reading: Online buyers identifying and validating the source or services/ Internet users validating the legitimacy of an email or a website to protect themselves (60 minutes) · Introduction of use case (ALAC) · Input from EPDP Team – questions, concerns, proposed modifications · Confirm next steps 7. Any other business (5 minutes) Priority 2 small team meetings update Accuracy and WHOIS ARS (see https://docs.google.com/document/d/1pS9Pibanj-Hp6LztZpeERtxdoLsnp4y_-do0vU5…) Input received on other priority 2 items from RrSG (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-June/002174.html) Leadership to recommend next steps via mailing list Council request for input on org letter requesting clarification on Data Accuracy and Phase-2 (see https://gnso.icann.org/sites/default/files/file/field-file-attach/marby-to-…) EPDP Team to provide input on the mailing list. Confirm deadline for input. 8. Wrap and confirm next EPDP Team meeting on Thursday 8 August 2019 at 14.00 UTC (5 minutes) Confirm action items Confirm questions for ICANN Org, if any

3 3

ICANN org question response
by Caitlin Tubergen July 31, 2019

July 31, 2019

Dear EPDP Team: During the course of review of the Priority 2 worksheet on Natural vs. Legal, an EPDP Team member suggested posing the following question to ICANN org: Can ICANN org please provide a list of the current notices registrars are required to provide to registrants? As no EPDP Team members objected to this question, EPDP Staff Support forwarded the question to ICANN org for its review. Please find the attached document which constitutes ICANN org’s response. Thank you. Best regards, Marika, Berry, and Caitlin

1 0

FW: Responses to rr input
by LEWIS-EVANS, Christopher July 31, 2019

July 31, 2019

OFFICIAL Afternoon all sorry for the response overlapping the meeting, please find responses to the questions in red below which we will cover in todays meeting. Regards Chris The RrSG has reviewed the LEA1 use case provided by the GAC team, and has the following feedback. ● In section (b), the RrSG is pleased to see the request limited to “Non-public registration data,” and affirms that this SSAD must not be used to disclose other data that may be held by the Controller, it should be limited only to previously-public registration data. ● In section (c), there is the expectation that not only redacted data is provided in the SSAD, but also data which are publicly available. The SSAD should be restricted to providing only non-public registration data which was previously public, and should not include currently-public data. We feel this gives an increased accuracy in processing the data, could you give a reason why this data should not be given by the disclosing party. ● For section (c), the RrSG notes that the footnote “For each request, the requestor will need to confirm which data elements are necessary.” is a part of the template, and may not be understood to be a mandatory part of the use case and any disclosure request. It should be clarified that the requestor must request only the minimum relevant data, and the Controller should disclose only the minimum relevant data. Agree change. ● Section (d) indicates the “Lawful basis of entity disclosing non-public registration data to the requestor” as 6 (1) f (legitimate interest). This is acceptable as the basis on which the disclosing entity provides the data, however we do note that the requestor needs to also indicate the legal basis for the request itself, which is likely to be 6 (1) e (public interest) Legal basis for the requestor is under section e ● In section (e), jurisdiction should also be part of the supporting info that is provided with the disclosure request, and there are related questions that the plenary team should consider. E.g., does an LEA have the authority to request non-public data from a non-local controller and does the non-local controller have a legal obligation/dispensation to provide such data to a foreign LEA. If the requestor is using 6.1f then no compulsion from the LEA is being used. Having the authority to request data would be dealt with under by accreditation /authentication but must be confirmed before release safeguard suggestion below would hopefully cover this? ● For section (f), we propose an additional safeguard: The requestor must be endowed with the appropriate legal authority to make such a request of a non-local controller. Agree change ● In section (g), the disclosing entity should have an additional safeguard: they must be enabled to verify the legal authority of the LEA to make the request. Via a accreditation /authentication method? ● Also in section (g), the RrSG notes the addition of this text: “The data subject should be able to challenge-with proper substantiation-the balancing test with rights to object and to erasure.” The right to erasure would seem to apply not to data disclosed through the SSAD but instead to the data held by the Controller; how would the right to erasure be operationalized here? Applicable to the disclosuring body so an erasure in this case would be removal of the Domain name and all related records assuming they are the rr/ry else another body would be the deletion of any records held (assuming any are held). ● The section (h) description has been updated to specify an automated system; this is not necessarily what the SSAD will require. It may be that an SSAD functions best when the expectation is manual review rather than automated processing; the decision has not yet been made and should not be presumed. Think this and other sections are what if this was agreed ● Also in (h), the RrSG is pleased to note that the disclosure is limited to the current registration data set, and will not include historical records. We would suggest also that this be limited to specific domains, bulk requests should not be considered. By bulk do you mean unrelated or do you mean multiple domains? ● In section (i) the RrSG again objects to the addition of “automatic” to the section description. This and other sections are provided along the lines of what if this was agreed ● Section (j) is strangely worded and the RrSG could not parse the intent of the section; we would appreciate clarification from the GAC team. >From earlier input we would suggest adding jurisdiction and legal basis to this ● In section (m) the required timeframe for a substantive response is 2 business days. This is not a sufficient period of time to review and address requests. Recommendation 18 of the EPDP Phase 1 Report gives 2 business days for acknowledging receipt of a request; we should not now modify this to require substantial response in that same 2 day period. If there will be any SLA in place, there should also be an exception to allow for manual processing of complex or questionable requests. As this is just for LEA use cases we believe this is a viable time frame for the expected volume within this subset. ● The RrSG does not agree with section (n), that automation of the substantive response is possible/desirable. Requests must be reviewed so that the balancing test can be performed, which is difficult to automate. It may be that a hybrid-style system is useful, in which an automated system does a first pass and then a human reviews the results and completes the disclosure. Worth further discussion The NCA email domain has changed to @nca.gov.uk. To ensure your email gets through please do not use @nca.x.gsi.gov.uk ************************ This information is supplied in confidence by NCA, and is exempt from disclosure under the Freedom of Information Act 2000. It may also be subject to exemption under other UK legislation. Onward disclosure may be unlawful, for example, under data protection legislation. Requests for disclosure to the public must be referred to the NCA FOI single point of contact, by email on PICUEnquiries(a)nca.gov.uk. All E-Mail sent and received by NCA is scanned and subject to assessment. Messages sent or received by NCA staff are not private and may be the subject of lawful business monitoring. E-Mail may be passed at any time and without notice to an appropriate branch within NCA, on authority from the Director General or their Deputy for analysis. This E-Mail and any files transmitted with it are intended solely for the individual or entity to whom they are addressed. If you have received this message in error, please contact the sender as soon as possible.

2 1

**Reminder** Meeting Invitation: Observers GNSO Temp Spec gTLD RD EPDP - Phase 2 call / Thursday, 01 August 2019 at 14:00 UTC
by Julie Bisland July 31, 2019

July 31, 2019

As a result of various requests to facilitate observers to follow the EPDP Phase 2 deliberations in real time, audio cast will be made available for the EPDP plenary meetings. Staff will be monitoring audio cast attendance numbers so that the EPDP leadership can assess its usage. As a reminder, the zoom recording, mp3 recording, chat transcript and transcript of the EPDP plenary meetings will be publicly posted as soon as available on the EPDP wiki page and GNSO master calendar. Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 is scheduled on Thursday, 01 August 2019 at 14:00 UTC for 120 minutes. (calls will be scheduled for 120 minutes but aim to keep to 90 minutes) 07:00 PDT, 10:00 EDT, 16:00 Paris CEST, 19:00 Karachi PKT, 23:00 Tokyo JST, (Friday) 00:00 Melbourne AEST For other times: https://tinyurl.com/yye2pq6f [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_yye2pq6f&d…> Agenda Wiki: https://community.icann.org/x/mqajBg The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> Meeting Audio Cast (for observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream02 <https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream02.m3u <https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> If needed, an option to join via telephone has been added for this meeting. Passcode: EPDP Dial in numbers: Country Toll Numbers Freephone/ Toll Free Number ARGENTINA 0800-777-0519 AUSTRALIA ADELAIDE: 61-8-8121-4842 1-800-657-260 AUSTRALIA BRISBANE: 61-7-3102-0944 1-800-657-260 AUSTRALIA CANBERRA: 61-2-6100-1944 1-800-657-260 AUSTRALIA MELBOURNE: 61-3-9010-7713 1-800-657-260 AUSTRALIA PERTH: 61-8-9467-5223 1-800-657-260 AUSTRALIA SYDNEY: 61-2-8205-8129 1-800-657-260 AUSTRIA 43-1-92-81-113 0800-005-259 BELGIUM 32-2-400-9861 0800-3-8795 BRAZIL RIO DE JANEIRO: 55-21-40421490 0800-7610651 BRAZIL SAO PAULO: 55-11-3958-0779 0800-7610651 CHILE 1230-020-2863 CHINA CHINA A: 86-400-810-4789 10800-712-1670 CHINA CHINA B: 86-400-810-4789 10800-120-1670 COLOMBIA 01800-9-156474 CROATIA 080-08-06-309 CZECH REPUBLIC 420-2-25-98-56-64 800-700-177 DENMARK 45-7014-0284 8088-8324 ESTONIA 800-011-1093 FINLAND 358-9-5424-7162 0-800-9-14610 FRANCE LYON: 33-4-26-69-12-85 080-511-1496 FRANCE MARSEILLE: 33-4-86-06-00-85 080-511-1496 FRANCE PARIS: 33-1-70-70-60-72 080-511-1496 GERMANY 49-69-2222-20362 0800-664-4247 GREECE 30-80-1-100-0687 00800-12-7312 HONG KONG 852-3001-3863 800-962-856 HUNGARY 36-1-700-8856 06-800-12755 INDIA INDIA A: 000-800-852-1268 INDIA INDIA B: 000-800-001-6305 INDIA INDIA C: 1800-300-00491 INDONESIA 001-803-011-3982 IRELAND 353-1-246-7646 1800-992-368 ISRAEL 1-80-9216162 ITALY MILAN: 39-02-3600-6007 800-986-383 ITALY ROME: 39-06-8751-6018 800-986-383 ITALY TORINO: 39-011-510-0118 800-986-383 JAPAN OSAKA: 81-6-7878-2631 0066-33-132439 JAPAN TOKYO: 81-3-6868-2631 0066-33-132439 LATVIA 8000-3185 LUXEMBOURG 352-27-000-1364 8002-9246 MALAYSIA 1-800-81-3065 MEXICO GUADALAJARA (JAL): 52-33-3208-7310 001-866-376-9696 MEXICO MEXICO CITY: 52-55-5062-9110 001-866-376-9696 MEXICO MONTERREY: 52-81-2482-0610 001-866-376-9696 NETHERLANDS 31-20-718-8588 0800-023-4378 NEW ZEALAND 64-9-970-4771 0800-447-722 NORWAY 47-21-590-062 800-15157 PANAMA 011-001-800-5072065 PERU 0800-53713 PHILIPPINES 63-2-858-3716 1800-111-42453 POLAND 00-800-1212572 PORTUGAL 8008-14052 ROMANIA 40-31-630-01-79 RUSSIA 8-10-8002-0144011 SAUDI ARABIA 800-8-110087 SINGAPORE 65-6883-9230 800-120-4663 SLOVAK REPUBLIC 421-2-322-422-25 0800-002066 SOUTH AFRICA 080-09-80414 SOUTH KOREA 82-2-6744-1083 00798-14800-7352 SPAIN 34-91-414-25-33 800-300-053 SWEDEN 46-8-566-19-348 0200-884-622 SWITZERLAND 41-44-580-6398 0800-120-032 TAIWAN 886-2-2795-7379 00801-137-797 THAILAND 001-800-1206-66056 TURKEY 00-800-151-0516 UNITED ARAB EMIRATES 8000-35702370 UNITED KINGDOM BIRMINGHAM: 44-121-210-9025 0808-238-6029 UNITED KINGDOM GLASGOW: 44-141-202-3225 0808-238-6029 UNITED KINGDOM LEEDS: 44-113-301-2125 0808-238-6029 UNITED KINGDOM LONDON: 44-20-7108-6370 0808-238-6029 UNITED KINGDOM MANCHESTER: 44-161-601-1425 0808-238-6029 URUGUAY 000-413-598-3421 USA 1-517-345-9004 866-692-5726 VENEZUELA 0800-1-00-3702 VIETNAM 120-11751 Thank you. Kind Regards, Terri

1 0

Notes and action items from EPDP Meeting #12 - 25 July 2019
by Ariel Liang July 30, 2019

July 30, 2019

Dear EPDP Team: Below, please find the notes and action items from yesterday’s EPDP Team Meeting. As a reminder, the next EPDP Team Meeting will be Thursday, 1 August at 14:00 UTC. Best regards, Marika, Caitlin, Berry (and Ariel – assisted with notetaking) EPDP Phase 2 - Meeting #12 Thursday, 25 July 2019 at 14:00 UTC Action Items: 1. If no further clarifying questions are submitted in response to the early input document by the deadline (25 July 2019), staff to consider the comments in the development of the draft policy recommendations and draft Initial Report. 2. Staff to set up survey for the EPDP Team to rank and identify the most representative case in each group of the use case categorization. EPDP Team to complete the survey by COB Monday, 29 July. 3. Staff to compile the input submitted on automation/accreditation to assist the EPDP Team in its substantive discussions during next week’s call and future calls. Leadership team to develop initial thoughts paper on accreditation to kick start discussions. 4. Chris Lewis-Evans to incorporate input received from the EPDP Team and continue fine tuning the use case (GAC LEA1-13719-1), which is expected to be attached in the annex to the Initial Report. Updated version to be posted on the Wiki and the leadership to make a further recommendation for how to finalize the use case. 5. In meeting on Thursday, 1 August, the EPDP Team to devote part of the meeting to discuss initial reaction from members on the SSAC Crime-Abuse Investigation Use Case. EPDP Team to provide input by writing no later than 14:00 UTC on Monday, 29 July. More detailed discussion about this use case will take place in the meeting on 8 August. 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/l6ajBg 1. Roll Call & SOI Updates (5 minutes) * Attendance will be taken from Zoom * Remember to mute your microphones upon entry to Zoom, which is typically the first icon on the left on the bottom toolbar. * 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) * No objections 3. Welcome and housekeeping issues (Chair) (10 minutes) a) Update from Legal Committee * Started out by reviewing prior session’s action items and questions * Reviewed the remaining questions, narrowed down the scope, and those questions will be evaluated based on the needs of Phase 2. Near term goal is to understand all the legal requirements and try to develop sizing for requesting additional resources from the Board. * Next LC meeting is 6 August. b) Early input review status (deadline 25 July) * A number of groups responded to the EPDP Team’s request for early input. This input was subsequently organized by staff in the form of an early input review tool. * Following EPDP Team discussion, input regarding SSAD has been incorporated into SSAD worksheet for EPDP Team review. In addition, the EPDP Team agreed to review the input received and document any clarifying questions in the google doc that was created. * Deadline for clarifying questions on the early input was Thursday 25 July. No comments/questions were received at the time of the call. * ACTION ITEM: If no further clarifying questions are submitted in response to the early input document by the deadline (25 July 2019), staff to consider the comments in the development of the draft policy recommendations and draft Initial Report. 4. Use Cases Categorization (10 minutes) a) Review proposed categorization put forward by small team * A small group of volunteers agreed to work with staff. Based on the original staff categorization and incorporating input from NCSG, BC and IPC, staff/volunteers went through a number of iterations to review the use cases. Important to note that no use case has been eliminated as a result of this exercise. Objective is to identify the most representative case for each category as a starting point for the deliberations. Following review of the most representative use case in each category, the EPDP Team can then decide whether additional cases need to be reviewed. * 5 groups, as noted on the document. * Appreciation to Milton, Margie, Chris, and Brian for their contributions to this exercise. * Chair’s proposal: Identify in each group, the most representative use case that the EPDP Team should look at first, starting from Group 1. * We have already made decisions where to start. First group 1. After that, group 2, move to group 4 and then group 3 or 5. * Staff to put in survey format and ask EPDP Team members to respond to the survey by COB Monday, 29 July. * Review the representative use case first, and see whether any issue associated other use cases that warrant being reviewed. Not sure whether there is time to do an in depth review of each of them. * For the rest of the cases, maybe only look at the differences instead of an in depth review. * Would it be useful to map the stages (e.g., a series of questions) that a compliant organization must go through as it determines whether it is a legitimate request for information. Who? What scope? Under what authority? Etc. Left column of the use cases are geared toward answering those questions and providing a framework for discussions. In reality we are talking about rather simple system. Supply is the Registry/Registrar, and they have the building blocks. Going through the use cases is to understand each of the building blocks. b) Confirm proposed categorization * No objection c) Confirm new ranking survey & deadline to determine most representative use case in each category * Staff to set up survey for the EPDP Team to rank and identify the most representative case in each group of the use case categorization. EPDP Team to complete the survey by COB Monday, 29 July. 5. Use case – first reading: Investigation of criminal activity where domain names are used. Typical specific example: phishing attack<https://community.icann.org/download/attachments/111386876/SSAC%20Crime-Abu…> (60 minutes) * Chair’s proposal: EPDP Team to identify the difficulty in the first reading of the case (SSAC Crime-Abuse Investigation Use Case), present them in writing and share on the mailing list. * Defer the discussion of the use case till 8 Aug due to Greg’s absence during next week’s meeting? Provide initial overview during today’s meeting with ability for EPDP Team to share initial observations during today’s and next week’s meeting, followed by in depth review during 8 August EPDP Team meeting. * Review a set of tasks / purposes that occur in a number of cyber crime cases. Some are done by investigators in private realm. Some steps are done by law enforcement due to the same goal. Purpose here is to explain how things work practically and see what issues would surface. * Start with practical instances (i.e., recital 49) about the processing of data. Then compromised/malicious registrations. * Section A, law enforcement may also rely on these parties and techniques. * Section B, Tasks 1-2: reasons why the data are requested and used. Maliciously registered means somebody uses the domain name to commit a crime. If a domain name is maliciously registered, suspending the domain name is an option. If a domain name is compromised, you don’t want to suspend the domain. Reputational providers do not generally block domains. Some just list domain names and say don’t have anything to do with them. You need to determine what additional domains may be related. The issue is dealing with ongoing harm. You can determine what other domain names are on the same IP address, which may not be operated by the same bad actor. * Section B, Task 3: If the contact data is bogus, it is a sign of bad faith. Sometimes criminals do a poor job of faking the data. Accessing accuracy is important. Comment from EPDP Team members: Bogus data is not automatically a sign of bad faith. And your accuracy check has to be done by compliance. * Section B, Task 4: Need to document the case and preserve the reason why you made the decision of suspending the domain name and substantiate why the domain name is problematic. Be responsible and give decision makers the information they need. * Section B, Task 5: law enforcement and private parties do this. Private parties may want to avoid associated assets. * Section B, Task 6: many aspects involve automation. Some block lists use algorism. The system that protects people involve a high degree of automation. * So how does 49 relate to domain names? When domains are as the mechanism for the cybercrime attack, the “ability of a network to resist…” will largely be based on the ability to continue to allow traffic from said domain, or (as Greg is explaining) to block / reject any further traffic from or access to said domain.  * How can you describe things generally and then go to nitty gritty issues like automation. you need to be very specific in other fields as well. Don’t see a Use Case here. Need clear explanation on how all those recitals and all the clauses apply to these issues. * It is an issue with the law but not what ICANN/EPDP Team can fix. We still have to apply the law as best as possible, but EPDP Team cannot make any effort to change the law. * The EPDP Team needs to work on how to deal with the balance of the law. * The internet will die far faster if people are advocating breaking it because people did not involve themselves in the crafting of such law. For example the e-privacy regulations were stalled because an affected party advocated on how the law would have an unintended consequence. Again ICANN cannot fix the way it is, we can only figure out a way of making the "new" post GDPR world better .... including shaping future legislative endeavors - not by ICANN policy supporting a bending of that law. * They should be reported to law enforcement. Not like Brian Krebs just putting out info of the attackers wife on a public blog. https://krebsonsecurity.com/2017/07/who-is-the-govrat-author-and-mirai-botm…  security researchers need to do their research diligently without harming those who are not involved.  * Suggest that people do their research on how investigations by private actors are managed under DP law in the meantime, and talk about the case the following week. While cybercrime is a good example of rampant regulatory avoidance, it is not the only one. However, it does not work well under data protection law (competition law also being relevant but not in our remit).  * The need is to stop the harmful activity, it is not to identify the guilty party. You don’t need redacted data to substantiate the domain. There will be a lot of information that won’t be redacted. Support efforts by private actors to sweep through the information to stop attacks, but we don’t need to open up the data. * The practical issue is that the vast majority of the cases do not involve law enforcement or are being reported. Law enforcement does not have the resources. A lot is done by relying on contract. * Phone number is relevant when its relevant. This use case doesn't cover those instances where passive DNS (for example) was sufficient. They do exist, but not relevant to this use case . * ACTION ITEM: In the meeting on Thursday, 1 August, the EPDP Team to devote part of the meeting to discuss initial reaction from members on the SSAC Crime-Abuse Investigation Use Case. EPDP Team to provide input by writing no later than 14:00 UTC on Monday, 29 July. More detailed discussion about this use case will take place in the meeting on 8 August. 6. Use case – final reading: Investigation of criminal activity against a victim in the jurisdiction of the investigating EU LEA requesting data from a non-local data controller<https://community.icann.org/download/attachments/111386876/Use%20Case%20-%2…> (30 minutes) * Chair’s Proposal: deal with this item before the first reading of item #5 * Starting from g) Safeguards (requirements) applicable to the Entity Disclosing the Nonpublic Registration Data * See responses from Chris Lewis-Evans to comments submitted by RrSG on this use case. Chris agrees with Registrar group’s suggestion re Section C, as it gives an increasing level of accuracy. Agree with the suggested change in Section D by the registry group. Section F, agree with the suggested change. * Chris Lewis-Evans will also consider additional registrars’ comments/questions. Registrar reps indicated that they will need a couple of days to review the responses Chris provided and may respond further on the list once they have had a chance to do that. Don’t take silence as complete agreement. * Re 6(1)F, the legal authority needs to be identified. EPDP Team is not expert to verify that. Ensure that LEA establishes the legal authority itself. * Section H: * Clarify the comments from registrars, add safeguards under automated system which may be different. * Need to have a discussion about how the automated system works. * Probably useful to drop a footnote in the template to provide the explanation Chris just gave so it’s clear on its face and avoids later confusion and uncertainty. * Section I, no further comments/requests. * Section J: * First time discussing accreditation. It is a chicken-egg situation, as it depends on the standardized system. Jurisdiction and legal basis would be necessary for an accreditation body to look at. * There are differences between accreditation and validation. Some suggested to first discuss validation first, as it has different forms which can or cannot be automated. Accreditation might then be fully automated. * “Validation” probably means “authentication” that is covered in Section K. We need to deal with accreditation first before authentication. There may be one exceptional case that one can be authenticated before accreditation, but it does not justify changing the default order. * This depends on the implementation of the standard system. Even we don’t end up with having a centralized system, we can still do it. A decentralized system can still have value. The same standards can be centralized and also applied in decentralized way. * The “code of conduct” may not be part of the accreditation. Disclosure / nondisclosure related issues belong more in the safeguard section. * EPDP Team can create a special accreditation entity that consists of one group or many groups. There are a number of options. But first need to see whether there is a broad agreement that accreditation as a principle should be introduced in the standard. * EPDP Team needs a set of definitions because people are using the terms in different ways, and for accreditation, there are two aspects. Accredditing of a group to be eligible to use a system (or make a manual request) and accrediting an individual requester to be part of that group.  This is what we currently have in the chair’s working definitions document: “Accreditation – refers to the process or action of recognizing a person as having a particular identity, possibly with an associated affiliation or status.” * See Chair’s working definitions here: https://community.icann.org/x/-5WjBg<https://community.icann.org/x/-5WjBg%5C>. Strongly suggest to flesh out the details when people are using different meanings for the same terms. * There is no accreditation body that the EPDP Team needs to define or create. The EPDP Team does not need to determine what the accreditation elements/criteria are. Specifically about the LEA, it is up to the law enforcement and the coalition of law enforcement bodies to do it. Part of this comment will represent part of the policy statement. As a policy matter, there should be accreditation, the accreditation should ensure certain aspects/points, etc. We can develop general policies on accreditation and it is in our work plan. * There would be some “approved” list of accredited based on some the set of criteria. * Another consideration, albeit not an immediate problem, is about authoritarian government, human rights protection, cloud act, etc. We can accredit a law enforcement agency as a legitimate one, but if there is a national law that allows the agency to investigate or harass people that criticize the government, how do we want to handle that? Do we want to have additional human rights protection attached to the accreditation criteria? * A lot of those human rights concerns can be addressed by the terms of use, ensuring there is strong enforcement of the terms of use. * General policies to keep authoritarian countries away from disclosure and accreditation? Don’t think this group can do that. Also some of these countries are allegedly undertaking cyber attacks. Whatever this LEA accreditation body would be, civil society would definitely have to be involved in the definitions, but this is outside of our remit. * Somebody accredited does not mean he/she has a valid request. You have to review each request to ensure it is valid. There is a responsibility for the entity that releases the data to validate the request. We all agree at this point that accreditation doesn't assume guaranteed access. A valid form of accreditation is merely a factor in the 6(1)f balance - or in the case of jurisdiction - a confirmation that there is a legal obligation on that controller in that jurisdiction. * Does every single contracted party need to act as its accreditation body? This may not be implementable. * The correct safeguards for both the accreditation and the authentication levels need to be developed. * If we are talking about a fully automated accreditation process, law enforcement organizations can be done easily, but not so easy to accredit other kinds of organizations. Need some human intervention. Also need a decision making process, which can be automated possibly. * Staff have grouped the input on accreditation together, aligning with the relevant charter questions (but no definition): * b) What are the unanswered policy questions that will guide implementation?   * b1) How will credentials be granted and managed?   * b2) Who is responsible for providing credentials?   * b3) How will these credentials be integrated into registrars’/registries’ technical systems?  * Chair’s proposal: When accreditation is discussed next time, Staff to pull out their compilation of everything that has been submitted on accreditation and identification related processes to help inform EPDP Team’s further deliberation on this fundamental building block. * Section L: * Come back to “credentialing” in a more structured way when reviewing the next case. * We add a footnote to note it.  * Section M: * it is up to the LEA whether there is any urgency. In certain cases, a specific quick turn around may be necessary, but 2 days across the board may be too restrictive. * There is concept of acknowledging the requests, whether the data will be delivered. Some requests have higher priority and some requests demand different levels of confidentiality. Need to accommodate these concepts. * If you have a lot of requests, you have to staff up too. * Maybe Section M and Section O should be different. The level of requests is just for the LEA’s consideration, and that level is generally lower than other kinds of requests. Maybe 4 business days would be more than reasonable? Some exceptions can be made and listened to. * We cannot apply go daddy standards to all Registrars. It is a long tail data set, and many registrars may have one request/day, aligning with their size of business. There is a natural balancing. Also need to factor in that not all registrars will receive the same volume of requests - this may be aligned with the # of domain names under management. * Section N: * Is it possible to have an automated decision? How determinations are made when there is disagreement? We can automate processes, but not all processes can be automated. Need to evaluate all the information received before moving forward. * If an LEA makes a request for 10,000 records all based on the same legal basis and investigation, could the request be manually reviewed but once approved the delivery of the data automatic? * There may be instances that some data fields can be released safely for bona fide parties. Automated does not mean all the way to finish, it can be 80% of the process. This is important to know by the practitioner. * All the details regarding use cases are relevant to what can be automated or not. Focus on the use cases first and then circle back to this question. Automation is one of the charter questions and building blocks. * Section N: * Suggest removing the word “possible” and leaving “desirable”. A “possible" question should remain in the template, though we may want to separate it from "desirable"  Data retention would be subject to legal requirements in the jurisdiction of the LEA would it not? Might be better to ask whether automation is consistent with legal requirements/legal basis . * Section P: not so clear, suggest the same language used in the previous section for retention. There is no blanket answer. * ACTION ITEM: Staff to compile the input submitted on automation/accreditation to assist the EPDP Team in its substantive discussions during next week’s call and future calls. Leadership team to develop initial thoughts paper on accreditation to kick start discussions. * ACTION ITEM: Chris Lewis-Evans to incorporate input received from the EPDP Team and continue fine tuning the use case (GAC LEA1-13719-1), which is expected to be attached in the annex to the Initial Report. Updated version to be posted on the Wiki and the leadership to make a further recommendation for how to finalize the use case. 7. Any other business (5 minutes) a) Priority 2 small team meetings update (1) Accuracy and WHOIS ARS (see https://docs.google.com/document/d/1pS9Pibanj-Hp6LztZpeERtxdoLsnp4y_-do0vU5…<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…>) (2) Input received on other priority 2 items from RrSG (seehttps://mm.icann.org/pipermail/gnso-epdp-team/2019-June/002174.html) (3) Leadership to recommend next steps via mailing list b) Council request for input on org letter requesting clarification on Data Accuracy and Phase-2 (see https://gnso.icann.org/sites/default/files/file/field-file-attach/marby-to-…<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_d…>). EPDP Team to provide input on the mailing list. Confirm deadline for input. * The EPDP Team did not address these agenda items 8. Wrap and confirm next EPDP Team meeting on Thursday 1 August 2019 at 14.00 UTC (5 minutes) a) Confirm action items b) Confirm questions for ICANN Org, if any

6 6

Re: [Gnso-epdp-team] REVISED: Question for legal advisors
by Alan Greenberg July 30, 2019

July 30, 2019

As I understand it, if we cannot rely on reputation and commitments, then there is no way to build an fully automated system to address ANY requests, no matter how repetitive or simple they may be. That implies that every request will require human intervention, and even that human must not rely of the requester credentials or commitments. Moreover, I am not sure I see the benefit of credentialing if we cannot rely on the credentials conveying some level of trust. Perhaps someone understands how we could still have a partially or fully automated system and if so I wish they would tell us. The hype around Artificial Intelligence implies it would be a piece of cake, but I remain skeptical and I have not heard any contracted parties saying they would be happy to rely on such a system. So if Milton and others are correct, and AI is not up to doing the "balancing", then we need to give up on the concept of an automated system or even an automation-assisted system. And the sooner we do it, the less time we will waste. But if we are ditching this core part of our task, I believe that we need professional guidance and not armchair lawyers. Alan At 29/07/2019 04:43 PM, Mueller, Milton L wrote: I find the discussions of this proposed question to be fundamentally detached from legal and practical reality. Essentially, this question boils down to this: can we avoid doing a balancing test if someone we think we trust wants the data? The answer to that should be obvious. If the law requires a balancing test, it doesn?t matter _who_ the person making the inquiry is. It doesn?t matter how ?trustworthy? they are, now nicely they ask, how sweetly they smile, the point here is that the interest of the requestor in obtaining the information must be weighed against the rights to privacy of the data subject. You cannot skirt that balancing test without breaking the law. Full stop. This question makes about as much sense as asking the data subject to unilaterally determine the outcome of the test. ?Hey, if we have a data subject we think is good and trustworthy, can we automatically nix any disclosure requests because we think they are good guys?? No, you can?t do that. Balancing test means a balancing test. One party?s interests are weighed against the other?s. I hope we do not waste our scarce legal time with something like this. Dr. Milton L Mueller School of Public Policy Georgia Institute of Technology From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> On Behalf Of Greg Aaron Sent: Monday, July 29, 2019 3:22 PM To: 'Alan Greenberg' <alan.greenberg(a)mcgill.ca>; 'EPDP' <gnso-epdp-team(a)icann.org> Subject: Re: [Gnso-epdp-team] REVISED: Question for legal advisors Dear Alan, Mark, legal team: Yes, this issue is a vital one to ask the legal advisers, and we must make sure they understand the issue. An additional way to explain it is below. Feel free to adapt or include any of this suggested language below if you like. <snip> 6(f) says that processing is lawful if it "is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject." This language describes a general requirement that must be met. It does not describe any specific decision-making process or the threshold that must be reached to satisfy the balancing test in any specific case. Question: can a data controller rely on advice or assertions that come from a qualified and trusted party in order to satisfy 6(f)?s balancing test? If it is possible, then what are the considerations? If not, why? Example: a third party is trying to mitigate a phishing attack. This third party is the victim of the attack, or is defending its customers. GDPR Recital 49 says that processing personal data for such a purpose ?constitutes a legitimate interest of the data controller concerned.? The third party makes a data request to the controller. The third party is in some way accredited, its identity and subject matter expertise are known to the data controller, and the third party makes representations about the legitimacy and accuracy of its request. Can the data processor rely on this information and relationship? </snip> (And I also assume what you wrote -- accreditation could be withdrawn, the requestor is following data minimization practices, etc. etc.) BTW, am hoping to move away from ?security researcher? as a blanket term to include those involved in operational security, for some previously explained reasons. Thanks, --Greg From: Gnso-epdp-team < gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Alan Greenberg Sent: Wednesday, July 24, 2019 11:18 PM To: EPDP <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> > Subject: [Gnso-epdp-team] REVISED: Question for legal advisors At Mark's suggestion, I have reformatted/reworded this for additional (hopefully) clarity. ============== Background: If information is to be requested released to third parties, the controller or other party(ies) must decide whether the need for the data outweighs the data subject's right to privacy. If the decision is made by a human, the competing needs/rights can be carefully weighed to decide whether the request should be honoured. If we are to consider any form of automated decision process, it is unlikely that we can build a sufficiently robust artificial intelligence engine to carry out the balancing operation. That raises the question of to what extent, based on appropriate accreditation processes, can we rely on the vetting during accreditation and the commitments made by the requester in order to be accredited can be relied upon. Examples: As a simple case, if a UDRP provider (who is authenticated as such) makes a request claiming it is for an ongoing UDRP process, can it be presumed that it is an authentic request and simply grant it. For a more nuanced situation, if a cyber security researcher who has been properly accredited (the Anti-Phishing WG as an example) makes a request for specific data, can we assume that given the process under which they are accredited, we can be assured that they need this data, have no practical alternative way of addressing the issue, and will only use/store the data appropriately Perhaps other specific cases should be cited in the question, but we do need guidance in the general case. Summary: Without being able to rely on the reputation and assurances of the requester, I do not see how ANY automated process will be possible. Question: If a requester is properly vetted (accredited, authenticated) and has provided assurances they understand they may only request data that meets the balance test (ie their need is sufficiently great that it warrants releasing to them otherwise redacted data), can an automated system presume that the GDPR balancing test has been satisfied? Of course, accreditation could be revoked if it comes to light that inappropriate requests are being made. At 24/07/2019 04:27 PM, Alan Greenberg wrote: As requested during the last meeting, here is a question to go to the Legal Committee looking for a clear legal opinion. =============================== If information is to be requested released to third parties, the controller or other party(ies) must decide whether the need for the data outweighs the data subject's right to privacy. If the decision is made by a human, the competing needs/rights can be carefully weighed to decide whether the request should be honoured. If we are to consider any form of automated decision process, it is unlikely that we can build a sufficiently robust artificial intelligence engine to carry out the balancing operation. That raises the question of to what extent, based on appropriate accreditation processes, can we rely on the vetting during accreditation and the commitments made by the requester in order to be accredited can be relied upon. Specifically, if a requester is properly vetted and provides assurances (and proof?) they understand the balancing that must be done, can the automated system presume that the balancing test has been satisfied. Of course, accreditation could be revoked if it comes to light that inappropriate requests are being made. In one simple case, if a UDRP provider (who is authenticated as such) make a request claiming it is for an ongoing UDRP process, can it be presumed that it is an authentic request and simply grant it. A less clear case is that of a cyber security researcher who has been properly accredited (the Anti-Phishing WG as an example). Perhaps other specific cases should be cited in the question, but we do need guidance in the general case. Without being able to rely on the reputation and assurances of the requester, I do not see how ANY automated process will be possible. Alan

2 1

RrSG Response to LEA1 use case
by theo geurts July 29, 2019

July 29, 2019

Countless of hours of hard work are attached ;) Best, Theo Geurts CIPP/E Privacy & GRC Officer | Realtime Register B.V. Ceintuurbaan 32A 8024 AA - ZWOLLE - The Netherlands T: +31.384530759 F: +31.384524734 U: www.realtimeregister.com E: legal(a)realtimeregister.com

3 3

REMINDER: For your input - categorization ranking survey - deadline Monday 29 July 2019
by Caitlin Tubergen July 29, 2019

July 29, 2019

Dear EPDP Team, Kind reminder to please complete the categorization ranking survey by COB today: https://www.surveymonkey.com/r/926YFGY [surveymonkey.com] Thank you. Best regards, Marika, Berry, and Caitlin From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings <marika.konings(a)icann.org> Date: Thursday, July 25, 2019 at 9:04 AM To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] For your input - categorization ranking survey - deadline Monday 29 July 2019 Dear EPDP Team, As discussed during today’s meeting, please complete the following categorization ranking survey by Monday 29 July at the latest: https://www.surveymonkey.com/r/926YFGY [surveymonkey.com] Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages.

1 0