EPDP Small meeting on Legal Committee Framework will take place on Wednesday, 23 January 2019 at 14:00 UTC for 2 hours.
06:00 PST, 09:00 EST, 15:00 Paris CET, 19:00 Karachi PKT, 23:00 Tokyo JST, (Thursday) 01:00 Melbourne AEDT
For other times: https://tinyurl.com/y769svlr
Two legal issues or questions were raised in our last EPDP meeting:
One is whether the data field for City is personal data or could result in unconsented disclosure of personal data and thus should be redacted from the data that is made publicly available in Whois. - where the City is part of the address of the Registered Name Holder. What bases are there in the GDPR, its official advisories and interpretations, and in practices similar to our own for making such a determination.
The second has to do with “accuracy." Some in the group cite the GDPR requirement (article xx) for the data controller to maintain accurate data as a requirement for this group to undertake an examination of how accuracy is currently defined in the contracts between ICANN and the registrars and possibly require changes to those methods. Others maintain that the GDPR requirement is to accurately record, maintain and process the data provided by the data subject and to update that information as informed by the data subject.
Apologies: Tatiana Tropina (NCSG), Emily Taylor (RrSG)
Alternate: Amr Elsadr (NCSG)
Notes/ Action Items
Action item #1: EPDP Support Staff to set up Google Doc with draft questions. COMPLETE.
Action item #2: Legal Committee members to propose edits to legal questions in advance of next Legal Committee meeting.
23 January 2019
Legal Committee Meeting
Proposed additional questions for Ruth
- Regarding the "city" field, it is important to know what fields would be seen in connection with the city field (show the fields that are redacted vs. not redacted)
- The city field is PII, so we should accept that as fact. The question is whether we have a legal basis the city with state/province and country. (the IP/BC argument)
- Replace the word "disclosure" with "publication". We're asking this question regarding if this field can be published in a public directory. There may be concerns with referring to other advice that has been provided, but in this instance, it may be important to point her to input that has already been received on this issue. Specifically, the advice the RDS WG received could be helpful here.
- It may be helpful for people who suggest revisions to post them in the chat.
- It would be helpful to collect feedback on questions but refrain from drafting by committee.
- Volunteers can then flesh the questions out based on the feedback received.
- Do the accuracy requirements under GDPR only apply to rectification by the data subject?
- Are there requirements above and beyond accurately inputting the data given by the data subject? Does the controller/processor need to validate the data for accuracy?
- Suggestion to create google doc on "suggestion mode" to propose edits
- What scenarios would lead to registrars being in violation of the agreement?
- We understand that the obligation to accurately record data as provided by the registrar is covered by Art. 5 I d GDPR. Are there additional requirements for the registrar to validate the accuracy of data elements, i.e. whether the data provided by the data subject is free of errors.
- It's not just about being free of errors - it should not be this precise. "accurate" is better than "free of errors"
- The additional question I’d like to propose asking is on the EDPB Guidance on territorial scope of GDPR, particularly the issue of ICANN having stable establishments within the EU, and how this impacts its responsibilities as a data controller. To me, the EDPB guidance suggests that ICANN, as a controller with stable establishments within the EU, might be required to comply with GDPR. My understanding is that this might be applicable even if processing activities (including registrar/reseller collection of data from RNH) take place outside of the EU. This might be helpful to the EPDP Team in determining whether or not the differentiation of practices for RNH based on their geo location is legally feasible, or not.
- ICANN's activities within the EU need to be mapped out against what constitutes a "stable establishment". This would be necessary to answer the question
- If a controller not based in the EU has a "stable establishment" within the EU, the processing would need to be GDPR compliant.
- How does this impact the EPDP Team's policy work?
- The geo indicators question is on tomorrow's plenary agenda. Based on that conversation, the LC could consider taking the question further.