Dear EPDP Team:

Please find below the notes and action items from today’s EPDP Team meeting.

Best regards,

Marika, Berry, and Caitlin

--

Action Items

1. EPDP Team members to review the Recommendation Input Review tables and provide further information in response to clarifying questions for the remaining yellow items (beginning at Item 42 for Recommendation 9) in advance of the next meeting on Tuesday, 23 June.
2. Brian and Matt S. to work together on an updated formulation of Rec. 7 (must vs. should, footnote 43), taking into account the team’s discussion.
3. Support Staff to update the draft final report in accordance with the agreements from today’s meeting.

EPDP Phase 2 - Meeting #66

Proposed Agenda

Thursday 18 June 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)

• Propose discussing Rec. 6 at our next team and allow staff to rewrite the recommendation based on yesterday’s discussion

4. Continue run through of yellow items (items identified for further discussion / clarification)

1. EPDP Team feedback

• Item 35 – second paragraph in this recommendation: “The SSAD MUST allow for the automated disclosure of data in response to” – this update should be rejected as this may unnecessarily limit the automation part of the recommendation. Can this go back to the original formulation?
• We requested that we allow for centralized decisions not only automated decisions
• Automated disclosure narrows the sentence – automated processing allows for more automation
• As long as it’s clear that the SSAD will allow automated decisions
• Would like to explicitly mention the disclosure of the data – perhaps say “allow for automation of the processing, including the automation of the disclosure of data”
• Everyone is OK with automating the receipt and processing requests, and now members are trying to shoehorn automated decision making here. This paragraph has no reason to be here because it is dealt with in Recommendation 7. Either we stick with the original language or delete the paragraph; the current modification is unacceptable.
• Agreement to revert to the original formulation.
• Items 36 – in one of the previous meetings, we discussed this part of the recommendation extensively. The language was originally SHOULD, and it was changed to MUST, but CPs were concerned about forced disclosure without any exemption. Footnote 43 outlines a process where CPs can notify ICANN Compliance when it believes is unable to automate the processing.
• CPs have provided alternative language
• Can the Team agree up front that there will be automated decision making in limited circumstances (where technically, legally, and commercially feasible), and that this is fundamental to the report?
• There should be a way for CPs to put the brakes on if they cannot automate. Concerned about FN 43 to put the brakes on immediately, but there doesn’t seem to be the ability to assess if the brakes were properly applied. This seems to be a one-way street – there needs to be more meat on this so that ICANN can assess whether the concern is justified. There is an imbalance here.
• There should be a procedure where the impacted groups are able to weigh in if they are in agreement with what has been designated as automated no longer is in light of guidance – there needs to be some kind of notice and comment process.
• Not comfortable with the use of the word “MUST” – need to use “SHOULD”. Data protection law is generally a risk management decision, so there will inevitably be different interpretations of what is “legally permissible”. We all promote the concept of making this simple and inexpensive where feasible, but let’s not pretend that something is feasible when it’s not.
• NCSG has moved far outside of its comfort zone – what would be the operational difference b/w must and should? Believe footnote 43 should be part of the main policy. Now, the concern is we are kicking the football to implementation guidance and the mechanism outlined in Rec. 19. Before we accept this language, what is happening in Rec. 19? If there is an acceptable process for Rec. 19, we can accept this language. If Rec. 19 turns into an alternative policy-making process, we cannot accept this.
• The team can provisionally agree on this rec before Rec. 19 – if there is no agreement on Rec. 19, we can revisit this language.
• Footnote 43 should be incorporated into the policy; footnotes should not have important text.
• “Must automatically disclose data for any categories, subject to [caveat]” instead of “automatically process”.
• From the RySG perspective, Rys had concerns with “should” to “must” and did not feel like the footnote language was sufficient to address the concerns. Rr suggestion is good here, in that they leave in the MUST but as a balance, but they leave it to the CP to determine what is technically and commercially feasible and legally permissible. CPs reside in different jx, so where the CP makes this determination that must automatically process is OK – strikes a good balance. It also allows for evolution.
• If CPs make the determination, there is no need for a footnote.
• IPC cannot live with CP in its sole discretion to decide whether to automate. This would not be enforceable by ICANN compliance. Interested in working on this exception process and how this would work.
• Proposal – maintain the text as is on the screen where CPs must automatically process and elevate FN 43 into the policy (rather than a FN).
• We have not done a DPIA despite certain parties screaming for it. In order for a CP to stop automate processing where they believe it is legally impermissible, they will have to do a DPIA. This is not cost-free, and we do not have a proper scoping of this.
• This should be a SHOULD and there should not a high bar for a CP to get out of this if they believe the processing is not technically or commercially feasible or legally permissible
• The change from SHOULD to MUST needs guardrails. If it is a must, the CP needs to make the decision.
• Technically and commercially feasible may need to be treated separately. If this is a bilateral agreement b/w two parties, this could be discussed; however, with thousands of agreements, this is unworkable. Technically and commercially feasible should be separated out.
• Rrs cannot have a process where the onus of proving that something is not legally permissible is on the Rr to prove. The DPIA needs to be done by ICANN. Just b/c something is legally impermissible in one jx, that doesn’t mean it needs to be pushed through for all jx. This language needs a lot more work.
• The role of ICANN Compliance should be a check that this exemption request process is not being abused. This would be close to a rubber stamp process by Compliance – just to guard against abuse.
• Item 39 from ICANN org asks some of the questions the Team has been speaking.
• Some colleagues are still OK with automating based on what they believe is legally permissible. The language Rrs suggested allows CPs to make their own determination. This may result in more automation; in some cases, it will result in less automation. It’s very hard to come up with a one-size-fits-all solution. While we have focused on GDPR, there are other laws that may be applicable.
• No amount of guardrails or caveats can turn a should into a must if there are so many unknowns
• What should the role of ICANN be? This refers to ICANN Compliance, and policy should probably refer to ICANN org instead of ICANN Compliance specifically as it’s not a foregone conclusion that ICANN Compliance will handle this
• Item 40 – even for decisions where the central gateway may direct automated disclosure, there may be manual processing at the central gateway, so there is some language added here – the CGM MAY request additional information to determine if the criteria for automated disclosure has been met.
• Additional information may not be always be personal information
• Do not see the harm in allowing this and it gives flexibility for the future
• Why do we have this in if we cannot think of a concrete example? If it’s not clear to the CGM at the beginning, it doesn’t meet the criteria, and it should be manual.
• Example – data previously disclosed – has this ever been disclosed before? If yes, it could be automated
• The CGM makes determination on whether the criteria for automation has been met
• What this is allowing is that the evolutionary mechanism may come up with new scenarios where the SSAD could disclose information – as CPs have pointed out repeatedly, Rrs are in many jx – some may be in a position to release information to the SSAD. This just allows flexibility to future decisions.
• If we make sure that there is no transfer of personal data, that would be acceptable
• Limiting this to no personal data unnecessarily limits this
• Item 41 – GAC team requested an addition. RySG is asking for further context.
• Based on Chris L-E’s explanation, OK with the particular edit, but the B&B analysis did not take this into account but neither were a lot of other law enforcement requests. This edit is OK, but there may be other problems.
• “or processing is to be carried out under an Article 2 exemption” – the or is ambiguous
• Chris to look at the sentence
• “applicable” doesn’t always mean it’s only law enforcement – some jx may be able to request data subject to contract or treaty, there are also Rrs are set up in multiple countries
• “or” could go after jurisdictions “or where processing is to be carried out under Article 2
• With either (i) local jx or (ii) confirmed article 2 exemption
• Item 42 – Priority matrix should not be implementation guidance as there is text that is part of policy rec and part is implementation guidance. If the team agrees, which part should be in the policy language? (also relevant in the context of rec. 19 b/c anything that is the policy rec. cannot be changed except through a PDP)
• If it’s moved into the policy rec., we would be locked in place
• Policy rec could be such – initial rec is: [x] but this can be adjusted per the evolutionary model so it gives the flexibility that we intended to give.
• Understanding is that at the very least the numbers in the third column were initial numbers that could be changed in implementation without changing the policy.
• Item 43 – is this to be negotiations b/w ICANN org and CPs or are these policy requirements?
• This may be tied to the Rec. 19 conversation.
• When did the Team decide on one business day?
• This is still an open question as to what business day means.
• Recollection that we are still discussing business days.
• Team to provide input by the next meeting.
• In the Google docs, if groups want to provide input on the clarifying questions on what has been flagged, please add this to the Google doc.

2. Confirm next steps

5. Wrap and confirm next EPDP Team meeting (5 minutes):

1. Monday, 22 June at 14:00 UTC – Small Team for Rec. 19
2. Tuesday, 23 June at 14:00 UTC – continue run-through of yellow items
3. Confirm action items

1. Confirm questions for ICANN Org, if any