Dear EPDP Team, Please find below the notes from today’s EPDP Phase 2A Team meeting. The next EPDP Phase 2A meeting will be Thursday, 25 March at 14:00 UTC. Best regards, Berry, Marika, and Caitlin -- EPDP Phase 2A - Meeting #11 Proposed Agenda Thursday 18 March 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) a. Update on submission of legal committee questions to Bird & Bird (Becky) * Three questions have been sent to Bird & Bird, and Bird & Bird expects to respond the week after next. * There is one additional question, which is an addition to the second question on mitigation steps for legal v. natural. Laureen and Melina have revised the question, based on the discussion during the Legal Committee meeting. * The updated question was circulated to the Legal Committee today with a request to respond by COB tomorrow. * Because this is an additional part of a question, this is unlikely to slow down Bird & Bird’s response time. 3. Legal vs. natural (70 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. a. ICANN org supplemental information on legal / natural study * Brief overview of supplemental information<https://community.icann.org/x/I4GBCQ> provided (ICANN org liaisons) * ICANN org presented its study to the EPDP Team approximately two months ago * During the presentation, SSAC reps asked a follow-up question re: how EU ccTLD operators and company trademark registers handle the publication of legal v. natural person data. * ICANN org provided its response on 3 March. * The first response deals with EU ccTLD operators’ differentiation. ICANN org looked at 33 EU ccTLD operators including .EU, .IS, .LI, .NO, .CH, .UK. Looked to see FAQs, general term, agreements. * Approximately 21 operators use some form of differentiation. * Appendix A provides greater detail of this breakdown. * Using .AT as an example – appears to differentiate. Break out types of data that is published – information was gathered from policy information available on the website re: the publication of personal data. * With respect to company trademark registers, ICANN org took a similar approach – looked at EU IP Office, USPTO, GDPR, and Hamilton memo. Found that company trademark registers are guided by legal obligations to maintain a public register. * EPDP Team questions & comments * Would be helpful to know which of these ccTLDS have laws/regulations (like the one applicable to .eu) that provide a public interest basis for processing. Otherwise very hard to make sense of this. * May be helpful to reach out to colleagues in the ccNSO * Was there a degree of uniformity across ccTLDs? It would be helpful to understand this as the Team is trying to develop a model that could work across many types of entities. * ICANN org to add a separate column re: public interest basis for publishing info * There didn’t seem to be a definitive method across all of the ccTLD operators; methods seemed to vary * How much uniformity in necessary in this system? From SSAC point of view, it may be possible to permit a certain amount of variation across different registries and registrars? Have we sought a posture with respect to the degree of uniformity across companies? * Under Phase 1 recommendations, CPs have discretion of how to handle this. The non-uniform approach is compatible with what is already going on. If we are looking for policy guidance based on ccTLD operators, it doesn’t appear we will get it since the methods vary. * While one method may work for a particular ccTLD, this is unlikely to work for a gTLD registrar. If differentiation is made, the Team should look at the results of the differentiation, how would this be transferable (if at all), what would the output in the RDS look like? * ccTLDs have a much lower risk from getting enforcement from a DPA. Comparing gTLD to registrars to land office registries is not pracitical because this is not analogous – there is not the same public interest or regulatory framework. * Is it worth considering/investigating the value of registrant consent vis-à-vis the various ccTLD policies on display of natural person data, either in the context of legal person registrations or actual natural person registrations? * ccTLDs and gTLDs are not an apples-to-apples comparison. This can be instructive, but they are not the same and should not be assumed to be the same. * The question of consent is a critical one. If NIS-2 gets approved, and there is a requirement to publish information about legal persons, there still may be natural person data present. Consent is likely the way to resolve this conundrum. This is a key question of how to resolve this in the long term. * The NIS-2 references the word “publish” but does not say “publish in an open database”. It could take another avenue such as publish in the SSAD. It is not clear what this means and there are multiple interpretations. The most likely interpretation will be publication in the SSAD. * Confirm next steps, if any Guidance development b. Review input provided on legal vs natural thought experiment * See https://docs.google.com/document/d/1Hf-Nt-VMznpGE4WZ7wWaHF8pXdm8qA28OW7Mjr4M... * The work on this exercise is to augment the work already done in Phase 1 and Phase 2. Publishing the data of legal persons does carry with it some risk. If we are thinking outside the box, are there ways to address that risk or mitigate that risk? Berry identified that in Phase 2, there was already the mention of legal risk fund – is this something that could be used to mitigate the risks identified in this table? * Teams to provide a brief summary of their main observations, focusing on new insights or ideas * IPC: Prefer to move away from the discussion of a legal risk fund. With respect to when differentiation would occur at registration or after – would prefer that this did happen at registration. If everything happens early and up front, this seems to be the simplest. Also, if it’s done at registration, there would be no issue with the 60-day lock. * RrSG: easy is not always the best. The 60-day lock may not apply because the only thing that would change is a flag would be added, the information wouldn’t necessarily change. Having a legal risk fund could be a big red flag to DPAs – this could result in additional fines. * NCSG: already agreed that registrants should be able to designate if they would like their info published or not. If this is entirely a self-designation, and there is no burdensome verification check superimposed into the registration process, would support this. Team needs to get to a middle ground. * GAC: encouraged by this framing of the issue. There is ample room to discuss how this goal could be met of allowing a registrant to designate its status and be in control of whether its data that is personal is published. In terms of verification, that is something included in the proposal since it was part of the guidance from Bird & Bird, but not wedded to this requirement. Registrant needs to make this designation and be informed of the consequences of this designation. * RrSG: voluntary self-identification of registrants is the correct direction. This is the way the group can find a solution. Anything that is too heavy-handed on the registrar or registrant would not work. * IPC: Curious to hear what registrars have to add re: the flags. Having worked at a few registrars, there are often indicators tied to a domain name (such as if a domain name is using a local presence service). * RrSG: policy should not be limited by current functionality, but group should still appreciate complexity of what is being suggested. Since a flag indicates a person set, this is more appropriately added to a contact set rather than a domain name. A contacts set is a group of fields that are associated together. One person could provide different information for the same person, and this could be seen as two different people – for example, if the registrant provides street or st, this would be two different people requiring two different flags. This results in an unhappy customer base that is required to take action for no perceived benefit. This flag is a complicated idea with no benefit. * NCSG: spent time looking at legal v. natural – do not understand why we are debating running a legal risk for registrars? The only people that will be hurt by a wrong designation are individuals. * BC: Seems that Tucows will not streamline the system, and that is disappointing. Putting a flag on a registrant is just a notifier or indication of an attribute. This is not personal information. This is not the correct definition of privacy by default. * RrSG: a flag is an internal or external indicator to notify itself that a certain data set is confirmed to contain personal data or not. Whether this is portable or just internal would have to be decided down the road. * Confirm next steps * Registrars – identify differences in Registrar input vs. Proposal 1(a) from Laureen. * RrSG: 1(a) is a step-by-step prescriptive guide that is more implementation rather than guidance, while the registrar guidance is guidance that could work for multiple types of registrars. c. Review input provided on RrSG proposal * See https://docs.google.com/document/d/1YyiBmtcpa5PxsPnKDXZFfU0WEPVhgjN5ySv9KvQb... * Teams to provide a brief summary of their main observations, focusing on new insights or ideas * Confirm next steps d. Development of guidance proposal(s) * If/how should the broadly supported aspects of the different proposals (RrSG, proposal 1a and thought experiment) be brought together? * One proposal or several? * High level vs. detailed? * How to allow for sufficient flexibility to accommodate different business models, while at the same time providing helpful insights to those that want to differentiate? * Volunteers to take a first stab, or should the staff support team be tasked with developing a first draft? 4. Wrap and confirm next EPDP Team meeting (10 minutes): 1. Update to GNSO Council 24 March at 17.00 UTC by Chair and Council Liaison (open to observers * Keith has obligation to report to the Council, which will happen during ICANN70. * Recommendation will be to allow the work to continue in light of the fact that the legal committee has submitted questions that we are awaiting feedback on. * There is a possible path forward on consensus on guidance for registrars who choose to differentiate; it’s premature to determine if there is consensus on consensus policy recommendations, as we are awaiting legal advice. * Recommendation will be to give this group until the end of May and that at the end of May, we will have a clear indication of if we have consensus or not. * Support Staff will circulate the slides that will be used during the Council presentation next week. * Appreciate the recognition that there are paths forward and hope these paths can be built upon. Next milestone will be at the end of May. * End of May is a clear inflection point as this is the target date for Initial Report publication. If there is no consensus on the Initial Report, it’s unlikely we will have consensus at all. * It is critical for team members to do their homework. 1. EPDP Team Meeting #12 Thursday 25 March at 14.00 UTC. 2. Confirm action items 3. Confirm questions for ICANN Org, if any