[Gnso-epdp-team] Notes from EPDP Phase 2a Meeting #16 - 22 April 2021

[Caitlin Tubergen]

Dear EPDP Team,

Please find below the notes from today’s EPDP Team meeting. The Staff Support Team will circulate the action items separately.

As a reminder, the next EPDP Team meeting will take place on Tuesday, 27 April at 14:00 UTC.

Best regards,

Berry, Marika, and Caitlin
--

EPDP Phase 2A - Meeting #16
Proposed Agenda
Thursday 22 April 2021 at 14.00 UTC


1.                     Roll Call & SOI Updates (5 minutes)



2.                     Welcome & Chair updates (Chair) (5 minutes)

  *   Thank you to all Team members who continue to contribute to the working documents. The engagement level is high, and that is helpful.
  *   As we enter the last five weeks of our work to develop the Initial Report, please remember to be constructive. Differences of opinion may become more crystallized, but please remember to be respectful and constructive.

  *   Update from the legal committee – outstanding question
  *   Still awaiting an answer to Question 3, which is the question regarding the manner in which EURID, ARIN, and RIPE are implementing GDPR.



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.

a.       EPDP Team to consider responses provided by Bird & Bird (see here<https://community.icann.org/download/attachments/155191493/ICANN%20-%20EPDP%20Phase%202a%20-%20Follow%20up%20memo%20re%20contact%20masking%20-%2020210409.docx?version=1&modificationDate=1618239470000&api=v2>) as well as definitions<https://mm.icann.org/pipermail/gnso-epdp-team/2021-February/003693.html> developed by legal committee

·       Intro to memo and definitions developed by legal committee (Becky)

  *   The memo from Bird & Bird confirms its previous guidance that a registrant-based contact and registrar-based contact involve the processing of personal data since the intent is to contact the individual. However, both of the uses provide privacy-enhancing technology. The memo provides a grid based on risk. In short, registrant-based email contact for web publication involves medium risk. The registration-based email contact with web publication is probably low risk. Automated disclosure for a registrant-based email is the lowest risk, but none of these approaches are without risk.

·       EPDP Team to consider what new insights, if any, are provided that will facilitate a response to the question whether or not unique contacts to have a uniform anonymized email address is feasible.

  *   There are at least two different issues that are conflated with uniform email addresses and pseudonyms – one is the service to the registrant, and the other is correlation for third parties. These are separate issues and tend to get conflated. The short answer to the question is that it is not feasible. It is not feasible to do this against the wishes of the registrant. For the basic idea of how to contact a registrant without implicating the identity is to have a forwarding process through the registrar.
  *   In terms of the utility of web forms, that is an ICANN compliance or Phase 1 IRT issue and should not be discussed in this forum.
  *   Agree that this is not feasible. Uniform has issues that cannot be resolved in a way that is privacy-friendly.
  *   Support automated disclosure of a registration-based contact, as the memo notes that this is the lowest risk and carries with it the highest amount of confidence that it cannot be abused. This would also improve the functionality of SSAD.
  *   Understand the preference for the lowest risk; however, also need to consider how to bring the risk assessment in line with other long-existing policies based on the legitimate interest of Internet users. For example, with respect to the UDRP, there is a possibility to show a pattern of bad faith registrations. If we opt for the lowest risk, we may be, de facto, revising the UDRP, and this group is not chartered to do this.
  *   The idea of trying to correlate is distinct and separate from whether you can contact the registrant. In order to facilitate correlation, you need to have access to non-public information.
  *   In this group, we are tasked to ensure that the policy enables us to perform relevant use cases in the ICANN policy space. In short, looking to get a list of domain names registered by a particular registration in order to substantiate a claim of bad faith under the UDRP – a list of domain names, alone, is not personally-identifiable information and this should be allowed.
  *   In terms of correlating bad faith for UDRP cases, this was never an issue before the Temp Spec. Reverse WHOIS search was never a function of WHOIS, this was a third-party service. Complainants can look at previous UDRP decisions for indicia of bad faith.
  *   What we are discussing is purposes not functions of the system. What is the legitimate purpose for processing this data, and there are purposes other than contacting the registrant.
  *   We are aware there was no reverse WHOIS previously. It is common that a trademark owner would identify multiple infringing domain names and prioritize action based on patterns of infringing domain names. We are currently seeking some sort of identifier that does not run afoul of data protection law.
  *   Another relevant use case is abusive domain name registrations. If a domain name is using malware, it would be helpful to identify other domain names registered by the same registrant to enable the stop of abuse.
  *   The problem with correlation is that the identifier may not be the person’s name but if it identifies every domain name registration the individual has made, this is personally-identifiable information. This is valuable for cyber-security research, but it can also be valuable for bad guys.
  *   The key question for this group is feasibility in light of the GDPR.
  *   For a trademark search, if domains are correlated, you will get the correlation anyway. For cyber security researches, this is different. Do not see how to publish this data for the few cases without publishing the email of every registrant in the domain name system.
  *   There is value in the identifier even if it’s not published. If the cyber-security expert would make a request and receive the full list – this could still be helpful.
  *   The same tools of correlation are available to bad actors – people are getting spammed and doxed. Ultimately, would rather have 100 domain names that are abusive than to have two customers that are harmed. Many registrars have an interest in doing this correlation themselves because it ultimately saves the registrar money by taking action proactively. Would rather turn off 100 domain names than receive 100 tickets over time. Maybe provide guidance to registrars to do this type of correlation themselves, and therefore, if this is handled by the registrars, a need for third parties to do this goes away.
  *   Could be worth looking at the benefit of having a registrant-based email address that is not published.
  *   There is some discussion about unique identifiers. There is a difference between a unique email address vs. a unique identifier.
  *   Given the way that EPP works, in that before a domain name is registered, a set of contact data is sent to a gTLD registry – an anonymized identifier could be done at a registry level and have a domain name attached to it. This could also be done at the RSP level.
  *   What we are recognizing in this discussion is that there is legal feasibility under GDPR and technical feasibility – technical feasibility seems like a secondary issue at this point.
  *   Where we are landing on the chart on the screen is the bottom left quadrant – whatever anonymized identifier is tied to the registrant.
  *   Believe the bottom right quadrant is the preferred option.
  *   Prefer to be in the top left quadrant, while registrars would like to be in the bottom right. Proposal is to meet in the middle with the bottom left quadrant.
  *   Is this guidance or a requirement? We will table this question for now and move on.

·       What are the next steps in developing a response for inclusion in the Initial Report?



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.

Consideration of question i. 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“);

a.         Each group to provide a high-level summary of responses to questions (see https://docs.google.com/document/d/1gMV29jRPQEFGv2psZ2py2_F8cr93OeeA/edit):

·       ALAC

  *   Strongly support Milton’s proposal – principle #1. This, however, does not seem to have the support of contracted parties. Discussion regarding the SSAD is a red herring – do not understand why a simple vanilla RDAP server could not be used. This would go to the registrar via RDAP. This is a PDP looking at policy, not building a mechanism. Would recommend focusing on the questions from the Council and not engage in extraneous conversation that may or may not be implemented in the long term.

·       BC

·       GAC

  *   As we approach the May deadline, it is good to remember the expected standards of behavior. Disappointed to see the response to a good faith intervention. While some members would prefer not to differentiate, this is OK to note but to claim DNS abuse is nonexistent is disrespectful. The RrSG position on this is very clear – only differentiate if required by law – seems that the registrar reps would prefer to be regulated rather than to self-regulate. Recall some helpful comments from contracted parties – why should we differentiate – it seems to benefit everyone but us. This is a valid and constructive point. Suggest focusing this meeting on what the benefits would be of making this a requirement. 1. By differentiating, you will have less access requests. (this will prevent having to do manual balancing tests and diminish the uncertainty). 2. Another advantage is reputation. There are implications that the current practices are lacking transparency. 3. Another benefit would be self-regulation – this is a great opportunity for registrars to influence things. You have the opportunity for your voice to be heard. From the messages we receive from the legislators, we should not presume that the requirements would be even more stringent. Could these aforementioned benefits make the contracted parties change their mind? We could wait for three years for the SSAD, but we risk legislation coming down in the meantime. With respect to the RrSG on the SSAD, we have taken this into account, but even if we use the SSAD for disclosure, you cannot remove the step of differentiating between legal and natural entities.
  *   Response to previous comments – question is shouldn’t the issue of consent only come into play when we’re talking about personal data. When we are talking about legal entities and their non-personal data, consent is not applicable. Do not understand the inclination to protect data that is not protected under the law.
  *   If the Team can separate out these two scenarios, might we agree on how to treat the non-personal data of legal entities? If we could move forward on this, it would be productive.

·       IPC

·       ISPCP

  *   Thought there was a constructive conversation regarding the difference between personal and non-personal data. Part of the data of legal entities is still personal data, so we were talking about a two-step approach, which includes a distinction of personal and nonpersonal data.
  *   No consent is required where the data of legal entities have no personal data present. There is a risk in seeking consent where it is not required. Under no circumstances should we ask for consent where none is needed.

·       NCSG

  *   Not pleased with the implied threat that governments will supersede this policy; however, this is a concern the group should consider. The stakes of this are less than many people believe. There are many ways of getting information in the digital environment. Historic WHOIS data is being commercially marketed all over the place. There are other internet services that are points of abuse or crime that may be more helpful than loading this onto DNS. Tried to explore a space for agreement. 1. There should be differentiation b/w legal and natural. Think that Volker’s idea to put everything behind the SSAD with automated disclosure is a very good idea. The third party can get the data quickly and efficiently, and in the event of bad actors, the bad actors could be kicked out of the SSAD.
  *   In the real world, the distinction between personal and non-personal data is becoming blurry. There is a gray area of quasi-legal persons who are small businesses or people working from home. The second articulated principle regarding the registrant being in control would help bridge this gap.

·       RrSG

  *   Would prefer self-regulation. Have made a concrete proposal regarding disclosure in the SSAD – similar to a German trade registrar. Following this example would benefit us as we would not be reinventing the wheel. There are many benefits from this proposal – not sure why this is not receiving greater support. Also do not understand why these publishing requirements are not also going after hosting providers? Recommend focusing on what is reasonable and implementable, even if it takes are few years rather than a stop-gap solution.
  *   The cited study was paid for by parties with a specific goal and do not find it persuasive.
  *   Cannot look at a certain data set and see if it is personal or not – that is only for the registrant to determine.

·       RySG

·       SSAC

b.         EPDP Team to consider next steps to develop response to question i.



c.          Confirm next steps



Guidance development



d.         Consider new issues flagged in the write up<https://docs.google.com/document/d/1whCpXHm3UPmJ-IDSbliveSkwxL679x2U/edit#heading=h.gjdgxs>:

·       Definition of “publish” (note, the write up currently includes the following definition “EPDP-p1-IRT: “Publication”, “Publish”, and “Published” means to provide Registration Data in the publicly accessible Registration Data Directory Services.”)

·       Any concern about moving “Distinguishing between legal and natural person data alone may not be dispositive, as the data provided by legal persons may include personal data that is protected under data protection law, such as GDPR” to the guidance section?

·       See 1d – what approach should be taken when a Registrant makes substantive changes to registration data?

·       Consider whether it would be helpful to add a timeline to scenario 2.

·       Consider whether scenario 3 should remain.

·       Other?


e.         Homework assignment – new version of write up has been developed by Staff Support team based on deliberations on B & B advice during last meeting and input received by deadline. Groups to review latest version and flag any concerns / issues by Friday 23 April at the latest. In the course of next week, ‘final’ draft version is expected to be circulated with the request for groups to flag any cannot live with items.



5.      Wrap and confirm next EPDP Team meeting (5 minutes):

  1.  EPDP Team Meeting #17 Tuesday 27 April at 14.00 UTC
  2.  Confirm action items

  1.  Confirm questions for ICANN Org, if any



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20210422/f9a878bd/attachment-0001.html>