February 2019 - Gnso-epdp-team

Responses to legal questions
by Kurt Pritz Feb. 1, 2019

Feb. 1, 2019

Dear EPDP Team: I am writing to notify you that outside legal counsel has responded to three questions from the EPDP Legal Team. The Legal Team has reviewed the responses. Rather than include a Legal Team opinion regarding the effect of the responses on our discussion, the Team decided to simply provide the answers (in summary form and in formal memo) that Bird&Bird provided to us. Below, please find the: EPDP Team questions posed to Bird&Bird, and Informal summary of the answers provided by Bird& Bird. The full legal memoranda can be found on the wiki page. <https://community.icann.org/display/EOTSFGRD/Meetings+Legal+Committee+Frame…> (https://community.icann.org/display/EOTSFGRD/Meetings+Legal+Committee+Frame…) Please respond with questions you might have to this list. Best regards, Kurt Legal vs. Natural Q: The EPDP Team discussed Charter Question h3, namely, should Contracted Parties be allowed or required to treat legal and natural persons differently, and what mechanism is needed to ensure reliable determination of status? In determining the answer to this question, the EPDP Team sought the guidance of external legal counsel, inquiring specifically, “If a registrar permits a registrant, at the time of domain name registration, to self-identify as a natural or legal person, does a registrant’s incorrect self-identification that results in the public display of personal data create liability under GDPR? If so, please advise, for each possible participant in the domain name registration process listed below, if that participant incurs liability.” External legal counsel provided the following summary answer. A: “We conclude that the relevant parties could be subject to liability if a registrant wrongly self-identifies as a legal person (and not a natural person) and the registrant's data is disclosed in reliance on this self-identification. To reduce the risks, we propose several solutions, such as focus group testing of the registration process to minimise the risk of errors and technical tools (if feasible) to verify the information provided. We also recommend providing clear notice to data subjects of the consequences for them of the designation as either a legal or a natural person as well as a way for data subjects to easily correct a mistaken classification. One way to do this effectively would be to send a follow-up email after registration to the listed contacts – this could also help with the notice issue addressed in question 1 [Technical Contact]. Technical Contact Q: The EPDP Team also took note of a related footnote [from the EDPB] which states, “[if contact details for persons other than the RNH are provided] it should be ensured that the individual concerned is informed”. The EPDP Team discussed whether this note implies that it is sufficient for the Registered Name Holder (RNH) to inform the individual it has designated as the technical contact, or whether the registrar may have the additional legal obligations to obtain consent. The EPDP Team requested external legal counsel guidance on this topic who provided the following summary answer: A: “In cases where the RNH and the technical contact are not the same person, relying on the RNH to provide notice on the registrar's behalf will not meet GDPR's notice requirements if the RNH fails to provide the notice. While this may provide grounds for a contractual claim against the RNH, it is unlikely to provide a viable defence under the GDPR. Moreover, this arrangement will make it difficult for registrars to demonstrate that notice has been provided. If notice is not effectively provided, this could affect the legitimate interests analysis, since technical contacts may not "reasonably expect" the manner in which their data will be processed. If relying on consent, such an arrangement would make it difficult to document that consent has been provided” . Article 6(1)(b) Q: The EPDP Team asked two questions about the application of Article 6(1)b to external legal counsel: Does the reference 'to which the data subject is party' limit the use of this lawful basis only to those entities that have a direct contractual relationship with the Registered Name Holder? Does "necessary for the performance of a contract" relate solely to the registration and activation of a domain, or, alternatively, could related activities such as fighting DNS abuse also be considered necessary for the performance of a contract? External legal counsel provided the following summary answers: A: “a) it is not clear if the contractual necessity condition can only apply where there is a contract between data controller and data subject, or whether the contract could be between another person and the data subject. (For example, so that ICANN or a registry could argue that their processing is necessary for the contract between the registrar and the RNH/data subject). In countries where we have checked, there are no cases on point. Some data protection authorities interpret the provision narrowly. However, there is also guidance arguing for a more liberal approach. We think a more liberal approach is correct – but this is untested. b) What is 'necessary' is interpreted strictly. We do not think that the EPDP could successfully argue that preventing DNS abuses is 'necessary' for the contract with the RNH. There is guidance from the Article 29 Working Party on this which has examples somewhat similar to ICANN's situation”.

1 0

Re: [Gnso-epdp-team] RrSG Comment on Recommendation 10
by Alan Greenberg Feb. 1, 2019

Feb. 1, 2019

Milton, you say that "Compliance can check the full Whois record". That is certainly not the case now, nor is it assured that it will be the case going forward. Right now they must ask for specific fields and Purpose 5 says "If a contractual compliance complaint is filed, the complainant provides certain information regarding the issue, which may contain personal data. Depending on the nature of the issue, ICANN Compliance may ask the Registrar or Registry Operator for the minimum data needed to investigate the complaint. Compliance may also look at the public WHOIS to supplement its review or processing." If we follow that, then Compliance must depend on the good faith of the registrar and that is problematic. Are you prepared to alter Purpose 5 to make it clear that Compliance has unfettered access to the actual entire WHOIS record? Alan At 01/02/2019 11:36 AM, Mueller, Milton L wrote: Maybe I do not understand what you are saying, AlanG, but your statement below seems mistaken. Party X sends some kind of a request which is supposed to be relayed to a RNH. The registrar forwards it and assign it a number, as AlanW suggests below. Party X gets no response and becomes concerned. They ask ICANN compliance to look into the accuracy of the Whois record. Compliance can check the full Whois record. Further, the concern about “requests not being relayed” is very different from “requests being relayed to a non-viable contact address.” The former is a registrar failure (and I am not sure WHY exactly a registrar would fail to forward a request), the latter is an accuracy problem for which the RNH is responsible. Seems to me these more complicated procedures for tracking email delivery and responses are simply a way for certain private parties to offload the costs of their monitoring and enforcement activities onto Registrars (and indirectly, RNHs). We oppose that. --MM From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Alan Greenberg Sent: Friday, February 1, 2019 10:10 AM To: Alan Woods <alan(a)donuts.email>; Greg Aaron <greg(a)illumintel.com> Cc: GNSO EPDP <gnso-epdp-team(a)icann.org> Subject: Re: [Gnso-epdp-team] RrSG Comment on Recommendation 10 Alan, "Should ICANN compliance wish to test the fidelity of the system, that is in their purview to do so to ensure the mechanics of the system." does not give compliance the ability to address complaints that messages are seemingly not being relayed (or are being relayed to a non-viable contact address). Alan At 01/02/2019 05:34 AM, Alan Woods wrote: Thank you Greg and our SSAC colleagues for this, However, with my privacy lawyer hat on, can we actually remind ourselves here of the goal. The Goal here is to simply confirm that the registrar has relayed the requestors communication. The suggestion from our SSAC colleagues, has the Registrar, not only maintaining this log, but creating a database of requestor data, email addresses, metadata, and, for good measure, a positive obligation to further monitor responses from those emails sent, so as to initiate an action which may result in a suspension of a domain name. Outside of the fact that a system of this size is likely complex and cost prohibitive to smaller registrars, it ignores necessity and data minimization and alas fails the privacy by default and privacy by design tests. I'm sure that the very clever folks at the registrars can come up with a much simpler and functional system along the lines of: A communication request received is assigned a number e.g. #X The number is provided to the requester (for their own reference) but the registrars have no need to maintain a record of which requester is assigned which number, just that request #X is made, and the system has confirmed its relay of the message associated with #X. Should ICANN compliance wish to test the fidelity of the system, that is in their purview to do so to ensure the mechanics of the system. None of the other data or actions are remotely necessary. I would also suggest that we give the registrars a bone here and state that nothing in our recommendation language should prevent the registrar from taking appropriate actions to prevent excessive use or abuse of the registrant contact process. Now to display how number 4 may be achieved, but also noting that this is not within ICANN's controllership and therefore outside of the ICANN policy reach: 4a. A Registrar may, at their own discretion, keeps a sufficiently anonymized log of requests (whereby the system pseudonymizes of somehow anonymizes personal data of the requester but is capable of logging where requestor (let's call him Y) has made 30000 requests #X ,#Z etc. This can then be used to perhaps filter such future requests from that requestor. To confirm this would be solely at the option of the regsitrar, abased on their own needs, size, resources etc. The registrar would be controller here, and ICANN base policy cannot dictate this. This would indeed be a prudent step for a larger registrar to prevent abuse of the relay system, and to avoid allegation that they are 'spamming' their registrants. To that end. I think Sarah's' proposed wording with Kristina's addition (and perhaps the clarification contained in 4 above) is still wholly sufficient for the goal and purpose pursued. Kind regards, Alan Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Thu, Jan 31, 2019 at 11:25 PM Greg Aaron <greg(a)illumintel.com<mailto:greg@illumintel.com>> wrote: The SSAC team proposes a revised version of #2. A goal is to make measurement and compliance activity around this contractual requirement possible. The Temp Spec doesn't offer that, and the existing proposals don't yet either. The RrSG proposal says that no personal data about the activity will retained, and log format or content are not specified. If so, how will a registrar demonstrate that a message from any requestor was sent to the registrant? The below makes clear that the records about forwarding are for examination by ICANN Compliance (only). If someone who originated a message is concerned, they can make a complaint to ICANN. That is the same model that we have now for invalid WHOIS and abuse reporting complaints. We also assume that such records will be retained for only an appropriate term. Part of the recommendation below is based on an existing procedure in the RAA. so it is familiar. It creates no new personal data transfer, and there is already a â��Pâ��urpose defined for cor contracted parties to send personal data to Compliance. It does not require the registrar to keep the entire email message if they do not want to. Proposed text: "2) The EPDP Team recommends that Registrars must maintain records that demonstrate that the communication from the requestor was relayed by email to the Registered Name Holder. This information must include the requestor's identity as it was provided to the Registrar, the Registered Name Holder's email address, and a timestamp. Such records will be available to ICANN for compliance purposes, upon request. If Registrar receives a bounced email notification or non-delivery notification message, the Registrar must initiate re-verification of the registrant's contact data per the RAA's WHOIS Accuracy Program Specification, paragraph 4." From: Gnso-epdp-team < gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Sarah Wyld Sent: Friday, January 25, 2019 4:14 PM To: gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] RrSG Comment on Recommendation 10 Hello All, For Recommendation 10, the RrSG has the following proposed new text: 1) In relation to facilitating email communication between third parties and the Registered Name Holder, the EPDP Team recommends that current requirements in the Temporary Specification that specify that a Registrar MUST provide an email address or a web form to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address or the contact itself, remain in place. 2) The EPDP Team recommends Registrars MUST maintain Log Files, which shall not contain any Personal Information, and which shall contain confirmation that a relay of the communication between the requestor and the Registered Name Holder has occurred, not including the origin, recipient, or content of the message. The registrar cannot be reasonably expected to confirm, or attempt to confirm by any means, the receipt of any such relayed communication. 3) DELETE 3 -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team

1 0

Re: [Gnso-epdp-team] Recommendation on privacy/proxy data.
by Alan Greenberg Feb. 1, 2019

Feb. 1, 2019

Alan, it is correct that the contents of a reply could contain identifiable information then the same is true for a web form. Are you saying that therefore there is NO possible way to allow contact? At some point, registrants need to take responsibility for what they do. Alan At 01/02/2019 07:46 AM, Alan Woods wrote: Thank you Alex for reopening this matter. >From a practicality POV the inclusion of a pseudonymised email in a publication is a disclosure of public data, as a pseudonymised email, is still an email for a data subject. It may be in a form the data subject does not recognize, but I believe a number of excellent and practical examples, such as auto-relay / auto out of office responses could easily identify the non-pseudonymised email and lead to identification of the Data Subject. I refer you recital 26 of the GDPR: "…Personal data which have unddergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person..." Alas the recommendation as worded, although I understand the practicality that is driving it, does not properly address data protection concerns. There is a lot of back and of forth possible on whether pseudonymisation may count as anonymization when published to a 3rd party, however in the context of Domain Names, where the domain name, and even the associated content, could be capable of linking the individual to the pseudonymised data (which is completely outside of outside of our control, but still relevant to our risk assessment), we need to tread carefully; more carefully than the ePDP has either the time or the scope to consider. To refer again to our goal : We must look to the state of the data that is in the RDDS currently, and whether the publication of individual data currently used would be data protection compliant or not. In its current state, with the myriad the uncertainties, it is not, therefore our recommendation must be not to publish. SOLUTION Allow the registrar / registry to consider (as Controller) the feasibility and the risk as it applies to them? Unless we, at this late stage, the ePDP can provide an actual means or suggestion as to implementation of how a registrar / registry can effectively figure out who is a P&P provider and thus publish those only details without an increase to risk, then our choice is plain. If the recommendation is to stand, use of MAY, and other permissive language, as opposed to a 'must' will allow each CP to assess the risk as they see it, as it all comes down to the fact that the ePDP cannot force the CPs to assume higher risk to appease some. Recommendation XX In the case of a domain name registration where a privacy/proxy service used (e.g. where data associated with a natural person is masked), Registrar (and Registry where applicable) MAY include in the public WHOIS and return in response to any query full WHOIS data, which may also include the existing privacy/proxy pseudonymized email. Kind regards, Alan Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon < alex(a)colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com>> wrote: All, Our review of ICANN's input on Temp Spec topics that were not covered by the Initial Report reminded me that we had at one point discussed ensuring that the current Temp Spec language on how Privacy/Proxy data should be handled (Appendix A 2.6) should added as a recommendation. Something along the lines of - Recommendation XX In the case of a domain name registration where a privacy/proxy service used (e.g. where data associated with a natural person is masked), Registrar MUST include in the public WHOIS and return in response to any query full WHOIS data, including the existing privacy/proxy pseudonymized email. There are two reasons why this is useful, IMO. First, given the time and effort needed to properly process "reasonable disclosure" requests by Registrars it seems useful to avoid a situation where non-public data is quickly found to be P/P service data. Avoiding this situation and simply including P/P data in the the initial response would make life better for all involved. Second, there is no need to redact information that is already "redacted" (by definition) by the P/P service. Also, given P/P services list the information of a legal person (in the case of a registrar affiliated service provider) in the place of the RNH's info it seems further redaction is unnecessary. Happy to discuss further on a future call. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex(a)colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team

1 0

RrSG Comment on Recommendation 10
by Sarah Wyld Feb. 1, 2019

Feb. 1, 2019

Hello All, For Recommendation 10, the RrSG has the following proposed new text: 1) In relation to facilitating email communication between third parties and the Registered Name Holder, the EPDP Team recommends that current requirements in the Temporary Specification that specify that a Registrar MUST provide an email address or a web form to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address or the contact itself, remain in place. 2) The EPDP Team recommends Registrars MUST maintain Log Files, which shall not contain any Personal Information, and which shall contain confirmation that a relay of the communication between the requestor and the Registered Name Holder has occurred, not including the origin, recipient, or content of the message. The registrar cannot be reasonably expected to confirm, or attempt to confirm by any means, the receipt of any such relayed communication. 3) DELETE 3 -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392

3 2

Revised Recommendations for (Final) Review
by Kurt Pritz Feb. 1, 2019

Feb. 1, 2019

Hello Everyone: Thanks again for your perseverance. And - thank you in advance for your spirit of cooperation and compromise in considering the attached. We have spent the last few days reviewing the transcripts and other records of our recent discussions and then amending the Final Report Recommendations - taking into account the Initial Report Recommendations, the small team work, the conclusions in Toronto and these last several meetings. The Recommendations included here are: Recommendation 5 - Data elements to be transferred from Registrars to Registries Recommendation 10 - Email communication Recommendation 12 - Reasonable Access Recommendation 14 - Responsible Parties [Not included are Rec. 13 (sent earlier) and Rec. 11 and the Research Purpose (to be sent tomorrow.] Each of these documents has a brief forward containing a description of the pertinent discussion and an explanation for choosing the wording in the Recommendations. They each then contain the Recommendation as originally written and a redline of the proposed recommendation based on the most recent discussions. Please read the entire documents (they are not long), and not just the recommendation itself. I am certainly not asking for you to stand silently by if you disagree with these Recommendations because they would negatively impact GDPR compliance. I am asking that you study the balancing that went into this and be ready to accept wording in cases where it does not match your own choice. Please review with your groups and return to us by Monday so that we can put any of these on the Tues/Wed/Thur agendas. Sincerely, Kurt

1 0