Dear EPDP Team, Please find the notes and action items from today’s face-to-face meeting below. To the volunteers who agreed to produce additional use cases, please use this updated use case template. Thank you, and to those of you traveling home from ICANN65, safe travels! Best regards, Marika, Berry, and Caitlin EPDP Team Meeting 2 of 2 ICANN65 27 June 2019 Action Items Based on feedback provided during today’s meeting, EPDP Support Staff to circulate updated use case template. Please use please use this updated use case template. (COMPLETED) EPDP Team Members who wish to submit additional use cases to submit use cases by Friday, 5 July. Georgios and Marc A. to work together to develop a first draft of policy questions to send to the Strawberry Team for the EPDP Team’s review. Georgios to review the safeguards for the registrant and provide guidance on where these safeguards may appropriately belong (requestor, entity disclosing nonpublic registration data, etc.). Recap of Tuesday, 25 June The Team reviewed Thomas’ draft use case for IP infringement. Support Staff updated the template to incorporate feedback received from the Team. EPDP Leadership requested other interested parties to submit additional use cases. Objectives for the Day Engage with ICANN org to understand ICANN org’s engagement with DPAs and the European Commission Review the updated trademark infringement use case Review the public safety use case Agree to additional use cases the Team may like to produce and examine Review timeline and project plan Engagement with ICANN org to discuss next steps in relation to outreach with DPAs This ICANN org team’s (the Strawberry Team) task is to present to the DPAs with a UAM based on the TSG model, for the purpose of testing its basic assumption and feasibility under the GDPR. EPDP Team Response This is a distraction from the EPDP Team’s work. We were informed that the TSG was a purely technical exercise. Now, we are being told this model is being taken to the DPAs. This has confirmed the fears this Team had regarding the TSG. It is not ICANN org or the TSG’s job to be developing policies - it is the ICANN community’s job. We are not talking about a UAM; we are talking about an SSAD. How does this independent and parallel work with DPAs inform the EPDP Team’s work? The TSG is a technical model and there are two parts to it. One is technical (the diagram); the other is legal, and that is the work that is underway by the EPDP Team. Having this technical consultation about whether this model could be feasible under GDPR does not substitute the EPDP Team’s work. If it is not feasible, then that will be as far as the TSG model will go. If it is feasible, it will inform the EPDP Team’s work. Will all of the communications ICANN org has been having with the DPAs be shared with the EPDP Team? It is crucial to test the basic question of whether this model is viable. There are several models that have been presented to this team - it is helpful to help visualize the implementation. The EPDP Team has been focusing on how to minimize liability and that will help us understand where the policy can go. This is timely and will inform the EPDP Team’s work. The TSG model has nothing to do with the policy the EPDP Team is developing. There is no evidence that this model will reduce the liability of the contracted party. There are no policy assumptions in this diagram - there are only implementation options. The fundamental question here is can such a system remove liability from the contracted parties? Unfortunately, the NCSG was not included in the TSG or the strawberry group. Most of the other stakeholders were involved in the TSG. While we have sympathy for the CPH, the NCSG’s main goal is not to move liability to some intermediate actor. This is a big policy issue we are discussing here, and it should be open to all stakeholders. We would like to come along to the meetings in Brussels, or we would like non-partisan advice from ICANN org so that we can go to Brussels and lobby for ourselves. The only way to do complex system design is to work in parallel; therefore, we support what the strawberry team is doing. The ICANN Bylaws provide that the GNSO develops gTLD policy. This is a purely ICANN org initiative, and it should not have been done in this way. What is the best way to move forward from here? Primary concern is the communication ICANN had with the Art. 29 working group - you could sense a frustration with these working bodies. ICANN did not come with solutions, only questions. It seems the same problem is occurring again. At this stage, it is premature to ask the EDPB’s advice before sorting out basic questions. This is not an ICANN org initiative - this is the ICANN Board requesting the CEO to see if the TSG model, which removes liability from the CPH, could be workable. With respect to the disclosure between ICANN and the DPAs, all communications have been disclosed. To suggest there have been communications not disclosed is incorrect. The strawberry team is more than willing to continue interacting with the EPDP Team. Updated Intellectual Property Use Case from Tuesday’s Discussion During Tuesday’s meeting, there was a lot of feedback and input with respect to the safeguards section. The updated document breaks out the safeguards by whom the safeguards apply (the requestor, the entity disclosing the data, the registered name holder, the access/disclosure system). The language within the categories is very similar to Thomas’ language and the language discussed during the session With respect to the accreditation of user groups, we have added language with respect to a code of conduct. As the title of the case changed, there may be further changes needed. For example, the section of data elements typically necessary should likely have a bulleted list of data elements. The lawful basis section also has quite a bit of text within it - is this text still required? Additionally, this section has been updated to note this is the liability of the entity disclosing the data. Proposed approach: take the suggestions made today and have support staff review edit the document rather than wordsmithing in this section. EPDP Team Feedback: · Use Case: · Requesting data was changed to processing data - proposal to change back to requesting as the processing occurs after the data is requested, and this use case involves the request. · Subsection A · Service providers should be added here, as agents may not fully capture this idea. · Concept of service providers is too broad; agent is more legally defined. · Perhaps brand protection service provider could be used for greater specificity. · Perhaps define the term agents to include brand protection service providers. · Proposal to add footnote, noting that brand protection service providers are included in this category. · Subsection B · Change “requested” to “needed” · Trademark infringement is the use case - this seems to only apply to cybersquatting, or is this broader? · B should be changed to match the title · Subsection C · Precise formulation of data elements should replace the text in the box · The labelling of C “maximum data fields to be disclosed in this use case” to make it more clear · Email address, telephone number, and fax should be added to this list currently in the field. · All contact fields should be added here to give some assurance that you can make contact. · Necessity of disclosure of specific elements needs to be considered. · Registration data was defined in the Phase 1 Final Report - given that it is a defined term, this should be consistent. Additionally, registrant and RNH need to be made consistent. · Postal address should be changed to reflect the relevant data fields, street address, city, etc. · The more the use case is broadened, the harder it is to pin down the data fields necessary - this will make it hard for the automation of responses. · It would be helpful to document the rationale of the necessary data elements for the sake of implementation and drafting the policy. · The requestor would provide the rationale as to why that data element should be disclosed. · All fields will not be disclosed systematically - the requestor would specify which information it would like disclosed and provide a rationale as to why · Subsection D · 6(1)(f) is a valid legal basis for this particular use case, which specifies trademark owners. There may, however, be cases with criminal investigations by law enforcement, which may involve a different legal basis. Is a separate use case needed for this? · There may be multiple legal bases that apply here. 6(1)(f) is not incorrect here; it may just be incomplete · Who will be doing the balancing test here? Does this mean the balancing test is always in favor of the trademark holder? · Assuming that 6(1)(f) is the lawful basis, who is to perform the balancing test? · What other legal bases could be involved here? It doesn’t seem it could fall outside 6(1)(f). · Discussing the lawful basis of the requestor, that would likely need to be included in another subsection. · Subsection E · If a requestor has a need to obtain information on multiple domain names, it seems foolish to force the requestor and the CP process each request individually. · Bulk access could be elaborated to include section 3.3.1 of the RAA · RDAP is set up in a way that you can only request one domain name at a time. · Items 2 - 4 may not be applicable to the requestor - this seems to be general systems on the system rather than burdens or safeguards to the requestor · Even though RDAP provides one response at a time, the system could gather the responses together · With respect to e5, what is meant by auditing - who will be doing the auditing, and for what purpose? · The point is there will be auditing of the requesting and use of the data, but how the auditing will be done is not appropriate for this template. · With respect to 3, each individual release of data related to a particular domain name needs to be reviewed. This means there are no shortcuts. · With respect to 3, no bulk access should be deleted. · Some of the items mentioned here are not necessarily safeguards for the requestor. · Opposed to deleting the parenthetical in e3 regarding bulk access · E4: there are ways to direct requests automatically - it’s not up to the requestor to figure out where to send the request - the technology generally points the user in the right direction. · The point of this exercise is to identify use cases where there could be automated responses, which is consistent with the EC letter · Automating is subject to applicable law. · Legal decisions need to be made individually for each request. · Subsection F · Should not end up in a situation where legitimate requests are being rejected because they are deemed abusive. · F2: this is vague and would likely be a feature of the system not a safeguard of the entity disclosing the nonpublic registration data. Entities may not always disclose data if there is no data or if it’s not legal. · Fishing expeditions should not be allowed by the system. · We don’t want to unnecessarily block legitimate requests. · If ICANN compliance is going to be auditing the CP’s use of the system, we may need to put markers down to add additional safeguards so that CPs can respond to audit requests. · Clarity on rate-limiting is necessary here b/c companies like MarkMonitor will be submitting a lot of requests. · CPs need to be able to protect their systems. · Subsection G · G3: “decision significantly affecting them” needs to be further defined · G seems to mix of items. Would it be possible to define the policy requirements for the data subject? · Many of the concepts here are a part of GDPR, so it may be redundant since this is already the law. · Art. 25 is relevant here - we need to do privacy by default. · It may be good to use these concepts as an opportunity to show the team’s work (G1, 2, 4, 5) 3 seems inapplicable here b/c it seems relevant for a bank loan. · Who is going to apply the safeguards? It may be wiser to note who is going to provide these safeguards (the requestor, the entity providing data, etc.) There may be a need for the further working out of these safeguards. · Action: Georgios to specify where the items in g below - is it the system, the requestor, or the entity disclosing the data? · These should be closely mapped to the system requirements, but they should not be deleted. · There should be a clause that says measures will be taken to safeguard the data subject. · Is there a parallel risk assessment activity going on as we are doing this? · ICANN org is not conducting a shadow DPIA while this is being conducted. · Re: parallel processes being OK for the TSG. One of those parallel processes should be a parallel risk assessment - perhaps this could be done by John Crain’s team. · It may be helpful to wait until we are further down the road to assess the risks - at this point, we are not sure who will be running this system, so this discussion seems premature. · Subsection H: Safeguards applicable to the access/disclosure system · Alex to provide further feedback to review the updates. · Subsection I · Perhaps change the wording to eligibility criteria for those requesting accreditation · Code of Conduct may be more appropriately placed under safeguards by requestor · What is the group thinking of when it refers to evidence of ownership of IP rights? · What does the group mean by accreditation - what does accreditation actually do for the requestor? · A code of conduct has not been done before - if this will be a prerequisite to the system, this will be difficult to agree to - perhaps it would be better to call it a data processing agreement rather than a code of conduct. · Need to be very clear on what accreditation actually means and what it gets you. The Team should first define what is meant by this concept before saying if it’s needed or not. · Do not want to limit how IP rights are to be evidenced - for example, there are common law trademarks. · Request to delete 2 “only issue disclosure requests with respect to the trademark(s) where ownership is evidenced” · Team needs to consider accreditation at a high level. Modalities of accreditation can vary largely. · Action: Support staff to capture the discussion and send an updated version to the Team for review. This case will be parked for now, and the Team can return to any individual case as needed in the future. LEA Use Case The diagram on the screen informs the thinking.

From left to right, the request will come in. The request itself will have to have its own legal basis. For any form of authorization, you must confirm the information the requestor has - purpose record, data elements Response: if everything else has already been confirmed, the response should be very easy. For each three points in the process, there has to be a legal basis. There has to be transparency and accountability across all of these aspects. Second diagram: where does the responsibility lie for the different aspects? If all items are under authorizing entity, they are operationally responsible for those sections - the contracted parties have the organizational responsibility for providing data elements It’s unlikely you can fully remove liabilities from the CPH.

EPDP Team feedback on diagrams: In addition to providing data elements, Rr/Ry has to review the request and make a determination This diagram is not exhaustive and where the bullets fit is a discussion the EPDP team will eventually get to. Is this diagram dependent on the model the team will eventually adopt? Liability as a whole cannot be escaped by contracted parties, but it could be nuanced it. They have legal liability on the provision and transfer of data. However, in an SSAD, a separate entity could disclose the data. LEA Use Case Template Use case - for example UK LEA requesting data from an Irish DPA User group: criminal law enforcement/national or public security Lawful basis - this will be down to local law - it will be 6(1)(f) b/c LEA is outside of the jurisdiction from which it is requesting data Got rid of three sections of safeguards - the data subject rights should be embedded in the requestor and the disclosing agent. The responsible parties are the disclosing entity, the requestor. This needs more work. Data elements typically necessary - all fields in RDS are required (per the Team’s earlier conversation, these fields should be listed) Accreditation of user - very similar to last section EPDP Team Feedback - General Comments What does secondary victim mean? Also, need a better understanding of the mapping of data elements to the secondary victim. In accreditation, trademark ownership is referenced, but that appears to be an improper copy/paste. The primary victim is the victim of the crime, such as the person who has been attacked. If there is a domain name in relation to the crime, we don’t know if the domain holder is involved in the crime, or a secondary victim - in that someone has maliciously used their domain name. Where are the data subject safeguards in this example? Since the data subject could be the subject of the investigation, could there possibly be a conflict? This is in g, but this example was drafted prior to this morning’s discussion Is it helpful to think of the overarching purpose for the use cases? Overarching purpose is extremely broad and could be broken out into five or six use cases. It’s not clear how this is useful in this context. This is useful, and this will likely need to be developed for the other templates. Chair’s suggestion: Taking into account the time left in this session, it is probably not practical to go through a detailed review of this template. Let’s now discuss additional use cases. IP will be providing additional cases; SSAC will provide three additional cases; BC would like to provide one use case; GAC to provide additional use case. It would be useful to highlight differences in the templates. SSAC has security research (correlate data); operational security is a different use case; reputation service providers are a third use case. The template has been expanded, so those who would like to provide updated use cases, it would be helpful to provide the additional data fields - for example, how long can the requestor retain the data. Action item: Staff will send out the master template to those who have volunteered to draft additional use cases. The retention period may not be within the remit of this group. It would be up to the requestor. Would authors of the cases be able to submit the use cases by the end of next week? Deadline for submission of all use cases is Friday, 5 July. There will be no meetings next week. Proposal: the only way to get through all of the use cases in a timely manner is to delegate responsibilities to sub-teams, ideally three sub-teams. Each sub-team would review three cases by the end of July/mid-August. That will allow time for Support Staff to synthesize commonalities in advance of the face-to-face meeting in September. It may be helpful to review the purposes provided earlier in Phase 2 to make sure no groups are excluded. EPDP Feedback: For three sub-teams, some groups participating only have two representatives and that would be unfair. Perhaps alternates could be tapped for this exercise. We have to also consider the time needed for Priority 2 items, and we are entering into the summer holidays. The use cases are not the end goal, so we need to review what the end goal of the use cases is. The use case is a tool to eventually synthesize and extract trends. The aim would be to have to initial policy document in September. To the extent the groups can slide in and out and observers can attend, then this proposal is OK. Call the teams 1, 2, and 3. If one member wants to be one week in 1 and then 3 the following week - that is fine. The important point is that we have representative discussions. The outcome of these groups is not binding on anyone. If this team does not demonstrate substantial progress by the end of the year, legislators will start making decisions for us. Accordingly, please support this timeline. Collective drafting generally fails. Support staff will be responsible for distilling commonalities and providing a first draft. The Team can then begin commenting/editing/redrafting the document from there. With respect to allowing observers to participate, as there are 190 observers, that may cause difficulties. Additionally, it may not be possible to have simultaneous audio-casting for calls run at the same time. Project Plan The project plan documents we will now review are a work in progress and do not constitute the formal project plan. The second page is a result of the PDP 3.0/result of strategic planning session. The status and condition components in the right quadrant are important to track - if these become yellow (behind schedule), this will have to be discussed with the GNSO Council. The Gantt chart will be based on tasks as opposed to the calendar. Once tasks or action items are identified, it will show what the task is, who it was assigned to, when it is due, and what the consequences are of not completing tasks on time. The fact sheet should be similar to Phase 2. EPDP Team feedback: In Phase 1, the Team ran out of time to get input from DPAs. This was a missed opportunity in Phase 1, and the Team should take this into account in Phase 2. With respect to outside legal counsel, some of the advice came back after the Final Report was submitted. Will these be factored into the timeline? (answer: yes) With respect to the representative legal committee, the Team would need to consider a moderator. As the Chair is not an attorney, Janis would prefer not to moderate this group. However, the Chair has asked Leon Sanchez, the board liaison, to moderate this group. Is this acceptable to the Team? No objections were noted. Based on the Strawberry group’s presentation, it is not clear the group is aligned on how to proceed here. Marc Anderson and Georgios to propose a few bullets of potential policy questions to the DPAs, it could be circulated to the list for discussion. With respect to the F2F meeting in September, the meeting will begin on Monday morning, so all participants should plan to arrive on Sunday evening. Please do not plan your departure before the end of the meeting.