Dear EPDP Team, Below, please find the notes and action items from today’s EPDP meeting. As a reminder, the next meeting will be Thursday, 10 October at 1400 UTC. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #23 Tuesday, 8 October 2019 at 14.00 UTC Action Items If any Team members disagree with the structure or overall approach of the accreditation building block proposal, please notify the list in advance of Thursday’s meeting. Based on today’s meeting, James Bladel to work with board liaisons and edit the last sentence of the Board questions letter. James to send updated letter to the Team for a 24-hour silent review period. Absent any objections, EPDP Support Staff to send the letter to the Board. Margie and Amr to work together to find a mutually acceptable solution to subsection C of Building Block D to share with the group by Friday, 11 October. Support Staff to reach out to Thomas regarding Building Block H, Subsection b. In absence of suggestion from Thomas, “or subset thereof” will be deleted. Margie to circulate the previously-suggested logging criteria from the BC accreditation model, and Support Staff to update the new auditing/logging building block accordingly. Support Staff to check the building blocks for consistency - specifically, review the text to ensure there is no reference to notifications to the data subject on a per-disclosure basis Support Staff to organize a conference call with interested members, including James, Chris and Amr to work together on compromise solution for Building Block H, Subpoint J re: confidentiality of LEA requests by Friday, 11 October. Support Staff to edit Subpoint C of Building Block A to address Volker’s concern regarding information provided by the requestor to be specific to the domain name for which disclosure is requested. Following receipt of edited text from Support Staff, EPDP Team will have 24 hours for silent review to express objections. Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ . 1. Roll Call & SOI Updates (5 minutes) · Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Welcome of new ICANN Org liaison – Eleeza Agopian b) Accreditation building block homework · Support Staff distributed the accreditation building block document, which incorporates input provided from the group’s submissions · Document separates policy principles and implementation-related guidance · A list of definitions from Alex Deacon’s proposal is also included · Team Members should review this document and come prepared to discuss during Thursday’s meeting · Question: should Team members wait until Thursday’s discussion to provide feedback? · EPDP Leadership is looking to see if the overall approach is acceptable to the group. The EPDP Team is welcome to provide feedback on the details of the accreditation building block in advance in the form of comments to the Google doc. · If any Team members disagree with the structure of the accreditation building block proposal, please provide this feedback in advance of Thursday’s meeting. c) Status of building blocks · The Team’s timeline is currently at risk. · Team members are encouraged to provide feedback to the building blocks in advance of meetings. Work conducted offline will help the Team in meeting the project timeline goals. 4. Finalization of questions to ICANN Org / ICANN Board a) Introduction of letter developed by CPH (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-October/002580.html) · This letter is the culmination of a discussion that began during the F2F. · The letter puts a point on the question of ICANN org’s involvement in the operation and development of an SSAD system. The Team needs an answer to this question now. · The Team seems aligned that ICANN should have some sort of role in this, but the concern is what if the Board says it will not accept the model the EPDP Team agrees to. b) Feedback from EPDP Team · Perhaps the questions from Marc A’s document should be attached to these questions · Last sentence of the message - absent input from the Board, the Team may come up with recommendations that are not palatable to the Board. With a slight tweak in the language, this message could be more clear · The intention is to note that the risk is that the EPDP Team puts together a set of recommendations that is unacceptable to the Board, and the last year of the Team’s work becomes a sunk cost. The Team needs an answer to ICANN’s willingness to accept risk. Important to not allow the ambiguity to continue. · The clearer the questions are, the clearer the response from the Board will be · Based on today’s conversation, James to work with board liaisons and edit the last sentence of the letter. Once completed, the letter will be sent to the Team for 24 hours of review. Absent any objections, EPDP Support Staff to send the letter to the Board. c) Confirm next steps 5. Acceptable use policy (building block d & h) – Second reading (15 minutes) a) Overview of updates made following first reading b) Feedback from EPDP Team Building Block D Subpoint b · With respect to audits, the Team should be clear on what can be audited and how. No objections to the concept of auditing, but additional clarity may be helpful. · The BC accreditation model includes an example of what auditing could look like - there could be a cross-reference to that building block · After the striking of (no bulk access), the Team would include a reference to the auditing building block in terms of what items can be audited · The requestor should keep a record of its data processing                                                 Subpoint c · Similar to subpoint b, the references to auditing should be moved to the auditing building block so there is clarity with respect to auditing and what that includes · The reworded language captures the importance of only using the data for the purposes for which the data was requested · Uncomfortable with this language “consistent with” · Proposal from Brian - the requestor will only use the data for the purpose it was requested · There may be multiple purposes. If a phishing attack involves a trademark, would not want to prevent using the data for cybersecurity. · Proposal to use “not processed further in a manner that is incompatible with the specified purpose” · If an individual gets access to data, they are a controller, and the concept of secondary purposes is under their remit. In the code of conduct, there should be a limit to the purpose for which it was collected. · Disclosing party has to ensure that the new controller is processing the data in a compliant fashion · Put subsection C in square brackets - Margie and Amr to work together to find a mutually acceptable solution to share with the group by Friday, 11 October. Building Block H Subpoint B · Support Staff to reach out to Thomas regarding Subsection b. In absence of suggestion from Thomas, “or subset thereof” will be deleted.                                                 Subpoint D · This text should be included in the auditing/logging building block · The question marked in the document does need to be addressed - are there any volunteers to suggest ideas for the logging requirements · In the BC accreditation model, there were some suggestions for what needs to be included in the logs · Margie to circulate the previously-suggested from the accreditation model, and Support Staff to update the building block accordingly.                                                 Subpoint E · This should be removed · Why is the balancing test called out here, but no other tests (like the purpose test)? Subpoint C already covers this. · Disagree that this is redundant - it is up to the EPDP Team to provide as much implementation guidance as possible. · Important to qualify the balancing test for when it is required · Take off the square brackets and retain the proposed text                                                 Subpoint F · How would the data subject be able to object to the balancing test after it had been done? · This section is not supported under GDPR - if it does come from GDPR, this should be tracked in this section. · Should this be deleted? · This should not be deleted, but it is a fair question - the GDPR does not explicitly say that a data subject may challenge the outcome of a balancing test, but the GDPR does make allowances for data subjects to challenge the use of their data. · Delete this for now, and provisionally open a new building block for the rights of the data subject, and come up with something workable - how the data subject could interact with SSAD · The data subject’s rights under GDPR will depend on who the controller is - this may belong in another section like what information needs to be provided to registrants · https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-g... right to object
 - review this in conjunction with new building block                                                 Subpoint G · G and J are closely tied - there needs to be a carve-out for law enforcement where confidentiality is necessary · G and J should be part of the same subsection or next to each other · This is also closely tied to the objection to the processing of the data - · Is there a mandatory requirement under GDPR to notify a party when data is disclosed to a third party? · During the registration process, Rys and Rrs would disclose that the information may be disclosed to a third party and the circumstances under which that would be done. · May need to cross-check previous documents that there is no notification to the data subject on a per-disclosure basis                                                 Subpoint J · If there is an LEA request for non-public data and that request includes withholding notification to the data subject - this should come out of SSAD and be part of the due process on a jurisdiction by jurisdiction basis. LEA should use their respective local authority to get a warrant/court order. · LEA may need to use abilities to compel GoDaddy, an MLAT is necessary and that would take months. LEA would like the right to ask the company not to notify the data subject due to an ongoing investigation · This effort cannot be 100% focused on the ease and convenience on the access of the data - this seems like there needs to be a warrant or a court order - it’s not in the Team’s remit to create a bypass here · Within the SSAD, there should be an ability to designate things as confidential and urgent · Regarding logging - everything needs to be logged (including law enforcement) for the sake of auditing · If there is no law enforcement through the SSAD, where are we doing it? Another PDP? · Everything should go in through the SSAD, but not every decision needs to be made through the SSAD · This is not an attempt to fix MLATs - trying to produce a system where the system is logged, and certain logs have a higher bar to being released · Action: James and Chris to work together to work on Subpoint J to come up with a compromise by Friday, 11 October.                                                 Subpoint K · Need to call out unaccredited privacy/proxy data - privacy/proxy data has to be disclosed · Affiliated privacy/proxy data would not be redacted, so this may not be applicable here. · This is not appropriate here - this should say data that clearly does not contain data of a natural person · The focus should be on the data itself, not natural vs. legal persons · Concerned with the word “must” - there may be examples of legal persons that are protected (battered women’s shelters, for example) · Potential rewrite “…must not disclose non-public data of clearly identifiable as a data subject protected under applicable data protection regimes.” c) Confirm next steps 6. Criteria & content of requests (building block a) – Second reading (15 minutes) a) Overview of updates made following first reading b) Feedback from EPDP Team Subpoint A · Ensure this does not prevent reverse whois look-ups Subpoint B · Insert Brian’s addition, as there were no objections                                                 Subpoint C · The info provided should be specific to the domain name for which disclosure is requested Subpoint D · Ask for affirmation, and have additions in the AUP Regarding reverse WHOIS look-ups, since some Team members are wishing to take this issue up, can the Team agree to discuss the issue and include a specific question for public comment in the Initial Report? EPDP Feedback: · No. There was no issue scoping for this process. Since the community was not consulted in the scoping of this EPDP, this is not appropriate. · Potential compromise position: do not require it, do not prohibit it c) Confirm next steps 7. Receipt of acknowledgement (building block k) – second reading (if time allows) a) Overview of updates made following first reading b) Feedback from EPDP Team c) Confirm next steps 8. Wrap and confirm next EPDP Team meeting (5 minutes): a) Thursday 10 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any