I support Ayden’s requests that the Strawberry team vet their questions with us, take notes at their meetings with DPAs, and share those notes with us. Indeed, it would be nice if this request could be made on behalf of the entire EPDP team. What is the raison d’etre of the Strawberry team if it is not intended to assist us with our choices in developing policies? The only possible alternative is that they are working for ICANN org to advise it on its potential liabilities. But those liabilities will hinge very much on the policy choices we make, so I would think an ongoing close cooperation with Strawberry team would be useful for both of us. Can we convey this request to ICANN org? Dr. Milton L Mueller Georgia Institute of Technology School of Public Policy From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Ayden Férdeline Sent: Thursday, September 12, 2019 9:08 PM To: Caitlin Tubergen <caitlin.tubergen@icann.org> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] High-level notes and action items - EPDP Team F2F - 9-11 September Thanks to Staff for collating these notes and action items. Just one observation I had: under accreditation bodies, I believe we agreed that there should be a means for individuals (and not just legal entities) to have a potential track to request non-public registration data without being accredited in any fashion. Also, I appreciate that it was not agreed as an action item, but is there any way in which we might be able to keep an open dialogue with the Strawberry Team and - importantly - to see their questions they plan to submit to the European Data Protection Board before they are submitted to any external party? I think we can all appreciate they would be in draft form - that's why we would like to help get the wording (and sentiment) correct, and to avoid reputational damage to ICANN if the wrong questions are asked. I realise this was requested already, and there was pushback from the Strawberry Team, but I think it's important and inconsistent with ICANN's stated commitments to transparency that we are all ignorant as to what is being asked that has a high potential to impact our work. Finally, I have previously asked to see Staff Notes from meetings with DPAs, and I have been told that no notes were taken and thus there is nothing to share. Can I please request that the Strawberry Team immediately take notes after their upcoming meeting(s) so that we have more of an idea as to what the reaction of the external parties was to the questions asked. I am not sure who the appropriate person is to channel this request through to. Thank you. And thanks for your efforts coordinating the meeting this week. Kind regards, Ayden Férdeline ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, 13 September 2019 02:39, Caitlin Tubergen <caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear EPDP Team: Below, please find high-level notes and action items from the face-to-face meeting. As a reminder, the next EPDP Phase 2 meeting will be Thursday, 19 September at 14:00 UTC. The Legal Committee will meet on Tuesday, 17 September at 14:00 UTC. Wishing everyone safe travels home. Best regards, Marika, Berry, and Caitlin -- Action Items 1. Alex Deacon, Milton Mueller and other willing volunteers to draft a write up of a potential accreditation model, taking into account the Team’s F2F discussions, in advance of the Thursday, 19 September meeting. 2. IPC, BC, SSAC, and GAC reps to separately draft a vision for their “ideal accreditation model” in order to assist the group with what the baseline accreditation requirements could be as well as the attendant benefits of accreditation within the architecture of an SSAD by Wednesday, September 18. 3. Support Staff to create a table (in the form of a Google Doc) which includes a column for each lawful basis and a column for what a requesting party would be required to provide in its request, what is the expected response time, is automation likely, what are the standardized categories that may fall within that lawful basis, etc. Following receipt of the table, the EPDP Team members to populate the contents of the table. If there are commonalities, policy recommendations can be drafted accordingly. 4. Support staff to create a Google Doc in which EPDP Team Members are to review and consider the types of disclosure decision models (in other words, who is making the ultimate determination to disclose non-public registration data - contracted party or ICANN) and what would make these options acceptable to the different groups by Thursday, September 19. 5. EPDP Team to review the legal memos and come back with the most relevant points that need to be factored in as the Staff Support Team produces the 1.0 draft by Thursday, September 19. 6. James and Mark Sv. to work together on a revised proposal for Building Block L (SSAD query policy) by Thursday, September 19. When discussing updates to Building Block L, Team members to consider if it is within the Team’s charter to continue discussing this issue. 7. Matt C. to review the legal advice on how to perform the balancing test and update Alan Woods’ initial balancing test document into a simple guide to conduct the balancing test to be included in the next iteration of the zero draft by Thursday, September 19. 8. Contracted party Team members to draft letter to ICANN Board, outlining scenarios discussed, including where the disclosure decision lies within the SSAD, and inquire whether there are any options the Board would not be amenable to. High-level Notes ACCREDITATION–Building Block F Straw Proposals Presented prior to Discussion: Milton Mueller and Alex Deacon Outcome / Agreements * EPDP Team did not agree on accreditation process or assignments; however, it agreed that a small group would consider the Team’s discussion during the F2F and develop a proposal for a subsequent discussion. * The EPDP Team agreed to separate authentication from authorization. The team did not agree that the accreditor would perform the authorization function. Discussion Notes Purpose • Remove burden from entity providing disclosure • Provide code of contract or series of contracts • Spread liability (without diminishing protections for data subjects) • Provide process pathway to track data / monitoring Who serves as accreditor • Entity develops request or proposal • Competent authority with legal basis; demonstrates consistency with Article 42 and 43 • EPDP sets outline and principles and assessment activities Accreditor Tasks Authentication – confirm identity Establish preliminary determination on lawful basis Consider how to manage volume requests NOTE: Authorization process is not necessarily with the accreditor. Sub-team will consider whether Authorization should rest with another entity or with the accreditor or unique criteria Role: Certifying Accreditor No Agreement, options discussed: • ICANN – difficult because they process of data • Independent Data Trust • DPA Role: Accreditation Body(ies) • WIPO • Law enforcement­–each country would have one entry point. i.e. in U.S. it might be FBI or in other countries, it would be the national country. • Europol and Interpol–agree this is not possible for law enforcement agencies, at least not for certain countries • Limit # of accrediting bodies to be able to manage system • Create track for entities that are not accredited Role: Auditor Agree that auditing is needed; unclear who should conduct audits Role & Process: De-Accreditation EPDP agrees that de-accreditation should be a component Accreditor must be compliant with DPAs Need to establish how to do this, such as: • Safeguards, prevent entity from setting up shop next door • Remedial action, i.e. may not shut down immediately, some corrective action is possible Decision to Disclose Joint Controller Who Balances? Entity with Legal Basis Options: Who Decides? {Note: EPDP did not decide on preferred option in LA. Group will consider options and potentially write a letter to Board to frame questions} JC Agreement • Responsibilities identified in agreement; CPs cannot increase their risk • Must be correct to manage liability / risk • Liability is clearly defined (ICANN or CPs) • Establish Joint and Severable Liability Contracted Parties ICANN Independent Data Trust PROS/CONS + Most accountable to data subject + Has physical access to data - Lack of consistency with hundreds of CPs applying policy to make decision to disclose - ICANN unable to indemnify CPs (maybe, shared risk possible) + Bird & Bird Memo states that CPs are controllers and retain liabilities PROS/CONS + Reduce risk of liability to CPs + Provides consistency + One party that performs decision and auditing role might be preferable + Build body of work / decisions consistently Considerations for all Options Standardized clearing house Timely Response Insurance to alleviate risk or establishing risk fund may be possible ICANN sets rules so it has to be a joint controller SSAD Not required by law Goal = predictable Easier [Processing Tasks § Decision to disclose § Decision on data set to be disclosed § Transfer of data] Building Block N, Financial Sustainability Outcome: Staff to develop Draft 1.0 with implementation guidelines consistent with the F2F discussion. Note: The EPDP noted the need to make SSAD Determination and consider cost-benefit analysis before finalizing approach to financial sustainability. Set Up Cost of Providing and Making Available an Investigative Tool Cost Sharing Share cost across the system Direct and indirect beneficiaries Share costs across the system CPs contribute intangible resources via in-house staff, etc. Use Look at other Models ANTICIPATED BENEFITS: Certainty to Process ­ Cost Savings FLIP CHARTS Each stakeholder group contributed principles / ideas to ignite the conversation. SSAC All participants have costs: * Central system = ICANN * CPs: receive, review, reply * Requestors: accreditation, query-making Issue subsidies? Letting market work RDS as basic service / core service Passing costs to requestors: May burden victims. GAC 1. Any financing model should not be profit/revenue generating 2. System should not provide financial disincentives to requestors acting on behalf of public authorities CPH 1. Any financial model should not be profit/revenue generating 2. Cost Neutral and borne by beneficiaries 3. Not a hidden tax / pass through charge to registrants / data subject 4. Integration costs represent CPH contributions ALAC Consider: • Costs • Cost Savings • Accreditation costs borne by users • Charge / Requestor: consideration of public interest exception • Chares passed through to registrants seems inevitable (it’s part of the infrastructure) NCSG Costs [potential funder] 1. Capital / set up costs [Large Users] 2. Accreditation costs [Flat fee per time period] 3. Usage costs (per request) [per request fee, cost-based. Higher for non-accredited] 4. Insurance costs [unsure] 5. Audit / enforcements [unsure, ICANN / DPAs?] CSG OK for cost-sharing to vary by volume, requestor type, legal obligation, etc. Fees on per-request basis are problematic Must not create disincentives to costs reductions