Dear EPDP Team, Please find below the notes and action items<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdV...> from today’s meeting. The next meeting will be Tuesday, 11 May 2021 at 14:00 UTC. Best regards, Berry, Marika, and Caitlin -- 🚨 Action Items 🚨 Please refer to the project spreadsheet<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdV...> for action items. EPDP Phase 2A - Meeting #20 Proposed Agenda Thursday 6 May 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) * Re: timeline – If the group chooses to publish an initial report for public comment, the comment period will be the standard 40 days. That will likely mean the Final Report will be submitted to the Council in August. 3. Legal vs. natural (60 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. Bird & Bird Response to Question #3<https://community.icann.org/download/attachments/155191493/ICANN%20EDPB%202a...> * High level overview (Becky) * B&B concludes – overall, the cited documents do not affect the previous answers to Q1 and 2 – in other words, the cited documents do not affect the previous assessment of risk. * Response: the entire focus has been on what information should be made public, but the larger picture is that we are picturing that there will be differentiated access. Would this analysis change if the info is gated? * When you are processing personal data under GDPR, you have to rely on 6(1)(f) balancing test. What weighs in on the balancing test – having credentials, reasons for accessing the data will all contribute to establishing the legitimate interest for the entity seeking to process the data. * Do you think that the memo asserts that the conclusion reached before that the risk of publishing legal person data is very limited? * This memo is consistent with the conclusions provided in the recent memo, which discusses the risks in detail. * The memo was helpful because it confirms the CPs position that what other parties are doing cannot be applied directly or indirectly to what we are doing. * EPDP Team to consider whether any aspects of the response warrant changes to the latest version of the write up or further consideration. * Confirm next steps Guidance write up * Consider remaining outstanding questions: Guidance #3 - 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). 1. 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. * Cannot receive support from the NCSG on the differentiation of legal vs. natural persons or include guidance. NCSG would prefer status quo. Question – if the guidance is not mandatory, what is the point? NCSG is officially in favor of no guidance. * Is there a concern that guidance could become a requirement? The answer is no, not without a PDP. * May be helpful to focus on the question of the benefits of differentiation. * Regarding the requirement for a flag that would be optional for a registrar to use is a concept that would be useful to flesh out with the group. Is there a benefit now and moving forward that allow for common implementation and framework going forward? * The word differentiation has become loaded. If you don’t put so much on top of the word differentiation and you think about registrars flagging, tagging, or characterizing data but do not make anything being done with those flags, that seems like something the group can agree with since this is something that registrars will need to do for SSAD anyway – for new registrations. * ALAC believes strongly in a new RDDS field and then it can be used or not. If we presume no one is ever going to differentiate, there is no point in doing guidance. * In principle, do not think flags are a bad idea, so long as the flag fulfills a purpose. If the use is voluntary, and the implementation is mandatory, this is not logical. Registrars can already voluntarily add fields. * It is important to define the contents of the field for the purpose of laying the foundation for the future. * What could the field be used for? If there is a flag, the SSAD could automate disclosure in certain circumstances. If there is a field, it is escrowed. We have already established a precedent that if certain fields are collected, they are processed in a consistent way. * Proposal to recommend a flag, define the format it should take if implemented and make it voluntary * Seem to be saying the same thing – there is now a legal/natural flag; it is not required to be used, but if they choose to send it in, there is a defined field, and it is in the overall format * No preference either way – this would not preclude a registrar from making this differentiation. Having this text in here may open the door to confusion if it is not framed correctly, but removing it is OK. * This scenario should remain to assist registrars that are not close to this process. * There is no problem with including this scenario * Removal is possible, but if we keep this scenario in, there should be some form of warning in it. 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. 2. 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. * Any time the data is updated, it should be treated like data collection. Nothing should be done differently. It should be treated the same as a new registration. * 15 days (from the WHOIS Accuracy Program Specification of the RAA) seems to be OK; Staff will include this update in the next iteration 3. 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. * Could list third party verification as something that someone can do, but the working group has no opinion either way. * Using a third-party verification provider could be a GDPR violation * This language allows registrars to use third party services to verify data that has been provided, whether that is postal code look-ups, company number look-ups, etc. The wording as is helpful. * Believe this needs to drop – fundamentally, this is creating a situation where registrars are manually going over registrations and ascertaining personhood. This needs to be removed. * Isn’t this just allowing registrars to subcontract its requirements? How can we take that away, not sure why we are having this discussion. * This is a question of which joint-controllers can engage subcontractors. If the outcome of discussions b/w CPs and ICANN org is there is no joint-controllership, then controllers can use subcontractors at their will. * No objection to remove this language. 4. Homework assignments reminder (5 minutes) · By Friday 7 May, EPDP Team to review proposed feasibility of unique contacts write up for Initial Report<https://docs.google.com/document/d/1uA_gEGmfyokKOP0Xft7q__RXVK1Ns_IXzSRoPKus...>. Please provide comments, suggestions and proposed edits in the form of comments. · By Friday 7 May, EPDP Team to review updated version<applewebdata://ACF5794E-D5EC-4AA4-9F45-1195E56EFB32/L%20v.%20N:%20https:/docs.google.com/document/d/1tbk4x7LDzqAazO2ABzjPPkR3gsPcPuBSrECQRpg0CdE/edit?usp=sharing> of legal/natural guidance write up 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<applewebdata://ACF5794E-D5EC-4AA4-9F45-1195E56EFB32/L%20v.%20N:%20https:/docs.google.com/document/d/1tbk4x7LDzqAazO2ABzjPPkR3gsPcPuBSrECQRpg0CdE/edit?usp=sharing> of write up 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. 5. Wrap and confirm next EPDP Team meeting (5 minutes): 1. EPDP Team Meeting #21 Tuesday 11 May at 14.00 UTC 2. Confirm action items 1. 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”.