Dear EPDP Team, Please find below the notes and a link to the action items from today’s meeting. As a reminder, the Legal Committee will be meeting on Tuesday, 2 February at 14:00 UTC, and the next EPDP Team meeting will be Thursday, 4 February at 14:00 UTC. Best regards, Marika, Berry, and Caitlin Action Items ❗️Please refer to the Google Sheet<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdV...> for Action Items. We will review the action items at the beginning of each call. ❗️ EPDP Phase 2A - Meeting #04 Proposed Agenda Thursday 28 January 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) a. Update on Council Liaison to EPDP-P2A * The Team will shortly have a GNSO Council liaison to EPDP P2A; this will be formalized at the next Council meeting. Philippe Fouquart has volunteered to serve in this role. b. Update on Legal Committee * Brian Beckham has submitted an expression of interest to the list; the Team should have received this yesterday. * As a reminder, since Brian is not a member of the EPDP Team, if the group is comfortable with Brian as the vice-chair, the Council would need to confirm this is OK. * Please indicate additional questions (if any) for Brian or any objections to his candidacy by COB Wednesday, 3 February, as we would like to formalize this at the next plenary meeting. * The legal committee is now fully formed and will have its first meeting, on Tuesday, 2 February at 1400 UTC. 3. Legal vs. natural (see https://docs.google.com/document/d/1QlM4O_vwx7cQ11DJ_Lx2kqhyyRgDkMXG/edit# [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QlM4O_vwx7cQ1...>) * Each EPDP team member who submitted a proposal will have the opportunity to present the proposal to the team. * Following the brief presentation of the proposal, the Team may respond; however, please provide feedback in a constructive manner. * Please note these are proposals for what registrars may do if they differentiate b/w legal vs. natural. * Question from EPDP Team: why is the group only focused on voluntary differentiation rather than having a discussion about making mandatory differentiation part of a consensus policy? * Response: The Council instructed the EPDP Team to develop best practices and then consider if mandatory differentiation should become consensus policy. * Some proposals only make sense if differentiation is mandatory. * Understand sequencing; however, the endgame for certain stakeholder groups is to find a way that information that is not protected under the GDPR to be published, and that any policy ultimately agreed to is consistency with GDPR. The current policy protects information that is not legally entitled to be protected. * The first question to consider is if any updates are required for EPDP Phase 1 a. Observations from ICANN org webinar · Any remaining questions or missing information on the topic? · Other comments * One interesting thing from the webinar is that the organizations who have differentiated have noted it’s not as onerous as some may have thought. It is worth investigating why these organizations have found this to be easier than one would assume. * There may be value is asking that question; however, this needs to be qualified – have these organizations always differentiated, or was this something they instituted following GDPR? * ICANN org overstepped in this study, as Org weighed the factors in the study but some of the conclusions drawn are wrong * ICANN org noted, during the webinar, that this is a framework and is not meant to be determinative and definitive. It is meant to be a tool to help the group in its deliberations. b. Introduction of proposals for guidance that can be provided to Registrars and Registries who differentiate or want to differentiate between registrations of legal and natural persons · Proponents to introduce proposal * GAC (proposal #5): Fully mindful of the fact that there is a difference in dealing with new registrants vs. legacy registrants, and this proposal is for new registrations, not legacy registrations. The goal is to leverage the legal advice from Bird & Bird. * Upon registration, registrants could identify as legal or natural persons. CPs would be required to use plain language to allow Jane or John Public to understand the difference. There are probably existing models to learn from, as some registrars already do this. In terms of the plain language, focus groups could be used to determine if the language is indeed understandable – the language could then be uniform and required. * Second step would be to send the confirmation to the contact, and technical and admin contact – the email could provide a warning about publication so that the registrant is informed of the consequences. * There could also be a separate verification after that – such as a corporate identification number or some sort of screening process or third-party provider. The EDPB also noted there should be a directive given that legal registrants should NOT be providing personal data in their registration. * Fourth step – if they get it wrong, it should be easy to get it right. * Response: many ccTLDs do similar things; however, registrars still have issues with this. ccTLDs generally focus on one jurisdiction only, while gTLD registrars are dealing with registrants from across the globe. In terms of fixing it if the registrant gets it wrong, there is no putting the genie back in the bottle because the data could have already been harvested. * Emphasize a degree to which GAC’s proposal introduces an unnecessary step. Key question: is the data published or not? If there is an option that says – I want this published – that’s all that is needed. The legal v. natural distinction is confusing and it’s unnecessary if the registrant consents to publication. Do not understand the need for this step. * Under GDPR – is it allowed for a legal person to not have their data disclosed? * Did not hear the GAC proposal invoke corporate registrars. GDPR is silent as to what extent one could voluntarily keep legal person data protected. * The distinction b/w legal and natural is a bit of red herring. The question is does the registration data contain personal information. Having to declare this in the registration path is a bit of a nightmare. An example is Customer A has a user handle for all registrations but now the user handle carries a different meaning. Consent may not be the consent of the data subject. Consent is hard online. * In terms of legacy registrations, this proposal cabins that off and focuses on new registrations. Understand that liability and fines are a concern. The point of this exercise is to go over proposals that minimize liability. As we have all recognized, there is no risk-free or liability-free world. However, if there are procedures in place that will help to minimize liability, we should visit those. Appreciate the suggestion to focus on consent, but focusing on consent does not take us where we need to go because the current policy allows protection of information that has no protection under the GDPR. The law requires certain info to be protected, and the policy goes above and beyond what the law requires. * For new registrants, introducing new handles should not be an issue. In relation to legal person’s data that could include personal data, declaring that there is no personal information is necessary but some of the safeguards suggested by the legal memos suggest using a technical tool to confirm that email addresses of legal persons do not contain personal information. Also, there should be tools for legal persons to correct their data, which is a requirement under Article 16. The legal memos and study provide safeguards in relation to each of the contracted parties’ concerns * The conversation is one-sided, in that it focuses on the privacy side without focusing on the NIS2 directive, which requires the publication of data of legal persons. It’s a good idea to design a policy that considers these issues. * The team is confusing privacy by default and privacy by design – some in the group are focusing on privacy by default. Privacy by design requires a design – we should focus on that. * The question is not if legal data should be protected. What we are talking about is an adjacent problem – we don’t know how we can achieve that in line with the law. Yes, the NIS2 directive notes that legal person data should be published so long as it is in line with data protection law. In terms of privacy by default and privacy be design – in order to have the design, there must be privacy by default. In other words, there was no breach of the data if we were to make a mistake in the design. One core concept in European law is proportionality, and that includes cost of implementation. Is this proportional and feasible, or is this a “in a perfect world scenario”? * NIS2 directive is not something that should be relied b/c it’s a proposal, it is subject to a lot of lobbying and discussion in parliament and when agreed to, it will take years to be transposed into local law. This could be at least five years down the line. How many emails do you expect registrars’ customers to receive? The required notices are numerous and customers already feel spammed by their registrar. * Have not yet heard an argument as to why the team can’t focus on consent rather than a legal v. natural distinction. Someone mentioned that some laws require legal persons to publish their information; however, that is an obligation imposed on the legal person, not the registrar. * With some collaboration and discussion, the team can consider a safety valve that would occur before publication, such as communications with the registrant. These safety valves would provide the registrant an opportunity to not have their information published. If the steps proposed are not enough, would welcome discussion on that. * Privacy by design is getting all of the aspects mentioned in the proposal into the design of the system which reduces the risk of getting information out there. * This may not be a silver bullet, but the team should focus on helping the proposal rather than focusing on getting to zero risk, which is not possible. We’re here to work on how to get to as close to zero risk as possible. * In response to previous characterization that NIS2 is a “legal nothing” is not constructive and minimizes on the EU’s role. There is a clear sign that this is the way the GDPR should be interpreted. There is a lot of talk about the existence of risk and liability, but the Team should try to qualify this. Not every DPA is going to use a nuclear bomb and fine everyone. * In terms of having zero risk here, that is not necessarily true. There is zero risk if there is no publication. * At this time, the NIS2 is a proposal – it will take years to become national law. Once it becomes a valid law, then we can act. * When we talk about privacy by default, there may be other considerations. Do not know how in this plenary we can constructively have a conservation about proportionality. Some people perceive the proportionality of risk to be very high; others think this is very low. * Real-life example: friend who cuts hair and rents a station at a salon. All of the info associated with the LLC is her personal address. Her clients stalked her at her home, and this is a risk that must be considered when legal person data is published. * Circling back to Laureen’s proposal – focus on the first point: notification to registrants to choose if they are legal or natural person and notifying of the risks. * The idea of finding appropriate language will probably look like an ICANN policy report and confuse people. You can ask someone meaningfully if they want their information published very easily, but explaining the difference b/w legal and natural and third party access is too confusing to the average registrant and is overly convoluted. * In the proposal, the term user-friendly – the text needs to be understandable with Joe and Jane Public. This could be an interactive process – it’s an engagement b/w the registrant and the registrar and doing this is part of the process of obtaining a domain name. This is currently being done; we can do some reconnaissance to see how other EU-GDPR compliant entities are doing this already. * Registrants may not speak English as their first language; they may not understand. For many registrars, this will amount to a check-box exercise, and this has inherent risks. · Q & A by EPDP Team · Confirm next steps 4. Feasibility of unique contacts (see https://docs.google.com/document/d/1weQemSQ0-884ILbhmR3OLzUWouyGXMKH/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1weQemSQ0-884I...> and https://docs.google.com/document/d/1e2-rVF2wh-821tct76O50QdWwn4ZcIqS/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1e2-rVF2wh-821...>) – if time allows a. Introduction of proposals for options to require unique contacts to have a uniform anonymized email address across domain name registrations that would not result in being treated as publication of personal data · Proponents to introduce proposal · Q & A by EPDP Team · Confirm next steps 5. Wrap and confirm next EPDP Team meeting (5 minutes): a. Meeting #05 Thursday 4 February at 14.00 UTC. b. Confirm action items * EPDP Team members to indicate objections or additional questions (if any) for the vice-chair candidate, Brian Beckham, by COB Wednesday, 3 February. * EPDP Team members who previously prepared proposals for Legal v. Natural and Feasibility of Unique Contacts to be prepared to present proposals to the EPDP Team at the next meeting on 4 February. 1. Confirm questions for ICANN Org, if any * How does ICANN org see its liability risk to enforce mandatory differentiation of legal v. natural persons? For example, the risk for a registry is for 1 zone, for ICANN, the risk is likely for thousands of contracted parties.