Dear EPDP Team: Please find notes and action items from today’s EPDP Team meeting below. As a reminder, the next EPDP Team meeting will be Tuesday, 24 September at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #19 Thursday, 19 September 2019 at 14:00 UTC Action Items Support Staff to update Building Block A (criteria/content of requests), following the feedback from today’s conversation. Support Staff to update Building Block E (retention/destruction of data), following the feedback from today’s conversation. With respect to where the disclosure decision is made, EPDP Team members who have not yet contributed to the table - please do so in advance of the next Team meeting by Monday, 23 September. Registrar Team members to consider the feedback today and reconsider the position noted in the table, if possible. 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 #19 Proposed Agenda Thursday, 19 September 2019 at 14:00 UTC 1. Roll Call & SOI Updates (5 minutes) · Attendance will be taken from Zoom · Remember to mute your microphones upon entry to Zoom. · 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) · Agenda was changed due to EPDP Team members not completing their homework · Request adding an update to .it bulk access · Request to discuss ICANN’s questions with DPAs · No objections to the agenda 3. Welcome and housekeeping issues (Chair) (5 minutes) i. Legal committee update · The Legal Committee met again on Tuesday and continued to review pending questions, noting that some questions may no longer be necessary due to the advice received from Bird & Bird. The Team is still undergoing this vetting exercise; after this additional analysis, there may be new questions sent in a second batch. · When can the plenary team expect to see the questions? When the questions become available (possibly as early as Tuesday, 1 October), the questions will be sent to the plenary for its sign-off. · Did the LC consider the four memos and see if there are any highlights or key takeaways that they wanted to highlight for the plenary? The LC has not done this, but this is a pending item for the LC. F2F Action Item Recap: Alex Deacon, Milton Mueller and other willing volunteers to draft a write-up of a potential accreditation model, taking into account the Team’s F2F discussions, in advance of the Thursday, 19 September meeting. (This will move to next week’s agenda.) IPC, BC, SSAC, and GAC reps to separately draft a vision for their “ideal accreditation model” in order to assist the group with what the baseline accreditation requirements could be as well as the attendant benefits of accreditation within the architecture of an SSAD by Wednesday, September 18. EPDP Members to contribute feedback to the staff-distributed Google table which includes a column for each lawful basis and a column for what a requesting party would be required to provide in its request, what is the expected response time, is automation likely, what are the standardized categories that may fall within that lawful basis, etc. Support staff to create a Google Doc in which EPDP Team Members are to review and consider the types of disclosure decision models (in other words, who is making the ultimate determination to disclose non-public registration data - contracted party or ICANN) and what would make these options acceptable to the different groups by Thursday, September 19. EPDP Team to review the legal memos and come back with the most relevant points that need to be factored in as the Staff Support Team produces the 1.0 draft by Thursday, September 19. James and Mark Sv. to work together on a revised proposal for Building Block L (SSAD query policy) by Thursday, September 19. When discussing updates to Building Block L, Team members to consider if it is within the Team’s charter to continue discussing this issue. Matt C. to review the legal advice on how to perform the balancing test and update Alan Woods’ initial balancing test document into a simple guide to conduct the balancing test to be included in the next iteration of the zero draft by Thursday, September 19. Contracted party Team members to draft letter to ICANN Board, outlining scenarios discussed, including where the disclosure decision lies within the SSAD, and inquire whether there are any options the Board would not be amenable to. EPDP Questions: · Action item 6: The second part of the action item is to determine whether this building block is within the scope of the EPDP Team - is the scope discussion just for James and Mark to discuss, or is this for the plenary team? Additionally, it may make sense to discuss the scope before conducting more work. · Mark and James agreed to review the charter questions before engaging in further discussion on this. · It may be a better path forward to conduct the scope discussion with the entire EPDP Team. · Chair proposal to conduct the work in parallel and await Mark and James’ deliverable before discussing with the plenary. Is bulk access allowed for ccTLDs, like .IT? · GAC colleagues discussed .IT bulk access with the Italian DPA – and noted this is done at the registrar level - the lawful basis is based on the consent of the data subject. · Other EPDP Team members thought the .IT discussion was about reverse searches, not bulk access. · .dk is allowing bulk search and reverse search, but the registry in this case owns all domain names, and the registrants are “renting” the names. B/c the legal structure is different, this is likely inapplicable for this case. · BC Team members have not been asking for bulk access; BC colleagues are exploring the potential to update RDAP to enable reverse look-ups · The Team may consider making a list of justified scenarios where reverse searching could be allowed. · Team to await the proposal from James and Mark, and continue the discussion after the receipt. · With respect to the Charter, there may be two charter questions that are relevant to this discussion: c1) What rules/policies will govern users' access to the data? c2) What rules/policies will govern users' use of the data once accessed?" The conversation around the query policy could fall under this. Instead of using the scope conversation to refrain from having this conversation, it may be worth having a discussion of whether this could be allowed or should not be allowed. · The charter guides the EPDP Team’s discussion, but the GNSO guidelines note the EPDP Team is to discuss narrowly-defined or previously-scoped issues. The GNSO Council should not and could not make this issue within the scope of this EPDP. · Building block L, where this issue comes from, was developed from the discussion of use cases, which were included in the Zero Draft. The Team will revisit this discussion following Mark and James’ completion of their action item. Questions for DPAs · The European Commission is of the position that engaging with DPAs would be useful for this Team’s policy work. Could a centralized model change the primary responsibility of the contracted parties? The EC advised ICANN to focus on responsibilities rather than liabilities, by highlighting safeguards. It is a tight schedule to seek feedback from the EDPB. When the questions are finalized, they will be forwarded to the EPDP Team. 4. Criteria/content of requests (building block a) (30 minutes) a. Initial discussion · What must requests contain? · The information from the Zero Draft came from the Team’s Phase 1 recommendations. · Are there any concerns with what is proposed in the zero draft? b. Feedback from EPDP Team · Is this text consistent with Rec. 18 from Phase 1? · Yes, this is a copy/paste from the Phase 1 recommendations; however, this may need to be cross-checked with the text resulting from the implementation of the Phase 1 recommendations. Domain name is missing from this list, but this may be considered a non-controversial addition. · It is important that this facilitates the standardized submission of inputs in the request. Request to add a footnote that specifies this. · On Section D, the second comment suggests alternative language for D - the suggested language is preferred here. · “Strictly necessary” should be deleted - GDPR requires detailing why the data is necessary, but not strictly necessary. · Strictly is not the standard under GDPR. · The requestor confirms the data will be processed in a lawful way if received - the retention of data is in a different building block. c. Confirm next steps · Support Staff to update Building Block A, following the feedback in today’s conversation. 5. Retention and destruction of data (building block e) (30 minutes) a. Initial discussion b. Feedback from EPDP Team · Is this the correct building block to discuss logs? · Logs are covered in a separate building block · Change “such as GDPR” to “including the GDPR” · “Including” may have a legal effect that the Team may not intend. · Perhaps include applicable data protection laws and delete reference to the GDPR. · What if applicable data protection laws do not have requirements? The policy should recommend that the data is stored and protected. · Should the Team include timeframes here? · It may be safer to say “applicable law, especially data protection law” · There are other legal obligations to retain data, as retention is important for data protection law, but not only data retention laws. · The Team may be overcomplicating this b/c “applicable law” is broad - it covers anything that is applicable. · Consider “in accordance with applicable law” · During the implementation, there needs to be a retention and deletion policy for all of the data that is being processed for this purpose. There are too many unknowns at this point to formulate specifics. · Should a policy recommendation be formulated about implementing a minimum destruction of data policy. · Confirming or ensuring the data is destroyed is likely not in the remit of the EPDP Team. It could be included as a policy recommendation to be included in the relevant data processing agreement. c. Confirm next steps · Support Staff to update Building Block E (retention/destruction of data), following the feedback in today’s conversation. 6. Who should be responsible for disclosure decision (30 minutes) a. Review team input (see https://docs.google.com/document/d/10VRZRziGDXvckC_y3ob_SGB- 1NN9WrL6Y6A3XQuniv8/edit [docs.google.com]) · The Team had a lengthy discussion on this topic during the F2F meeting, and Leadership proposed distributing a table where Team members could provide feedback. · IPC input notes that in the case of CPH, the decision must be made by a different party since most requests to CPH are ignored today · IPC also notes that if ICANN or designee makes a decision, the decision needs to carry weight and not just a suggestion · RrSG notes that if ICANN or designee makes a decision, full indemnity of other controllers is necessary. b. Consider team input and approach forward · Full legal indemnification - that concept is not possible. Recognizing that this is dooming the possibility, is it possible for the RrSG to consider a scenario where the disclosing entity would accept legal liability. · The conversation may be framed better with a single entity making the decision since the policy is likely the same if it’s ICANN or a trust. Can this be done with a single entity, or do other joint controllers have to be included in the decision. · Even in situations where there is a clear distinction b/w a controller and a processor, the processor could be liable. The liability is not just the decision to disclose, but also the act of disclosing. · One action is the decision to disclose; the second action is forming the data file; the third action is transferring the data file to the requesting entity · Are there any conditions that there would be a central gateway where the decision of disclosure could be made? · Could registrars consider Ashley’s comment? · It is important to set sights on what the DPAs return with. Legal guidance is helpful, but the most authoritative answer is from the DPAs (in response to Strawberry Team’s questions) · Unclear whether there is a difference b/w accepting full legal liability and indemnification. · At a practical level, this is the same, but no entity is going to indemnify another party. Consider what is realistically possible here - getting an entity to accept full liability for something would be easier to attain. c. Confirm next steps · EPDP Team members who have not yet contributed to the table - please do so in advance of the next Team meeting (by Monday, 23 September). · Registrars to consider the feedback today and reconsider position if possible. 7. Proposed schedule of meetings and topics to be covered until ICANN66 (15 minutes) a. Review proposed schedule · After the F2F meeting, the Leadership Team reviewed the outstanding items and the time left until ICANN66. Due to the limited time left, Leadership proposes to add an additional three meetings before Montreal. Specifically, the Team would meet on Tuesdays when there is no legal committee meeting. · Following Montreal, Leadership would reassess whether it’s possible to have an initial report in early December. b. Feedback from EPDP Team c. Confirm next steps · The Team will proceed with this proposal. The next EPDP Team meeting will be next Tuesday. 8. Wrap and confirm next EPDP Team meeting (5 minutes): a. Tuesday 24 September 2019 at 14.00 UTC b. Confirm action items c. Confirm questions for ICANN Org, if any