Notes and action items from today's EPDP Team Meeting - 30 August 2018
Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Tuesday, 4 September, 13:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Team Meeting #9 Thursday, 30 August 2018 High-Level Notes and Action Items Regarding progress on the Purposes for Processing Data: Registrars will rewrite section 4.4 to align the purposes for data processing with current data collection processes and the domain name lifecycle. It is requested that the draft be completed in time for the meeting on Tuesday, 4 Sept so that the rest of the team can review it. For sections 4.4.2, 4.4.8 and 4.4.9, it was agreed to take those purposes for accessing data out from under the heading, “Purposes for Processing Data” and place it in another section of the Policy that is being developed. The Support Team will recommend alternatives for identifying those access needs in the new Policy in time for the 4 September meeting. The support team will facilitate the creation of a team to consider a re-drafting of section 4.4.8. Several team members volunteered to participate, and Alex Deacon and Amr Elsadr volunteered to lead. The Support Team will develop the time requirements for this team to finish its work, taking into account the project plan and delivery requirements. The team will have a “narrow remit,” i.e., to draft the purpose for data disclosure for the reasons set out in section 4.4.8. Regarding other sub-sections of 4.4 the following team members offered to propose revised language for the below-mentioned sections: § 4.4 (introductory paragraph): Alex Deacon § 4.4.2: Amr Elsadr § 4.4.9: Ashley Heineman, Kavouss Arasteh Regarding Appendix C, Data Processing Requirements: Alan Woods will provide a draft recommendation to ICANN that the subject matter be taken out from consideration by this group and folded into current CPH-ICANN negotiations regarding registration data elements of the RAA and RA. This writing should address Margie’s intervention that certain elements of Appendix C remain under the purview of this group, e.g., Disclosure of non-public RDDS/WHOIS to third parties. Additionally, Alex Deacon will compose amendments to Appendix C, section 2, Lawfulness of Processing, that includes all GDPR mechanisms that allow processing of data. Other items: Support Team to adapt Thomas’s spreadsheet to aid in future discussion of data elements. We will also re-affirm the timing of this discussion to ensure it is prioritized. Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way? Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/2IpHBQ. 1. Roll Call & SOI Updates Attendance will be taken from Adobe Connect Please remember to mute your microphones when not speaking, and state your name before speaking for transcription purposes. Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Welcome and Updates from EPDP Team Chair Triage report - planning to create an updated, truncated version of the report to be distributed shortly Please ensure that any chat during the meeting is relevant to the discussion and does not distract from the speaker. 3. Review proposed next steps and action items on 4.4 a. Consider any input form the EPDP team that would include specific recommendation for amendments to the temporary specification for: 1. Registrar / Registry / ICANN processing of data: clarifying the elements proposed in the ICANN-developed specification 2. Third party processing where more specificity was requested At the end of the preamble, some suggested the text, "and only for the following legitimate purposes", may be unduly restrictive because of (1) potential new privacy laws in the future; and (2) updated advice from courts/DPAs. Accordingly, a proposed tweak may be, "and for legitimate interests not outweighed by the fundamental rights of relevant data subjects, consistent with GDPR." Feedback from EPDP Team: The point of the comment is when only focusing on legitimate interests, we are leaving out other lawful processing described in Article 6(1) of the GDPR - such as 6(1)(b), 6(1)(c), and 6(1)(f). Action item: Alex to propose updated language. Problem with 4.4.2 and 4.4.8 and 4.4.9 is that this is an access issue, not an ICANN purpose issue. The legitimate interest list is trying to incorporate third party legitimate interests into purpose definitions. If you try to accommodate access concerns by incorporating this into ICANN purposes, this is making the conflation DPAS explicitly warned against. Accordingly, this needs to be separated. If these sections are not in the correct part of the Temp Spec, where would these sections go? These sections appropriately belong in the access section. Clarifying question: we transitioned out of the welcome message into the substantive discussion. We are beginning on a wording issue, seemingly based on triage comments. What is the objective here? Are we trying to edit 4.4 and 4.4.2? This was an experiment is see if the language was an easy fix the team could agree to. It appears we are commingling purposes and legitimate interests for access, and we can explore separating these sections. We cannot provide access later, unless we have the data to start with. We may need to lower the rhetoric -- comments like "we will never agree to something" is unhelpful for forward progress. When we speak of data processing, we do not have to go through what a legitimate interest is. For data processing, we need to come up with what we mean by data processing at this stage. Are we talking about data collection? If so, this needs to be very narrowly defined - it needs to be based on ICANN's mission and purpose. Re: Thomas' email which mentions slicing and dicing, there are paths to obtain information. We must remember that payment information is collected for other registrar/registry purposes. We have to make a distinction making access to the data separate. We should focus now on collecting/processing of the data, and put access aside for now. We may need to add a few qualifiers to the text, such as ICANN's legal basis for processing this data. When we’re looking at bylaws references in the Temp Spec and any successor, we need to look at what the bylaws actually say and what they mean. This entire section appears to be hastily written. We might consider rewriting this from scratch, rather than tweaking current language. In the previous meeting and here, we need to bifurcate the sections in 4.4 et. seq. and create the first list for data processing for Ry/Rr. In reading through the triage comments, registrars frequently objected to this section, as there is a set of data collected for the purpose of dealing with the registrant, and this list may not be the correct list for dealing with these issues. Instead, we might consider rewriting this entire section to better align with Ry/Rr purposes. Kurt asked contracted parties to come up with a better way of looking at this type of data. Action item: Registrars to to rewrite section 4.4 in an attempt to align the text with actual business practices. The Temp Spec was written as a reaction to GDPR. It’s not written as policy recommendations. The intent here was to bolt on GDPR compliance to the existing system. Taking what is there and redlining it will be an unsuccessful endeavor. The starting point here is to make sure the entire group has a common understanding of what it means to deliver the service of a domain name registration to a registrant, as that will be the starting point of the purposes. There may be other purposes involved, but the first purpose is the delivery of the service of a domain name registration to a registrant. What clarification or direction is needed from the EPDP team for registrars to move forward with a conversation with your stakeholder group? Registrars will put pen to paper and circulate to the group. Perhaps we do not start with purposes, we start with what it means to deliver the service to avoid the problems the RDS group experienced. Re: ICANN Contractual Compliance, what does this mean, and what activities are involved? Like a third party, ICANN would have to demonstrate a legal basis to access this information. ICANN is a data controller, and ICANN collects data from contracted parties based on the RA and RAA. ICANN just needs to vet out their purposes and their legal basis to access this information. ICANN has solid purposes, but they need to be clear in what those purposes are. ICANN as a controller and as a party to the contract has a performance of contract purpose that is under GDPR. It is written in the bylaws and a commitment ICANN made during the transition. It is inappropriate to limit what ICANN can get access to for the purposes of enforcing the contract. We talked about whether ICANN has access to the data, and I believe the Temp Spec took away ICANN’s right to thick WHOIS, but only thin WHOIS. The Temp Spec did remove thick data transition, but that data is part and parcel of our discussions. There is still disagreement over § 4.4.8. This data disclosure does not belong under the purposes. Should the group rewrite these access questions? Where in our policy should these sections go so that we can preserve this right away? One option would be to move it to Appendix A, Section 4. Thinking about earlier comments, we may want to consider using a tool such as Thomas’s spreadsheet or concrete input from Rys/Rrs, and other groups would assist in drafting something so that when we come together next time, we are focused on specifics. The spreadsheet deals with data elements that support each purpose. Thoughts on path forward – flesh out purposes of data processing first and then identify data required to fulfill those purposes. If we can get the feedback from the RrSG to furnish the aforementioned homework quickly, we can move to the discussion on data elements shortly. Action: Alex as lead to clarify 4.4 Action: GAC as lead to rewrite section 4.4.9 We do not have a framework for investigation of cybercrime. We do have an obligation to support investigation of cybercrime, but it is not our framework, and this is an overreach in Section 4.4.8. This needs to be separated out and reworded. This discussion appears to be jumping around a bit. How are we going to reach a final product? Our end goal here is policy recommendations. Ad hoc debate of various sections of the temp spec may not help us reach our end goal. We’re talking about Section 4.4 today because we agreed to talk about purposes for processing first. However, we can use a spreadsheet as a tool to have a concrete discussion about data. To close this out, for third party uses of data, does anyone think these need to be adjusted? 4. Begin discussion on Appendix C For each section, we will refer to the Triage survey and meeting comments as a guide for considering to amend the specification section. We might then form a rough consensus for the content of edits and assign a small team (1-3) people to create a revised version for the next meeting. Breaking the Appendix into its parts: a. Preamble EPDP Team Feedback: Appendix C includes a chart which includes gTLD processing activities We can guide the discussion of what was capture in the triage EPDP Team Feedback: Amend the preamble, then amend the table. Take these in order. In reference to the preamble, some of the comments note that restating the GDPR (but not precisely) is not helpful. Should this match the GDPR, or should it be removed? Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way? Perhaps this should be handed back to ICANN Legal for review – send the chart back to ICANN and have that married with the other discussion on what other processing needs to take place. Should this be examined with the domain name lifecycle as a reference? When you put a point on discussion in the debate, it would be helpful to have one or two leads to put pen to paper and then share with the group for discussion. b. gTLD Processor Activity Chart c. Section 1 (Principles for Processing) Section 2 (Lawfulness of Processing) EPDP Team Feedback: Should the reference to applicable laws and regulations be removed? Should Section 1 in principles for processing might include principles from GDPR other than 6.6? Should it reference data principles more broadly? In Section 2, should there be an LEA carve out for the balancing test? Should we go back once we have agreed upon legitimate interests, should we go do an Article 4 code of conduct referral? How do we move this forward? Should we post these questions online and ask for responses? Proposal to change each controller “shall observe” instead of “will observe” On Section 2, it focuses on legitimate process and does not include other lawful purpose, so it needs to be changed similar to Section 4. The LEA carve out could then be removed. We have to have a discussion on the critical part – we are allowed to consider the needs of others if we have a justification. Are we allowed to look at others’ needs in WHOIS or not? There seems to be a copy/paste of Article 28 of the GDPR. This should be a suggestion to the GNSO that it should be added to the contract, not in here. This is a contractual matter and should not be in the policy. The feedback is not that we not consider other legitimate interest, but rather, to not conflate the legitimate interests of third parties with ICANN’s purposes. This Appendix may not be necessary once the agreement is re-negotiated with the contracted parties, though certain elements may still be necessary. It is not that we cannot consider third party interests, it is that they should not be conflated with ICANN’s interests. The fact that we take third party interests in the data into consideration does not mean that we collect data with third party interests in mind. Cooperation is the key here. · d. Deliberate on Sections 3.1, 3.1.1 – 3.1.6 (Specific Controller Processing requirements) e. Deliberate on 3.2 – 3.11 (Specific Controller Processing requirements) Discuss next steps for dealing with input on Appendix C 5. Confirm action items and questions for ICANN Org, if any Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way? 6. Wrap and confirm next meeting to be scheduled for Tuesday 4 September at 13.00 UTC.
Dear all, Just a suggestion: Might it be possible to have a table of Action Items that could be added to each meeting as a standing item on the agenda? Perhaps they could be colour coded (green - complete, yellow - in progress, white - not started, etc) so we could quickly review the progress and see where we are at with everything. The GNSO Council has a similar resource (‘[Action Item List](https://community.icann.org/display/gnsocouncilmeetings/Action+Items)’) which I happen to find very useful. Kind regards, Ayden Férdeline
On 30 Aug 2018, at 18:37, Caitlin Tubergen <caitlin.tubergen@icann.org> wrote:
Dear All,
Below, please find notes and action items from today’s EPDP Team Call.
As a reminder, our next meeting will be Tuesday, 4 September, 13:00 UTC.
Best regards,
Marika, Berry, and Caitlin
EPDP Team Meeting #9
Thursday, 30 August 2018
High-Level Notes and Action Items
Regarding progress on the Purposes for Processing Data:
- Registrars will rewrite section 4.4 to align the purposes for data processing with current data collection processes and the domain name lifecycle. It is requested that the draft be completed in time for the meeting on Tuesday, 4 Sept so that the rest of the team can review it.
- For sections 4.4.2, 4.4.8 and 4.4.9, it was agreed to take those purposes for accessing data out from under the heading, “Purposes for Processing Data” and place it in another section of the Policy that is being developed. The Support Team will recommend alternatives for identifying those access needs in the new Policy in time for the 4 September meeting.
- The support team will facilitate the creation of a team to consider a re-drafting of section 4.4.8. Several team members volunteered to participate, and Alex Deacon and Amr Elsadr volunteered to lead. The Support Team will develop the time requirements for this team to finish its work, taking into account the project plan and delivery requirements. The team will have a “narrow remit,” i.e., to draft the purpose for data disclosure for the reasons set out in section 4.4.8.
- Regarding other sub-sections of 4.4 the following team members offered to propose revised language for the below-mentioned sections:
- § 4.4 (introductory paragraph): Alex Deacon
- § 4.4.2: Amr Elsadr
- § 4.4.9: Ashley Heineman, Kavouss Arasteh
Regarding Appendix C, Data Processing Requirements:
- Alan Woods will provide a draft recommendation to ICANN that the subject matter be taken out from consideration by this group and folded into current CPH-ICANN negotiations regarding registration data elements of the RAA and RA.
- This writing should address Margie’s intervention that certain elements of Appendix C remain under the purview of this group, e.g., Disclosure of non-public RDDS/WHOIS to third parties.
- Additionally, Alex Deacon will compose amendments to Appendix C, section 2, Lawfulness of Processing, that includes all GDPR mechanisms that allow processing of data.
Other items:
- Support Team to adapt Thomas’s spreadsheet to aid in future discussion of data elements. We will also re-affirm the timing of this discussion to ensure it is prioritized.
- Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way?
Notes
These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/2IpHBQ.
1. Roll Call & SOI Updates
- Attendance will be taken from Adobe Connect
- Please remember to mute your microphones when not speaking, and state your name before speaking for transcription purposes.
- Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team.
2. Welcome and Updates from EPDP Team Chair
- Triage report - planning to create an updated, truncated version of the report to be distributed shortly
- Please ensure that any chat during the meeting is relevant to the discussion and does not distract from the speaker.
3. Review proposed next steps and action items on 4.4
a. Consider any input form the EPDP team that would include specific recommendation for amendments to the temporary specification for:
1. Registrar / Registry / ICANN processing of data: clarifying the elements proposed in the ICANN-developed specification
2. Third party processing where more specificity was requested
- At the end of the preamble, some suggested the text, "and only for the following legitimate purposes", may be unduly restrictive because of (1) potential new privacy laws in the future; and (2) updated advice from courts/DPAs. Accordingly, a proposed tweak may be, "and for legitimate interests not outweighed by the fundamental rights of relevant data subjects, consistent with GDPR."
Feedback from EPDP Team:
- The point of the comment is when only focusing on legitimate interests, we are leaving out other lawful processing described in Article 6(1) of the GDPR - such as 6(1)(b), 6(1)(c), and 6(1)(f).
Action item: Alex to propose updated language.
- Problem with 4.4.2 and 4.4.8 and 4.4.9 is that this is an access issue, not an ICANN purpose issue. The legitimate interest list is trying to incorporate third party legitimate interests into purpose definitions. If you try to accommodate access concerns by incorporating this into ICANN purposes, this is making the conflation DPAS explicitly warned against. Accordingly, this needs to be separated.
- If these sections are not in the correct part of the Temp Spec, where would these sections go?
- These sections appropriately belong in the access section.
- Clarifying question: we transitioned out of the welcome message into the substantive discussion. We are beginning on a wording issue, seemingly based on triage comments. What is the objective here? Are we trying to edit 4.4 and 4.4.2?
- This was an experiment is see if the language was an easy fix the team could agree to.
- It appears we are commingling purposes and legitimate interests for access, and we can explore separating these sections.
- We cannot provide access later, unless we have the data to start with. We may need to lower the rhetoric -- comments like "we will never agree to something" is unhelpful for forward progress.
- When we speak of data processing, we do not have to go through what a legitimate interest is. For data processing, we need to come up with what we mean by data processing at this stage. Are we talking about data collection? If so, this needs to be very narrowly defined - it needs to be based on ICANN's mission and purpose.
- Re: Thomas' email which mentions slicing and dicing, there are paths to obtain information. We must remember that payment information is collected for other registrar/registry purposes.
- We have to make a distinction making access to the data separate. We should focus now on collecting/processing of the data, and put access aside for now.
- We may need to add a few qualifiers to the text, such as ICANN's legal basis for processing this data. When we’re looking at bylaws references in the Temp Spec and any successor, we need to look at what the bylaws actually say and what they mean.
- This entire section appears to be hastily written. We might consider rewriting this from scratch, rather than tweaking current language.
- In the previous meeting and here, we need to bifurcate the sections in 4.4 et. seq. and create the first list for data processing for Ry/Rr. In reading through the triage comments, registrars frequently objected to this section, as there is a set of data collected for the purpose of dealing with the registrant, and this list may not be the correct list for dealing with these issues. Instead, we might consider rewriting this entire section to better align with Ry/Rr purposes. Kurt asked contracted parties to come up with a better way of looking at this type of data.
- Action item: Registrars to to rewrite section 4.4 in an attempt to align the text with actual business practices.
- The Temp Spec was written as a reaction to GDPR. It’s not written as policy recommendations. The intent here was to bolt on GDPR compliance to the existing system. Taking what is there and redlining it will be an unsuccessful endeavor. The starting point here is to make sure the entire group has a common understanding of what it means to deliver the service of a domain name registration to a registrant, as that will be the starting point of the purposes. There may be other purposes involved, but the first purpose is the delivery of the service of a domain name registration to a registrant.
- What clarification or direction is needed from the EPDP team for registrars to move forward with a conversation with your stakeholder group?
- Registrars will put pen to paper and circulate to the group.
- Perhaps we do not start with purposes, we start with what it means to deliver the service to avoid the problems the RDS group experienced.
- Re: ICANN Contractual Compliance, what does this mean, and what activities are involved?
- Like a third party, ICANN would have to demonstrate a legal basis to access this information.
- ICANN is a data controller, and ICANN collects data from contracted parties based on the RA and RAA. ICANN just needs to vet out their purposes and their legal basis to access this information. ICANN has solid purposes, but they need to be clear in what those purposes are.
- ICANN as a controller and as a party to the contract has a performance of contract purpose that is under GDPR. It is written in the bylaws and a commitment ICANN made during the transition. It is inappropriate to limit what ICANN can get access to for the purposes of enforcing the contract. We talked about whether ICANN has access to the data, and I believe the Temp Spec took away ICANN’s right to thick WHOIS, but only thin WHOIS.
- The Temp Spec did remove thick data transition, but that data is part and parcel of our discussions.
- There is still disagreement over § 4.4.8. This data disclosure does not belong under the purposes. Should the group rewrite these access questions? Where in our policy should these sections go so that we can preserve this right away?
- One option would be to move it to Appendix A, Section 4.
- Thinking about earlier comments, we may want to consider using a tool such as Thomas’s spreadsheet or concrete input from Rys/Rrs, and other groups would assist in drafting something so that when we come together next time, we are focused on specifics.
- The spreadsheet deals with data elements that support each purpose. Thoughts on path forward – flesh out purposes of data processing first and then identify data required to fulfill those purposes. If we can get the feedback from the RrSG to furnish the aforementioned homework quickly, we can move to the discussion on data elements shortly.
Action: Alex as lead to clarify 4.4
Action: GAC as lead to rewrite section 4.4.9
- We do not have a framework for investigation of cybercrime. We do have an obligation to support investigation of cybercrime, but it is not our framework, and this is an overreach in Section 4.4.8. This needs to be separated out and reworded.
- This discussion appears to be jumping around a bit. How are we going to reach a final product? Our end goal here is policy recommendations. Ad hoc debate of various sections of the temp spec may not help us reach our end goal.
- We’re talking about Section 4.4 today because we agreed to talk about purposes for processing first. However, we can use a spreadsheet as a tool to have a concrete discussion about data.
- To close this out, for third party uses of data, does anyone think these need to be adjusted?
4. Begin discussion on Appendix C
For each section, we will refer to the Triage survey and meeting comments as a guide for considering to amend the specification section. We might then form a rough consensus for the content of edits and assign a small team (1-3) people to create a revised version for the next meeting. Breaking the Appendix into its parts:
a. Preamble
EPDP Team Feedback:
- Appendix C includes a chart which includes gTLD processing activities
- We can guide the discussion of what was capture in the triage EPDP Team Feedback:
- Amend the preamble, then amend the table. Take these in order.
- In reference to the preamble, some of the comments note that restating the GDPR (but not precisely) is not helpful. Should this match the GDPR, or should it be removed?
- Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way?
- Perhaps this should be handed back to ICANN Legal for review – send the chart back to ICANN and have that married with the other discussion on what other processing needs to take place.
- Should this be examined with the domain name lifecycle as a reference?
- When you put a point on discussion in the debate, it would be helpful to have one or two leads to put pen to paper and then share with the group for discussion.
b. gTLD Processor Activity Chart
c. Section 1 (Principles for Processing)
Section 2 (Lawfulness of Processing)
EPDP Team Feedback:
- Should the reference to applicable laws and regulations be removed?
- Should Section 1 in principles for processing might include principles from GDPR other than 6.6?
- Should it reference data principles more broadly?
- In Section 2, should there be an LEA carve out for the balancing test?
- Should we go back once we have agreed upon legitimate interests, should we go do an Article 4 code of conduct referral?
- How do we move this forward? Should we post these questions online and ask for responses?
- Proposal to change each controller “shall observe” instead of “will observe”
- On Section 2, it focuses on legitimate process and does not include other lawful purpose, so it needs to be changed similar to Section 4. The LEA carve out could then be removed.
- We have to have a discussion on the critical part – we are allowed to consider the needs of others if we have a justification. Are we allowed to look at others’ needs in WHOIS or not?
- There seems to be a copy/paste of Article 28 of the GDPR. This should be a suggestion to the GNSO that it should be added to the contract, not in here. This is a contractual matter and should not be in the policy.
- The feedback is not that we not consider other legitimate interest, but rather, to not conflate the legitimate interests of third parties with ICANN’s purposes.
- This Appendix may not be necessary once the agreement is re-negotiated with the contracted parties, though certain elements may still be necessary.
- It is not that we cannot consider third party interests, it is that they should not be conflated with ICANN’s interests. The fact that we take third party interests in the data into consideration does not mean that we collect data with third party interests in mind.
- Cooperation is the key here.
·
d. Deliberate on Sections 3.1, 3.1.1 – 3.1.6 (Specific Controller Processing requirements)
e. Deliberate on 3.2 – 3.11 (Specific Controller Processing requirements)
Discuss next steps for dealing with input on Appendix C
5. Confirm action items and questions for ICANN Org, if any
- Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way?
6. Wrap and confirm next meeting to be scheduled for Tuesday 4 September at 13.00 UTC.
<smime.p7s>
Thanks, Ayden for this suggestion. It is actually one that staff had already started working on so we hope to be able to share a link to the relevant wiki page soon. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Ayden Férdeline <icann@ferdeline.com> Reply-To: Ayden Férdeline <icann@ferdeline.com> Date: Friday, August 31, 2018 at 04:57 To: "gnso-epdp-team@icann.org" <Gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items from today's EPDP Team Meeting - 30 August 2018 Dear all, Just a suggestion: Might it be possible to have a table of Action Items that could be added to each meeting as a standing item on the agenda? Perhaps they could be colour coded (green - complete, yellow - in progress, white - not started, etc) so we could quickly review the progress and see where we are at with everything. The GNSO Council has a similar resource (‘Action Item List<https://community.icann.org/display/gnsocouncilmeetings/Action+Items>’) which I happen to find very useful. Kind regards, Ayden Férdeline On 30 Aug 2018, at 18:37, Caitlin Tubergen <caitlin.tubergen@icann.org<mailto:caitlin.tubergen@icann.org>> wrote: Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Tuesday, 4 September, 13:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Team Meeting #9 Thursday, 30 August 2018 High-Level Notes and Action Items Regarding progress on the Purposes for Processing Data: * Registrars will rewrite section 4.4 to align the purposes for data processing with current data collection processes and the domain name lifecycle. It is requested that the draft be completed in time for the meeting on Tuesday, 4 Sept so that the rest of the team can review it. * For sections 4.4.2, 4.4.8 and 4.4.9, it was agreed to take those purposes for accessing data out from under the heading, “Purposes for Processing Data” and place it in another section of the Policy that is being developed. The Support Team will recommend alternatives for identifying those access needs in the new Policy in time for the 4 September meeting. * The support team will facilitate the creation of a team to consider a re-drafting of section 4.4.8. Several team members volunteered to participate, and Alex Deacon and Amr Elsadr volunteered to lead. The Support Team will develop the time requirements for this team to finish its work, taking into account the project plan and delivery requirements. The team will have a “narrow remit,” i.e., to draft the purpose for data disclosure for the reasons set out in section 4.4.8. * Regarding other sub-sections of 4.4 the following team members offered to propose revised language for the below-mentioned sections: · § 4.4 (introductory paragraph): Alex Deacon · § 4.4.2: Amr Elsadr · § 4.4.9: Ashley Heineman, Kavouss Arasteh Regarding Appendix C, Data Processing Requirements: * Alan Woods will provide a draft recommendation to ICANN that the subject matter be taken out from consideration by this group and folded into current CPH-ICANN negotiations regarding registration data elements of the RAA and RA. * This writing should address Margie’s intervention that certain elements of Appendix C remain under the purview of this group, e.g., Disclosure of non-public RDDS/WHOIS to third parties. * Additionally, Alex Deacon will compose amendments to Appendix C, section 2, Lawfulness of Processing, that includes all GDPR mechanisms that allow processing of data. Other items: * Support Team to adapt Thomas’s spreadsheet to aid in future discussion of data elements. We will also re-affirm the timing of this discussion to ensure it is prioritized. * Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way? Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/2IpHBQ. 1. Roll Call & SOI Updates * Attendance will be taken from Adobe Connect * Please remember to mute your microphones when not speaking, and state your name before speaking for transcription purposes. * Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Welcome and Updates from EPDP Team Chair * Triage report - planning to create an updated, truncated version of the report to be distributed shortly * Please ensure that any chat during the meeting is relevant to the discussion and does not distract from the speaker. 3. Review proposed next steps and action items on 4.4 a. Consider any input form the EPDP team that would include specific recommendation for amendments to the temporary specification for: 1. Registrar / Registry / ICANN processing of data: clarifying the elements proposed in the ICANN-developed specification 2. Third party processing where more specificity was requested * At the end of the preamble, some suggested the text, "and only for the following legitimate purposes", may be unduly restrictive because of (1) potential new privacy laws in the future; and (2) updated advice from courts/DPAs. Accordingly, a proposed tweak may be, "and for legitimate interests not outweighed by the fundamental rights of relevant data subjects, consistent with GDPR." Feedback from EPDP Team: * The point of the comment is when only focusing on legitimate interests, we are leaving out other lawful processing described in Article 6(1) of the GDPR - such as 6(1)(b), 6(1)(c), and 6(1)(f). Action item: Alex to propose updated language. * Problem with 4.4.2 and 4.4.8 and 4.4.9 is that this is an access issue, not an ICANN purpose issue. The legitimate interest list is trying to incorporate third party legitimate interests into purpose definitions. If you try to accommodate access concerns by incorporating this into ICANN purposes, this is making the conflation DPAS explicitly warned against. Accordingly, this needs to be separated. * If these sections are not in the correct part of the Temp Spec, where would these sections go? * These sections appropriately belong in the access section. * Clarifying question: we transitioned out of the welcome message into the substantive discussion. We are beginning on a wording issue, seemingly based on triage comments. What is the objective here? Are we trying to edit 4.4 and 4.4.2? * This was an experiment is see if the language was an easy fix the team could agree to. * It appears we are commingling purposes and legitimate interests for access, and we can explore separating these sections. * We cannot provide access later, unless we have the data to start with. We may need to lower the rhetoric -- comments like "we will never agree to something" is unhelpful for forward progress. * When we speak of data processing, we do not have to go through what a legitimate interest is. For data processing, we need to come up with what we mean by data processing at this stage. Are we talking about data collection? If so, this needs to be very narrowly defined - it needs to be based on ICANN's mission and purpose. * Re: Thomas' email which mentions slicing and dicing, there are paths to obtain information. We must remember that payment information is collected for other registrar/registry purposes. * We have to make a distinction making access to the data separate. We should focus now on collecting/processing of the data, and put access aside for now. * We may need to add a few qualifiers to the text, such as ICANN's legal basis for processing this data. When we’re looking at bylaws references in the Temp Spec and any successor, we need to look at what the bylaws actually say and what they mean. 1. This entire section appears to be hastily written. We might consider rewriting this from scratch, rather than tweaking current language. * In the previous meeting and here, we need to bifurcate the sections in 4.4 et. seq. and create the first list for data processing for Ry/Rr. In reading through the triage comments, registrars frequently objected to this section, as there is a set of data collected for the purpose of dealing with the registrant, and this list may not be the correct list for dealing with these issues. Instead, we might consider rewriting this entire section to better align with Ry/Rr purposes. Kurt asked contracted parties to come up with a better way of looking at this type of data. * Action item: Registrars to to rewrite section 4.4 in an attempt to align the text with actual business practices. * The Temp Spec was written as a reaction to GDPR. It’s not written as policy recommendations. The intent here was to bolt on GDPR compliance to the existing system. Taking what is there and redlining it will be an unsuccessful endeavor. The starting point here is to make sure the entire group has a common understanding of what it means to deliver the service of a domain name registration to a registrant, as that will be the starting point of the purposes. There may be other purposes involved, but the first purpose is the delivery of the service of a domain name registration to a registrant. * What clarification or direction is needed from the EPDP team for registrars to move forward with a conversation with your stakeholder group? * Registrars will put pen to paper and circulate to the group. * Perhaps we do not start with purposes, we start with what it means to deliver the service to avoid the problems the RDS group experienced. * Re: ICANN Contractual Compliance, what does this mean, and what activities are involved? * Like a third party, ICANN would have to demonstrate a legal basis to access this information. * ICANN is a data controller, and ICANN collects data from contracted parties based on the RA and RAA. ICANN just needs to vet out their purposes and their legal basis to access this information. ICANN has solid purposes, but they need to be clear in what those purposes are. * ICANN as a controller and as a party to the contract has a performance of contract purpose that is under GDPR. It is written in the bylaws and a commitment ICANN made during the transition. It is inappropriate to limit what ICANN can get access to for the purposes of enforcing the contract. We talked about whether ICANN has access to the data, and I believe the Temp Spec took away ICANN’s right to thick WHOIS, but only thin WHOIS. * The Temp Spec did remove thick data transition, but that data is part and parcel of our discussions. * There is still disagreement over § 4.4.8. This data disclosure does not belong under the purposes. Should the group rewrite these access questions? Where in our policy should these sections go so that we can preserve this right away? * One option would be to move it to Appendix A, Section 4. * Thinking about earlier comments, we may want to consider using a tool such as Thomas’s spreadsheet or concrete input from Rys/Rrs, and other groups would assist in drafting something so that when we come together next time, we are focused on specifics. * The spreadsheet deals with data elements that support each purpose. Thoughts on path forward – flesh out purposes of data processing first and then identify data required to fulfill those purposes. If we can get the feedback from the RrSG to furnish the aforementioned homework quickly, we can move to the discussion on data elements shortly. Action: Alex as lead to clarify 4.4 Action: GAC as lead to rewrite section 4.4.9 * We do not have a framework for investigation of cybercrime. We do have an obligation to support investigation of cybercrime, but it is not our framework, and this is an overreach in Section 4.4.8. This needs to be separated out and reworded. * This discussion appears to be jumping around a bit. How are we going to reach a final product? Our end goal here is policy recommendations. Ad hoc debate of various sections of the temp spec may not help us reach our end goal. * We’re talking about Section 4.4 today because we agreed to talk about purposes for processing first. However, we can use a spreadsheet as a tool to have a concrete discussion about data. * To close this out, for third party uses of data, does anyone think these need to be adjusted? 4. Begin discussion on Appendix C For each section, we will refer to the Triage survey and meeting comments as a guide for considering to amend the specification section. We might then form a rough consensus for the content of edits and assign a small team (1-3) people to create a revised version for the next meeting. Breaking the Appendix into its parts: a. Preamble EPDP Team Feedback: * Appendix C includes a chart which includes gTLD processing activities * We can guide the discussion of what was capture in the triage EPDP Team Feedback: * Amend the preamble, then amend the table. Take these in order. * In reference to the preamble, some of the comments note that restating the GDPR (but not precisely) is not helpful. Should this match the GDPR, or should it be removed? * Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way? * Perhaps this should be handed back to ICANN Legal for review – send the chart back to ICANN and have that married with the other discussion on what other processing needs to take place. * Should this be examined with the domain name lifecycle as a reference? * When you put a point on discussion in the debate, it would be helpful to have one or two leads to put pen to paper and then share with the group for discussion. b. gTLD Processor Activity Chart c. Section 1 (Principles for Processing) Section 2 (Lawfulness of Processing) EPDP Team Feedback: * Should the reference to applicable laws and regulations be removed? * Should Section 1 in principles for processing might include principles from GDPR other than 6.6? * Should it reference data principles more broadly? * In Section 2, should there be an LEA carve out for the balancing test? * Should we go back once we have agreed upon legitimate interests, should we go do an Article 4 code of conduct referral? * How do we move this forward? Should we post these questions online and ask for responses? * Proposal to change each controller “shall observe” instead of “will observe” * On Section 2, it focuses on legitimate process and does not include other lawful purpose, so it needs to be changed similar to Section 4. The LEA carve out could then be removed. * We have to have a discussion on the critical part – we are allowed to consider the needs of others if we have a justification. Are we allowed to look at others’ needs in WHOIS or not? * There seems to be a copy/paste of Article 28 of the GDPR. This should be a suggestion to the GNSO that it should be added to the contract, not in here. This is a contractual matter and should not be in the policy. * The feedback is not that we not consider other legitimate interest, but rather, to not conflate the legitimate interests of third parties with ICANN’s purposes. * This Appendix may not be necessary once the agreement is re-negotiated with the contracted parties, though certain elements may still be necessary. * It is not that we cannot consider third party interests, it is that they should not be conflated with ICANN’s interests. The fact that we take third party interests in the data into consideration does not mean that we collect data with third party interests in mind. * Cooperation is the key here. · d. Deliberate on Sections 3.1, 3.1.1 – 3.1.6 (Specific Controller Processing requirements) e. Deliberate on 3.2 – 3.11 (Specific Controller Processing requirements) Discuss next steps for dealing with input on Appendix C 5. Confirm action items and questions for ICANN Org, if any * Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way? 6. Wrap and confirm next meeting to be scheduled for Tuesday 4 September at 13.00 UTC. <smime.p7s>
Thanks Marika, I am very glad to hear that! Ayden On Fri, Aug 31, 2018 at 14:03, Marika Konings <marika.konings@icann.org> wrote:
Thanks, Ayden for this suggestion. It is actually one that staff had already started working on so we hope to be able to share a link to the relevant wiki page soon.
Best regards,
Caitlin, Berry and Marika
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Ayden Férdeline <icann@ferdeline.com> Reply-To: Ayden Férdeline <icann@ferdeline.com> Date: Friday, August 31, 2018 at 04:57 To: "gnso-epdp-team@icann.org" <Gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items from today's EPDP Team Meeting - 30 August 2018
Dear all,
Just a suggestion:
Might it be possible to have a table of Action Items that could be added to each meeting as a standing item on the agenda? Perhaps they could be colour coded (green - complete, yellow - in progress, white - not started, etc) so we could quickly review the progress and see where we are at with everything.
The GNSO Council has a similar resource (‘[Action Item List](https://community.icann.org/display/gnsocouncilmeetings/Action+Items)’) which I happen to find very useful.
Kind regards,
Ayden Férdeline
On 30 Aug 2018, at 18:37, Caitlin Tubergen <caitlin.tubergen@icann.org> wrote:
Dear All,
Below, please find notes and action items from today’s EPDP Team Call.
As a reminder, our next meeting will be Tuesday, 4 September, 13:00 UTC.
Best regards,
Marika, Berry, and Caitlin
EPDP Team Meeting #9
Thursday, 30 August 2018
High-Level Notes and Action Items
Regarding progress on the Purposes for Processing Data:
- Registrars will rewrite section 4.4 to align the purposes for data processing with current data collection processes and the domain name lifecycle. It is requested that the draft be completed in time for the meeting on Tuesday, 4 Sept so that the rest of the team can review it.
- For sections 4.4.2, 4.4.8 and 4.4.9, it was agreed to take those purposes for accessing data out from under the heading, "Purposes for Processing Data" and place it in another section of the Policy that is being developed. The Support Team will recommend alternatives for identifying those access needs in the new Policy in time for the 4 September meeting.
- The support team will facilitate the creation of a team to consider a re-drafting of section 4.4.8. Several team members volunteered to participate, and Alex Deacon and Amr Elsadr volunteered to lead. The Support Team will develop the time requirements for this team to finish its work, taking into account the project plan and delivery requirements. The team will have a "narrow remit," i.e., to draft the purpose for data disclosure for the reasons set out in section 4.4.8.
- Regarding other sub-sections of 4.4 the following team members offered to propose revised language for the below-mentioned sections:
· § 4.4 (introductory paragraph): Alex Deacon
· § 4.4.2: Amr Elsadr
· § 4.4.9: Ashley Heineman, Kavouss Arasteh
Regarding Appendix C, Data Processing Requirements:
- Alan Woods will provide a draft recommendation to ICANN that the subject matter be taken out from consideration by this group and folded into current CPH-ICANN negotiations regarding registration data elements of the RAA and RA.
- This writing should address Margie’s intervention that certain elements of Appendix C remain under the purview of this group, e.g., Disclosure of non-public RDDS/WHOIS to third parties.
- Additionally, Alex Deacon will compose amendments to Appendix C, section 2, Lawfulness of Processing, that includes all GDPR mechanisms that allow processing of data.
Other items:
- Support Team to adapt Thomas’s spreadsheet to aid in future discussion of data elements. We will also re-affirm the timing of this discussion to ensure it is prioritized.
- Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way?
Notes
These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/2IpHBQ.
1. Roll Call & SOI Updates
- Attendance will be taken from Adobe Connect
- Please remember to mute your microphones when not speaking, and state your name before speaking for transcription purposes.
- Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team.
2. Welcome and Updates from EPDP Team Chair
- Triage report - planning to create an updated, truncated version of the report to be distributed shortly
- Please ensure that any chat during the meeting is relevant to the discussion and does not distract from the speaker.
3. Review proposed next steps and action items on 4.4
a. Consider any input form the EPDP team that would include specific recommendation for amendments to the temporary specification for:
1. Registrar / Registry / ICANN processing of data: clarifying the elements proposed in the ICANN-developed specification
2. Third party processing where more specificity was requested
- At the end of the preamble, some suggested the text, "and only for the following legitimate purposes", may be unduly restrictive because of (1) potential new privacy laws in the future; and (2) updated advice from courts/DPAs. Accordingly, a proposed tweak may be, "and for legitimate interests not outweighed by the fundamental rights of relevant data subjects, consistent with GDPR."
Feedback from EPDP Team:
- The point of the comment is when only focusing on legitimate interests, we are leaving out other lawful processing described in Article 6(1) of the GDPR - such as 6(1)(b), 6(1)(c), and 6(1)(f).
Action item: Alex to propose updated language.
- Problem with 4.4.2 and 4.4.8 and 4.4.9 is that this is an access issue, not an ICANN purpose issue. The legitimate interest list is trying to incorporate third party legitimate interests into purpose definitions. If you try to accommodate access concerns by incorporating this into ICANN purposes, this is making the conflation DPAS explicitly warned against. Accordingly, this needs to be separated.
- If these sections are not in the correct part of the Temp Spec, where would these sections go?
- These sections appropriately belong in the access section.
- Clarifying question: we transitioned out of the welcome message into the substantive discussion. We are beginning on a wording issue, seemingly based on triage comments. What is the objective here? Are we trying to edit 4.4 and 4.4.2?
- This was an experiment is see if the language was an easy fix the team could agree to.
- It appears we are commingling purposes and legitimate interests for access, and we can explore separating these sections.
- We cannot provide access later, unless we have the data to start with. We may need to lower the rhetoric -- comments like "we will never agree to something" is unhelpful for forward progress.
- When we speak of data processing, we do not have to go through what a legitimate interest is. For data processing, we need to come up with what we mean by data processing at this stage. Are we talking about data collection? If so, this needs to be very narrowly defined - it needs to be based on ICANN's mission and purpose.
- Re: Thomas' email which mentions slicing and dicing, there are paths to obtain information. We must remember that payment information is collected for other registrar/registry purposes.
- We have to make a distinction making access to the data separate. We should focus now on collecting/processing of the data, and put access aside for now.
- We may need to add a few qualifiers to the text, such as ICANN's legal basis for processing this data. When we’re looking at bylaws references in the Temp Spec and any successor, we need to look at what the bylaws actually say and what they mean.
- This entire section appears to be hastily written. We might consider rewriting this from scratch, rather than tweaking current language.
- In the previous meeting and here, we need to bifurcate the sections in 4.4 et. seq. and create the first list for data processing for Ry/Rr. In reading through the triage comments, registrars frequently objected to this section, as there is a set of data collected for the purpose of dealing with the registrant, and this list may not be the correct list for dealing with these issues. Instead, we might consider rewriting this entire section to better align with Ry/Rr purposes. Kurt asked contracted parties to come up with a better way of looking at this type of data.
- Action item: Registrars to to rewrite section 4.4 in an attempt to align the text with actual business practices.
- The Temp Spec was written as a reaction to GDPR. It’s not written as policy recommendations. The intent here was to bolt on GDPR compliance to the existing system. Taking what is there and redlining it will be an unsuccessful endeavor. The starting point here is to make sure the entire group has a common understanding of what it means to deliver the service of a domain name registration to a registrant, as that will be the starting point of the purposes. There may be other purposes involved, but the first purpose is the delivery of the service of a domain name registration to a registrant.
- What clarification or direction is needed from the EPDP team for registrars to move forward with a conversation with your stakeholder group?
- Registrars will put pen to paper and circulate to the group.
- Perhaps we do not start with purposes, we start with what it means to deliver the service to avoid the problems the RDS group experienced.
- Re: ICANN Contractual Compliance, what does this mean, and what activities are involved?
- Like a third party, ICANN would have to demonstrate a legal basis to access this information.
- ICANN is a data controller, and ICANN collects data from contracted parties based on the RA and RAA. ICANN just needs to vet out their purposes and their legal basis to access this information. ICANN has solid purposes, but they need to be clear in what those purposes are.
- ICANN as a controller and as a party to the contract has a performance of contract purpose that is under GDPR. It is written in the bylaws and a commitment ICANN made during the transition. It is inappropriate to limit what ICANN can get access to for the purposes of enforcing the contract. We talked about whether ICANN has access to the data, and I believe the Temp Spec took away ICANN’s right to thick WHOIS, but only thin WHOIS.
- The Temp Spec did remove thick data transition, but that data is part and parcel of our discussions.
- There is still disagreement over § 4.4.8. This data disclosure does not belong under the purposes. Should the group rewrite these access questions? Where in our policy should these sections go so that we can preserve this right away?
- One option would be to move it to Appendix A, Section 4.
- Thinking about earlier comments, we may want to consider using a tool such as Thomas’s spreadsheet or concrete input from Rys/Rrs, and other groups would assist in drafting something so that when we come together next time, we are focused on specifics.
- The spreadsheet deals with data elements that support each purpose. Thoughts on path forward – flesh out purposes of data processing first and then identify data required to fulfill those purposes. If we can get the feedback from the RrSG to furnish the aforementioned homework quickly, we can move to the discussion on data elements shortly.
Action: Alex as lead to clarify 4.4
Action: GAC as lead to rewrite section 4.4.9
- We do not have a framework for investigation of cybercrime. We do have an obligation to support investigation of cybercrime, but it is not our framework, and this is an overreach in Section 4.4.8. This needs to be separated out and reworded.
- This discussion appears to be jumping around a bit. How are we going to reach a final product? Our end goal here is policy recommendations. Ad hoc debate of various sections of the temp spec may not help us reach our end goal.
- We’re talking about Section 4.4 today because we agreed to talk about purposes for processing first. However, we can use a spreadsheet as a tool to have a concrete discussion about data.
- To close this out, for third party uses of data, does anyone think these need to be adjusted?
4. Begin discussion on Appendix C
For each section, we will refer to the Triage survey and meeting comments as a guide for considering to amend the specification section. We might then form a rough consensus for the content of edits and assign a small team (1-3) people to create a revised version for the next meeting. Breaking the Appendix into its parts:
a. Preamble
EPDP Team Feedback:
- Appendix C includes a chart which includes gTLD processing activities
- We can guide the discussion of what was capture in the triage EPDP Team Feedback:
- Amend the preamble, then amend the table. Take these in order.
- In reference to the preamble, some of the comments note that restating the GDPR (but not precisely) is not helpful. Should this match the GDPR, or should it be removed?
- Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way?
- Perhaps this should be handed back to ICANN Legal for review – send the chart back to ICANN and have that married with the other discussion on what other processing needs to take place.
- Should this be examined with the domain name lifecycle as a reference?
- When you put a point on discussion in the debate, it would be helpful to have one or two leads to put pen to paper and then share with the group for discussion.
b. gTLD Processor Activity Chart
c. Section 1 (Principles for Processing)
Section 2 (Lawfulness of Processing)
EPDP Team Feedback:
- Should the reference to applicable laws and regulations be removed?
- Should Section 1 in principles for processing might include principles from GDPR other than 6.6?
- Should it reference data principles more broadly?
- In Section 2, should there be an LEA carve out for the balancing test?
- Should we go back once we have agreed upon legitimate interests, should we go do an Article 4 code of conduct referral?
- How do we move this forward? Should we post these questions online and ask for responses?
- Proposal to change each controller "shall observe" instead of "will observe"
- On Section 2, it focuses on legitimate process and does not include other lawful purpose, so it needs to be changed similar to Section 4. The LEA carve out could then be removed.
- We have to have a discussion on the critical part – we are allowed to consider the needs of others if we have a justification. Are we allowed to look at others’ needs in WHOIS or not?
- There seems to be a copy/paste of Article 28 of the GDPR. This should be a suggestion to the GNSO that it should be added to the contract, not in here. This is a contractual matter and should not be in the policy.
- The feedback is not that we not consider other legitimate interest, but rather, to not conflate the legitimate interests of third parties with ICANN’s purposes.
- This Appendix may not be necessary once the agreement is re-negotiated with the contracted parties, though certain elements may still be necessary.
- It is not that we cannot consider third party interests, it is that they should not be conflated with ICANN’s interests. The fact that we take third party interests in the data into consideration does not mean that we collect data with third party interests in mind.
- Cooperation is the key here.
·
d. Deliberate on Sections 3.1, 3.1.1 – 3.1.6 (Specific Controller Processing requirements)
e. Deliberate on 3.2 – 3.11 (Specific Controller Processing requirements)
Discuss next steps for dealing with input on Appendix C
5. Confirm action items and questions for ICANN Org, if any
- Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way?
6. Wrap and confirm next meeting to be scheduled for Tuesday 4 September at 13.00 UTC.
<smime.p7s>
Dear All, Please find the new wiki page, which includes a table of action items here: https://community.icann.org/display/EOTSFGRD/Action+Items. Thank you for flagging this, Ayden. Best regards, Marika, Berry and Caitlin From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Marika Konings <marika.konings@icann.org> Date: Friday, August 31, 2018 at 5:09 AM To: Ayden Férdeline <icann@ferdeline.com>, "gnso-epdp-team@icann.org" <Gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items from today's EPDP Team Meeting - 30 August 2018 Thanks, Ayden for this suggestion. It is actually one that staff had already started working on so we hope to be able to share a link to the relevant wiki page soon. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Ayden Férdeline <icann@ferdeline.com> Reply-To: Ayden Férdeline <icann@ferdeline.com> Date: Friday, August 31, 2018 at 04:57 To: "gnso-epdp-team@icann.org" <Gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items from today's EPDP Team Meeting - 30 August 2018 Dear all, Just a suggestion: Might it be possible to have a table of Action Items that could be added to each meeting as a standing item on the agenda? Perhaps they could be colour coded (green - complete, yellow - in progress, white - not started, etc) so we could quickly review the progress and see where we are at with everything. The GNSO Council has a similar resource (‘Action Item List’) which I happen to find very useful. Kind regards, Ayden Férdeline On 30 Aug 2018, at 18:37, Caitlin Tubergen <caitlin.tubergen@icann.org> wrote: Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Tuesday, 4 September, 13:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Team Meeting #9 Thursday, 30 August 2018 High-Level Notes and Action Items Regarding progress on the Purposes for Processing Data: Registrars will rewrite section 4.4 to align the purposes for data processing with current data collection processes and the domain name lifecycle. It is requested that the draft be completed in time for the meeting on Tuesday, 4 Sept so that the rest of the team can review it. For sections 4.4.2, 4.4.8 and 4.4.9, it was agreed to take those purposes for accessing data out from under the heading, “Purposes for Processing Data” and place it in another section of the Policy that is being developed. The Support Team will recommend alternatives for identifying those access needs in the new Policy in time for the 4 September meeting. The support team will facilitate the creation of a team to consider a re-drafting of section 4.4.8. Several team members volunteered to participate, and Alex Deacon and Amr Elsadr volunteered to lead. The Support Team will develop the time requirements for this team to finish its work, taking into account the project plan and delivery requirements. The team will have a “narrow remit,” i.e., to draft the purpose for data disclosure for the reasons set out in section 4.4.8. Regarding other sub-sections of 4.4 the following team members offered to propose revised language for the below-mentioned sections: · § 4.4 (introductory paragraph): Alex Deacon · § 4.4.2: Amr Elsadr · § 4.4.9: Ashley Heineman, Kavouss Arasteh Regarding Appendix C, Data Processing Requirements: Alan Woods will provide a draft recommendation to ICANN that the subject matter be taken out from consideration by this group and folded into current CPH-ICANN negotiations regarding registration data elements of the RAA and RA. This writing should address Margie’s intervention that certain elements of Appendix C remain under the purview of this group, e.g., Disclosure of non-public RDDS/WHOIS to third parties. Additionally, Alex Deacon will compose amendments to Appendix C, section 2, Lawfulness of Processing, that includes all GDPR mechanisms that allow processing of data. Other items: Support Team to adapt Thomas’s spreadsheet to aid in future discussion of data elements. We will also re-affirm the timing of this discussion to ensure it is prioritized. Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way? Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/2IpHBQ. 1. Roll Call & SOI Updates Attendance will be taken from Adobe Connect Please remember to mute your microphones when not speaking, and state your name before speaking for transcription purposes. Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Welcome and Updates from EPDP Team Chair Triage report - planning to create an updated, truncated version of the report to be distributed shortly Please ensure that any chat during the meeting is relevant to the discussion and does not distract from the speaker. 3. Review proposed next steps and action items on 4.4 a. Consider any input form the EPDP team that would include specific recommendation for amendments to the temporary specification for: 1. Registrar / Registry / ICANN processing of data: clarifying the elements proposed in the ICANN-developed specification 2. Third party processing where more specificity was requested At the end of the preamble, some suggested the text, "and only for the following legitimate purposes", may be unduly restrictive because of (1) potential new privacy laws in the future; and (2) updated advice from courts/DPAs. Accordingly, a proposed tweak may be, "and for legitimate interests not outweighed by the fundamental rights of relevant data subjects, consistent with GDPR." Feedback from EPDP Team: The point of the comment is when only focusing on legitimate interests, we are leaving out other lawful processing described in Article 6(1) of the GDPR - such as 6(1)(b), 6(1)(c), and 6(1)(f). Action item: Alex to propose updated language. Problem with 4.4.2 and 4.4.8 and 4.4.9 is that this is an access issue, not an ICANN purpose issue. The legitimate interest list is trying to incorporate third party legitimate interests into purpose definitions. If you try to accommodate access concerns by incorporating this into ICANN purposes, this is making the conflation DPAS explicitly warned against. Accordingly, this needs to be separated. If these sections are not in the correct part of the Temp Spec, where would these sections go? These sections appropriately belong in the access section. Clarifying question: we transitioned out of the welcome message into the substantive discussion. We are beginning on a wording issue, seemingly based on triage comments. What is the objective here? Are we trying to edit 4.4 and 4.4.2? This was an experiment is see if the language was an easy fix the team could agree to. It appears we are commingling purposes and legitimate interests for access, and we can explore separating these sections. We cannot provide access later, unless we have the data to start with. We may need to lower the rhetoric -- comments like "we will never agree to something" is unhelpful for forward progress. When we speak of data processing, we do not have to go through what a legitimate interest is. For data processing, we need to come up with what we mean by data processing at this stage. Are we talking about data collection? If so, this needs to be very narrowly defined - it needs to be based on ICANN's mission and purpose. Re: Thomas' email which mentions slicing and dicing, there are paths to obtain information. We must remember that payment information is collected for other registrar/registry purposes. We have to make a distinction making access to the data separate. We should focus now on collecting/processing of the data, and put access aside for now. We may need to add a few qualifiers to the text, such as ICANN's legal basis for processing this data. When we’re looking at bylaws references in the Temp Spec and any successor, we need to look at what the bylaws actually say and what they mean. This entire section appears to be hastily written. We might consider rewriting this from scratch, rather than tweaking current language. In the previous meeting and here, we need to bifurcate the sections in 4.4 et. seq. and create the first list for data processing for Ry/Rr. In reading through the triage comments, registrars frequently objected to this section, as there is a set of data collected for the purpose of dealing with the registrant, and this list may not be the correct list for dealing with these issues. Instead, we might consider rewriting this entire section to better align with Ry/Rr purposes. Kurt asked contracted parties to come up with a better way of looking at this type of data. Action item: Registrars to to rewrite section 4.4 in an attempt to align the text with actual business practices. The Temp Spec was written as a reaction to GDPR. It’s not written as policy recommendations. The intent here was to bolt on GDPR compliance to the existing system. Taking what is there and redlining it will be an unsuccessful endeavor. The starting point here is to make sure the entire group has a common understanding of what it means to deliver the service of a domain name registration to a registrant, as that will be the starting point of the purposes. There may be other purposes involved, but the first purpose is the delivery of the service of a domain name registration to a registrant. What clarification or direction is needed from the EPDP team for registrars to move forward with a conversation with your stakeholder group? Registrars will put pen to paper and circulate to the group. Perhaps we do not start with purposes, we start with what it means to deliver the service to avoid the problems the RDS group experienced. Re: ICANN Contractual Compliance, what does this mean, and what activities are involved? Like a third party, ICANN would have to demonstrate a legal basis to access this information. ICANN is a data controller, and ICANN collects data from contracted parties based on the RA and RAA. ICANN just needs to vet out their purposes and their legal basis to access this information. ICANN has solid purposes, but they need to be clear in what those purposes are. ICANN as a controller and as a party to the contract has a performance of contract purpose that is under GDPR. It is written in the bylaws and a commitment ICANN made during the transition. It is inappropriate to limit what ICANN can get access to for the purposes of enforcing the contract. We talked about whether ICANN has access to the data, and I believe the Temp Spec took away ICANN’s right to thick WHOIS, but only thin WHOIS. The Temp Spec did remove thick data transition, but that data is part and parcel of our discussions. There is still disagreement over § 4.4.8. This data disclosure does not belong under the purposes. Should the group rewrite these access questions? Where in our policy should these sections go so that we can preserve this right away? One option would be to move it to Appendix A, Section 4. Thinking about earlier comments, we may want to consider using a tool such as Thomas’s spreadsheet or concrete input from Rys/Rrs, and other groups would assist in drafting something so that when we come together next time, we are focused on specifics. The spreadsheet deals with data elements that support each purpose. Thoughts on path forward – flesh out purposes of data processing first and then identify data required to fulfill those purposes. If we can get the feedback from the RrSG to furnish the aforementioned homework quickly, we can move to the discussion on data elements shortly. Action: Alex as lead to clarify 4.4 Action: GAC as lead to rewrite section 4.4.9 We do not have a framework for investigation of cybercrime. We do have an obligation to support investigation of cybercrime, but it is not our framework, and this is an overreach in Section 4.4.8. This needs to be separated out and reworded. This discussion appears to be jumping around a bit. How are we going to reach a final product? Our end goal here is policy recommendations. Ad hoc debate of various sections of the temp spec may not help us reach our end goal. We’re talking about Section 4.4 today because we agreed to talk about purposes for processing first. However, we can use a spreadsheet as a tool to have a concrete discussion about data. To close this out, for third party uses of data, does anyone think these need to be adjusted? 4. Begin discussion on Appendix C For each section, we will refer to the Triage survey and meeting comments as a guide for considering to amend the specification section. We might then form a rough consensus for the content of edits and assign a small team (1-3) people to create a revised version for the next meeting. Breaking the Appendix into its parts: a. Preamble EPDP Team Feedback: Appendix C includes a chart which includes gTLD processing activities We can guide the discussion of what was capture in the triage EPDP Team Feedback: Amend the preamble, then amend the table. Take these in order. In reference to the preamble, some of the comments note that restating the GDPR (but not precisely) is not helpful. Should this match the GDPR, or should it be removed? Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way? Perhaps this should be handed back to ICANN Legal for review – send the chart back to ICANN and have that married with the other discussion on what other processing needs to take place. Should this be examined with the domain name lifecycle as a reference? When you put a point on discussion in the debate, it would be helpful to have one or two leads to put pen to paper and then share with the group for discussion. b. gTLD Processor Activity Chart c. Section 1 (Principles for Processing) Section 2 (Lawfulness of Processing) EPDP Team Feedback: Should the reference to applicable laws and regulations be removed? Should Section 1 in principles for processing might include principles from GDPR other than 6.6? Should it reference data principles more broadly? In Section 2, should there be an LEA carve out for the balancing test? Should we go back once we have agreed upon legitimate interests, should we go do an Article 4 code of conduct referral? How do we move this forward? Should we post these questions online and ask for responses? Proposal to change each controller “shall observe” instead of “will observe” On Section 2, it focuses on legitimate process and does not include other lawful purpose, so it needs to be changed similar to Section 4. The LEA carve out could then be removed. We have to have a discussion on the critical part – we are allowed to consider the needs of others if we have a justification. Are we allowed to look at others’ needs in WHOIS or not? There seems to be a copy/paste of Article 28 of the GDPR. This should be a suggestion to the GNSO that it should be added to the contract, not in here. This is a contractual matter and should not be in the policy. The feedback is not that we not consider other legitimate interest, but rather, to not conflate the legitimate interests of third parties with ICANN’s purposes. This Appendix may not be necessary once the agreement is re-negotiated with the contracted parties, though certain elements may still be necessary. It is not that we cannot consider third party interests, it is that they should not be conflated with ICANN’s interests. The fact that we take third party interests in the data into consideration does not mean that we collect data with third party interests in mind. Cooperation is the key here. · d. Deliberate on Sections 3.1, 3.1.1 – 3.1.6 (Specific Controller Processing requirements) e. Deliberate on 3.2 – 3.11 (Specific Controller Processing requirements) Discuss next steps for dealing with input on Appendix C 5. Confirm action items and questions for ICANN Org, if any Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way? 6. Wrap and confirm next meeting to be scheduled for Tuesday 4 September at 13.00 UTC. <smime.p7s>
participants (3)
-
Ayden Férdeline -
Caitlin Tubergen -
Marika Konings