Dear RDA Scoping Team Members, Please find below the notes and action items from today’s meeting. The next meeting will be Thursday, 26 May at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items 1. Brian G. to inquire with ICANN org colleagues if there is any update or further information that can be provided regarding the status of the DPA during the next meeting on Thursday, 26 May. 2. Scoping Team members to provide an update to their respective stakeholders group with respect to today's discussion about the draft EDPB communication, particularly with respect to scenario 2 and a data protection impact assessment (DPIA) of Scenario 2. Please provide any proposed updates by Friday, 27 May. https://docs.google.com/document/d/1rCBaQ175p_VrP6DtxLUuuoO9Uv5C2qp_/edit 3. Policy Support Staff to incorporate changes agreed to during today's call into the write-up of assignments 1 and 2 by Friday, 20 May. 4. Scoping Team members to review all comments received on the write-up and propose compromise language in comments form (where applicable) in advance of next week's call (by Wednesday, 25 May). https://docs.google.com/document/d/13sP-2z7rusEYrDyntrgm-tcIavPMJndU/edit 5. Scoping Team members to review the newly-circulated write up of C.2.2 and propose edits/comments in comment form by Wednesday, 25 May. https://docs.google.com/document/d/1CYs9mLHsKcZevmZtFrQBDXbv_nkQ5PKe/edit by Wednesday, 25 May. Registration Data Accuracy Scoping Team – Meeting #30 Thursday 19 May at 14.00 UTC 1. Welcome & Chair Updates (5 minutes) * ICANN74 tentative agenda (see https://community.icann.org/x/KRR1Cw) & registration for session * If any members plan to attend ICANN74 in person, please register and reserve your spot for the session – please check your email, as the information has been sent to the list. 2. Scenarios for EDPB - see update from ICANN org (https://mm.icann.org/pipermail/gnso-accuracy-st/2022-May/000444.html) (15 minutes) * Review Scoping Team input (see https://docs.google.com/document/d/1rCBaQ175p_VrP6DtxLUuuoO9Uv5C2qp_/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1rCBaQ175p_VrP...>) * There was a comment from ICANN org, and it seems to change the overall area for discussion and may change earlier comments from others. Can the group get clarification? Specifically, the document starts off with scenarios with EDPB, and some of the scenarios don’t seem to need permission – that seems to change the scope of the document. The document seems to be going in two different directions – what is this document for? * ICANN was instructed to go and think about scenarios and steps that it could take in furtherance of registration data accuracy – Org looked at what it can do under the current agreements and policies. If the group wants ICANN to look at scenarios that are outside of what it can do under the current agreements and policies, ICANN can do that, but started with what it believes it can do. * This does not address the concern as this was driven by the board’s request to see what could possibly be done in the future. * The ultimate consumer of the data is not the registrars and not ICANN org, so the gold standard is to ask the requestors what they want and need. Asking ICANN org to come up with scenarios should be a proxy for asking what the ultimate consumers of the data should want. Looking at the contract, it’s understandable why that is a focus, but it is, at most, secondary, as it doesn’t describe what could or should be done. * Not suggesting that ICANN should act beyond its current remit – the document was confusing because there is a number of scenarios, and there are scenarios for processing of non-personal data, but it’s good to understand that only the scenarios that involve the processing of personal data would be sent to the EDPB. The second scenario seems the most relevant here. * There are 4 scenarios in the document: * Scenario 1: Analyze publicly available registration data for syntactical and operational accuracy (as was done previously in the WHOIS ARS program). * Scenario 2: Analyze a sample of full registration data provided by registrars to ICANN org. * Scenario 3: Proactive Contractual Compliance audit of registrar compliance with registration data validation and verification requirements. * Scenario 4: Registrar registration data accuracy survey (voluntary). * Do any members believe there are any scenarios missing from this list? * Two scenarios were added by a member: * Restarting the ARS with the same sampling methodolgy as before, but requiring Registrars to provide the full set of contact information (clearly in an automated way). ICANN would have to specify how long the information would be kept and in detail how and by whom it would be processed. * A complete or partial retrieval of contact info on a registrar by registra basis (essentially an accuracy audit) with anaylsis similar to that used in the ARS. * These example scenarios that were added seem to fall under Scenario 2. The first is ARS and the second is similar to ARS – both involve ICANN processing data that is sent to it. * One scenario the group had talked about is instead of doing a survey of all of the data, the group talked about doing a survey on domain names that are subject to DAAR reporting. If the group does not provide the specificity of a sample of registration data, the EDPB may say that ICANN trying to survey all 200+ MM names would probably not suffice under Art. 6; however, if there is a narrower scoping, that may be more acceptable. There could be more scoping on the sampling. * Supportive of ICANN meeting its compliance needs, but concerned with the group getting too in the weeds with what ICANN needs to do to meet its needs, and the community does not direct ICANN compliance – ICANN needs to evaluate its own legitimate interests. The group should be careful about telling ICANN what it needs to do since these are questions from ICANN, not the community. * It would be shortsighted to miss the opportunity to ask questions of the EDPB based upon work and subject matter that this group has been deliberating for the last eight months. * The group needs to appreciate its roles and responsibilities as parties – there is a lot of work going on these types of issues. Not saying not to ask questions; rather, thank you, ICANN, for asking these questions. However, this seems to be an ICANN internal risk evaluation. This group can say what we think ICANN’s role is and what is needed to process data properly, but wanted to make the point that ICANN should be careful about saying what Compliance’s job is. (in other words, support this outreach, without directing) * What happens if we, this team, agree on a set of questions the team would like asked? If we forward these to ICANN org as part of their engagement with the EPDB but not presupposing on behalf of ICANN org, and ICANN org chooses not to include them. The question is – is ICANN not including the questions, does this team send its own communication to the EDPB? * Perhaps deal with this if it happens. This is a confrontation b/w the team, ICANN org, and the GNSO. ARS is not a compliance issue, so we are not looking at this from a compliance perspective. GDPR does not allow ICANN to do what it did before. Four years into this process, ICANN org has chosen not to go to the EPDB to see if it can continue its work is its choice. We should ask these questions. * We are still dealing with the same data from registrars, and now we are looking at a small subset of what we are doing to discuss the data. ICANN is meant to specify business processes. It is unclear what role ICANN wants to play. EDPB will likely give ICANN the same response – do your homework – write up the processes and your role. EPDB is not legal counsel for ICANN. These are questions for ICANN to answer, and those who believe we should not direct ICANN to answer specific questions are spot on. * As part of the last guidance of “do your homework,” do you believe having a DPA b/w ICANN and CPs is a prerequisite to that homework assignment before the EPDB can further opine? * The first thing that would need to be done is to do a DPIA, and would ask ICANN org if there is a DPIA. * Within this communication, ICANN notes it is planning to do a DPIA on at least one of the scenarios – scenario 2 * Given the discussion about the broad breadth of scenario 2, could ICANN consult with the community about the specificity of scenario 2 before a DPIA is undertaken? * In sending this request to this team, ICANN is looking for this team’s input on these scenarios. Hoping to get some input or specific links to compliance would be helpful to include. * Believe the two added scenarios are very different – one is a sample based on randomness or DAAR and the other is a registrar audit that could, in theory, request all of the data. The terms that would ultimately have to go into the RAA to allow those would be quite different. The group will have to a lot of homework on this. Because the impacts on privacy may be different depending on what the group does, the group will need to be very specific. * The group has veered from the assignment – focus on the scenarios that ICANN has requested input on and not get into too much detail here. A DPIA would be great, but that is a different assignment than reviewing scenarios that are to be sent to the EDPB. * Perhaps the group pause on this analysis today and each group go back with respect to Scenario 2 with a further level of detail, acknowledging that ICANN org is doing a DPIA on Scenario 2 * It could also be useful to know the status with respect to controllership agreements – that could change the whole picture. We know there is supposed to be negotiations with respect to the Phase 1 implementations and this would be useful in understanding the overall picture. * Action Item: ICANN org to report back on the status of the DPA negotiations. * This seems tangential to the discussion of accuracy. Controllership is not relevant to accuracy. This does not give the group a picture of the status of accuracy. Who the controller is does not inform on the accuracy levels – these two questions should be separate. * If the group is going to look at what actions ICANN org can take, then the controllership questions are relevant to the EDPB. * Encourage all members to go back to their respective stakeholder groups and update them on today’s conversation, specifically the potential DPIA on Scenario 2. * The original deadline was 23 May – is more time needed, and if so, how much more time is needed? * One more week would be helpful. This concept of engagement with the EDPB was introduced to the group at ICANN73. * In terms of timing, the questions are being drafted and the discussion and input on the scenarios is an important part of that – goal is to submit these as soon as possible, though there is some prep work that needs to get done so they are received in the most effective manner and that may involve conversations with members of the EC. It seems that asking the questions is part of the DPIA in a sense, but to the extent that it makes sense to go to the EDPB with a DPIA in hand is a reasonably good suggestion and could be done rather quickly. * What definition of accuracy would the group like to use – is it the existing definition in the RAA or is it a new definition? * Scenario 2 – the response or input we get could be broad enough to cover Org for edge or sub-scenarios * The DPIA should flow easily from the chosen scenario(s) * Confirm next steps 1. Write up for assignments #1 & #2 (see https://docs.google.com/document/d/13sP-2z7rusEYrDyntrgm-tcIavPMJndU/edit[docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/13sP-2z7rusEYrDyntrgm-tcIavPMJndU/edit__;!!PtGJab4!-cQ5xs34J7SLOT_OCZ0MkPoKz0xOKPsmUfF1Dw9oYBjgVHkPxOiz1y6jXE15VFkOAH5g3ro-hMGaNH_OyK5IYe2B5xF-1Gm4GLPy$>) (30 minutes) * Review input received * Suggest removing “of particular relevance” * No objection to removing this from the group * Agreement to strike this comment - how certain Registry Operators as part of ICANN's compliance audit have had to provide proof of Registrant verification. If we are looking to provide a complete and accurate snapshot of our work I think it would be prudent to include in this section * To mirror what is found in other sections, pulling out and highlighting certain sections may place more weight on them than is intended. Viewing the information in full, on the other hand, is preferable. All of the information from Compliance was helpful – proposal to remove bullets and cite the full compliance response. * Agree that the full document should be cited; however, an obscure pointer to the document is unhelpful – it’s preferred to include the salient references. * Could the group consider leaving the bullets as they are but including the full compliance response as an annex, rather than just a link? * The language should be high-level – there is a reference in the second bullet to V1 and V2 – these should be stricken for the sake of readability * Are there any objections to striking references to V1 and V2? * There may be confusion here since V1 and V2 may come from the original question that was asked. Perhaps removing these references may be sufficient to avoid this confusion. * Suggestion to keep the word willfully as that is part of the RAA. * Suggestion to defer this discussion until next week. * Please look at the document and weigh in before the next call, particularly if there is a middle ground proposal. * Also shared a write up for C.2.2. – please put questions or concerns in the form of comments. * Confirm next steps 1. Write up for Section 2.1.2 – Measurement of whether current goals are met (see https://docs.google.com/document/d/1CYs9mLHsKcZevmZtFrQBDXbv_nkQ5PKe/edit [docs.google.com]<https://docs.google.com/document/d/1CYs9mLHsKcZevmZtFrQBDXbv_nkQ5PKe/edit%20...>) (15 minutes) * Review input received * Confirm next steps 1. Confirm action items & next meeting (Thursday 26 May at 14.00 UTC)