Dear EPDP Team, Please find notes and action items from today’s call below. As a reminder, the next plenary call will be Thursday, 13 June at 14:00UTC. Best regards, Marika, Berry, and Caitlin -- ACTION ITEMS Support Staff to update the working definitions based on input received from the EPDP Team. Each group to nominate one person for the representative legal committee and provide the nomination to the Chair in advance of the next meeting, Wednesday, 12 June. Within 2-3 hours after the call, Support Staff to work with the EPDP Chair to produce a one page synthesis of concerns and questions the Team wishes to provide to the Council regarding the Board resolution. Annex all submissions to that synthesis page. Post synthesis page for silent procedure until tomorrow (Friday, 6 June). EPDP Team to only react if there is violent disagreement with concept (not edits, etc.) Team to review the Priority 1 SSAD Worksheet by COB tomorrow, Friday, June 7. Staff will then edit the document based on the suggestions and provide it to the Team by Tuesday, June 11. Support Staff will organize a list of purposes from previous documentation (https://www.icann.org/en/system/files/files/gdpr-dataflow-matrix-responses-r...) and post for Team members to suggest edits by Tuesday, 11 June. Notes & Action items 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. 1.Roll Call & SOI Updates (5 minutes) Alternate from NCSG and RrSG 2. Confirmation of agenda (Chair) No objection 3. Welcome and housekeeping issues (Chair) (10 minutes) SG/C/SO/AC input requests have been sent – deadline for input 21 June · No comment Working definitions · Input received on “access” and “legitimate interest”. There is no agreement on the “access” definition. Text on “legitimate interest” has been modified based on proposed edits. · Replace “full set and subset of the data set” with “provision of a dataset appropriate for the purpose” or “provision of a dataset necessary to achieve the purpose”. · Second bullet, 3rd party access, definition is dependent on GDPR but policy is meant to be global policy, replace “GDPR” with “applicable law”. · SSAD bullet point: ICANN is not a third party, suggest “third party plus ICANN” · These are not agreed text by the whole group yet, but incorporate the input as part of the exercise. · ACTION ITEM: Staff to update the working definitions based on input received from the EPDP Team Legal advisory group · The Chair proposed to create a subset of the team -- a small team, but not with a representative model -- to make a first cut of legal issues, review the issues, and discuss them with the Team. Every legal question will be dealt in the small team, staff and leadership will propose background document for the consideration of the group. · Important that the questions are delivered to the legal counsel with no censoring on the questions, and get responses from the legal counsel fast. Don’t lose time on the formality or how this small team would not work out. · The task for the small team is to formulate the right questions, filtering out the questions that legal advice has already been provided. · The small team should be balanced and all interest should be represented. It should be clear that the team cannot be dominated by certain interests. · Why can't we revert to the format and category composition used by the "legal committee" in phase 1? (New members where previous members are not participating in Phase 2.) The Phase 1 legal committee seemed to function okay. · It seems premature to abandon the sub team concept. Support continuing the legal group as a sub group. · Based on the input from the team. Chair withdrew his proposal. · ACTION ITEM: Each group nominates one person for the representative legal committee, and lets the chair know the nominee by the next meeting. 4. Review of clarifying questions, concerns and/or background information submitted in relation to GNSO Council -Board consultation in relation to Board action on Phase 1 recommendations - see https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b[icann.org] (Chair) (15 minutes) a. Overview of clarifying questions, concerns and/or background information put forward · RrSG: · Rec 12, significant background info has been provided, propose to focus on the solution. Can add a similar requirement as the one in Rec 29 for Rec 12. It is important to have a blank organization field. If the presence of data in the Org field indicates that the domain is owned by a legal person, then natural persons must be able to keep the field blank. If we cannot delete the Org field contents, how would we make the field blank for this user? · Redaction is not necessarily sufficient for data minimization principles, it is still a processing activity for which we may not have a legal basis. · RySG · Feedback is similar to the registrars. Rec 3 and Rec 18 were adopted by the Board. · Organization field, some concerns about implementation, unintended consequences. If incorrect data cannot be deleted, it would be troublesome. Should provide more info to the Council and Board why the recommendation is made it was. RrSG’s suggestion about deleting data is practical and can be implemented. RySG supports RrSG’s suggestion. · ALAC: · Board has issue with “deleting” the field. The option is to continue redacting the field, unless the registrant has been silent. · BC: · Rec 1, purpose 2, we agree that the Board question but disagree with how to address it. See email from Margie’s email. Separate the purposes, one for ICANN purpose and one for third party purpose. EPDP Team should come up with a revised version of purpose. · Rec 12 part of the concern is the inaccuracy of the org field. That is related to inaccurate records but not general concept of the org field. The rec be modified to allow the contracted parties to update any inaccuracies. · NCSG: · Rec 1, Purpose 2: the proposed second part of purpose 2 Margie propose was considered and soundly rejected during Phase 1. The only reason of getting consensus is rejecting idea. Issue should not be relitigated, and it did not address the Board comments. · EC advice is that purpose 2 is not needed. If including this purpose, it is inflating the ICANN purpose with the third party purpose. · IPC: · Not sure how to address EC’s comments, not to inflate ICANN purpose and third party purpose. · ISPCP · Should focus on working on phase 2 and not try to fix to purpose 2 now without legal counsel responses yet. · The data field can be deleted, otherwise it would potentially cause troubles to the legal party involved. · If the new policy is not to have an org field as it is not required, then the data has to be deleted if the user incorrectly populates the field with data that is the only piece of data to identify the registrant. · The org field is optional and therefore it must not contain data that is the only data with which the registrant can be identified. . b. Discuss which of these have support of EPDP Team to be submitted to GNSO Council c. Confirm next steps · ACTION ITEM: Within 2-3 hours after the call, Staff to work with the EPDP Chair to produce an one pager synthesis of concerns and questions the team wishes to provide to the Council regarding the GNSO-Board resolution. Annex all submissions to that synthesis page. Post synthesis page for silent procedure until tomorrow. EPDP Team to only react if there is violent disagreement with concept (not edits, etc.) · Now the EPDP Team should focus on clarifying questions, concerns and comments, then the Team can focus on what to do next. The document should separate out the explanatory background and the clarifying questions, from what should happen and how should the Council deal with these questions. · Leave the window open for feedback and commentary to the GNSO Council. Submit the feedback by Friday. The more information we send to the GNSO Council the better. Clearly there is divergence. Prefer Janis’ initial suggestion. 5. SSAD Priority 1 worksheet (15 minutes) (Marika) a. Overview of input received – see https://docs.google.com/document/d/1uoolznpxb0JxddFZA5n9ueRkB4tjDOQQCoMeQWpb... [docs.google.com] · Thank you to all Members who provided feedback thus far. · Following the call, Support Staff would apply the non-controversial changes in redline format. Staff would not apply to the substantive changes, but rather, flag those for future discussion. · Action: Team to review the Priority 1 Worksheet by COB tomorrow, Friday, June 7. Staff will then edit the document based on the suggestion. b. Further comments / questions c. Confirm next steps for finalization of priority 1 worksheet · Action: Team to review the Priority 1 Worksheet by COB tomorrow, Friday, June 7. Staff will then edit the document based on the suggestion. 6. SSAD – Topic c Topic: Define user groups, criteria and purposes / lawful basis per user group (Marika) (60 minutes) a. Review template developed by staff support team (see attached) · Support Staff aimed to kick off the conversation with the user groups and looked at various documents that touched on this topic, and from that review, came up with this document. · The document is a starting point for the Team to begin its deliberations. · After the Team has broad agreement on the user groups, the Team will look at data elements for the purposes identified. b. EPDP Team input · Starting from groups may not be the correct approach; it may be preferable to look at the purposes and then look at the users. · If the Team is looking at which data elements to apply to which requestor, what will happen if there is a new requestor group after the Final Report is delivered? This does not seem like a practical way to go forward. · This approach is backwards, and the categories are bizarre. The RDS Working Group started from the idea of user groups and use cases instead of purposes - this amounted to a lot of wasted time. Confused by the group “end users” - why is this a category? The Team needs to set aside the user groups until we discuss the purposes that require disclosure. · The document is a good attempt at trying to structure the conversation. Having these documents and clearly articulating that it is for discussion purposes is good - this is document is not binding. · There are two challenges related to this document - it is common to start with user groups and profiles to build an engineering group. The failure of the previous PDP may be because they were not trying to design anything. It is also equally valid to look at the purposes. Within the document itself, we may be conflating the lawful bases and the use cases with the ultimate implementation of the system. · The group needs to stop looking at defining the purposes of user groups. If we look under 6(1)(f), it is not about the legitimate purpose or business group, it is the legitimate purpose based on the data the group is seeking. The registrant is the data subject - therefore, they do not need a legal basis. · If the Team starts with the concept that we are building a UAM, then you are building a system to provide access. However, what the Team is doing is trying to implement GDPR in a series of procedures, processes, and management practices. If you approach it from a user group, it will vary on a case-by-case basis. Who is requesting third party disclosure - someone has to authenticate the third party, someone has to parse the request and determine if there is a legitimate interest, and then someone has to figure out how to provide the data and make sure nothing goes awry. · The Team needs to bake in the registrant user group so that registrants can access data that is being processed about them. Unsure if registrants are guaranteed access to data in the registrar portal. · When a large online system is designed, it has to understand who will be doing what and what will be done within the system. It is true that if you define a large aggregate user group and then haphazardly sprinkle in interests that they have, there are problems. Since we have this document, introducing greater granularity is OK, but either method is acceptable. · What the Team should be careful of is not to conflate purposes and users. The definition of law enforcement needs to be refined. · A data subject can go to any controller and ask a question. The controller has a legal obligation to respond to the data subject. · There seems to be a presumption in some interventions that everyone in the same category gets the same data. That is not the case. This is just a way to start the discussion. · The Team should start with purposes. This document should not start with user groups; it should start with purposes. c. Confirm next steps · Proposal to take one user group - there is an identified purpose and a basis. Would 6(1)(e) and 6(1)(f) be the appropriate basis for law enforcement to request information? · No. The purposes for requesting data for law enforcement is on the local law that gives them the right to access the data. If we look to the GDPR, we are looking at the wrong place. · Law enforcement are not able to use 6(1)(f) within the EU. · It is not for this Team to decide on a third party’s legal basis. · This Team is supposed to be developing a global policy. If we are creating a global policy, we should create user groups that are jurisdictional in nature, i.e., law enforcement in the jurisdiction of the registrant/Rr/Ry. Accordingly, the distinction b/w EU law enforcement and non-EU law enforcement makes no sense here. · The Team has a lot of work to do here - the investment now will cut down on the 6(1)(f) requests down the road. · The Team should be making use of the wisdom of the groups implicated in this chart - ask law enforcement to provide their lawful basis and what they need. · Action item: All members to put down purposes they believe are relevant, then we will identify who will be the requestor. · A lot of this work has already been done in the calzone model - the group should consider what of this could be used rather than reinventing the wheel. Please see: https://www.icann.org/en/system/files/files/gdpr-dataflow-matrix-responses-r... · Support Staff can put the previous list of purposes into a Google Doc and Team Members can add to it. We can then take the list of purposes and match it to the requestors. 7. Any other business a. Priority 2 small team meetings update · The updated worksheets for PPSAI and Legal vs. Natural have been updated and will be posted to the list after this call. · Following the already-scheduled meetings, we will endeavor to schedule meetings only on Tuesdays and Thursdays going forward. b. Reminder - Call schedule remaining priority 2 worksheets Wednesday, 12 June - 20:00 – 21.30 UTC City field redaction Data Retention Monday 17 June – 13:00 – 14:30 UTC Potential OCTO Purpose Feasibility of unique contacts to have a uniform anonymized email address TBC (post ICANN65) Accuracy and WHOIS ARS 8. Wrap and confirm next meeting to be scheduled for Thursday, 13 June at 14.00 UTC (5 minutes) a. Confirm action items b. Confirm questions for ICANN Org, if any