Dear EPDP Team: Please find below the notes and action items from today’s meeting. Thank you. Best regards, Marika, Berry, and Caitlin -- Action Items In preparation for the next meeting, EPDP Team to review the public comments received for Recommendation 7 (authorization automated) and Recommendation 16 (automation) and the legal memo regarding automation. Please note EPDP Team Members DO NOT have to fill out the discussion tables for these recommendations. Instead, EPDP Team to review the staff support team's proposed edits to Recommendation 7 and 16 and come prepared to discuss additional edits or raise concerns if the Team feels the public comments were not captured correctly. Staff Support Team to separate the urgent requests from Recommendation 8 and include it in a separate recommendation. Chris Lewis-Evans to provide additional examples of categories of urgent requests for the Team's consideration. Staff Support Team to update Recommendation 11 based on today's discussion. GAC reps to inform Janis when they expect to complete the update of Recommendation 2. EPDP Phase 2 - Meeting #55 Proposed Agenda Thursday 30 April 2020 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (10 minutes) Update from the legal committee Solely automated decisions can only take place where there is no personal data or the decision does not have a legal or similarly significant effect on the data subject The summary table in section 3.5 provides a visual example B&B advised about scoping each use case and its legal basis The Legal Committee also asked about proximate cause – there is no generalized case law on this, so it is difficult to determine where data protection authorities could come out on this issue Under scenario 1 where the CP is making the decision, the parties would likely be joint controllers Under scenario 2 where the central gateway would be making the decision – in the macro sense, the parties would likely be joint controllers. If this is viewed in a micro sense, the CP would be the controller with respect to the decision to transfer data to the central gateway, but where the CP has no decision whether to release it, the Central Gateway would be the Controller for the disclosure decision. As between Scenario 1 and 2, B&B noted that Scenario 2 would result in lower risk of liability to the CPs Based on this advice and the comments received, the Staff Support Team updated the draft recommendation, and the Team will review these updates during the next meeting 4. Recommendation #8 – Response Requirements (10 minutes) Review remaining discussion item (#8) gleaned from input provided on recommendation #8 discussion table (see discussion items attached) One remaining issue regarding urgent requests. Proposal to include a list of examples for urgent requests in the implementation guidance Do not agree with the Mark Sv examples, but could propose some alternate examples on this list Next step: Separate recommendation on urgent requests, and there will be examples provided in implementation guidance. Chris L-E to propose additional examples on the list. Confirm next steps 5. Recommendation #11 – Disclosure Requirements (45 minutes) Review discussion items gleaned from input provided on recommendation #11 discussion table (see discussion items attached) ICANN org liaisons – looking to confirm that the requirements here also apply to automated decisions Have an issue with “automated decisions by the SSAD” – a decision from the SSAD is not necessarily automated. There may be staff associated with the SSAD, so need to make it clear that decisions from the SSAD are not automated. Janis recollection – automation would be done at the central gateway level without human involvement The controllership or co-controllership of the SSAD is relevant here. A decision could be made at the SSAD level if the SSAD is the controller. The disclosure requirements apply to a – j – if we look at the actual question – do all parties need to comply with these factors – the answer to the question is yes e – balancing test – if we are talking about an automated decision, e is not applicable If a CP believes the request violates the law, it needs to ability to reject the request On e, would changing processing to disclosing fix the issue Part of the confusion is that the recommendation references automated responses, but recommendation 7 relates to automated disclosure – does this comport with Rec. 7 – do a – i apply to all parties? a) – keep data as is b) – what does current data mean? There is a multi-day SLA here – the data could be requested and the data could change The idea that a name cold be locked is a non-starter, as this could allow a requestor to hold a domain name hostage The data returned needs to be data the disclosure decision was made against If the data changes when the request is made and the time someone looks at the request, that is life. If the data is retrieved, a decision is made to release, and the data changes in that period – not sure how to handle. Maybe RDAP will refuse the response if the data is changed while the inspection is being done. Focus on the first question – if the policy says must not disclose historic data, then the definition of historic data may be ambiguous which would make it difficult to apply to the MUST. Should define what historic data means here. Define when the snapshot occurs, and if it changes in the meantime, the requestor will need to make a new request. When does the data cease being the current data and become historic data – this needs to be defined for the policy. Exempt data that is authoritative at the time the request is made – this shouldn’t be prohibited. Authoritative data at the time the request is transmitted from the SSAD shall not be considered historic data. We could define how long the CP would have to keep a record of the change – we can discuss this more in retention schedules Talking about a situation where a disclosure decision – how can we not provide data for making the decision? It has to be that the data used for the disclosure is the data is the data that went under the balancing test, otherwise, this is a serious issue. f) there is no obligation for registrars to proactively inform registrants. However, opposed to a recommendation that prohibits this. Opposed to language provided in item 6. The language in 7 causes more confusion than clarity – recommend leaving the language as is No objection to leave the language as is g) this is redundant, but recommend leaving as is h) – it is in everyone’s interest that this is based in applicable law, and that should be left Could clarify that the privacy policy includes minimum requirements in the GDPR The privacy policy of the SSAD might be different than the privacy policy of the contracted parties – the privacy policy would require public comment The privacy policy referenced here is for SSAD The Team needs to clarify – registrants would not be presenting a privacy policy to SSAD users Support Staff Team will update this language to make it clearer The Privacy Policy would apply to the users of the SSAD – this is a heads up to the users of the SSAD. That said, the two approaches are in conflict could be resolved as a matter of sequencing. This could be something that ICANN org handles in conjunction with its legal advisors – and thereafter, a public comment process could be sought especially if the proposed policy goes beyond the law. The Team is going about this backwards – it would be inadvisable to have many privacy policies. Privacy policies for registrars vs. privacy policies for the SSAD – the registrar is the interface to the data subject, so the registrar needs to make sure that the information is presented to the data subject at the point of collection. The privacy policy describes the purposes, legal basis, which we are crafting now. Caution against making this a community exercise, where community members will rehash arguments about what type of processing can take place. There needs to be a clarification in subpoint h, and Support Staff will think of the best way to reflect this. SSAD itself should have a privacy policy itself, and this should be crafted by lawyers in the best possible way. Question 12 – recollection that i was the result of work between Chris L-E and James – would be helpful to see if Chris could weigh in on his thoughts on these proposed edits. Not in favor of changing the Initial Report language – believe it should be “and” and not “or” Agree not to make these changes – the two bullet points open a can of worms In terms of implementation notes, agree with the first bullet point coming from the perspective of a civil law enforcement agency Prefer the entity vs. authority change Keep the “and” here Support Staff will do a write-up of the edits, and the Team will look at the edits, using the “cannot live with” edits Confirm next steps 6. Recommendation #6 – CP Authorization (45 minutes) Review discussion items gleaned from input provided on recommendation #6 discussion table (see discussion items attached) Question 2: Leave as is Question 3: any objection from changing provided to demonstrated Believe this is an important change Comment re: question 8 – not clear on how a CP might go back to the requestor when the CP does not have a direct line of communication with the requestor – good question here – how are SLAs considered if there are questions between the requestor and the disclosing entity. Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): Thursday 7 May at 14.00 UTC. Topic to be addressed: Authorization automated, Automation, Recommendations not considered by EPDP Confirm action items Confirm questions for ICANN Org, if any