- Gnso-epdp-team - lists.icann.org

For your review - updated version of Final Report
by Marika Konings Feb. 16, 2019

Feb. 16, 2019

Dear EPDP Team, Based on the input received to date, the staff support team has made some further updates to the Final Report, mainly for clarity and consistency reasons. You will find these changes in redline in the attached version (a Word version is posted on the wiki, see https://community.icann.org/x/VZwWBg) We also included references to the legal guidance provided on city field and accuracy, consistent with how other parts of legal advice have been included. In a new Annex F, you find the statements received to date for inclusion from the SSAC and ALAC. The staff support team is assuming at this stage that the input provided by RySG and NCSG relates to the consensus designation process and finalization of the report – if this is not correct, please let us know and we can include the input provided accordingly. Please note that the RySG input provided further suggestions for clarifications / changes to some of the recommendations or parts of the report, these have NOT been applied so that the EPDP Team can first review and consider these. Further updates have also been made to the data element tables and workbooks in Annex D as a result of further work by the data elements team. You will find an overview of the changes below (these do not appear in redline in the report). If any of the changes made are considered substantive and requiring further discussion, please flag these as soon as possible (by Monday 18 Feb COB at the latest) so these can be added to the agenda for the meetings next week. Best regards, Caitlin, Berry and Marika Workbook updates: • Incorporated the split of Purpose 1 into 1A and 1B • Made updates to address a shortcoming of the workbooks where by a “transfer” from a Registrar is also considered a collection by a “Registry” • Developed a clearer distinction for the use of “optional” • Refined data elements designations for collection and transfer processing activities that better reflect what occurs technically • Refined the disclosure processing activity to identify a disclosure to a third party versus publication • Migrated the publication and disclosure processing activities from Purpose 2 to Purpose 3 to better represent a minimum public data set available on a public directory • Imported data element designations into update consolidated tables by processing activity • Created an additional view of data transferred from a Registrar to a Registry that better represents why data is transferred based on URS as a contractual arrangement for gTLDs versus gTLDs that are not contractually obligated to support URS • Applied filters to generate new tables used for recommendations in the final report which now include better representation for those data elements that are required for processing versus optional Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

1 0

NCSG comments on the final report
by Mueller, Milton L Feb. 16, 2019

Feb. 16, 2019

NCSG has reviewed the 11 Feb final report and attached are our comments. I've also attached them as text below. 15 February 2019 NCSG Comments for the annex of the final EPDP report The comments that follow pertain only to recommendations where the NCSG strongly disagrees or has important warnings or qualifications. Additional objections to other elements appearing in the report have been withheld due to our desire to reach a consensus policy. Recommendation #1: Purposes: * Purpose 2: Disclosure of data to third parties. NCSG continues to maintain that disclosure to third parties is not a valid ICANN purpose for processing domain name registrants’ data. Further, defining disclosure as a purpose is not necessary to disclose redacted data to law enforcement and other third parties with legitimate interests. To achieve consensus on this report, we have accepted this as a “purpose,” but warn that it could be overruled by law. * Consensus guidance: NCSG would like to record its concern. It does not object to this purpose. * Purpose 7: Purpose 7 is not acceptable to NCSG because it would needlessly increase the number of data registration elements in the RDDS or Whois. Some of these data elements could be very sensitive and personally identifiable. Registries can validate eligibility independently, without use of ICANN’s RDDS/Whois. We were assured by registry operators that such data elements would not go into the RDDS, but since this proceeding concerns RDDS/Whois we believe it is inevitable that the data will go into it. * Consensus guidance: NCSG dissents on this purpose. Recommendation #2: Research and OCTO * Recommendation 2 states that Phase 2 will consider whether additional purposes should be defined to facilitate carrying out the mission of ICANN’s Office of the Chief Technology Officer (OCTO). Yet OCTO has clearly stated on multiple occasions that it does not need access to personal information of domain name registrants. While we favor seeking legal guidance on ICANN’s ability to use Whois data for research, Rec 2 is too ambiguous and broad and could open the door to bulk access for many third parties (and is actually intended to do so) * Consensus guidance: NCSG dissents on this recommendation. Recommendation #7: Transfer of registration data elements * Recommendation 7 states “the specifically-identified data elements under “[t]ransmission of registration data from Registrar to Registry” … must be transferred from registrar to registry provided an appropriate legal basis exists and data processing agreement is in place." * Consensus guidance: NCSG can accept this but wishes to emphasize that there may be no valid legal justification for transferring all of these data elements from registrars to registries and inclusion of this recommendation does not imply that there is one. Recommendation #8: Transfer to Escrow * As noted in our objection to Purpose 7, additional data elements identified by registries should not be added to escrow. * Consensus guidance: NCSG dissents from Purpose 7 Recommendation #16: Geographic differentiation * The Recommendation says that Registrars and Registry Operators are permitted to differentiate between registrants on a geographic basis, but are not obligated to do so. * NCSG does not recall the group settling on this position. NCSG believes that ICANN’s rules should be uniformly applicable, therefore registries and registrars should be obliged NOT to differentiate. Recommendation #18: Reasonable access, Timeline, and Criteria NCSG accepts the recommendation and particularly emphasizes the importance of re-naming this to “Reasonable Requests for Lawful Disclosure of Non-Public Registration Data.” We have the following observations: * Logs of requests: Logs of requests should be provided only to ICANN upon request, on a case by case basis, as stated in purpose 13. The audit function, which has been added to the recommendation 18, is not acceptable. * Logs of the request should only contain information about “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 distinction between urgent and non-urgent requests and obliging contracted parties to treat requests differently is not acceptable. * We recommend deleting recommendation 18 provisions about logs and responding to urgent requests

1 0

ALAC statement on the Phase 1 Final Report
by Alan Greenberg Feb. 16, 2019

Feb. 16, 2019

Please find attached the ALAC statement on the report submitted to the GNSO Council. Please note that this statement has the formal approval of the ALAC. Alan

1 0

RySG feedback on 11 Feb Draft of phase 1 report
by Anderson, Marc Feb. 16, 2019

Feb. 16, 2019

Kurt and Team, The RySG has reviewed the 11 Feb draft of the phase 1 report and is providing the attached comments and assessment of where we support and do not support the purposes and recommendations as written. Thank you, Marc Marc Anderson mcanderson(a)verisign.com<mailto:mcanderson@verisign.com> Cell: 571.521.9943 Office: 703.948.3404 12061 Bluemont Way, Reston, VA 20190 Verisign.com<http://www.verisign.com/>

1 0

Timing of Feedback on Draft Final Report
by Kurt Pritz Feb. 15, 2019

Feb. 15, 2019

Hi Everyone: TIMING I have been asked by a couple groups about the timing of feedback for the Final Report, given that we are at the conclusion of the quiet period. The purpose of this time was to flag issues for the final report and also to provide a group written statement accompanying the report on topics. As it currently sits, today is the day to flag issues in the final report so that the next version can be developed and meet agendas can be set for next week. However, statements that will be included in the reports can be provided later as they will added to or incorporated into the report in some way. If necessary, statements could be issued as late as Tuesday. (To differentiate between today’s requirement to flag issues and the statements: I think it means that there are no surprises in the report.) I wish to thank many who have contributed their review of the report. Many questions were raised and I believe the report will be better understood based on the email interactions and clarifications that have taken place. We plan meetings for Tuesday and Wednesday to discuss issues raised and items that need to be closed. OUTSTANDING ITEMS I have not yet sent out the last Bundle (aka “3B”) for designation of consensus. Part of this week was to allow for online discussion of those recommendations. I have had been party to discussions on the recommendation for Reasonable Access where the there is not yet agreement on the phrasing “Reasonable Requests for Lawful Access” vs “Reasonable Lawful Access” so that I could fully understand the concerns between the two phrases. This remaining difference is the result of the clock running out as different versions were championed at different meetings. I think we should place Reasonable Access on the agenda for Tuesday. This is an important recommendation and one where we have made great headway and come farther than I thought we would. It is always risky for me to characterize an issue but I want to take advantage of the work we have done to date and the agreement in principle that we have on this Recommendation and come to agreement on the language as well. During our meetings, I heard two concerns raised in reference to the two different phrasings above. Contracted Parties want to ensure that just because a request is reasonable or properly submitted, that disclosure is not required. The request must still be lawful (e.g., in a Art 6(1)f sense) before a disclosure is made. Data requesters want to ensure that registrars will not respond merely by rejecting all requests - but that they take reasonable steps to determine if the request can be fulfilled in a GDPR-complaint way. I think the spirit of the agreement addresses both of those concerns but there is concern that the different phrasings allow the agreement in principle to be turned. I believe that the Recommendation can be made final by adding sentence regarding a reasonable response by registrars and the requirement that requests must be GDPR complaint before disclosure can be made. I hope you find that constructive. It is sort of an extraordinary intervention on my part but I see an opportunity to arrive at a consensus position on a very difficult topic. Please let me know if you have questions on either of these two topics. Best regards, Kurt

3 2

Consensus calls, SSAC - Bundle 3
by Ben Butler Feb. 15, 2019

Feb. 15, 2019

Hi Kurt, As requested, and after deliberating with SSAC members, here are the consensus call positions from SSAC for Bundle 3/3B. I have grouped the recommendations based on our position. We have provided comments on a few for inclusion/consideration in the report to GNSO Council. SSAC will likely provide additional comments next week as well based on the extended deadline referred to in your last correspondence. Supported Recommendations: Recommendation #5 (old #4) - Data elements to be collected by Registrars – SSAC concurs with the recommendation with the understanding that Registrars must support / process Tech Contact data if it is provided by the RNH Explanation: There is some confusion whether Recommendation 5 requires registrars to offer the Tech Contact fields to their Registered Name Holders or not. This is because Recommendation 5's table marks the Tech Contact fields as mandatory to collect, but Recommendation 5 also says "if the Registrar provides this option". SSAC understands that there are legal requirements for collecting and transferring the Tech Contact data which will need to be discussed in the implementation phase. SSAC believes that the ePDP Team's discussion was: Registrars MUST offer the Registered Name Holder the opportunity to provide Technical Contact data. Technical Contact data should be optional for the Registered Name Holder to provide. If Technical Contact data is provided to the registrar, the data must be provisioned to the registry. If that is what Recommendation 5 delivers, SSAC can endorse Recommendation 5. If Recommendation 5 does not deliver that, SSAC cannot endorse Recommendation 5. Recommendation #7 (old #5)– Data elements to be transferred from Registrars to Registries – SSAC concurs with the recommendation as written Recommendation #9 (old #7) – Contractual Compliance – SSAC concurs with the recommendation as written Recommendation #10 (old #8) – Data Redaction – SSAC concurs with the recommendation as written Recommendation #12 (old #9) – Organization field – SSAC concurs with the recommendation as written Recommendation #13 (old #10) – Email communication – SSAC concurs with the recommendation as written Recommendation #14 – Privacy/Proxy Registrations – SSAC concurs with the recommendation as written Recommendation #19 (old #13) - Controller Agreement – SSAC concurs with the recommendation as written Recommendation #20 (old #14) - Responsible Parties – SSAC concurs with the recommendation as written Recommendation #27 (old #22) – Impact on other policies – SSAC concurs with the recommendation as written Recommendation #29 – Admin Contact Transition – SSAC concurs with the recommendation as written Recommendation #2 –Additional Purposes – SSAC concurs with the recommendation as written Dissentions: Recommendation #16 – Geographic Basis – SSAC cannot support the recommendation as written (See Below) Recommendation #17 – Natural vs. legal – SSAC cannot support the recommendation as written (See Below) Reasoning: Recommendations 16 and 17 have a negative effect on security and legitimate contactability. Recommendation 16 allows significant over-redaction of data not required by GDPR (or other laws currently in place), and enables a race to the bottom, allowing venue-shopping without respect to the actual location of registrars or registrants. Recommendation 17 enables ongoing redaction of information about legal persons that do not have the rights of natural persons. These outcomes are not balanced, and are neither necessary nor desirable. We believe that better, more balanced solutions are both legally and technically possible and should be discussed. It is the SSAC's position that: * Recommendation 16: Registrars and Registry Operators must be obligated to differentiate between registrants on a geographic -- i.e. legal jurisdiction basis, after a suitable implementation period. * Recommendation 17: Registrars and Registry Operators must be obligated to differentiate between registrations of legal and natural persons, after a suitable implementation period. Regarding Recommendation 17: * The EPDP Team will discuss the Legal vs. Natural issue in Phase 2, and SSAC looks forward to participating in that discussion. Should Recommendation 17 be adopted by Council, SSAC notes that the study criteria in section #2 are unbalanced and must be updated. They assume that the main decision-making criteria are the costs and risks to contracted parties. The list is missing consideration of how policy affects third parties with legitimate interests, and how the law imposes new responsibilities(and therefore costs) on the Contracted Parties . As SAC104 notes: "The GDPR imposes certain new obligations and therefore risk and costs on registrars and registry operators. It has also imposed risk and costs on the parties who rely upon domain registration data for the wide array of legitimate purposes. The GDPR calls for balancing and the accommodation of legitimate security interests, explicitly called out in Recital 49. ICANN policy should also provide balanced solutions. In some cases the Initial [and now the Final] Report asks what costs will be borne by the Contracted Parties, but does not also evaluate the costs on all other parties, or the cost of not putting a balanced solution into place. Cost or risk to registrars or registry operators alone is not a persuasive argument against balanced solutions." Supporting Documentation: SAC104: https://www.icann.org/en/system/files/files/sac-104-en.pdf SAC101v2: https://www.icann.org/en/system/files/files/sac-101-v2-en.pdf As SSAC stated in SAC104: "The GDPR states clearly that it 'does not cover processing of personal data which concerns legal persons.' We recommend that registrars be required to deploy mechanisms that ensure a reliable declaration or determination of natural or legal person status for new registrations going forward, and to eventually obtain those declarations or determinations for existing registrations and their registrants. "Contact data associated with natural persons should be published in RDS where such is not prohibited by local law. In SAC101, SSAC stated: 'The new policy [The Temporary Specification] allows RDDS operators complete freedom to choose when to redact domain contact data from publication, whether or not a domain contact is protected by GDPR or by any other local privacy law. The result has been blanket redactions, hiding more data than is legally called for. A more balanced and justified approach is needed.. access should not be less timely, more restricted, and less public than law requires.... We also note that as of this writing, most ccTLD operators in the European Union continue to publish some (and sometimes all) contact data fields for domains registered by legal persons. Some continue to publish some personal data for natural person registrants in public WHOIS output.' "SAC101 also highlights RIPE-NCC's solution, which allows for the publication of data about natural persons contained in the contact data for legal persons. This process provides mechanisms that RIPE-NCC says were specifically designed to comply with GDPR. The RIPE-NCC solution seems to be balanced in that it provides contactability and does not overapply the law. SSAC believes that RIPE's model deserves a full examination and neutral legal evaluation.... We also recommend the following: 1. Introduction of a policy requiring registrants to make a legal or natural person declaration. 2. Obtaining declaration would be mandatory for registrars to implement within a reasonable time. 3. A declaration would only be required during registration events, i.e. when a new domain is registered, or when an existing domain is renewed or transferred (by gaining registrar). This would eventually "fill in" status data about existing/historical registrations. 4. Registrar may make declaration on behalf of registrant if the registrar has reasonable knowledge of registrant's status and the registrant has not made a declaration of its own. This would be applicable to registrars with specific business models, for instance when they only process registrations on behalf of organizations where it is clear that the registrant falls into a particular category based on their relationship with the registrar. 5. Registrant may change its declaration at any time. 6. The absence of a declaration results in assumption that the registrant is a natural person; i.e. a default redaction of data. 7. Inaccurate declarations will be subject to a revised WHOIS inaccuracy complaint process." Cluster #3B Recommendation #11 City Field – SSAC concurs with the recommendation as written Recommendation #15 (new #11) - Data retention – SSAC concurs with the recommendation as written Recommendation #18 (old #12) – Reasonable access – SSAC concurs with the recommendation as written Recommendation #28 - Implementation Transition Period – SSAC concurs with the recommendation as written As always, please reach out if we can provide any additional context or clarification. -Ben

1 0

Issues with the report
by Caitlin Tubergen Feb. 15, 2019

Feb. 15, 2019

Hi Alan, Please find answers to your questions in blue. We are still looking into one of your questions, but noting the request for a quick reply, please see the answers below. Thank you. Best regards, Marika, Berry, and Caitlin -- There are several issues with the report that are either incorrect, or I do not know how the decisions were made (and several others also do not know). - Rec #8 implies (but does not clearly say) that offering Tech Contacts is an option for registrars. In the interim report, we raised the question of whether "optional" for the Tech fields meant optional for the registrant, or optional for the registrar. I cannot recall ever discussing this when we went over the comments, but somehow it is now optional for registrars, requiring registrants to shop around for a registrar that accepts the option - if indeed any registrars will! When was this decided? Please refer to the 24 January meeting as well as the response from Bird & Bird re: the liability associated with additional contact information. As you may remember, there was an “informal vote” at the end of the 24 January call, during which there was no consensus with respect to the meaning of “optional”. In other words, approximately half of the groups preferred optional to mean the registrar has the option of offering a technical contact field to the registrant, and half of the groups preferred optional to mean the registrar must offer the technical contact field but the registrant has the option of providing contact information for the technical contact field. We noted, during the call, that we would document the status of the issue in the Final Report and await further legal advice. The following question was posted to legal counsel: 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: Legal Counsel provided the following response: “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”. If you would like to refer to the full response from Bird & Bird, please refer to the this memo. This response has also been documented in the Final Report. - Rec #16 takes geographic differentiation off the table. My recollection is that we put that decision into Phase 2. When was this decision taken? Please refer to the email from Marc A. (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-February/001543.html) which includes the text that is now in the Final Report. Feedback was requested, following a number of positive responses to this approach (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-February/001485.html) - no objections were raised at the time; however, if your group believes this is in error, please flag this accordingly. Please also note the following question has been posed to legal counsel: In light of the EDPB Guidance on territorial scope of GDPR, how do ICANN’s stable establishments within the EU impact its responsibilities as a data controller. The EDPB Guidance appears to suggest that ICANN, as a controller with stable establishments within the EU, might be required to comply with GDPR? Is this the case even if the majority of processing activities (including registrar/reseller collection of data from RNH) take place outside of the EU? . Specifically: Do any of ICANN’s operations within the EU qualify as Establishments, as defined by Recital 22 of the GDPR? If ICANN is found to have Establishments within the EU, do these Establishments require ICANN (as a controller of gTLD Registration Directory Services related processing activities) to be subject to article 3.1 of the GDPR? Do the answers to the above questions impact ICANN’s, and/or any associated controllers’ or processors’, ability to distinguish between Registered Name Holders (RNH)/data subjects based on the geographic location of the RNHs in determining the geographic scope of GDPR? - Rec #18 does not make sense to me. It says that Temp Spec sections 4.1 and 4.2 are to be replaced "upon expiration". What is the purpose of replacing these sections once the Temp Spec is no longer operative? And how does that affect access? I note that Rec #28 temporarily reinstates the Temp Spec, but the version PRIOR to expiration. The work of the EPDP Team is to confirm, or not, the language in the Temporary Spec. In some cases, the Team confirmed the precise language in the Temporary Specification. Per the feedback of the EPDP Team, rather than simply confirming language, we have inserted the specifically-agreed upon language within the Temporary Specification into the Final Report. In the case of Recommendation 18, the Team agreed to replace the language in the Temporary Specification with the language noted in the recommendation, noting that work in Phase 2 may complement or replace the language within the recommendation. The Team agreed these new defined criteria would be effective as soon as the Temporary Specification expires, which is why it is denoted as such. - Rec #29 requires explicit action from registrars before the Admin fields can be eliminated. Either we need to explicitly say that this action must be taken prior to 29 February 2020, or we need to include them in Rec #5 listing all RDDS fields flagging them as being there only until the Rec #29 action is taken. Thank you for flagging this. We could add a sentence that this action must be taken prior to 29 February 2020 if the EPDP Team agrees. On a less substantive level: - We say the Tech name and contact fields are option, but in the various tables, the are not flagged with a trailing (opt.) like the other optional fields are. - In Rec #8, why are Tech name and contacts transmitted by registries to escrow but not by registrars (as currently required by the RAA)? We are looking into this and will revert to you shortly. - Rec #13 makes a reference to "Recommendation X". I presume this should be Rec #6. Yes, thank you for noting this. - Rec #21 makes reference to Thick and Thin registries, a concept that we are told no longer exists. The language you reference is part of the Temporary Specification that the Team agreed to confirm at its face-to-face meeting in Toronto. Please refer to Annex D of the Temporary Specification. The first issues have a direct bearing on whether the ALAC can support this report and I would appreciate a quick reply. Alan

4 3

Re: [Gnso-epdp-team] Permission to publish redacted information
by Marika Konings Feb. 15, 2019

Feb. 15, 2019

Alan, can you clarify why you consider that this is not covered under recommendation #6: "The EPDP Team recommends that, as soon as commercially reasonable, Registrar must provide the opportunity for the Registered Name Holder to provide its Consent to publish additional contact information in the RDS for the sponsoring registrar." Thanks, Caitlin, Berry and Marika On 2/15/19, 08:55, "Gnso-epdp-team on behalf of Alan Greenberg" <gnso-epdp-team-bounces(a)icann.org on behalf of alan.greenberg(a)mcgill.ca> wrote: Temp Spec 2.3 allowed a registrant to consent to publication of redacted fields. In Toronto, we noted that this did not apply to e-mail since it was not technically "redacted". Rec #6 addressed this. But we seem to have lost the ability of a registrant to consnt to publication of the redacted fields! Is this an error that will be corrected or intentional (I do not recall such a decision). Alan _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team

2 1

Permission to publish redacted information
by Alan Greenberg Feb. 15, 2019

Feb. 15, 2019

Temp Spec 2.3 allowed a registrant to consent to publication of redacted fields. In Toronto, we noted that this did not apply to e-mail since it was not technically "redacted". Rec #6 addressed this. But we seem to have lost the ability of a registrant to consnt to publication of the redacted fields! Is this an error that will be corrected or intentional (I do not recall such a decision). Alan

1 0

Recommendation 9
by Trang Nguyen Feb. 15, 2019

Feb. 15, 2019

Dear EPDP Team, Please see below a request from Jamie Hedlund, ICANN’s SVP of Contractual Compliance and Consumer Safeguard. Regards, Trang Nguyen ICANN Org Liaison ** ICANN Contractual Compliance requests confirmation that the scope of Recommendation #9 is limited to registration data elements that appear in WHOIS (and eventually RDAP), and that it does not include data or information other than WHOIS (or RDAP) data elements. With this understanding, ICANN Contractual Compliance requirements for other data and information from contracted parties which is necessary for enforcement of ICANN’s agreements and policies, including the types of data listed in the ICANN Contractual Compliance Data Processing Activities overview, would not be governed by Recommendation #9. Please confirm. Thank you.

1 0