Versions Compared

Old Version 3

changes.mady.by.user Terri Agnew

Saved on

compared with

New Version Current

changes.mady.by.user Terri Agnew

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

For other times: https://tinyurl.com/rnl7aka

Info

PROPOSED AGENDA

EPDP Phase 2 Legal Committee Meeting #12

17 December 2019Proposed Agenda


  1. Roll Call & SOI Updates 
  2. Continued Substantive Review of Priority 1 (SSAD) Legal Questions Submitted to Date

           a)Substantive       Substantive review of SSAD questions (beginning where LC left off during last LC meeting)

  

  • Updated Google Right to be Forgotten Question

questions  

  • Updated Territorial Scope Question (Margie)


In light of the Right to Be Forgotten Case regarding the reach of GDPR, and the recent guidelines published by the EDPB on Geographic Scope [edpb.europa.eu],

Does this ruling and the Guidelines affect:

  1. The advice given inPhase 1 Regarding Territorial Scope, in Sections 4.2 or 6.2- 6.9?     
  2. The advice given in Q1-2 with respect to liability (Section 4 of the memo)?

In light of this ECJ decision and the Geographic Scope Guidelines [edpb.europa.eu], using the same assumptions identified for Q1 and Q2, would there be less risk under GDPR to contracted parties if:

          a. the SSAD allowed automated disclosure responses to requests submitted by accredited entities for redacted data of registrants and/or controllers located outside of the EU, for legitimate purposes (such as cybersecurity investigations and mitigation)and/or other fundamental rights such as intellectual property infringement investigations (See Article 17, Section 2 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:12012P/TXT);and/or   

         b. ICANN served as the sole entity making disclosure decisions for the SSAD, and directly provided access to the redacted data from a processing center outside of the EU (such as from ICANN’s Los Angeles Headquarters)?

Previously-worded question (for reference): In light of the finalized guidelines on the territorial scope of the GDPR and the ECJ opinion on regarding the right to be forgotten (Google case), are there any modifications you would propose to your previous memo on the territorial scope of the GDPR?

          b b)Agree       Agree on next steps

  • Questions to be submitted to plenary (Q11)


    3 3. Continue review of Priority 2 Legal Questions – WHOIS Accuracy and City Field Redaction

          a) . Substantive review of Priority 2 Legal Questions:

    i. Volker’s updated draft questions on Privacy/Proxy + Uniform Anonymized Email address:

The group has discussed the option of replacing the email address provided by the data subject with an alternate email address that would in and of itself not identify the data subject (Example: 'sfjgsdfsafgkas@pseudo.nym'). With this approach, two options emerged in the discussion, where (a) the same unique string would be used for multiple registrations by the data subject ('pseudonymisation'), or (b) the string would be unique for each registration ('anonymization'). Under option (a), the identity of the data subject might - but need not necessarily - become identifiable by cross-referencing the content of all domain name registrations the string is used for.

From these options, the following question arose:

1) Under options (a) and/or (b), would the the alternate address have to be considered as personal data of the data subject under the GDPR and what would be the legal consequences and risks of this determination with regard to the proposed publication of this string in the publicly accessible part of the registration data service (RDS)?

    ii. Matthew’s updated questions on Legal v. Natural:

Proposed Legal Question

As a follow-up to the previously provided memos on Accuracy and Legal vs. Natural persons, the EPDP team requests the following clarification on the scope of the GDPR accuracy principle under Article 5.1(d).  As a reminder, one proposal to address the issue of treating all registration data as containing personal data is to allow registrants to self-identify as legal persons at the time of registration.  Contracted parties would rely on this self-identification (which could be inaccurate) when deciding whether to redact the registration data.

Question 1:

Does the accuracy principle only take into account the interests of the data subject and the controller, or does the principle also consider the interests of third-parties (in this case law enforcement, IP rights holders, and others who would request the data from the controller for their own purposes)?

In responding to this question, can you please clarify the parties/interests that we should consider in general, and specifically when interpreting the following passages from the prior memos:

Both memos reference “relevant parties” in several sections.  Are the “relevant parties” limited to the controller(s) or should we account for third-party interests as well?“There may be questions as to whether it is sufficient for the RNH or Account Holder to confirm the accuracy of information relating to technical and administrative contacts, instead of asking information of such contacts directly. GDPR does not necessarily require that, in cases where the personal data must be validated, that it be validated by the data subject herself. ICANN and the relevant parties may rely on third-parties

 i. Legal vs. Natural:

Updated question from Tara:

Registration data submitted by legal person registrants may contain the data of natural persons.  A Phase 1 memo stated that registrars can rely on a registrant's self-identification as legal or natural person if risk is mitigated by taking further steps to ensure the accuracy of the registrant's designation. 

As a follow-up to that memo: what are the consent options and requirements related to such designations?  Specifically: can data controllers state that it is the responsibility of a legal person registrant to obtain consent from any natural person who will act as a contact, and whose data may be displayed publicly in RDS?

As part of your analysis, please consult the GDPR policies and practices of the Internet protocol (IP address) registry RIPE-NCC (the registry for Europe, based in the Netherlands).  RIPE-NCC’s customers (registrants) are legal persons, usually corporations.  Natural persons can serve as their contacts, resulting in the data of natural persons being displayed publicly in WHOIS.  RIPE-NCC places the responsibility on its legal-person registrants to obtain permission from those natural persons, and provides procedures and safeguards for that.  RIPE-NCC states mission justifications and data collection purposes similar to those in ICANN's Temporary Specification.  Could similar policies and procedures be used at ICANN? 

 Please see these specific references:

1) “How We're Implementing the GDPR: Legal Grounds for Lawful Personal Data Processing and the RIPE Database”:

https://labs.ripe.net/Members/Athina/gdpr-legal-grounds-for-lawful-personal-data-processing-and-the-ripe-database [labs.ripe.net]  

2)  “How We're Implementing the GDPR: The RIPE Database”: https://labs.ripe.net/Members/Athina/how-we-re-implementing-the-gdpr-the-ripe-database [labs.ripe.net]


If time permits, also see the policies of ARIN, the IP address registry for North America.  ARIN has some customers located in the EU.  ARIN also publishes the data of natural persons in its WHOIS output.  ARIN’s customers are natural persons, who submit the data of natural person contacts.

3) ARIN "Data Accuracy": https://www.arin.net/reference/materials/accuracy/ [arin.net]

4) ARIN Registration Services Agreement, paragraph 3: https://www.arin.net/about/corporate/agreements/rsa.pdf [arin.net]

"Personal Data Privacy Considerations At ARIN": https://teamarin.net/2018/03/20/personal-data-privacy-considerations-at-arin/ [teamarin.net]  especially the first two paragraphs

            ii. WHOIS Accuracy and ARS (Support Staff to pull up document submitted by Laureen):


Legal Committee Proposed Questions Related to Data Accuracy

Suggested Status on GAC Questions:

GAC Question

Status:  Keep, Delete, Proposed edits

Rationale

4. If current verification statistics provide that a number of data is inaccurate, would that be considered a metric to deduce that the accuracy principle is not served in a reasonable manner as demanded by the GDPR? (GAC)

 

Delete.  Consider how to make this question more concrete in light of specific data.  


5. According to the GDPR all personal data are processed based on the principle that they are necessary for the purpose for which they are collected. If those data are necessary, how can the purpose be served while the data are inaccurate? (GAC)

Delete.  The current Question 1 on Legal vs. Natural asks whether third parties also have an interest in the accuracy of the registration data and references ICO guidance about the importance of data accuracy.  This gets at the same issue, albeit from a different angle.


6. Can you provide an analysis on the third parties mentioned in para 19 on which "ICANN and the relevant parties may rely on to confirm the accuracy of personal data if it is reasonable to do so"? Do they become in such a scenario data processors? (GAC)

Keep.  Proposed edit: 

Can you provide further information and explanation on the reference to third parties mentioned in para 19 in which "ICANN and the relevant parties may rely on to confirm the accuracy of personal data if it is reasonable to do so

. Therefore, we see no immediate reason to find that the current procedures are insufficient.” (emphasis added) (Paragraph 19 – Accuracy)
  • “In sum, because compliance with the Accuracy Principle is based on a reasonableness standard, ICANN and the relevant parties will be better placed to evaluate whether these procedures are sufficient. From our vantage point, as the procedures do require affirmative steps that will help confirm accuracy, unless there is reason to believe these are insufficient, we see no clear requirement to review them.” (emphasis added) (Paragraph 21 - Accuracy)
  • “If the relevant parties had no reason to doubt the reliability of a registrant's self-identification, then they likely would be able to rely on the self-identification alone, without independent confirmation. However, we understand that the parties are concerned that some registrants will not understand the question and will wrongly self-identify. Therefore, there would be a risk of liability if the relevant parties did not take further steps to ensure the accuracy of the registrant's designation.” (emphasis added) (Paragraph 17 – Legal v. Natural)

    • "? Please describe these third parties and their contemplated role.  Do they become in such a scenario data processors?

    This question would provide further clarification on a passage already flagged by the legal team as needing explanation. The current question focuses on the interests of “relevant parties” as mentioned in the Legal Memo, and whether these parties are distinct from the data controllers.  However, clarification is also needed on what is meant by “third parties to confirm the accuracy of personal data.”  Such clarity would assist the team in creating policy that ensures the accuracy of the data collected, consistent with the GDPR.

    7. How is the accuracy principle in connection to the parties' liability has to be understood in light of the accountability principle of the GDPR? What are the responsibilities of ICANN and the contracted parties (who are subject to the GDPR) under Chapter IV of the GDPR? If the contracted parties (as data controllers) engage third entities as processors (e.g. to provide data back-up services), what are the responsibilities of these entities? What does this mean in terms of liabilities (in light of Art. 82 GDPR)? (GAC)

    Keep in part.  Proposed edit:

    Provide further discussion on the liability risks to the data controllers and processors with regard to the accuracy of data provided by registrants, in light of GDPR Article 5?  Article 5 requires, among other things,  that personal data shall be “accurate and, where necessary, kept up to date, every reasonable step must be taken to ensure that personal data are that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay.” What are the responsibilities of ICANN and the contracted parties with respect to ensuring data accuracy?  If the data controllers engage third parties to assist with processing personal data, how would that affect the risk of liability to the data controllers?

    This question relates to the proposed question 2 regarding liability but seeks more specific guidance on identification of the liability risks and the specific responsibilities of the data controllers, either acting alone or with the assistance of third parties.  

    8. While it is up to the registrants to provide accurate details about themselves and it is up to the registrants not to mistakenly identify themselves as natural or legal persons, the Memo on "Natural vs Legal persons" provides interesting ideas/suggestions for the contracted parties to proactively ensuring the reliability of information provided, including through measures to independently verify the data. Could similar mechanisms be identified also for ensuring the reliability of the contact details of the registrant? Can best practices be drawn from the ccTLDs? (GAC)

    Keep with edits:  Recognizing that registrants provide the personal information about themselves and identify as either “natural” or “legal” entities, are there nevertheless reasonable pro-active steps that are advisable for contracted parties to take in order to ensure the reliability of the information provided (including the registrant contact details), including through measures to independently verify the data? Do the practices of ccTLD’s with regard to data verification provide reasonable models?   

    This question seeks practical guidance on what steps would be reasonable for contracted parties to take in order to ensure data accuracy.  This is a logical follow up tour current questions on liability risks. 


               b)      Agree on next steps

     

       

  • Similarly, the Legal vs. Natural person memo refers to the “importance” of the data in determining the level of effort required to ensure accuracy.  Is the assessment of the “importance” of the data limited to considering the importance to the data subject and the controller(s), or does it include the importance of the data to third-parties as well (in this case law enforcement, IP rights holders, and others who would request the data from the controller for their own purposes)?
    • “As explained in the ICO guidance, "The more important it is that the personal data is accurate, the greater the effort you should put into ensuring its accuracy. So if you are using the data to make decisions that may significantly affect the individual concerned or others, you need to put more effort into ensuring accuracy.” (Paragraph 14 – Legal vs. Natural)

    • Question 2:

    The Legal vs. Natural person memo discusses a “risk of liability” if additional steps are not taken to ensure the accuracy of data. How do you characterize the level of risk of liability - low, medium, or high?  What is the threshold for “reason to doubt” registrant self-identification that triggers this risk of liability?  Is the risk in Paragraph 17 the same or different than the risk discussed in Paragraph 23?

    • “If the relevant parties had no reason to doubt the reliability of a registrant's self-identification, then they likely would be able to rely on the self-identification alone, without independent confirmation. However, we understand that the parties are concerned that some registrants will not understand the question and will wrongly self-identify. Therefore, there would be a risk of liability if the relevant parties did not take further steps to ensure the accuracy of the registrant's designation.” (emphasis added) (Paragraph 17 – Legal vs. Natural)
    • “When a registrant identifies as either a natural or a legal person, this self-identification will determine whether the data provided is made publicly available by default. If there is a reasonable risk that data subjects will wrongly self-identify, then failing to make the consequences of the self-identification known to data subjects could result in liability for failing to meet the Lawfulness, Fairness and Transparency Principle.” (emphasis added) (Paragraph 23 – Legal vs. Natural)

        iii. Potential OCTO Purpose

         b)Agree on next steps

     

       4. Wrap and confirm next meeting to be scheduled 

            a   a) Confirm action items

               b) AOB

    • Note: No objections received re: Bird and Bird’s updates to the memo summaries by the pre-holiday deadline. The summaries are now included in the Initial Report Google Doc.
    • Note: No objections received regarding questions to submit for plenary review by the pre-holiday deadline. Following this call, EPDP Support Staff forward the questions to the plenary for its review (with highlighting removed).


              c)The next Legal Committee meeting is scheduled for Tuesday, 7 21 January at 15:00 UTC.


    BACKGROUND DOCUMENTS



    Info
    titleRECORDINGS

    Audio Recording

    Zoom Recording

    Chat Transcript


    Tip
    titlePARTICIPATION

    Attendance Attendance 

    Apologies:  none

    Alternates:  none


    Note

    Notes/ Action Items


    Action Items

    1. Brian and Margie to review 2A of the Territorial Scope question to clarify the ask based on the Legal Committee’s discussion, for example, consider adding a matrix.

    Question provided for reference:

    1. The advice given in Q1-2 with respect to liability (Section 4 of the memo)?

    In light of this ECJ decision and the Geographic Scope Guidelines [edpb.europa.eu], using the same assumptions identified for Q1 and Q2, would there be less risk under GDPR to contracted parties if:

        1. the SSAD allowed automated disclosure responses to requests submitted by accredited entities for redacted data of registrants and/or controllers located outside of the EU, for legitimate purposes (such as cybersecurity investigations and mitigation) and/or other fundamental rights such as intellectual property infringement investigations (See Article 17, Section 2 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:12012P/TXT);and/or   


    1. Laureen and Georgios to review and consider combining GAC-proposed questions 4, 5, 7, and 8 based on the Legal Committee’s discussion as well as the Phase 1 Accuracy Memo.


    Questions provided for reference:


    1. If current verification statistics provide that a number of data is inaccurate, would that be considered a metric to deduce that the accuracy principle is not served in a reasonable manner as demanded by the GDPR?


    1. According to the GDPR all personal data are processed based on the principle that they are necessary for the purpose for which they are collected. If those data are necessary, how can the purpose be served while the data are inaccurate?


    1. How is the accuracy principle in connection to the parties' liability has to be understood in light of the accountability principle of the GDPR? What are the responsibilities of ICANN and the contracted parties (who are subject to the GDPR) under Chapter IV of the GDPR? If the contracted parties (as data controllers) engage third entities as processors (e.g. to provide data back-up services), what are the responsibilities of these entities? What does this mean in terms of liabilities (in light of Art. 82 GDPR)?


    1. While it is up to the registrants to provide accurate details about themselves and it is up to the registrants not to mistakenly identify themselves as natural or legal persons, the Memo on "Natural vs Legal persons" provides interesting ideas/suggestions for the contracted parties to proactively ensuring the reliability of information provided, including through measures to independently verify the data. Could similar mechanisms be identified also for ensuring the reliability of the contact details of the registrant? Can best practices be drawn from the ccTLDs?