Action Items

1. EPDP Support Staff to update Recommendation 8 based on today’s discussion.
2. EPDP Team to review the attached discussion issue documents for Recommendation 8 (beginning at the takeaways following Question 8), Recommendation 11, and Recommendation 6. EPDP Team to come prepared to answer the questions highlighted within these documents during the next EPDP Team meeting on Thursday, 30 April.
3. EPDP GAC representatives to provide an update on when they plan to circulate an updated version of Recommendation 2 (accreditation of governmental entities).

EPDP Phase 2 - Meeting #54

Proposed Agenda

Thursday 23 April 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)

• Following the EPDP Team’s discussion of recommendations, Support Staff will propose draft updated text and post them on the dedicated wiki page as they come in. The Team will have a chance to review all of the updated recommendations and groups may identify text they cannot live with.
• For now, the Team should focus on the delineated homework schedule and provide feedback via the discussion tables.
• The legal committee has received responses to their questions on accuracy and automation and will be meeting to discuss these next Tuesday at 14:00 UTC
• GNSO-secs will circulate a notice

4. Recommendation #8 – Response Requirements (20 minutes)

1. Review discussion items gleaned from input provided on recommendation #8 discussion table

• Question 1: Regarding “relay the disclosure request to the responsible Contracted Party,” the EPDP Team needs to discuss further whether the disclosure request is only relayed to the registrar and/or in which circumstances it may be related to the registry. It has been suggested that the request must always be forwarded to the REGISTRAR, and if the registrar does not respond by the SLA or there are specific circumstances that make it impossible to relay the request to the registrar, the request could be forwarded to the Registry by the Central Gateway Manager. However, if the Registrar denies the request, the requestor cannot forward the request to the registry.
• Team did agree that by default requests would go to the registrar. If the request is denied by the registrar, the requestor should not be precluded from going to the registry with the same request.
• Would the requestor go to the registry outside of SSAD or inside SSAD?
• Response – requestor should be able use SSAD to contact the registry
• Currently, there are registrars that say no to everything. Compliance has noted it will not question the decision of the contracted parties. Either the Rr or Ry could be a point of inquiry. It makes sense to go to the registrar first, but if there is problem, requestors should be able to go to a registry
• There may be some instances where the registry is in the same jurisdiction as law enforcement, and as long as there is a proper reason and due process is followed, there should be no prohibition against going to the registry.
• Registrar answering “no” to most requests may not be in violation of their requirements. If there is now a secondary path to the registry, where data a registrar refused to disclose can suddenly disclosed – this will present a bit problem to registrars. Would like to avoid this.
• If registrars are denying requests, there is probably a reason. Some members are expressing issues with denying requests. Right now, CPs are functioning under the Temp Spec – the new policy will have new requirements where ICANN Compliance can investigate.
• Discomfort falls into two categories: (1) there is a recognition that not all registrars will behave in a way that is consistent with the requirements. If there is a pattern of unreasonable rejections, there needs to be recourse. (2) There are some jurisdictional hurdles where law enforcement cannot obtain info from registrars in a jurisdiction other than its own – there needs to be a way to get information in these circumstances.
• Registrars should be the first point of response for these types of request. Requestor should be able to go to the registry if there is a repeated SLA issue but should not have this option in the event of a denial. Otherwise, the decision of a registrar does not stick – it is just a speed bump on the way to asking other parties for the same request. If there is a codified process where Rrs have to give data to a party that may disclose over the Rr’s objection, this is a concern.
• If a registrar says no, they have to have a reason, and “the law prevents me from disclosing” is a viable reason. If compliance will not question the reasoning, this is a real problem.
• These are all issues that should be sorted out in co-controller agreements. Do not see how ICANN Compliance can fail to intervene when someone is not complying with data protection law.
• Most people seem to agree that this is a real issue. The request for safeguards seems to be what the Team should be talking about here and provide some implementation guidance.
• The Team is talking across each other. The suggestion – should always be to the registrar, but there are defined procedural elements that can be looked at where in a specific instance the request can be routed to the registry. When it comes to the legal decision, the recourse is to the data protection commissioner, not to ICANN compliance.
• Based on this conversation, Staff Support Team will finetune this proposal and put it in the draft recommendation.
• Question 2: In the case of an automated decision, what information must be relayed to the contracted party?
• Answer: all data the gateway has about the request and the requestor.
• Request comes in – Central Gateway determines if it should be automated, or the request goes to the Contracted Party. If CGM determines it can make a disclosure decision – should the entire request itself be sent to the contracted party?
• The general principle – if the CP has liability, the information should be relayed. If having the info would create more liability, the CP may not want the information. We should park this decision until the Legal Committee reviews the legal advice on automation.
• In case a decision is made by the CGM and a contract defines liability and in case the CP is not legally answerable to its decision, there is no reason to receive the request or a checklist of how the criteria is met. If the answer is no – who is relaying the no – the CGM or the CP?
• Willful ignorance is not a legal defense to data protection. Saying I would like to know less so I can answer your question is probably not a way forward. Provide the full information and the Registrar will respond based on that.
• Question 3: how will the CGM make recommendations to the Contracted Parties?
• Is this about the decision or a recommendation – the CGM is in a position based on knowledge in the system to make a recommendation, but the decision always stays with the contracted party.
• Decision will be made by CPs unless instances are agreed where requests may fall in the automation category – local law enforcement and UDRP/URS. If the decision is made at the central gateway, the CP would receive a request to disclose the data. In the case of a denial, CGM will provide the denial to the requestor.
• The CGM’s recommendation and that this is a machine learning mechanism does not make sense – would recommend studying the decisions that were made and look at which were made correctly, and which were made incorrectly. How does the CGM make these decisions, or is this a relay function? This is an incoherent recommendation – the whole premise behind this does make sense.
• It would be good for CPs to have a recommendation from the CGM – it doesn’t matter whether it’s manual or automated. On the second question, the CGM should use all information available to it. This will help the gateway get smarter and it will help the requestors learn as well.
• Response data should be securely logged – there will be a lot of information that will generate confidence in requestors and certain types of requests.
• This is a good recommendation that should be there as an option, but the implementation is uncertain. The Team has not discussed the implications of there being manual intervention at the central system to help make the decision – how effectively this can be implemented may well change over time.
• Is the recommendation to be automated or manual? Assumed that this would be an automated evaluation and recommendation. May be helpful to hear from Staff regarding costing around automated vs. manual.
• Based on discussion in Los Angeles, it was discussed that a computer would make this decision.
• Maybe after two years of operation, the CGM could provide a recommendation – if not, this does not respect basic data science
• This is a MAY requirement, and it is unlikely this will happen on Day 1, so do not share the concern that this will happen on Day 1
• This needs to be operated based on the co-controller agreements – this machine is owned by ICANN and it’s part of ICANN’s process
• No one expects this to happen on Day 1 – it would be up to ICANN to decide how and when to launch the automated recommendation
• Question 4: is an appeals mechanism necessary for requestors who believe the CP improperly denied their request?
• An appeals mechanism is necessary – there may not be a DPA involved, and it’s important as part of the policy to have an appeals process.
• How would this look in practical terms?
• Look to examples in the ICANN space – there are dispute resolutions in the new gTLD space
• Willing to entertain the concept of an appeals for a negative decision if this is also an appeals process for a positive decision if a data subject believes its data was improperly disclosed. To make this into a legalistic thing where every decision can be appealed would be very costly. We should probably not do this; we should use existing compliance processes against registrars who are making decisions in either direction.
• ICANN Compliance will not be reviewing how a CP applied a balancing test. If ICANN Compliance won’t do it, there has to be an appeals mechanism that gets it right. The cost of this would be very high, which would limit the number of appeals.
• Cost of appeals mechanism would be borne by the individuals who file the appeals
• Is there a way to come up with a fast-track process or streamlined mechanism – there is a need to deal with systemic problems, but we don’t want to bog down the process with too many layers of review. Could it be ICANN Compliance or a standing panel?
• You cannot have an appeals mechanism for requestors of data without having an appeals mechanism for data subjects/registrants
• This is too granular to have an appeals mechanism on individual requests, but maybe the registrar can be flagged it can be based on denial or acceptance on a CP basis
• Staff to note the appeal mechanism idea and see whether it can be factored in within the evolutionary mechanism, and if this is not supported or feasible, this can be flagged when looking at the final report.
• Question 5: Do decisions to not disclose data need to go to ICANN Compliance?
• ICANN Compliance does not need to be notified of all rejected requests
• Compliance should have access to all of the same information as the CGM, but the CGM does not have to send every single one
• Compliance reports should be limited to exceptional circumstances
• Question 6 There is disagreement on the following text in e): “including, for example, an analysis and explanation of how the balancing test was applied (if applicable).” Some commenters believe this should be removed because the determination should be lightweight to avoid including personal information, while others agree it should remain. Note, this sentence included ‘for example’ and (if applicable) to make clear that this is not a requirement but could be the type of information that may help the requestor understand the rationale for the decision.
• This is a for example – there are circumstances where the reasoning cannot be provided in order to protect the data subject
• This may overlap on rec. 6 with contracted party authorization spelled out in section 5 – the rationale for the denial must be documented with care taken to not disclose personal information.
• Staff to review if this could this be integrated into Recommendation 6.
• Question 7 Regarding the text, “Additionally, in its response, the entity receiving the access/disclosure request MUST include information on how public registration data can be obtained,” a Contracted Party may be unaware of every source where the specifically-requested public data is available. Could this be changed to a MAY? Or, alternatively, could the CGM provide a message to requestors, noting how to access public information via RDAP? Additionally, if a requestor is repeatedly using the SSAD to obtain information that is available elsewhere, is that abusive behavior?
• Do not like having CP responsible for identifying where data can be publicly obtained – better approach would be for CGM provide information re: RDAP is a better approach.
• Propose to change the must to a may
• It does not matter what information is on the website b/c the registrant is the one who is responsible, so information on a website is the answer to a WHOIS inquiry
• Urgent requests
• Can Mark SV. and Volker work together an updating the definition of urgent requests?
• At this stage, do not feel comfortable expanding the scope without additional safeguards

2. Confirm next steps

5. Recommendation #11 – Disclosure Requirements (20 minutes)

1. Review discussion items gleaned from input provided on recommendation #11 discussion table
2. Confirm next steps

6. Recommendation #6 – CP Authorization (20 minutes)

3. Review discussion items gleaned from input provided on recommendation #6 discussion table
4. Confirm next steps

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

1. Thursday 30 April at 14.00 UTC. Topic to be addressed: Authorization automated, Automation, Recommendations not considered by EPDP
2. Confirm action items
3. Confirm questions for ICANN Org, if any