Dear RDA Scoping Team members, Please find below the notes and action items from today’s meeting. The next meeting will be Thursday, 2 June at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items 1. EXTENDED: Scoping Team members to provide an update to their respective stakeholders group with respect to last week’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 Wednesday, 1 June. https://docs.google.com/document/d/1rCBaQ175p_VrP6DtxLUuuoO9Uv5C2qp_/edit 2. ❗️❗️❗️FINAL EXTENSION: Scoping Team members to review all comments received on the write-up and propose compromise language in comments form (where applicable) in advance by COB, Tuesday, 31 May. Please note this is the group's final opportunity to raise concerns with this document. https://docs.google.com/document/d/13sP-2z7rusEYrDyntrgm-tcIavPMJndU/edit. ❗️❗️❗️ 3. ❗️❗️❗️FINAL EXTENSION: Scoping Team members to review the newly-circulated write up of C.2.2 and propose edits/comments in comment form by COB, Tuesday, 31 May. https://docs.google.com/document/d/1CYs9mLHsKcZevmZtFrQBDXbv_nkQ5PKe/edit. ❗️❗️❗️ --- Registration Data Accuracy Scoping Team – Meeting #31 Thursday 26 May at 14.00 UTC 1. Welcome & Chair Updates (5 minutes) * Registration for ICANN74 has been open, and the availability to sign up for sessions is now available. Please remember to register in advance and for individual sessions. In-person slots will be limited, so please sign up for the sessions in advance. 2. Scenarios for EDPB - see update from ICANN org (https://mm.icann.org/pipermail/gnso-accuracy-st/2022-May/000444.html) (15 minutes) * Continue review of 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 does not appear to be any new comments added as of our last meeting. * There is still no feedback from the GAC, IPC, BC – this is concerning * This is one of the most important things the group has been asked to consider during its deliberations. * Previous attempts by ICANN org to the Belgian DPA or EDPB have not resulted in actionable guidance that moved policy deliberations forward. * At a certain point in time, it’s important to make these interventions count. Accordingly, it’s important to make these deliberations count and position ICANN for success. * Alan G. – will flesh out * The original date was 23 May, we extended it to 27 May. How much time does the group need? * Proposal: this group will meet in person at ICANN74. Believe this is very important – accordingly, do we dedicate the meeting in the Hague to this communication? * Do not agree with this approach – do not believe this will be sent to the EPDB in the next two weeks. ICANN org still has a lot of work to do in terms of a DPIA, so the timing is not that critical. The Council instructions ask important questions that the group has yet to tackle – what should accuracy look like in the future? * Org spoke with the GAC earlier – for a variety of reasons, the instructions are still that ICANN needs to work through the EC and the Belgian DPA – the plan is to start those conversations quite soon; however, that does not mean there has to be a completed letter or DPIA at this time. Timing – would like to get started on this soon, but there will be parallel preparatory work done along the way. * In terms of making the most constructive use of face-to-face time: one issue the group has struggled with is what does accuracy mean? If we, in this group, cannot come to an agreement of what accuracy is – that would be a very important item for this group to opine on both to ICANN and the DPA. * In terms of making use of face-to-face time – one issue the group has not reached consensus on is what the term accuracy even means. * This is not the right question – we need to know what levels of accuracy are needed with respect to various elements in the RDDS * The two definitions that we had – binary (either inaccurate or accurate) or there are degrees of accuracy * On the last call, the group should support ICANN, but it is ultimately their work. Do not know if it is within the scope of this group to do this work. We have not seen a DPIA or received a request from ICANN. If members need more help giving generalized feedback to ICANN, a few more days should be helpful. In terms of the definition, the write-up shows the agreed upon description of accuracy and the proposals to gather more data to inform the current description. Believe we should focus on this before going to assignments 3 and 4. * * 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-2z7rusEYr...>) (30 minutes) * Continue review of input received * When we talk about the description, this refers to existing requirements in the RAA * Manju provided a definition, and it may be helpful to try to coalesce around that * The concept of accuracy revolves around what kind of accuracy are we trying to require noting there are certain uncertainties. As an example of a change we might make in the future is instead of verifying one of two fields, they may be required to verify all field – this is just an example. * If people are not available to attend, there are alternates that can attend in their stead. There is a timeline, here, however – urge representatives to have alternates attend. * Probably best to keep this to describing current RAA definition. * Have to keep in mind the purpose of the collection when defining data protection terms * Do not believe Melina agrees with the addition of “degree of correctness,” but this is how contracted parties understand it – as it has to be measured against a specific standard * When looking at the assignment, everyone seems to agree what is written in the document – everyone agreed that this is what is provided for in the contracts and how it is enforced. The assignment asked for a current definition, and it appears that everyone agrees there is no current definition. * The problem with this definition is that it includes absolute terms – if we say something is free from PCBs, we assume there are no PCBs in it, if something is true, it is not false. However, correctness has flexibility depending on what the standard is. In this case, there seems to be a contradiction. * To go to Alan’s point, if something is complete and accurate, do we really need to verify it? That may be the cause of confusion here. One way to reconcile this – look to the identity space. There are three levels of identify assurance levels, you have been identity-proofed, but to what degree have you been identity-proofed? Using the terms true, complete, and free of error can scale. If GAC reps were here, would be asking them the question about identity verification since those definitions support a degree or range. * What is a specified standard? BC reps are concerned with actual registrant accuracy – in other words, is the data accurate for that particular registrant? There are many instances of identity theft, and this is a big problem. * This is not for assignments 1 and 2 – that is for later assignments. There is a difference b/w what members want accuracy to look like vs. what it does look like. In reading the definition, read the first and second part together – accuracy is generally […], but registration data accuracy is being defined […]. * Would it be possible to engage with the BC to see if the definition provides a current vs. future state – is this something the BC could live with – but under the specified standard, the BC finds it unacceptable for the following reason. The specified standard gives the group the flexibility to scale this to the future. What this specified standard is will become clearer through best practices through – and this allows it to grow and evolve over time. * Where does the second sentence originate from? * This text originally came from the RySG and NCSG added some language * There is a distinction between the absolute text – the group talks about validation and verification are not specifically defined * Is it possible to note how the group understands what these terms to mean – validation and verification rather than cite a specific source * Propose not to agonize over the definitions – just cite what is in the RAA * Confirm next steps * Due to lack of homework, the same assignments will be extended (for the final time) until next week 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://urldefense.com/v3/__https:/docs.google.com/document/d/1CYs9mLHsKcZev...>) (15 minutes) * Review input received * Confirm next steps 1. Confirm action items & next meeting (Thursday 2 June at 14.00 UTC)