Dear EPDP Team, Please find below the proposed agenda for tomorrow’s EPDP Team meeting. We are aware that some groups have added or are adding input after the deadline to the document for agenda item #3a, so please come prepared to speak up during the meeting. The write up that has been produced by the Staff Support Team (see attached) is based on the input that was received by the deadline from the BC, RrSG and the SSAC; however, this does not prevent other groups from weighing in and providing specific suggestions for additions and/or changes when this document gets posted as a google doc following Tuesday’s meeting. Thank you. Best regards, Berry, Marika, and Caitlin -- EPDP Phase 2A - Meeting #19 Proposed Agenda Tuesday 4 May 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Feasibility of unique contacts (30 minutes) 1. Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement. 2. If feasible, but not a requirement, what guidance, if any, can be provided to Contracted Parties who may want to implement uniform anonymized email addresses. * Review input received (groups that provided input to provide high level overview of their input – BC, RrSG, SSAC) * Walk through of staff proposed write up of Initial Report text * Confirm next steps – proposed deadline for comments / suggestions / proposed edits Friday 7 May 2021 4. Legal vs. natural (45 minutes) 1. Whether any updates are required to the EPDP Phase 1 recommendation on this topic (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so“); 2. What guidance, if any, can be provided to Registrars and/or Registries who differentiate between registrations of legal and natural persons. Guidance write up * Consider outstanding questions: Guidance #3 - As part of the implementation, Registrars should consider using a type of flag in the RDDS or their own data sets that would indicate the type of data it concerns (personal or non-personal data) as this could facilitate review of disclosure requests via SSAD and the return of non-personal data of legal persons by systems other than SSAD (such as Whois or RDAP). A flagging mechanism could also assist in indicating changes to the type of data in the registration data field(s). 1. ALAC has suggested that more specificity should be provided to Registrars about how this implementation could work especially in relation to how a ‘flag’ could be applied. Would it be helpful to provide further guidance on how this could be implemented or does that make it too prescriptive? The current guidance already includes references to the use of a type of flag – what is missing that would be helpful for Registrars to know? Example scenarios (note, these scenarios are intended to be illustrations for how a Registrar could apply the guidance above. These scenarios are NOT to be considered guidance in and of itself). 2. EPDP Team to consider whether or not these scenarios should remain or whether they should be replaced by the RrSG table as suggested by ALAC. If there is agreement that scenarios should remain as examples, EPDP Team to consider whether scenario #3 (Registrar determines type based on data provided) should remain as some concerns have been expressed by NCSG in relation to the Registrar making an initial assessment about whether or not the registrant is a legal or a natural person. Note, updates were made to ensure that the Registrant is requested to confirm this assessment. Scenario #2 - Data subject self-identification at time when registration is updated a. The Registrar collects Registration Data and provisionally redacts the data. b. The Registrar informs the Registrant (per guidance #3 above) and requests the Registrant (data subject) to designate legal or natural person type. The Registrar must also request the Registrant to confirm whether only non-personal data is provided for legal person type.[1] c. Registrant (data subject) indicates legal or natural person type and whether or not the registration contains personal information after registration is completed. For example, the Registrant may confirm person type at the time of initial data verification, in response to its receipt of the Whois data reminder email for existing registrations, or through a separate notice requesting self-identification.[2] d. If the data subject identifies as a legal person and confirms that the registration data does not include personal data, the Registrar should (i) contact the provided contact details to verify the Registrant claim[3] (ii) set the registration data set to automated disclosure in response to SSAD queries and (iii) publish the data. 3. The GAC has suggested that it might be helpful to add some timelines to this scenario. How could/should such a timeline look? Registrars shall not be prohibited from voluntarily utilizing a third party to verify that a registrant has correctly identified its data[4], provided that such verification is compliant with applicable data protection regulations. 4. Proposed language changes from Volker were applied to make clear that third party verification is not disallowed, but neither specifically recommended. NCSG has noted its objection to this rewrite as it would make scenario 3 ten times worse. EPDP Team to consider concerns and determine if/how these can be addressed. Note, the Bird & Bird advice specifically talks about the option to verify information provided by the registrant. 5. Expected Homework assignments (5 minutes) · By Friday 7 May, EPDP Team to review proposed feasibility of unique contacts write up for Initial Report (to be posted as google doc after meeting). Please provide comments, suggestions and proposed edits in the form of comments. · By Friday 7 May, EPDP Team to review updated version of legal/natural guidance write up (to be circulated after meeting) and indicate which aspects, if any, your group cannot live with for inclusion in the Initial Report. · By Friday 7 May, GAC and RrSG Team to review updated version of write up (link to be circulated after meeting) and to indicate to EPDP Team if GAC updated proposal and RrSG table, respectively, need to be included, where it would be included and what aspects it would cover that are currently not addressed in the write up. Please provide your response via the mailing list. 6. Wrap and confirm next EPDP Team meeting (5 minutes): 1. EPDP Team Meeting #20 Thursday 6 May at 14.00 UTC 2. Confirm action items 3. Confirm questions for ICANN Org, if any ________________________________ [1] Note that the confirmation that only non-personal data is provided could also happen at a later point in time. However, until the Registrant confirms that no personal data is present in the registration data, the Registrar does not set the registration data to automated disclosure. [2] Note, the implementation of EPDP Phase 1, recommendation #12 (Organization Field) may facilitate the process of self-identification. [3] Per the guidance<https://community.icann.org/download/attachments/155191493/ICANN%20-%20EPDP%...> provided by Bird & Bird, “this verification method is advisable, and will help reduce risk. That risk reduction will be greatest if there is a reasonable grace period within which the objection can be lodged, before the data in question is published in the Registration Data” and “requiring an affirmative response to verification mailings seems over-cautious, unless and until studies show that the measures adopted are failing to keep very substantial amounts of personal data out of published Registration Data. However, if a verification email “bounces” (i.e. a Contracting Party knows it was not delivered), then it would be better if publication does not proceed”. [4] Per the guidance<https://community.icann.org/download/attachments/155191493/ICANN%20-%20EPDP%...> provided by Bird & Bird, “a company registration number may be another means of verifying legal personhood”.