[Gnso-epdp-team] Recommendation 13 - Responsibilities of the Parties - email list discussion

Chris Disspain chris.disspain at board.icann.org
Mon Feb 4 09:58:12 UTC 2019


Hi Kurt,

I think your suggested language below brings together all of the points of view. 

I do have one concern regarding the indemnification language “Indemnification clauses shall ensure that the risk for certain data processing is borne by either one or multiple parties that determine the purpose and means of the processing”. This goes beyond my understanding of ICANN’s plan to explore ways to possibly reduce risk to the contracted parties with respect to providing access to non-public WHOIS data through a unified access model. As currently drafted, I think the language might prove challenging when it comes time for the Board to consider this recommendation. 

Trang also raised a related question about indemnification where she noted that it’s not clear that liability should necessarily always rest with the party or parties that determine the purposes and means of processing, for example in the case of a data breach.
 
I think both of these points could be addressed if the sentence were edited to say something to the effect of: “Indemnification should be addressed as appropriate as part of the arrangements between ICANN, registries, and registrars.” 

I hope this makes sense. Happy to discuss as always. 


Cheers,

CD

> On 30 Jan 2019, at 19:53, Kurt Pritz <kurt at kjpritz.com> wrote:
> 
> Hi Everyone: 
> 
> To me, it seems as if we are in agreement with a set of principles and a variety of wordings will suit our purpose. 
> 
> I believe we need to point directly  to the thorough work done by several of our team that indicates that JCAs are an appropriate solution in many of the data processing cases. Before we made any recommendation, we started with this analysis of data, purposes, etc. 
> 
> I also have learned that the responsibilities of the parties (contracted parties and ICANN) will vary for each purpose even for each data processing step. There is analysis left to go. 
> 
> Taking into account the Initial Report Recommendation, the work of the small group subsequent to that, and the comments on this list,  I’d like to settle on the following wording: 
> 
> "The EPDP Team recommends that ICANN Org develop and implement any required data protection arrangements, as appropriate, with the Contracted Parties. In addition to the legally required components of such agreement, the agreement shall clearly specify the responsibilities of the respective parties for the processing activities as described therein. Indemnification clauses shall ensure that the risk for certain data processing is borne by either one or multiple parties that determine the purpose and means of the processing. Due consideration should be given to the analysis carried out by the EPDP Team ("Processors, Controllers, Co-Controllers and Joint Controllers," above in this Final Report).”
> 
> In addition, if Thomas or others wish to augment the analysis in the Initial Report with his email that are part of this chain (about avoiding liability), we should include that as an individual contribution to the team analysis.
> 
> It’s my hope we can accept this as a team.
> 
> Thanks for letting me weigh in on this and thank for the energy that’s gone into this discussion and the others.
> 
> Best regards,
> 
> Kurt
> 
> 
> 
>> On Jan 30, 2019, at 11:22 AM, Heineman, Ashley <AHeineman at ntia.doc.gov <mailto:AHeineman at ntia.doc.gov>> wrote:
>> 
>> I won't belabor this, but just to correct the record, the USG does not ask that the recommendation be deleted.  It does however specifically express concern about the EPDP proposing a "specific legal vehicle (i.e., Joint Controller Agreement)."
>> 
>> 
>> From: farzaneh badii <farzaneh.badii at gmail.com <mailto:farzaneh.badii at gmail.com>>
>> Sent: Wednesday, January 30, 2019 1:57 PM
>> To: Heineman, Ashley
>> Cc: Thomas Rickert; gnso-epdp-team at icann.org <mailto:gnso-epdp-team at icann.org>
>> Subject: Re: [Gnso-epdp-team] Recommendation 13 - Responsibilities of the Parties - email list discussion
>>  
>>  it seems like USG has suggested deleting the whole recommendation. I do not see any other opposition against JCA.  https://community.icann.org/display/EOTSFGRD/Public+Comment+Review+Tool?preview=/102139731/102139865/gnso-EPDP-pcrt-Initial-Report-REC13_20181228.docx <>
>> 
>> Unless you agreed on something during the F2F, I don't think we should remove JCA because of a single entity opposition - maybe staff can tell us if there have been other public comments specifically against JCA. 
>> 
>> Farzaneh 
>> 
>> 
>> On Wed, Jan 30, 2019 at 1:48 PM Heineman, Ashley <AHeineman at ntia.doc.gov <mailto:AHeineman at ntia.doc.gov>> wrote:
>> Attaching the narrative version of the USG comments should it be of interest.
>> 
>> 
>> 
>> Sent from my Verizon, Samsung Galaxy smartphone
>> 
>> 
>> -------- Original message --------
>> From: "Heineman, Ashley" <AHeineman at ntia.doc.gov <mailto:AHeineman at ntia.doc.gov>>
>> Date: 1/30/19 13:44 (GMT-05:00)
>> To: farzaneh badii <farzaneh.badii at gmail.com <mailto:farzaneh.badii at gmail.com>>, Thomas Rickert <epdp at gdpr.ninja <mailto:epdp at gdpr.ninja>>
>> Cc: gnso-epdp-team at icann.org <mailto:gnso-epdp-team at icann.org>
>> Subject: Re: [Gnso-epdp-team] Recommendation 13 - Responsibilities of the Parties - email list discussion
>> 
>> For what it is worth,  the USG comments caution against getting into legal specifics as they pertain to agreements. 
>> 
>> 
>> 
>> Sent from my Verizon, Samsung Galaxy smartphone
>> 
>> 
>> -------- Original message --------
>> From: farzaneh badii <farzaneh.badii at gmail.com <mailto:farzaneh.badii at gmail.com>>
>> Date: 1/30/19 13:36 (GMT-05:00)
>> To: Thomas Rickert <epdp at gdpr.ninja <mailto:epdp at gdpr.ninja>>
>> Cc: gnso-epdp-team at icann.org <mailto:gnso-epdp-team at icann.org>
>> Subject: Re: [Gnso-epdp-team] Recommendation 13 - Responsibilities of the Parties - email list discussion
>> 
>> I agree with Thomas.
>> 
>>  I do not agree that we should be after giving "flexibility" to ICANN org and CPs. But since some public comments asked for such flexibility, then I think we should provide them a framework, the framework should consider ( as I gather from Alan and Thomas emails) legal, binding instruments that minimize the risk of fine and provides the appropriate and legal level of data protection for domain name registrants[ - sorry I am being sinful today].
>> I can live with what Kristina has proposed [Personal opinion] But I also want to point out that no one in the public comments is against having JCA. So why we are changing that I do not know. I don't think JCA will take away flexibility (as .Chris suggests). If we want to give flexibility to org and CPs that is fine but we have to provide them with a set of criteria to work with. Otherwise, what is the point of this recommendation? They would have done agreements and contracts even without it. The law asks them to! 
>> 
>> As to Trang's point about indemnification, I am a little confused.  I didn't see any ICANN legal concern raised in the public comment, is this a new issue being raised now? Are we bringing new issues to the table? 
>> 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Farzaneh 
>> 
>> 
>> On Wed, Jan 30, 2019 at 12:41 PM Thomas Rickert <epdp at gdpr.ninja <mailto:epdp at gdpr.ninja>> wrote:
>> All,
>> I still think it is a mistake to dilute the language from where we were before we published the initial report. We are in in the process of analyzing public comment and establishing whether the comments received require us to amend our report / recommendations. What we heard and read were primarily implementation issues, which - as I hope we can agree by now - must not guide our decision, but the actually circumstances. Additionally, we heard and read about concerns, but no alternative has been suggested that would be a better solution to what we agreed on earlier. To me, that does not require a change of our recommendation. We are replacing a concrete recommendation with something vague without good reason.
>> 
>> Also, the language in our initial report allows for a change of model as we had the language in there that our recommendation is subject to further legal analysis (or something to that effect).
>> 
>> Thus, the JCA approach should be the starting point and only be deviated from if there is a sufficiently robust alternative.
>> 
>> I trust what unites us is the interest in ensuring that no-one in the ICANN ecosystem will be fined. Let’s just imagine two scenarios:
>> 
>> 1. We say joint controllers and in fact the parties are independent controllers
>> 
>> In this scenario, there should not be any risk for the parties at all. 
>> 
>> The reason for this assumption is that the data flows between joint controllers need to be legally sound as between third parties (or independent controller for that matter). Also, JCAs provide probably the highest protection level for data subjects. 
>> 
>> 2. We go for independent controllers and in fact a joint controller scenario is present
>> 
>> In this case, legal requirements would not be fulfilled. There would be a breach that could be sanctioned. In a proceeding with a supervisory authority, the authority will surely review the documents publicly available, which are eg.:
>> 
>> - a letter from the Art 29 WP suggesting a joint controller scenario might be present
>> - a memo from Wilson Sonsini pointing in the direction of joint controllers
>> - a memo from Hamilton suggesting a joint controller scenario
>> - a memo from ICANN quoting from the above and concluding that it should be independent controllers nonetheless.
>> 
>> I am afraid that the authorities will then say that we could have known that joint controllers should be the way to go and that we increase the liability risk for everyone by not doing so. 
>> 
>> In other words, we would need to have very good reasons not to go for a joint controller scenario. The language in the initial report ensures that. The revised language not much so.
>> 
>> Thanks for reading all this.
>> 
>> Best,
>> Thomas
>> 
>> PS - In practical terms, I think joint controller agreements can be operationalized without insurmountable difficulties. In the long run, we should apply for a code of conduct anyway and we could present a different approach than joint controllers. If there is blessing for an alternative form the authorities via that route or by means of a guidance or other confirmation, we can certainly take a different and potentially more light-weight approach.
>> 
>> 
>>> Am 30.01.2019 um 14:40 schrieb Alan Woods <alan at donuts.email <mailto:alan at donuts.email>>:
>>> 
>>> Dear all, 
>>> 
>>> I am perplexed, if not a little bit frustrated by continuous tendency to wordsmith matters out of existence here. 
>>> 
>>> So this end, and regardless of the ultimate settling of Roles and Responsibilities can we just go back to basic principles and remind ourselves of the GDPR's requirements: 
>>> 
>>> Art 28: (processor) "Processing by a processor shall be governed by a contract or other legal act"[emphasis added] 
>>> Art 26: (Joint Controllers) "They shall in a transparent manner determine their respective responsibilities for compliance with the obligations under this Regulation, in particular as regards the exercising of the rights of the data subject and their respective duties to provide the information referred to in Articles 13 and 14, by means of an arrangement between them" [emphasis added] 
>>> 
>>> I appreciate this is likely where Trang's suggestion is deriving from and I have no real issue with the concept of 'Arrangement' - but can we please be very clear, that as a contracted party, who's lead DPA is clearly going to be Ireland (as will also be the case for a number of other CPs), my interpretation MUST be led by the laws which will be applicable to me, which is the Data Protection Act, 2018 <http://www.irishstatutebook.ie/eli/2018/act/7/section/79/enacted/en/html#sec79>. Section 79. which states: 
>>> 
>>> "  Where 2 or more controllers jointly determine the purposes and means of the processing of personal data (in this Part referred to as “joint controllers”), they shall determine their respective responsibilities for compliance with this Part in a transparent manner by means of an agreement in writing between them, save in so far as the said responsibilities are determined by the law of the European Union or the law of the State. [emphasis added] 
>>> 
>>> So regardless of whether or not we are considered Processors, Controllers or Joint controllers   at some point in time, CPs will require a Contract (or more correctly an addendum to our existing contracts) with ICANN, in writing, that governs the processing of data. 
>>> 
>>> So long as it is clear, on the record, that whatever word is used, be it agreement, arrangement, or Ketubah, it means a legally binding instrument, then I'm fine with it. 
>>> 
>>> 
>>> Kind regards,
>>> 
>>> Alan
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>  <http://donuts.domains/>	
>>> Alan Woods
>>> Senior Compliance & Policy Manager, Donuts Inc.
>>> The Victorians, 
>>> 15-18 Earlsfort Terrace
>>> Dublin 2, County Dublin
>>> Ireland
>>> 
>>>  <https://www.facebook.com/donutstlds>   <https://twitter.com/DonutsInc>   <https://www.linkedin.com/company/donuts-inc>
>>> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful.  If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
>>> 
>>> 
>>> On Tue, Jan 29, 2019 at 1:18 AM Trang Nguyen <trang.nguyen at icann.org <mailto:trang.nguyen at icann.org>> wrote:
>>> Thank you, Sarah and Kristina for circulating revised text for recommendation 13. We would like to make one additional suggestion: replace “…negotiates and enters into required data protection agreements…” with “…develop and implement any required data protection arrangements…” Referring to an “arrangement” instead of an “agreement” would provide greater flexibility during implementation, which might take the form of an agreement, a policy, or a specification. Accordingly, the following sentence should also refer to “arrangement” instead of “agreement.”
>>> Also, we would like to ask for clarity on the sentence regarding indemnification. Implementation discussions will work out the details of allocation of responsibility and liability and it’s not clear that liability should necessarily always rest with the party or parties that determine(s) the purposes and means of processing, for example in the case of a data breach. We look forward to additional discussions with the EPDP Team on this.  
>>>  
>>> Dan and Trang
>>> ICANN Org Liaisons
>>>  
>>> From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org <mailto:gnso-epdp-team-bounces at icann.org>> on behalf of "Rosette, Kristina via Gnso-epdp-team" <gnso-epdp-team at icann.org <mailto:gnso-epdp-team at icann.org>>
>>> Reply-To: "Rosette, Kristina" <rosettek at amazon.com <mailto:rosettek at amazon.com>>
>>> Date: Monday, January 28, 2019 at 5:14 PM
>>> To: "gnso-epdp-team at icann.org <mailto:gnso-epdp-team at icann.org>" <gnso-epdp-team at icann.org <mailto:gnso-epdp-team at icann.org>>
>>> Subject: Re: [Gnso-epdp-team] Recommendation 13 - Responsibilities of the Parties - email list discussion
>>>  
>>> All, <>
>>>  
>>> Subject to a friendly amendment, RySG supports the RrSG proposed text for Recommendation 13.  Our friendly amendment is to change “shall” to “should” in the 3rdsentence.  
>>>  
>>> As revised, Recommendation 13 reads:
>>>  
>>> The EPDP Team recommends that ICANN Org negotiates and enters into required data protection agreements, as appropriate, with the Contracted Parties. In addition to the legally required components of such agreement, the agreement shall specify the responsibilities of the respective parties for the processing activities as described therein. Indemnification clauses should ensure that the risk for certain data processing is borne by either one or multiple parties that determine the purpose and means of the processing. Due consideration should be given to the analysis carried out by the EPDP Team in its Final Report.
>>> Kristina
>>>  
>>> From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces at icann.org <mailto:gnso-epdp-team-bounces at icann.org>] On Behalf Of Sarah Wyld
>>> Sent: Monday, January 28, 2019 3:29 PM
>>> To: gnso-epdp-team at icann.org <mailto:gnso-epdp-team at icann.org>
>>> Subject: Re: [Gnso-epdp-team] Recommendation 13 - Responsibilities of the Parties - email list discussion
>>>  
>>> Hello All,
>>> Here is the RrSG's proposed text for Rec 13:
>>> The EPDP Team recommends that ICANN Org negotiates and enters into required data protection agreements, as appropriate, with the Contracted Parties. In addition to the legally required components of such agreement, the agreement shall specify the responsibilities of the respective parties for the processing activities as described therein. Indemnification clauses shall ensure that the risk for certain data processing is borne by either one or multiple parties that determine the purpose and means of the processing. Due consideration should be given to the analysis carried out by the EPDP Team in its Final Report.
>>> The RrSG is aware that ICANN's status as controller, joint or independent, is not yet fully determined. As such, this proposed wording allows the flexibility to determine the appropriate type of data protection agreement following further input.
>>> -- 
>>> Sarah Wyld
>>> Domains Product Team
>>> Tucows
>>> +1.416 535 0123 Ext. 1392
>>>  
>>>  
>>> On 1/23/2019 6:22 PM, Kurt Pritz wrote:
>>> Hi Everyone:
>>> With the goal of progressing on issues via email, the leadership team has considered the discussion provided during the Toronto meeting and suggests the following compromise language to address the different positions expressed. (This is a resend of an earlier email with only the subject line of the email updated.)
>>> Discussion 
>>> The language below is the same language proposed by the small team that reviewed the comments, but modified: 
>>> as suggested by Diane during the meeting to reflect that GDPR Art 28 is unlikely to apply in this situation, and
>>> by an addition (bracketed & bolded below) to reference the analysis in the Final Report that this team recommends the creation of Joint Controller Agreements, to appropriately influence the negotiation of GDPR-compliant agreements.
>>>  
>>> This language is intended to strike a balance between those preferring to leave some flexibility for ICANN Org and Contracted Parties to consider the appropriate agreements and those preferring to be specific about the type of agreement to be pursued.
>>> I understand this is a complex topic that might require additional discussion but it is also possible that we cannot be dispositive on this issue prior to a lengthy contract formation discussion that extends well beyond our time frames. For that reason, we are taking the liberty of making this recommendation and hope you accept it in the spirit it is offered.
>>> Proposed Recommendation #13 Language
>>> The EPDP Team recommends that ICANN Org negotiates and enters into required data protection agreements such as a Data Processing Agreement (GDPR Art. 28) or Joint Controller Agreement (Art. 26), as appropriate, with the Contracted Parties. In addition to the legally required components of such agreement, the agreement shall specify the responsibilities of the respective parties for the processing activities as described therein. Indemnification clauses shall ensure that the risk for certain data processing is borne by either one or multiple parties that determine the purpose and means of the processing. [Due consideration should be given to the analysis carried out by the EPDP Team in its Final Report.]
>>> Action: 
>>> Please indicate on the mailing list whether you have any concerns about these modifications and/or what other aspects of this recommendation should be discussed.
>>> Deadline: Monday, 28 January, additional email discussion might follow depending on responses. 
>>> Sincerely,
>>> Kurt
>>>  
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Gnso-epdp-team mailing list
>>> Gnso-epdp-team at icann.org <mailto:Gnso-epdp-team at icann.org>
>>> https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://mm.icann.org/mailman/listinfo/gnso-epdp-team>_______________________________________________
>>> Gnso-epdp-team mailing list
>>> Gnso-epdp-team at icann.org <mailto:Gnso-epdp-team at icann.org>
>>> https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://mm.icann.org/mailman/listinfo/gnso-epdp-team>_______________________________________________
>>> Gnso-epdp-team mailing list
>>> Gnso-epdp-team at icann.org <mailto:Gnso-epdp-team at icann.org>
>>> https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://mm.icann.org/mailman/listinfo/gnso-epdp-team>
>> _______________________________________________
>> Gnso-epdp-team mailing list
>> Gnso-epdp-team at icann.org <mailto:Gnso-epdp-team at icann.org>
>> https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://mm.icann.org/mailman/listinfo/gnso-epdp-team>_______________________________________________
>> Gnso-epdp-team mailing list
>> Gnso-epdp-team at icann.org <mailto:Gnso-epdp-team at icann.org>
>> https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://mm.icann.org/mailman/listinfo/gnso-epdp-team>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190204/22a7b531/attachment-0001.html>


More information about the Gnso-epdp-team mailing list