[Gnso-epdp-team] ICANN Org Feedback on Roles and Responsibilities Memo

Fri Nov 16 13:49:23 UTC 2018

Hi Trang, Dan, all,
Thanks so much for sharing the memo. 

We will surely discuss this during the upcoming call. I would like to share a few thoughts in writing, though:

Before I go into substance: My name is mentioned in the covering note as well as the document in various places. This might make it look like this is „my solution“, but whilst I have shared the memo, the memo itself is more or less a verbatim excerpt from the eco GDPR Domain Industry Playbook, which I co-authored. So I am happy to take the blame for criticism, but not the credit for the contents as this has been written by a group of 6. More importantly, I am not here to defend or fight for a particular solution. To be quite honest, I do not care what solution we come up with as long as it is compliant. 

Today, it is my personal opinion that a joint controller solution is the best way to achieve compliance. Some have said it should be different scenarios, but they have either not provided any rationale for their thinking or the rationale that was offered did not convince me. Absent a compelling alternative, I do not see any other concept to pursue. The memo did not change my thinking. In fact, I took it as a confirmation of the concept laid down in the current version of the initial report in many ways.

Here come my questions / reactions to the memo:

1. 
If the document is not an ICANN Org or Board position, what is it? Can we please get information on who wrote it so that we can enter into a dialogue? In the document, concerns are raised, some of which are valid. Unfortunately, our group cannot just raise concerns. It would be great to be able to talk to the author / authors to exchange thoughts on solutions.  

2.
Point 1.4. (B) mentions the example of a travel agency where the parties were the ARt. 29 group concluced that there are three different data controllers. This is example no. 7 from WP 169 of the Art. 29 group. I would like to bring to your attention example no. 8, again on the travel industry. But in that example, the Art. 29 Group concluded that a joint controller scenario is given.  Here comes the example:

The travel agency, the hotel chain and the airline decide to set up an internet-based common platform in order to improve their cooperation with regard to travel reservation management. They agree on important elements of the means to be used, such as which data will be stored, how reservations will be allocated and confirmed, and who can have access to the information stored. Furthermore, they decide to share the data of their customers in order to carry out integrated marketing actions. 
In this case, the travel agency, the airline and the hotel chain, will have joint control on how personal data of their respective customers are processed and will therefore be joint controllers with regard to the processing operations relating to the common internet-based booking platform. However, each of them would still retain sole control with regard to other processing activities, e.g. those relating to the management of their human resources. 
You decide which scenario resembles the gTLD world more.

3. 
On 2.1. and 2.2. it is interesting to read that ICANN understands that both the Art. 29 group as well as Hamilton point to joint controllership, but ICANN then goes for independent controllers.

4.
In 2.3. reference is made to the Cookbook, namely that ICANN took the position that „ICANN has determined that each contracting party is acting as an independent controller in connection with the processing of WHOIS data“. The memo continues that this understanding is also reflected in the Temp Spec.

If ICANN has determined at the time that an independent controller situation is present, can we please see the legal analysis on which this conclusion is based? If there is no such legal analysis, we should also get that information. 
Then, maybe there was the intention to continue that understanding in the Temp Spec, but the Temp Spec does not say so. I could not find the term "independent controller“ in the Temp Spec. I quoted Becky’s intervention at ICANN 63, so there does seem to be the understanding, at least by some, that ICANN has accepted to be and is a joint controller.

Also, ICANN mentions multiple times in the memo that a detailed analysis needs to be conducted to determine the legal situation. We have not seen any legal analysis apart from this memo. So how can ICANN say a joint controller situation cannot be confirmed before an in depth analysis is conducted, but consider an independent controller situation to be present if there is no such analysis?

4.
In 2.4., ICANN explains that it took a different approach than Hamilton or the Roles and Responsibilities Memo because an analysis of the parties’ responsibilities must be completed. It goes on to say that without such analysis, a joint controllership that generally covers all processing could lead to a lack of transparency lead to a lack of guidance / direction regarding what each contracted party is responsible for. 

Firstly, I have mentioned more than once that the determination of joint controllership is complex. One could write much much more about this, but I offered a pragmatic concise rationale to be included in our report. 
Secondly, we have done analysis concluding that a joint controller situation is given. It is then for the joint controller agreement to specify the responsibility and provide exactly the transparency that ICANN is asking for. 

Again, the assessment of what the legal situation is is fact-based. If you look at the genesis of Art. 26 GDPR, first the European Commission planned that multiple parties should just agree on who shall take care of which legal requirements of the GDPR. A regulation on the distribution of liability was not foreseen. The European Parliament has then requested that the agreements amongst the controllers must reflect the actual situation and that this shall be brought to the attention of the affected individuals. In cases of doubt, there should be joint and several liability. Then the joint and several liability was introduced (see Bertermann in Ehmann / Selmayr Art. 26 No. 2). So we can expect that in a world of convoluted data processing activities and multiple parties involved, to be applied from the perspective of the data subject.

5. 
In section 4 the case is made for determine the parties' responsibilities. That is correct and I think our group is aligned that a detailed review is necessary. But I think our group is also aligned that such detailed analysis shall be left to the contracted parties and ICANN as it is a matter of implementation and not one for policy work. I would disagree, though, with the statement that a determination can only be made after the assessment has been completed. Rather, we have to make the determination in our group and ask the parties to negotiate a JCA, in the process of which a greater level of granularity of the work is warranted. 

It it also correct to state that not all processing activities are encompassed by joint controllership. In fact, contracted parties might be doing additional processing of the data, which they are solely responsible for. 

4.1 (C) (3) criticizes that the r&r memo does not single out processing activities and asks how transparency could then be promoted. The short answer is that we suggest to look at the macro level to determine joint controllership, but then go to the individual processing activities in the JCA.

Footnote 11 on that same page is also interesting as it compares ICANN to legislators and judicial bodies who do not become controllers by virtue of the fact that they set requirements. This situation is just not comparable. ICANN does not set law and ICANN is actually involved much more in the processing and can get access to data in its compliance work, which regulators don’t do.

In 4.2. ICANN suggests that the means of processing also need to be discussed. That is correct. We could write much more about that and in fact, a lot of detail will need to be discussed during the negotiations of the JCA. I will gladly offer more details in support of the JCA situation if needed.

Let’s discuss the questions in the memo on the call.  It strikes me odd, however, that ICANN lists a lot of questions and concerns and does not seem to have worked on solutions (or shared the information on its work with us). All this is not news. 

Best,
Thomas

> Am 16.11.2018 um 03:04 schrieb Trang Nguyen <trang.nguyen at icann.org>:
> 
> Dear EPDP Team, <>
>  
> Attached, please find ICANN org’s feedback on the roles and responsibilities memo that Thomas circulated on 7 November. This document is not an official ICANN org or Board position but is intended to provide additional input from ICANN org into the ongoing deliberations of the EPDP Team about whether or not Article 26 of the European Union’s General Data Protection Regulation (GDPR) applies to processing activities concerning gTLD registration data. The document sets out key points to add to the discussion on the Roles and Responsibilities Memo. These points provide additional viewpoints to help assess whether or not Article 26 of the GDPR applies to various gTLD registration data processing activities. The points are not intended to be exhaustive; other issues may arise and should be further discussed among the EPDP Team, and ICANN org looks forward to participating in further discussions. 
>  
> Dan and Trang
> ICANN org liaisons
>  
> <ICANN Org Feedback on Roles and Responsibilities Memo - 2018-11-15.docx>_______________________________________________
> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20181116/1dcbfdec/attachment-0001.html>