Dear EPDP Team:

Please find below the notes and action items from today’s call.

As a reminder, the next call will be Thursday, 21 May at 14:00 UTC.

Best regards,

Marika, Berry, and Caitlin

--

Action Items

1. EPDP Team members who have not yet done so – please complete late homework by COB today, Tuesday, 19 May: review and provide input on the discussion table for Recommendation 14 (retention), Recommendation 12 (query policy) and Recommendation 13 (terms of use).
2. EPDP Team to review and provide input on the discussion tables for Recommendation 17 (logging), Recommendation 18 (audits), and implementation guidance i (multiple requests) by COB today, Tuesday, 19 May.

EPDP Phase 2 - Meeting #58

Proposed Agenda

Tuesday 19 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 do not have sufficient activity in homework completion – this has resulted in a Catch-22 situation where we cannot proceed when homework is not done.
• Could groups consider assigning tasks to individual members instead of reviewing by groups

4. Recommendation #7 Authorization Automated & Recommendation #16 Automation (15 min)

1. Overview of changes applied by staff support team in response to last week’s discussion and input provided (see updated recommendation)

• We started reviewing this recommendation during the previous call
• We have to go through some minor issues to clarify
• Support Staff has applied edits based on the team’s last discussion, including trying to clarify areas of confusion or trying to find a compromise between divergent positions.
• Support Staff removed the highlighting so the Team could clearly see the edits.
• Edits and accompanying explanations are included in the table at the end of the recommendation text
• There is also a link to the previous version at the end of the document.

2. Continue review of remaining ‘cannot live with’ items & minor issues for clarification (see discussion items list)

• a) how do automated disclosures happen?
• Understanding – data would be held by the contracted party, so what other alternatives exist within the bounds the team discussed?
• Is the Central Gateway manager now making the decision and accepting the liability?
• No, the majority of cases involve the CGM channeling the request to the CP.
• For limited cases at the beginning and possibly more in the future, the CGM will confirm that criteria for automation are met (the criteria is established by the policy)
• According to Rec. 7, the cases we are talking about are 4 cases noted in the implementation notes. Since the CGM will not hold any data, there is no other way to handle this except for the CP to disclose the data.
• This could not be done via RDAP, not as it’s described here. By way of example, this would be like someone trying to open a webpage in a browser and someone else getting the response. RDAP, just like a browser, is a restful interface. The person who submits the request would get the response.
• Have to make sure we have a viable way to go forward – the result cannot be sent in open email. There has to be a secure transmission mechanism. The only simple solution is to somehow have the originator make the request again, but then it has to pass through the SSAD.
• This discussion would be better handled in the implementation phase – the return mechanism needs to be discussed further. Replace RDAP with secure mechanism. This would be covered by a JCA, and depending on the type, a DPIA.
• Once we got to a place where something is automated, the central gateway manager is making the decision and should be responsible for the decision
• We are recommending a hybrid model, which will hopefully become more centralized as time goes on. We have centralized the intake of requests, centralized format. For the requestor side, there will be a significant improvement
• The CGM is not making a decision on automated requests – it is making a decision over whether the bar for automated disclosure has been met.
• Even if the gateway is making the decision, they are doing what we have told them to do.
• Support Staff to review the language to ensure it is crystal clear.
• b) human intervention at the central gateway
• This is something that was discussed periodically – since full automation is not advisable is most instances, then adding a level of human scrutiny that doesn’t have to take a lot of time can take a lot of time. We should provision for decisions to be made centrally.
• What does “person associated with SSAD” mean? We don’t know the jx or the relevant credentials the person would have. As a general comment, if we aren’t able to say and agree the category is automated, it has to go to the CP to decide. This is not viable at this point.
• Agree that human intervention at the central gateway should not be ruled out – should not preclude this scenario, since the preference is for the decision to be made centrally.
• ICANN is also a controller, and ICANN will oversee and run the SSAD. This clarification is just to include this as an option – this may not necessarily be used, but it could be. Somehow automation and centralization became synonymous, but we should bring back the option that it may not be fully automated if it is centralized.
• ICANN is a controller, but ICANN has agreed that it will oversee the gateway, but they may not operate the gateway. Uncomfortable keeping an option open when there are many variables.
• For the hybrid model, there is centralization of the request, but the decision will be made by the CP. The problem we are running into to is the open-endedness of the evolution. We need to stop using the concept of evolution to relitigate the hybrid vs. the centralized model
• c) OK with the language on the screen as it reads now
• Language is still ambiguous – a CP should not be able to automate all requests. Some CPs will break the law and automate requests simply to reduce their workload and this will be noncompliant with the GDPR and other data protection laws
• An example could be for .pharmacy and .bank, where all the registrations are legal people.
• Suggest adding “if it is legally permissible”
• Where are the joint-controller agreements?
• Not all CPs are subject to GDPR, some CPs only deal with legal registrants – it does not seem appropriate to remove this flexibility
• d) support the deletion of “meaningful human”
• b) revisit if evolutionary mechanism could take care of centralization vs. automation
• c) currently, no way to reconcile opposing views

3. Confirm next steps

5. Recommendations not considered by EPDP (15 min)

1. Review discussion items gleaned from input provided on recommendations not considered by EPDP

• Cross-border transfers – should there be a mention in the final report that contracted parties would need to adhere to cross-border transfer requirements
• Important for the requestor to note where the data will be processed, but this is for implementation
• Should mention this in the report
• In terms of Rec. 3 – there is no requirement for the requestor to identify its location, so perhaps adding it there would address this concern
• Agreement to highlight this in the recommendation
• Other issues that need to be highlighted – under which grounds the requestor makes the demands
• Support Staff to update Rec. 3 to include trans-border transfer of data

2. Confirm next steps

6. Recommendation #4 Third Party Justification (15 min)

1. Review discussion items gleaned from input provided on Third Party Justification Discussion Table

• Purposes should be changed to justifications
• Should third parties be changed to requestor in the title as well?
• Do not agree with changing purposes to justifications
• The point of deleting purposes here is to avoid confusion with the conflation of third-party purposes and ICANN purposes
• GDPR talks about purposes, and part of what we are doing is providing a purpose statement to the registrant. Changing it to justification takes it out of the GDPR context.
• We spent Phase 1 deliberating on purposes for collection of the data and agreed that we would discuss and document third-party purposes in Phase 2.
• NCSG is withdrawing the objection, but not sure why justifications is still in – this is sloppy language
• No objection to remove the justifications from the title
• Question 3 –
• There may be instances where data subjects may want their data disclosed not globally but in certain instances
• Yes to consent, but not via the SSAD
• This is a recommendation for third party purposes. The items listed in subsection iv do not make sense. Remind everyone that this is not an exhaustive list – dropping iv seems to be the simplest and easiest way to move forward.
• The vast majority of RNH requests for data should go to CPs b/c they have deeper data and the average data request will not be for data held by the SSAD
• Prefer to keep the first part in
• iv is not a third party purposes – it’s a basis for processing the data “or on the basis of iv”

2. Confirm next steps

7. Recommendation #14 Data Retention (15 min)

1. Review discussion items gleaned from input provided on Data Retention Discussion Table
2. Confirm next steps

8. Recommendation #10 Acceptable Use (15 min)

1. Review discussion items gleaned from input provided on Acceptable Use Policy Discussion Table
2. Confirm next steps

9. Recommendation #12 Query Policy (15 min)

1. Review discussion items gleaned from input provided on query policy discussion table
2. Confirm next steps

10. Recommendation #13 Terms of Use (15 min)

3. Review discussion items gleaned from input provided on terms of use discussion table
4. Confirm next steps

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

1. Thursday 21 May at 14.00 UTC. Topic to be addressed: Logging, audits and implementation guidance i (submission of multiple requests).
2. Confirm action items

1. Confirm questions for ICANN Org, if any