Dear EPDP Team,Please find the notes and action items from today’s EPDP meeting below.As a reminder, there will be an optional meeting for those wishing to review the project plan in detail on Tuesday, 13 August at 14:00 UTC.Best regards,Marika, Berry, and Caitlin--EPDP Phase 2 - Meeting #12Thursday, 8 August 2019 at 14.00 UTCAction Items Action: EPDP Team to review Priority 2 Next Steps table for final review and comment by Thursday, 15 August. Action: Greg and SSAC Team to propose edits to the use case based on comments received today as well as outstanding comments received this week and next week on the Google Doc. Following the fine-tuning of the document, a final reading will occur at a later meeting. Action: Hadia and ALAC Team to propose edits to the use case based on comments received today as well as outstanding comments received this week and next week on the Google Doc. Following the fine-tuning of the document, a final reading will occur at a later meeting. Notes EPDP Phase 2 - Meeting #12Thursday, 8 August 2019 at 14.00 UTCThese 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. Roll Call & SOI Updates (5 minutes) Confirmation of agenda (Chair) No objections to the agenda. 3. Welcome and housekeeping issues (Chair) (10 minutes) a. Early input review – reminder to review. To be added to the agenda for next week’s meeting. Per a previous suggestion, the Team will discuss early input received from other groups at the next meeting. Are groups prepared to discuss this next week? No objections from the Team; therefore, the Leadership Team will add early input discussion to the agenda next week. b. Experts for lunch time presentations during F2F meeting Mark Sv. proposed a presentation by the Microsoft cybercrime unit. A proposal was received to have the presentation during lunch at the F2F, but this was objected to by multiple team members. Would Team members agree to a webinar presentation on this topic? As there were no objections, EPDP Leadership will coordinate with Microsoft to schedule a webinar presentation. c. Priority 2 small team meetings update Accuracy and WHOIS ARS (see https://docs.google.com/document/d/1pS9Pibanj-Hp6LztZpeERtxdoLsnp4y_-do0vU5V... [docs.google.com]) 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. Action: EPDP Staff Support to send the Priority 2 materials to the Team for review today. EPDP to send comments and proposed edits (if any) by Thursday, 15 August. d. Update from Legal Committee Legal Team has been reviewing questions related to SSAD (EPDP Team Priority 1 work). Legal Team has approved one question for final sign-off by the EPDP Team. Pending no objections, this question will be forwarded to Bird & Bird. The next call will be Tuesday, 20 August, and the Team will continue to discuss outstanding questions. Will the Team be sending questions in batches or as they individually come in? The LC will discuss this question at its next meeting. 4. Use case – second / final reading: Investigation of criminal activity where domain names are used. Typical specific example: phishing attack (45 minutes)a. Overview of updated version in which EPDP Team input has been considered and addressed (Greg Aaron) In this use case, it is mainly 6(1)(f) legal basis, but there may be other legal bases that are relevant in other use cases, which is why other legal bases are included. In terms of the accuracy of contact data, one thing to consider is that registrants have the contractual obligation to provide accurate contact information. However, it is common to see domain names registered to streets that do not exist or vacant lots. When reporting an issue to a registrar, a requester needs to report the specifics of the problem and substantiate it. The SSAC felt obligated to put information into the safeguards section, noting that safeguards will likely come later in the working group discussions. SSAC would like to go through a real-life use case to illustrate these principles: This is an example of a phishing URL that came to an SSAC rep during ICANN65. There are other phishing URLs on that domain name - one targeting GA Tech and one targeting Microsoft users Based on the WHOIS information for this domain name and what we can tell from it - it’s registered at OVH, the creation date on the name is about one week before the phishing took place. This is not determinative. There is no contact information for the name, but there is a country code associated with it - DZ - for Algeria. Again, this is not determinative, but not many gTLD names are registered in Algeria. By looking at DNS records, you can see what other names are hosted at this IP address. In this example, there are other similar-looking names to the name the phish came from. It’s helpful to know what other domain names the phishers have registered - without the contact information, this is hard to tell. In this example, there was phishing on the set of domain names before and after this Georgia Tech phish. In this particular case, contact information/attribution would have been very useful for reporting and preventing additional harm. GDPR Recital 49 provides looking at information for this purpose is legitimate. b. Feedback from EPDP Team This example demonstrates that just b/c a requester asks for contact data does not mean it hasn’t tried other avenues before. NCSG provided comments on the document yesterday - what would be the preferred way of handling the concerns noted in the document? It may be helpful for SSAC to respond in the Google Doc. Law enforcement’s job is to provide attribution and this work is regulated by criminal procedure. Law enforcement has a framework of accountability for dealing with this, while private companies do not. Attribution by researchers and security professionals is important in many instances. Attribution is not only for law enforcement - it is often done by private parties. No one is challenging the concept that more data points allow for a more comprehensive investigation of harm. Can pseudonymized data be used for this? Unlike law enforcement, there are no credentials to check that the security organization is who they say they are. Registrars need to mitigate potential harms of over-blocking names or releasing too much information. Pseudonymized data is an interesting topic, but it does pose challenges that could be discussed at a later time. With respect to this example, major providers of access have phishing issues at large scale/high volume. This is not something that can be solved by LEA only. Attribution is important because when so many domain names are involved, attribution will show you where to focus your resources and who to go after. As this team creates the WHOIS policy, the team should not prohibit accredited cyber security professionals from getting high volume, quick access to data to prevent harm. This example looks like a civil case, not a criminal case. Many of these cases do start with private investigators since LEA may not have the resources. The questions posed highlight why a webinar from Microsoft may be helpful. Pseudonymization may be helpful in some cases, but not all cases. In terms of attribution to individuals vs. states, the attribution was to a criminal gang, not a state actor. Microsoft got a court order to investigate as they found the domain names - the judge gave them the approval on an ongoing basis. This could be a civil or criminal issue. Phishing is a criminal activity, but could also be pursued by a private party. What a law enforcement agency would like to see is some scale of impact to a number of victims, LEA would have more to go on. Pseudonymization could apply in this case, but you could perhaps look at if the data is fake/compromised host. This Team needs to make sure the policy is within the law. The initial search may be a 6(1)(f), but the court may provide the ability to data under a different legal basis. If looking to Section B to all tasks performed, is there any violent opposition to these tasks? No objection. Section C - data elements - not all data elements would be required on a systematic basis. Any objections? No comments. Section D: no comments. Section E: have a problem with 6(1)(d). Before you get to a threat to life situation, you are likely acting on another legal basis before. For this final reading, NCSG’s comments were not addressed and cannot do the final review without the comments being addressed. Final reading will occur later. Legal basis may need further revision once advice has been provided by Bird & Bird. This use case about private actors doing investigations is slipping over into law enforcement. It would be helpful to keep these distinct. Do not agree with 6(1)(c) being applicable in this use case. 6(1)(f) is likely the only applicable lawful basis in this use case. Response: SSAC will take these comments into consideration. There are various legal obligations in place. Section F: How do we interpret safeguards for disclosing entities? The safeguards should protect the data subject. In this use case specifically, the safeguards facilitate disclosure. These safeguards represent the input to build the Team’s understanding of the action of the requester and the actions of the requestee. Section N: This is a core legal question that needs to be answered, and it will be helpful to defer to Bird & Bird on this. Legal analysis should provide this answer, so this text should not be asserted - it should be qualified c. Confirm next steps Action: Greg and SSAC Team to work in response to comments on the Google Doc. Following the fine-tuning of the document, a final reading can occur at a later meeting. 5. Use case – first reading continued: Online buyers identifying and validating the source or services/ Internet users validating the legitimacy of an email or a website to protect themselves (45 minutes)a. Continue introduction of use case (ALAC) The issue of legal vs. natural persons is an issue this team needs to come back to. The use case presumes that there is no change to the legal vs. natural policy recommendation. There is no question that a data requester that is not identifiable Section E: lawful basis 6(1)(f) - it’s important to note that this is to prevent fraud, so it happens before the fraud occurs. Actual case - credit card has not been deducted for an airline ticket purchased online. The purchaser receives an email asking for a copy of the ID. A purchaser may provide the information or not - if not, the purchaser may seek information access to information to see who is behind the website. For this use case, no accreditation or automation is sought, but ALAC does believe a means for a consumer to verify its activity is necessary. b. Input from EPDP Team – questions, concerns, proposed modifications Generally, the use case described is consumer trust, consumer confidence and/or verifying the integrity of a website. This is out of scope for this team - this use case represents websites, but RDS does not link contact information to websites; it links to domain names. There is not a one-to-one relationship between websites and domain names. This is not a case where RDS is a useful tool; SSL, BBB, or Yelp could be better tools in this case. There are two types of individuals that would be engaged in this - curious users would not have access to personal information, or groups that have legal authority to pursue this. Curious users does not rise to the level of a legitimate use case, and therefore this use case is redundant and unnecessary. It is profoundly irresponsible for ICANN to attempt to step in here for what goes on with a domain name after it is allocated. To encourage consumers to look to the WHOIS directory or WHOIS data to determine the reliability of a website when the ecosystem is so multilayered is irresponsible. In this use case, there are a variety of ways to determine the integrity of a website. Under GDPR, necessity is the key, and this case does not demonstrate necessity. It should therefore be deleted. The ICANN bylaws are not as restrictive as some Team members have noted. Perhaps this could be limited to legal persons. When a registrar is receiving a request, the registrar can look at the info to determine if it is a natural or legal person. There is an ability to do the balancing test when it is a commercial website, so the use case should be kept. Skeptical of this use case where it applies to curious users - it’s really only applicable when there is a reputation service going on. The ICANN bylaws note that during a policy making process, we do have to consider the global public interest - what is useful for the public. There is a division of thought as to what that involves, but it is different than public policy. Looking at this use case is a legitimate thing to do. GDPR does not protect legal persons. If the team resolves the legal/natural distinction differently, this use case would not be applicable. The contracted party may look at the use case and decide whether to grant access. A registrar claims it would never grant access based on this, but that may be incorrect. There may be cases where the controller determines this is a reasonable request. c. Confirm next steps Action: Hadia and ALAC Team to respond to comments received today as well as outstanding comments received this and next week on the Google Doc. Following the finetuning of the document, a final reading will occur at a later meeting 6. Any other business (5 minutes)7. Wrap and confirm next EPDP Team meeting:a. For those interested, an additional meeting will be held on Tuesday 13 August at 14.00 UTC – presentation of leadership-proposed EPDP work plan for submissions to GNSO Council Tomorrow morning, EPDP Support Staff will distribute the project management package. b. Next plenary meeting will be held Thursday 15 August 2019 at 14.00 UTC c. Confirm action itemsd. Confirm questions for ICANN Org, if any