2021-05-04 EPDP Team Phase 2A - Meeting #19

Notes/ Action Items

Please refer to the project spreadsheet [docs.google.com] for action items.

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)

        i. Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement.

        ii. 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.

1. Review input received (groups that provided input to provide high level overview of their input – BC, RrSG, SSAC)
   • BC: Established that the creation of pseudonymous email addresses is technically feasible. BC believes this should be a requirement because it is a privacy-enhancing technology. The pseudonyms can be used for a variety of purposes, including contacting people. Webforms are not an ideal way to contact people because receipt is unclear and there are often character limits. Also, pseudonyms would help with correlation. For these benefits, creating these should be a requirement, and this group should work on refining the associated policy requirements.
   • RrSG: Acknowledge that it is technically feasible, but there are risks not only to the registrar, but also to the domain owner. There could be spam messages, and correlation could reveal sensitive information. The webform is sufficient. Have heard that webforms are insufficient – it may be helpful to includes more rules around webforms, but this does not mean they are not fit for purpose. Even having an email does not equate to mandatory responses.
   • SSAC: Uncomfortable with the idea of pseudonymous email addresses – do not know that it is safe and appropriate to do this. An alternate way to do the correlation is to have a trusted service and ask how many of these domain names are related to each other and have the service be able to do this. This would allow more control over evolution. There are better ways to accomplish this and trying to impose a pseudonymous algorithm on everyone is not the ideal way to move forward.
   • GAC: Uniform anonymized email is feasible but it has to be tempered with sufficient safeguards. Appreciate the concerns raised by other stakeholder groups with the current system – there are currently no safeguards baked in to make sure that the webform reaches the registrant and promotes a response. One concern is that there needs to be sufficient safeguards to protect the data. One scenario that comes to mind is registrars who use pseudonymized email addresses in privacy/proxy dealings. It may be helpful to know what functionality these services get.
   • ALAC: We have enough evidence that webforms as they are used today do not work. If we wanted to write rules for what webforms are supposed to do, we could, but not sure we are going to do that in this group. While you cannot guarantee that an email is read, but you can be sure it’s sent to a valid email box, which you cannot do with a webform. ALAC strongly supports pseudonymized email addresses.
   • Team has had multiple conversations on the topic of webforms. Remind the Team that if there are challenges with webforms, that should be dealt with in relation to the implementation of Phase I recommendations through the IRT or through ICANN compliance.
   • Cannot rely on an IRT to impose rules about webforms. If we had a new policy saying you can use webforms, but the details of what you can include must be set for the IRT. This is out of scope for an IRT. If an email is sent by forwarding or if a webform bounces, this is not relayed back to a requestor. If the registrar receives proof that the message was not delivered, this should be communicated to the requestor.
   • The question of whether an email address should be a requirement is being addressed in part because there is no other way to contact the registrant. The failure of webforms is evidence that this should be a requirement.
   • In Rec. 13 from Phase 1 is designed specifically to meet Purpose 3 – enable communication with the registered name holder. Many concerns raised note that there is no way to show that the relay has occurred. The Team discussed this in Phase 1, which is why logging of the relay is required.
   • IPC: remind that the B&B memo noted that the risks are low. The purpose of making this available is contactability and correlation. The UDRP gives complainants the opportunity to show a pattern of bad faith registrations. We need to find the correct balance between what can be disclosed but ensuring that pre-existing policies are still able to function properly.
   • Establishing a pattern of bad faith is not necessary for success in a UDRP case.
   • This group is conflating anonymized/pseudonymized email addresses with what is in WHOIS; these emails could be provided via the SSAD
   • NCSG: No further changes are needed. The claim of necessity for correlation of email addresses – simply because this was used does not make it lawful. Webforms are sufficient to contact the registrant.
   • ISPCP: Are pseudonymized emails desirable? No, because of risks with reverse-engineering. The purpose of processing is for contacting the registrant, and this can be achieved via webforms. Need to follow the principle of privacy by design. If the group chose to require email addresses, would recommend this is per domain name, not per registrant. Would further recommend that the per domain name email be rotated.
   • RySG: Contactability and correlation appear to be the two goals. In both of these cases, this is not the best way of achieving either of these goals. For contactability, Rec. 13 from Phase 1 should be sufficient. With respect to correlation, this does not seem to be a good way of achieving that goal as it creates additional risk and effort for contracted parties.
   • Members keep conflating anonymized and pseudonymized with reverse engineering – particularly via the SSAD.
   • Understand that one of the reasons why groups are pursing this as a path forward is to have the ability to correlate. This was made clear in the IPC comments. Believe what was said is to take efforts to prevent correlation.
   • Do not believe an IRT can set rules for webforms. Answer is nuanced because we need something better than what we have today.
   • If the Team can agree on the contactability point and use this as a starting point, perhaps we could build on that.
   • There does not appear to be consensus around if this should be a requirement. The Team may wish to consider what type of guidance could be provided. The Team could also provide guidance to the Phase 1 IRT regarding webforms/email addresses. The Team should consider the path forward.
   • In thinking about proportionality, if you think about RDS data fields, the email address is the least likely to be personal data, but we know that email addresses are free of charge and made up of any string of characters. Guidance we could give – tell registrants not to put personal data in their email address.
   • Seems to be the assumption that real registration data would be disclosed via the SSAD
2. Walk through of staff proposed write up of Initial Report text
3. Confirm next steps – proposed deadline for comments / suggestions / proposed edits Friday 7 May 2021

4. Legal vs. natural (45 minutes)

   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“);

   ii. What guidance, if any, can be provided to Registrars and/or Registries who differentiate between registrations of legal and natural persons.

Guidance write up

1. 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?

• Contracted parties will have to do this already under Phase 2. Maybe we note that CPs will have to flag data one way or the other in their systems.
• Follow-up question for ALAC – what does this suggestion mean in terms of implementation. If we are talking about a flag in the registrar’s system to indicate if there is personal or non-personal data, that would not be a flag in the RDDS. RDDS systems are generally query systems. Are you instead looking for an indication in the response to an RDDS query? The mention of a flag in confusing in this context. What is ALAC hoping to accomplish with this guidance?
• The difference b/w a registrar field and an RDDS field is that one is just for a registrar, the other is not. Having a defined field in the RDDS is important because this conveys a lot of information that is completely lost in the registrar system. Believe this should be a public field.
• Proposing three types of fields – differentiate b/w legal and natural registrants. The other fields differentiates b/w personal and non-personal data and one for protected and unprotected data. This is important across registries and registrars.
• This is based on assumption that because it works at the registrar level, it will work at the registry level. Registry has an obligation to have a means of testing flags of every registrar. This is an extreme factor of complexity.

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. Please provided comments, suggestions and proposed edits in the form of comments.

• By Friday 7 May, EPDP Team to review updated version of 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 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.

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

       a. EPDP Team Meeting #20 Thursday 6 May at 14.00 UTC

       b. Confirm action items

       c. Confirm questions for ICANN Org, if any