2019-07-18 EPDP- Phase 2 call #09

Notes/ Action Items

Action Items

1. Support Staff to propose a new grouping of use cases with the help of Milton, Chris, Margie, and Brian by next Thursday, 25 July. 
2. In light of today’s conversation, Chris Lewis-Evans to seek the guidance of the previously-consulted DPO, with the goal of fine tuning the overarching LEA purpose. Following the receipt of guidance, Chris Lewis-Evans to propose modifications accordingly. 
3. Alan Greenberg to draft proposed legal question regarding the trustworthiness of the requestor and send to Leon and EPDP Leadership.
4. EPDP Team to finish reviewing the LEA use case offline, beginning at subcategory g and identify questions to the list in writing (if any) by Tuesday, 23 July.
5. Chris Lewis-Evans, with the help of GAC colleagues (as applicable) to consider any questions identified and propose corresponding edits/clarifications to the use case.

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 #11

Proposed Agenda

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
• Kristina Rosette no longer works for Amazon Registry but will continue representing the RySG until the RySG finds another representative

1.               Confirmation of agenda (Chair)

• Proposal to begin by discussing a possible consolidation of the use cases into a small number of cases. Before the Team ranks the cases, the cases should be consolidated.
• Chair proposal to discuss this proposal under Agenda Item 4

1.               Welcome and housekeeping issues (Chair) (10 minutes)

• Update from Legal Committee
• The Phase 2 Legal Committee met on Tuesday for the first time.
• The P2 LC established its working methods, which are the same for Phase 1
• The LC began by reviewing draft legal questions submitted for SSAD (Priority 1 work)
• Some LC members volunteered to consolidate similarly-worded questions. Some questions were identified as being too early in the Team’s work to ask now.
• EPDP Team comments/questions:
• With respect to prioritization of questions, some questions may be more urgent in the Team’s current work. How is budget begin considered - is this a potential issue for the number of questions the Team could send to outside counsel?
• Answer: yes, the budget is also being considered in the course of the LC’s work. Once the LC has a better idea of how much assistance from outside counsel is needed, there could be a request for additional budget.

1.               Use Cases Ranking Exercise (10 minutes)

• Overview of use cases submitted: https://community.icann.org/x/-KCjBg
• The NCSG sent a document to the list with a proposal for how to group the use cases, noting a fundamental distinction b/w criminal and civil law cases where policy recommendations will likely be the same. For criminal cases, a law enforcement agency would be requesting the information, while for a civil case, it would be a non-state actor or private party requesting the information. Additionally, random forms of validation could be grouped together; these all share a distinctive pattern where information is being requested for validation purposes. The last two categories are (1) requesting additional information to contact the registrant and (2) stand-alone cases like UDRP/URS and maintaining the domain name registration by the registrant.
• EPDP Team Feedback:
• There is value in working through a single use case from start to finish - if the cases are grouped, how would this work?
• The idea would be to make the cases more general and then look at the fields one by one. 
• Grouping cases does make sense; perhaps it would help to look at an exemplary case and see where differences need to be pointed out. Group one may just be called “crime” instead of law enforcement as other parties, outside of law enforcement, investigate crime. Additionally, the SSAC cases need to be added to the crime use case.
• This grouping is well done and will be beneficial. The Team needs to be careful it doesn’t inadvertently miss anything by grouping cases. For example, a national cert is not included here. It may be helpful to rely on one case from the group rather than a more broadened case.
• Do not agree with this categorization. For example, the consumer protection use case may be associated with a law enforcement agency, but it may not be. Fraud prevention may occur through consumers reporting incidents, rather than victims.
• Do not agree with this approach; the previous support staff proposed grouping makes more sense. In particular, there are categorizations within the groupings that do not makes sense.
• Agree that support staff’s categorization makes more sense than this proposal. What efficiencies is the Team gaining by proceeding with this grouping? There is value to consider use cases in grouping 3 and 4.
• The Team has more cases than time. Some cases do have commonalities. 
• Agree with the concept of grouping because spending time evaluating similar use cases is a waste of time. It’s not useful to capture all of the unique elements for the use cases into one overarching use case. 
• The concept of grouping can introduce efficiencies if the group is thoughtful about it. Primary concern with the NCSG proposal - LEA should be separated out from other quasi-criminal use cases identified. LEA has a different status and has different needs. There is value, independent of that, for the EPDP Team to first complete the LEA use cases.
• Focus on principles rather than single use cases. There is value in singling out certain cases, but the exercise of consolidating the cases will have the Team review all of the cases.
• The Team will likely ultimately combine several use cases. Three groupings: one from support staff; one from NCSG; one from BC. Proposal to begin with support staff’s grouping.
• Have heard support for the idea of grouping. One issue the Team seems to agree on: separate the LEA cases and prioritize them. One reason to separate the LEA cases and non-state actors is that the balancing test will be different. Combating crime is too broad of a category. This grouping should be much more explicitly focused. If the Team could make progress on the LEA case first, agree with previous point that it will be optically important.
• The Team needs a grouping and then to review to see if anything missing. Is the civil law grouping “civil law” or “quasi-law enforcement by civil entities”? This needs to be made more clear.
• There needs to be a distinction b/w who is making the request and what the entity is doing with the data. The entities may be doing the same type of work with the data.
• The Team is looking at the third-party purpose - the purpose is to contact someone about a crime or a civil wrong or private harm. If it’s about the purpose and what is being investigated rather than user groups, this could work. 
• There is a difference b/w criminal investigations and investigations by people who are trying to assist law enforcement, and that will have a material effect on if data can be released or not. Having a badge and a gun will make a difference.
• Chair proposal to move forward:
• Action: Staff to propose grouping with the help of a few volunteers from the Team. This grouping can be brought to the attention of the Team by next week or the week after. In the meantime, however, the Team will continue working on open cases such as law enforcement. Review a representative case and then identify if there are significant differences that would result in different responses to the template and discuss in the course of review.
• Staff already made a first cut. If volunteers can provide additional information on why that grouping doesn’t make sense, support staff can make a grouping. 
• Confirm results of ranking exercise
• Confirm leadership proposed order and next steps

1.               Use case – second reading: Investigation of criminal activity against a victim in the jurisdiction of the investigating EU LEA requesting data from a non-local data controller (30 minutes)

• Proposed methodology: Chris Lewis-Evans to introduce the changes to the document, and then review the contents for each category.
• Last week, the Team discussed separating safeguards to automatic and manual safeguards. The disclosing party must define and perform a balancing test. Because this is a law enforcement use case, the system must allow for some form of confidentiality while the investigation is ongoing. The manual section is new, which is why there are a lot of changes. Similar to the other use cases discussed, only data requested can be disclosed, and only new data (not historic data) can be disclosed. Please review the red-lined changes to see the specific changes in detail.
• The Team will now review the document section by section and consider this as a final reading of the case.
• EPDP Team Feedback:
• Comments on overarching purpose (a):
• The second half of the overarching purpose is extremely broad and capable of justifying anything. National security, in particular, provides a very broad application. 
• Support the language as is - broad purposes are good here until we receive legal advice. This is sufficiently encompassing and specific.
• Activities associated with certs may be lost - that activity would now fall under here. The primary issue with government certs, it is not sworn law enforcement. An example like this shows it is helpful to keep the language broad.
• Purpose makes sense. NCSG’s approach narrows the purpose too much. Propose keeping as is and seeking legal advice on it.
• There may be a government entity that investigates non-criminal activity.
• In reviewing the purpose, it was taken to a governmental DPO who agreed this purpose was OK. 
• Action: Chris to go back to DPO to answer and finetune the overarching purpose in light of today’s conversation and propose modifications accordingly. 
• This exercise is helpful to show potential groupings. Is it better to start with a narrow case and then expand to additional use cases, or vice versa? As we go through this exercise, it is important to consider how we go from this list to do the grouping as a practical exercise.
• It is difficult to review these use cases line by line when Team members are approaching the cases differently - some are requesting the purpose to be narrow, while others believe it should be broad. It will be difficult to go through the cases line by line until the Team agrees if the use case should be broad or narrowly focused. For this use case - the key is the action is outside the jurisdiction - this is a complicating factor and the Team needs to spend some time thinking about it. The victim may be in the jx of the LEA, requesting data from a controller who is outside this jx, and the data subject may also be in a different jx.
• The purpose of this exercise is not to finetune each use case to perfection, but rather to capture commonalities and see if they can be translated into policy recommendations. For example, with respect to the overarching purpose, that will be law enforcement requesting disclosure of data. In a policy recommendation, it is unlikely every specific situation can be taken up.
• With respect to the International Budapest Convention on Crime - it deals with trademark and copyright infringement, et. al. The use case here is not very broad because of everything the Budapest Convention covers. 
• Category b: 
• Why does this only refer to a secondary victim and not to identification of a criminal or the primary victim?
• The explanation in b does not seem to align with the overarching purpose.
• The concept of necessity seems lost here - why is the data from the contracted party necessary to achieve the purpose? This needs to be changed because it is not considering necessity in the correct way.
• With respect to necessity, it is not answered in the above-suggested way. 
• The primary victim is not identified b/c LEA would be conversing directly with the victim; would need the registration data for the secondary victim.
• The request needs to be justifiable and reasonable so that the data is reasonably necessary. Just because something is easy does not make it legal. Ease does not equal necessity. 
• Perhaps the question should be changed - why is disclosure reasonable and justifiably necessary or something similar?
• Ease is not the correct word as ease may equate to practicality. 
• Category c
• Under category c, it seems like it should allude to redacted data elements that are necessary.
• A reason why all of the data elements are included here is partly b/c it is preferable and practical to go to one source for the data.
• In this use case, would the LEA be requesting all data every time? 
• No, some cases may only need a subset of information.
• The requesting entity should not be requesting all of the data all of the time; it should be limited and specific.

• Category d - lawful basis:
• In this particular case, EU LEA access is asking for data from a controller outside the EU. In this instance, there is a different legal basis between the requestor and the requestee.
• No disagreement.
• Should the Team think of non-EU asking EU law enforcement, and vice versa?
• If a UK law enforcement was to ask another EU law enforcement, I would be acting under my own law enforcement, but it doesn’t make a different to an Irish law enforcement. The lawful basis of the Irish company would be 6(1)(f). Realistically, that would also work for non-EU requesting to EU.
• Can you investigate on behalf of a victim not in your jx? 
• That may be the case, but realistically, you need to ensure you have your own lawful basis in your country.
• Category e - supporting info to determine lawful basis
• No comments
• Category f - Safeguards to requestor
• Why is the first sub-bullet there?
• There may be an assumption that we are using protocol to make a request.
• This use case is not asking for all of the data the registry or registrar holds. If it were, it would likely be under a court order, and would definitely be outside of automation.
• Category g - Safeguards for entity disclosing the data
• The penultimate bullet - entity disclosing the data needs to perform a balancing test with the right to object and erase - we may need to flesh out how that will work. 
• The balancing test under 6(1)(f) is very hard to automate.
• The last bullet point - there may be instances where the entity cannot disclose, so this should not be a must.
• This is a topic the Team hasn’t delved into comprehensively - when the data subject has a right to know who is requesting their data and when the requests need to be held confidential. This topic needs to be fleshed out more.
• Do not see how a balancing test can be automated and very uncomfortable with this assumption.
• This use case has a particularity to deal with a balancing test for a 6(1)(f) legal basis. It is necessary to demonstrate safeguards for the balancing test. This is the first iteration of what GAC could come up with but do understand the concerns regarding the automation of the balancing test. The important issue here is that we need safeguards for the process of the balancing.
• This needs to be a policy consideration of how the balancing test can be applied ahead of time.
• One question that may need legal advice is to what extent the balancing test can rely on the trustworthiness of the requestor. The whole concept of automating these processes is through authentication/accreditation of users.
• Action: Alan Greenberg to draft proposed legal question regarding the trustworthiness of the requestor and send to Leon and Support Staff.
• Cannot assume that the balancing test needs to be manual in every instance - legal advice would be helpful. 
• Team Members should look at the case starting from g down and propose any questions in writing by Tuesday, 23 July.
• Start examination beginning with g to the next call. 
• Consider concerns / issues expressed on the mailing list prior to the meeting
• Preliminary agreement on use case
• Confirm next steps, if any

1.               Use case – first reading: Investigation of criminal activity where domain names are used.  Typical specific example: phishing attack (60 minutes)

• Introduction of use case (SSAC)
• Input from EPDP Team – questions, concerns, proposed modifications
• Confirm next steps

1.               Any other business (5 minutes)

o    Priority 2 small team meetings update

1. a)     Accuracy and WHOIS ARS (see https://docs.google.com/document/d/1pS9Pibanj-Hp6LztZpeERtxdoLsnp4y_-do0vU5VJuw/edit [docs.google.com])
2. b)     Input received on other priority 2 items from RrSG (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-June/002174.html)
3. c)     Leadership to recommend next steps via mailing list

o    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-drazek-21jun19-en.pdf [gnso.icann.org]). EPDP Team to provide input on the mailing list. Confirm deadline for input.   

1.               Wrap and confirm next EPDP Team meeting on Thursday 25 July at 14.00 UTC (5 minutes)

o    Confirm action items

o    Confirm questions for ICANN Org, if any