Dear EPDP Team: Please find below the notes and action items from EPDP Phase 2 Meeting #59 on Thursday, 21 May. Best regards, Marika, Berry, and Caitlin Action items 1. EPDP Team members who have not yet done so – please complete late homework by Monday, 25 May by 18:00 UTC: review and provide input on the discussion tables for Recommendation 17 [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_documen...> (logging), Recommendation 18 [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_documen...> (audits), and implementation guidance i[docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_documen...> (multiple requests). 2. EPDP Team members to review and provide input on the discussion table for Recommendation 15<https://docs.google.com/document/d/1e2kdKDoLH04OqNfZLJMd1qbDM07an2tZFs9rJOPo...> (financial sustainability) and review the updated Recommendation 19<https://docs.google.com/document/d/1-npFkABPc-u3To6uYe2v6MTFHlrEOUD5i6x8LrHA...> (evolutionary mechanism) and include “cannot live with items” in the chart within the document by COB Tuesday, 26 May. 3. Support Staff to update Recommendation 14 (retention), Recommendation 10 (Acceptable Use Policy) and Recommendation 12 (query policy) following the review of Recommendation 13 so that the recommendations may be considered together to avoid duplication. EPDP Phase 2 - Meeting #59 Proposed Agenda Thursday 21 May 2020 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) * We plan to discuss Rec. 19 with Financial Sustainability on 26 or 28 May, depending on how we progress through the other recommendations * Re: automation – comment from EPDP Team Member – some members were under the impression that with few automated use cases, the Central Gateway would take the decision and instruct the CP to disclose. Others were under the impression that the CGM confirms the request meets the request for automated disclosure and sends to the CGM. Important to have a common understanding of this. 4. Recommendation #14 Data Retention (15 min) 1. Review discussion items<https://community.icann.org/download/attachments/126430750/Recommendation%20...> gleaned from input provided on Data Retention Discussion Table<https://docs.google.com/document/d/1k5w2BMWiPBzpj_HeghcaijX2F2SVd5JHjKgDKIGR...> * Do we need to define abuse? Is this a one-time occurrence or multiple occurrences? * This has already been discussed extensively. * What does “this” mean? * Fine with specific text. Can we look at the audit recommendation. * Re: the question if CPs can audit the requestors? This is probably not practical. * No objections to bold language being added. * CPs auditing the requestor for retention of the data is unworkable in practice. It would be difficult to prove a negative here. Bolded language is acceptable. * If requestor who has received the data is not handling it according to GDPR, this requestor would be on the hook. Suggest adding suggested text. * What is the context for adding this in? That said, no objection. * The disclosing party would still be liable if they’re not in control of who they are disclosing the data to. Do not need permission from the SSAD to audit the data a controller discloses. If this is covered by the audit requirements, this does not need to be included. * Action item: Support Staff to verify what can be audited and if this is acceptable * Address this question by including data retention violation in a non-exhaustive list in Rec. 1 * Concerned that we are approving terms of use that permit CPs to audit the parties they disclose data to – this could be a big problem * Is ICANN Compliance OK with this? ICANN org liaisons need to speak with colleagues in Compliance on this. A written question would be helpful here. * ICANN would enforce compliance here * Review the recommendation in the entirety and see what it is about. If the requestor systematically violates the acceptable use policy, the question is – who could ban the requestor from using this. Is it ICANN org or Central gateway? * In terms of the role of ICANN compliance, it may just be on use of the SSAD itself. If violating is de-accreditation, then this is ICANN’s role as a data controller to limit use of the system it’s put in place. * It would be helpful to have a written question. Becoming increasingly uncomfortable of stretching ICANN’s mandate in an attempt to cobble this together. People have been clear about whether ICANN is staying within its mission – no one should assume that ICANN will do this. “ICANN will” is unlikely to come until the Board sees the full picture of the SSAD. * The question is relatively easy to answer. If the SSAD is within ICANN’s remit, then ensuring anyone using the SSAD is playing by the rules is also in ICANN’s remit. Highly likely that ICANN will engage a subtractor to work on its behalf. * This is about whether it’s in ICANN’s mission or not. * If the Team is thinking in the wrong direction, it would be helpful for the ICANN liaisons to steer the team in the right direction * This is a bit late in the process, as if the answer will be no, this would be a problem. * Is ICANN org willing to take on an additional task – now it’s framed much more broadly is that is this within ICANN’s mission to take on the additional task. Does the Board see issues with the policy recommendations? We do not want to end up with presenting this, passing it at the GNSO Council level only to find issues with the Board believing this is out of scope. * Working under assumption that ICANN will do many things. * Want to ensure that we test every assumption that ICANN will do something that is in its mission. If it is as simple as you can no longer have access to the system, that would be one thing – but is this also subject to re-consideration requests, et. al. * Had we sorted out the controllership arrangements, ICANN’s responsibility would be clear. An obligation under the GDPR is to not continue to accredit people who are violating the rules. * Action: Janis to pose relevant questions to ICANN org and share the message with the team. 1. Confirm next steps 5. Recommendation #10 Acceptable Use (15 min) 1. Review discussion items<https://community.icann.org/download/attachments/126430750/RECOMMENDATION%20...> gleaned from input provided on Acceptable Use Policy Discussion Table<https://docs.google.com/document/d/1h2179UY3KNoA3eIC1sdVR8G-GN_brLAN3h89r9fO...> * CP should be able to trigger enforcement if they find the AUP has been violated * This should be triggered by ICANN compliance is the right place to do this * There is some overlapping – there are different and distinct items that serve different and distinct purposes * The acceptable use and terms of use are referring to two different things: one is for how users will use the SSAD system and the other is how requestors will use data once it is disclosed to them. * Wondering if to drive the point home about what the Acceptable Use Policy vs. the Terms of Use – would it be helpful to call this Terms and Conditions of using the SSAD * The CGM should just do a check that the requestor has agreed to the terms * This seems to be all the CGM could do in this case – a requestor would not be accredited if it doesn’t agree to the AUP * Not clear on what the new text means. The addition is already covered by b and e of this recommendation. Do not object to the addition but do not think it is necessary. Suggest this NOT be included. Note that we’ve covered elsewhere and move on. * Suggestion – leave the addition out and stick to the original text of the recommendation 1. Confirm next steps 6. Recommendation #12 Query Policy (15 min) 1. Review discussion items gleaned from input provided on query policy discussion table<https://docs.google.com/document/d/1IkLu_tfMCayjjeXZLpivgXL5G2dtCepv440YpVTA...> * Comments about assumptions and takeaways – there are a number of items that are said to be addressed in implementation. Ask that where we expect things to be addressed in implementation – we state that in the recommendation. This would be helpful for the implementation phase. * Question 1 will be further described in implementation * Thought the whole idea of not addressing historic data was agreed – this should not be included. While the presumption is accurate, the EPDP Team does not need to report on this in its recommendations. * This text is confusing and contradicts the main principle * Agree to NOT include this text * Each request should be examined on its own merits * Consider on its own merits may predate that the CGM is now doing this – this is for the CP to do * Do not agree with the removal of this * If the gateway cannot review requests on its merits, it can’t perform any recommendations * Much easier if we’re looking at a flowchart of how the SSAD will work * If you have 1000 identical requests from the same requestor, you would not give 1000 similar answers in one click, you would have to go through each request individually. * Ultimately, if there is a centralized version of disclosure, this principle may come into play, so this should be referenced. * Action item: Support Staff to review “examine on the merits” and make sure these are consistent with each other * Here, the idea was in case of many similar requests, each request should be examined individually by a computer 1. Confirm next steps 7. Recommendation #13 Terms of Use (15 min) 1. Review discussion items gleaned from input provided on terms of use discussion table<https://docs.google.com/document/d/1sBVjsUf3JNQclGMpMS4PXBaffarVF5galoWxpVjz...> * SSAD users = requestors * The concept that we’re trying to address is there should be input from users and requestors before the contracts are published. This should be similar to how the RAA was negotiated – in other words, there is input from others before the negotiation begins. * In terms of SSAD privacy policy, what was suggested makes sense. * Concerned with dropping the word “requestor” – there may be accredited users who are habitual users and everyone else is not accredited. 1. Confirm next steps 8. Recommendation #17 Logging (15 min) 1. Review discussion items gleaned from input provided on logging discussion table<https://docs.google.com/document/d/1YaHV2F49-9FpbmJdciCgkYeGCiwNNVTvfmqqnlPh...> 2. Confirm next steps 9. Recommendation #18 Audits (15 min) 1. Review discussion items gleaned from input provided on audits discussion table<https://docs.google.com/document/d/14ctH4bAqrWTWK_XqnmvaFG7CnPcJdODQ5XaEwMwc...> 2. Confirm next steps 10. Implementation guidance I (15 min) 1. Review discussion items gleaned from input provided on implementation guidance i<https://docs.google.com/document/d/1C9Z4Rv-sdtYmGcUqOBG-3-XsvovXUAPQ0y6gbMYu...> discussion table 2. Confirm next steps 11. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Tuesday 26 May at 14.00 UTC. Topic to be addressed: financial sustainability, high level review of public comments received on the addendum. 2. Confirm action items 1. Confirm questions for ICANN Org, if any