Here’s the BC response to Caitlin’s questions:

• The concept of user groups is useful because it helps explain the likely types of requestors that are expected to use the SSAD, and will make it easier to identify those that can validate their identity to help with accreditation.
• We believe that a predetermined list of purposes is necessary.  In Phase 1, the BC dissented from the Final Report because Purpose 2 did not specify the important third party purposes such as cybersecurity, IP infringement and consumer protection.  We continue to believe that this is required under GDPR to provide transparency to the registrant regarding how their personal data may be processed.  As a result, we do not support replacing this specificity with a list of user groups.  Instead, the policy recommendation needs to:
• List specific third party purposes in an updated Recommendation 1, Purpose 2
• Identify the legal basis to support the purpose cited by the requestor
• We propose that the following language be added to the Purposes Building Block.  Please note that the list in our proposed Purpose 2.2 (i)-(v) is based on the categories of user cases from the Wiki. 

All the best,

Margie & Mark,

On behalf of the BC

_______________________________________________________

Proposed text for the Purposes Building Block:

With respect to the ICANN purpose for this disclosure, the EPDP Team recommends that the requestors may select from the following purposes:

• Purposes 1, 3-7 as listed in the EPDP Phase 1 Final Report
• Purpose 2 from the EPDP Phase 1 Final Report is replaced with the following:

Purpose 2.1: The EPDP recognizes that ICANN has a responsibility to foster the openness, interoperability, resilience, security and/or stability of the DNS in accordance with its stated mission (Bylaws Section 1.1). It has a purpose to require actors in the ecosystem to respond to data disclosure requests that are related to the security, stability and resilience of the system.

Purpose 2.2: The EPDP recognizes that third parties may submit data disclosure requests for the following specific purposes: (i) criminal law enforcement, national or public security, (ii) non law enforcement investigations and civil claims, including, intellectual property infringement and UDRP and URS claims,  (iii)  contacting registrants, (iv) consumer protection, abuse prevention, digital service provider (DSP) and network security, or (v)  Registered name holder consent or contract.

From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen@icann.org>
Date: Thursday, November 21, 2019 at 3:02 PM
To: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org>
Subject: [Gnso-epdp-team] For your review: purposes and user groups

Dear EPDP Team:

Under the Team’s current review schedule, no time has been set aside to further discuss purposes and user groups. To that end, we wanted to test a proposed approach to these building blocks as outlined in the list of issues that was shared prior to ICANN66.

User groups:

• Consider whether or not a set of user groups needs to be developed – is this already addressed through the accreditation recommendations?
• If this is considered addressed as a result of the accreditation recommendations, consider the following text:

“The EPDP Team expects that the question of user groups will be addressed through the accreditation policy; specifically, all requestors will need to be accredited, and accreditation will include identity verification, which may include user category/categories.” 

Purposes:

• Consider purpose 2 and the previous agreement: “The EPDP Team agreed to consider at a later stage in the process whether an ICANN purpose for disclosure is necessary and/or desirable”. Has a later stage arrived, or is further time needed? Is this a question to be raised as part of the public comment period on the Initial Report?
• Consider also whether a set of pre-determined purposes needs to be developed that third-party requestors can provide. If this is not deemed necessary at this stage, consider the following text:

“As identified in building block a) criteria and content of requests, each request must include information about the legal rights of the requestor specific to the request and/or specific rationale and/or justification for the request, e.g. What is the basis or reason for the request; Why is it necessary for the requestor to ask for this data? The EPDP Team expects that over time, the entity responsible for receiving requests will be able to identify certain patterns that could result in the development of a preset list of rationales and/or justifications that a requestor can select from, while always maintaining the option for the requestor to provide this information in free form”.

Based on your feedback, the leadership team will determine when to discuss this further or whether the proposed approach has sufficient support to be incorporated in the draft Initial Report.

Please provide feedback by Thursday, 28 November.

Best regards,

Marika, Berry, and Caitlin