Hi Thomas (and everyone): Thanks for the thoughtful summary. On the administrative side of things here, we were also thinking fo releasing a data matrix similar to the one you published as we took from the work of the RDS team that had fleshed out much of the data details. I think we should get closer to the finish of our “purposes” discussion before going on to that data analysis so we haven’t sent that RDS-related work product to the group yet. Thomas, in regard to your recommendations on §4.4.8, please forgive me for using it as an opportunity to provide a better explanation regarding our end-of-the-meeting discussion on Tuesday, including next steps and assignment of between-meeting work. I intended to write this as a separate memo, but am happy to take advantage of your intervention to do so now. For the discussion regarding purposes of data processing (§4.4), based on the comments of others, I had proposed that contracted parties recommend amendments or a re-writing of the data purposes associated with the registration and maintenance of a domain in the DNS; and that the entire group examine and refine the purposes of data processing associated with third-party access. Given that the 46 hours between meetings was not sufficient time for thoughtful reflection, I thought to reiterate in writing the proposed approach for moving forward on §4.4 – in order to address possible mis-communication and provide a basis for additional discussion on this viewpoint. 1. The current purposes for data processing in the Temporary Specification would be divided into two buckets: a. Registrar-Registry-ICANN Contract Purposes (for data collection and administering to domains), which includes: 4.4.1. – Ability for Registered Name Holder to exercise its rights (I believe the Transfer Policy is included here) 4.4.3. – Enabling mechanism for identifying and contacting registered name holder 4.4.4. – Payment and invoicing 4.4.5. – Notification of technical issues 4.4.6. – Notification of commercial or technical changes 4.4.7. – Technical & administrative points of contact 4.4.11. – Safeguarding in case of failure 4.4.12. – Dispute resolution services 4.4.13 – ICANN Contractual Compliance b. Registrar-Registry providing third-party access to data for purposes that includes: 4.4.2. – Providing access based on legitimate interests not outweighed by the fundamental rights 4.4.8. – Providing a framework to address consumer protection, investigation of cybercrime, DNS abuse, IP protection 4.4.9. – Supporting a framework to address LE needs 4.4.10. – Provision of zone files For these third-party purposes (for access), personal data processed in the context of Whois can be made available to third parties who have a legitimate interest in having access to the data, provided that appropriate safeguards are in place to ensure that the disclosure is proportionate and limited to that which is necessary and the other requirements of the GDPR are met, including the provision of clear information to data subjects. 2. For Registrar-Registry-ICANN Contract Data Processing Purposes in paragraph (a) above (for collection), all, but registrars specifically, are asked to provide input on whether there are additional or fewer legitimate purposes why contracted parties collect data (through their ICANN contracts) from registrants. Should these purposes be re-grouped or re-stated in some way to better capture their relevance, necessity and the data needed to support them? 3. For Third Party Access Data Processing Purposes (in paragraph (b) above), the EPDP Team was asked to provide greater clarity for how data would be used to address the enumerated purposes in §4.4.8, i.e., consumer protection, investigation of cybercrime, DNS abuse, and intellectual property protection (noting that discussion on safeguards and limitations to access necessary to ensure GDPR compliant disclosures would happen after the gating questions have been answered). Should the EPDP team weigh in on whether the purposes enumerated here are valid and legitimate, and with a corresponding legal basis? One approach might be to address GDPR-compliant third-party access in section where: · The current model for providing GDPR-compliant third-party access to data can be described · The definition of “reasonable access” could continue to evolve as DPA advice and case law are received (with a forum established for doing so) · The Access Model would be incorporated into this new policy 4. As a next step, the EPDP Team would list the data elements required for these purposes, factoring in the work that has been done by the RDS PDP Working Group on data elements. I’ll try to reflect this in the slides for the meeting. Best regards, Kurt
On Aug 30, 2018, at 7:20 AM, Thomas Rickert <epdp@gdpr.ninja> wrote:
All, A few points below that I committed to send to the list.
Data matrix
During our last call, we have discussed a proposed methodology to slice and dice the work and document what data elements can be processed for what purpose based on what legal basis with what rationale. I have attached an attempt to capture that. This only covers the framework for capturing the collection of data by the registrar and the transfer from registrar to registry. The table would need to be extended to cover the additional processing activities, but at this stage it shall serve only to illustrate an approach where we could all feed our ideas into one document with a level of granularity that prevents us from conflating issues.
4.4.8.
Also, when we discussed 4.4.8. I proposed we also discuss the purpose in concrete terms. Milton asked me to give an example.
4.4.8 reads: Supporting a framework to address issues involving domain name registrations, including but not limited to: consumer protection, investigation of cybercrime, DNS abuse, and intellectual property protection only.
Many in the group think this is too broad.
So let’s take IP protection.
If the purpose included the publication of all data of potential cybersquatters, including their payment data to allow for investigators to do their work efficiently, I think we would all agree that that would go too far. Yet, one could think that such action was covered by the purpose of 4.4.8..
On the other hand, if in the case of a UDRP proceeding, the data of the registrant shall be disclosed to the dispute resolution provider, we would probably (not to say hopefully) all agree that this would be fine.
So my plea is that when we are talking about all those issues that could fall under 4.4.8. - let’s come up with concrete suggestions as to what the parties involved are supposed to do. We should all put some thought into that. What shall be done in the area of consumer protection e.g.? Are we talking about collection of additional data elements? Disclosing them to third parties? Retaiing them for a longer period? In other work, what could or should consumer protection entail in the gTLD world? Same for the other aspects in 4.4.8.
Playbook
Mark asked during the last call to send a link to the eco Playbook. Here it is: eco GDPR Domain Industry Playbook <https://www.eco.de/wp-content/uploads/2018/02/eco-domain-industry-playbook-v1.0-en.pdf>
We have gone through a lot of the exercises that this group will need to go through, so I encourage you to take a look at it. Maybe we can reuse parts of it to expedite our work.
Don’t get me wrong - I am not trying to sell you the approach in the Playbook, but I think it can be a good basis to argue over certain questions. Finally, I happen to be one of the authors. The good sentences have likely been written by others. The things you might not like surely come from me.
Best, Thomas
<Data Elements Matrix.xlsx>
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team