[Gnso-epdp-legal] Proposed agenda - EPDP Phase 2 Legal Committee Meeting #8 - 1 October 2019

Mon Sep 30 13:45:32 UTC 2019

Dear EPDP Phase 2 Legal Committee:

Please find the agenda for our next meeting below.

As a reminder:
Thomas, Volker, Brian and Margie to work together on refining this Q11, including considering the addition of a question on reverse look-ups, in advance of the next LC call on Tuesday, 1 October. 
Brian and Matt to review and refine updated Q12/13 and provide the updated language to the EPDP Team in advance of the next call on Tuesday, 1 October.

Best regards,

Marika, Berry, and Caitlin

--

EPDP Phase 2 Legal Committee Meeting #8

Tuesday, 1 October at 14:00 UTC

Proposed Annotated Agenda
Roll Call & SOI Updates 
Housekeeping 
·         Legal Committee to provide high-level summary of legal memos for the plenary to review – Volunteers needed 
Continued Substantive Review of Priority 1 (SSAD) Legal Questions Submitted to Date

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

Updated Question 11

Status: Thomas, Volker, Brian and Margie to work together on refining this question in advance of the next LC call on Tuesday, 1 October.

(Previous text proposed by Margie): Is it permissible under GDPR to provide fast, automated, and non-rate limited responses (as described in SSAC 101) to nonpublic WHOIS data for properly credentialed security practitioners1 (as defined in SSAC 101) who are responsible for defense against e-crimes (including network operators, providers of online services, commercial security services, cyber-crime investigators) for use in investigations and mitigation activities to protect their network, information systems or services (as referenced in GDPR Recital 49) and have agreed on appropriate safeguards? Or would any automated disclosure carry a potential for liability of the disclosing party, or the controllers or processors of such data? Can counsel provide examples of safeguards (such as pseudonymization/anonymization) that should be considered?

For purposes of this question, please assume the following safeguards are in place: 

o    Disclosure is required under CP’s contract with ICANN (resulting from Phase 2 EPDP policy).

o    CP’s contract with ICANN requires CP to notify the data subject of the purposes for which, and types of entities by which, personal data may be processed. CP is required to notify data subject of this with the opportunity to opt out before the data subject enters into the registration agreement with the CP, and again annually via the ICANN-required registration data accuracy reminder. CP has done so.

o    ICANN or its designee has validated/verified the requestor’s identity, and required in each instance that the requestor: 

•                     represents that it has a lawful basis for requesting and processing the data,  

•                     provides its lawful basis, 

•                     represents that it is requesting only the data necessary for its purpose,  

•                     agrees to process the data in accordance with GDPR, and  

•                     agrees to EU standard contractual clauses for the data transfer.  

Footnote 1: SSAC defines “security practitioners” in SSAC 101 as those who have a responsibility to perform specific types of functions (as specified in Section 3) related to the identification and mitigation of malicious activity, and the correction of problems that negatively affect services and users online.

Updated Question 12 and 13

Status: Brian and Matt to review and refine updated Q12/13 and provide the updated language to the EPDP Team in advance of the next call on Tuesday, 1 October.  

(Previous text proposed by Margie) 

Background: The recent EC Letter [icann.org] provides clarification regarding the possible legal bases for disclosure of non-public registration data to in the section entitled “Legal Bases for Processing”, and noted:

“As explained in our comments, Art. 6(1)f GDPR (legitimate interest) is one of the six possible legal bases provided under Art. 6(1) GDPR. For instance, disclosure of nonpublic gTLD registration data could be necessary for compliance with a legal obligation to which the contracted parties are subject (see Art. 6(1)c GDPR).”

and

“With regard to the formulation of purpose two, the European Commission acknowledges ICANN’s central role and responsibility for ensuring the security, stability and resilience of the Internet Domain Name System and that in doing so it acts in the public interest.”

Questions:
In light of these statements from the EC, are there any updates to the prior memos submitted by B&B regarding the applicable bases for disclosure of non-public registration data to third parties for the purposes identified in EPDP Phase 1 Final Report Rec. 1 (Final Report), such as the memo on 6(1)(b)?   
To what extent can disclosures of non-public registration data to third parties for the purposes identified in the Final Report Rec. 1 be justified under GDPR’ Article 6(1)e (public interest), in light of the EC’s recognition that: “With regard to the formulation of purpose two, the European Commission acknowledges ICANN’s central role and responsibility for ensuring the security, stability and resilience of the Internet Domain Name System and that in doing so it acts in the public interest.”

Question 6

Status: Awaiting updated text from Georgios (if any) 

(Updated proposal from Brian and Georgios): Q6) Within the context of an SSAD, in addition to determining its own lawful basis for disclosing data, may the disclosing party (which may not be the entity that houses the requested data) take full responsibility to assess the lawful basis of the third-party requestor (without the entity that houses the requested data being responsible for assessing the lawful basis of the requestor)?

*Note to legal subteam: do we want to expand this question to cover the other aspects of a disclosure request, beyond merely the lawful basis?

Previous legal advice rec’d from Bird & Bird: “The safeguards require attestation by the Requestor that it has a legal basis for its collection of personal data via the SSAD. Our conclusion above is that CPs will most likely be viewed as controllers for this processing. Accordingly, the main concern for CPs will be that they (rather than a Requestor) have a legal basis for the processing. Where multiple different controllers are involved, the challenge is greater.”

Questions previously put on hold pending further legal advice and/or EPDP Team discussion

a)      Additional topics noted in plenary sessions, where an EPDP Member requested the topic be considered by the Legal Committee

o    Domain names based on identical contact information: If a requestor obtains contact information for a domain name engaged in bad activity, is accessing contact information from other domain names with identical contact information permissible? (topic introduced by Brian K. during 6 September plenary meeting)

o    ccTLD operators offering reverse WHOIS look-up services (topic introduced by Margie during F2F – requested legal advice) 

Status: Thomas, Volker, Brian and Margie to consider these items in their review of Q11. 

o    SSAC-proposed topics: 

·         BALANCING, AND RIGHT TO OBJECT: The defense of networks, the prevention of fraud, resisting cybercrime, and indicating possible criminal acts or threats to public security to a competent authority are tasks performed by third parties who are not law enforcement or government agencies. Such parties have legitimate interests in making data requests under GDPR, notably under Article 6(1)f; see also Recitals 47, 49, and 50. We are considering balancing where the data subject may be infringing upon the rights of others, and the safety of third-party requestors who deal with cybercrime.  The third-party purposes above also require timely responses to data requests.

Assume that registrars notify their registrants up-front of the purposes of data collection, under what circumstances the data may be released, the right to object, etc. 
When a data controller receives a legitimate third-party data request, under what circumstances is the controller required under GDPR to explicitly notify the data subject that a request has occurred, and/or that it has provided data to a third party? 
Under what circumstances do data subjects have the right to object under GDPR  to the release of their data to third parties?  Per Bird & Bird's Question 3 memo, ICANN's use cases do not involve profiling or highly sensitive data categories (race, political affiliation, etc.), and "a decision to release information via the SSAD is would not in itself have legal effect on the data subject."
Are data controllers ever required to notify the data subject of the identity of a third-party requestor?
Please confirm: when a data subject objects to processing, the decision to release the data resides with the data controller?
If a registrant must be notified of a request and then be given the opportunity to object, please explain how this process can be reconciled with or integrated into a SSAD that is designed to provide timely data exchange when possible and does not involve "a decision based solely on automated processing". (See Bird & Bird's Question 3 memo, paragraph 1.12.) 

·         LEGAL VERSUS NATURAL PERSONS: Registration data submitted by legal person registrants may contain the data of natural persons.  For example the contact data they provide may include a natural person's name and email address. Legal person registrants also have the ability to publish non-personally identifiable contact data ("admin at companyname.com") should they desire.

If registrants are required to self-identify as either a natural or legal person, then:

a.      Can registrars rely on that self-identification? 

b.      Can registrars make the contact data submitted by legal person registrants publicly available in RDS (WHOIS), by stating that it is the responsibility of a legal person registrant to obtain consent from any natural person whose data it submits?  

Please state any considerations, such as the ability of the registrant to correct its data. As part of the analysis, please examine the policies of the Internet protocol (IP address) registries RIPE NCC (the registry in Europe, based in the Netherlands) and ARIN (the registry in North America, which has customer contacts in Europe).  These registries publish the data of natural persons who are subject to the GDPR, publicly via their WHOIS services, by placing the choice and responsibility on their registrants, who are legal persons.  IP addresses and domain names are two sides of the same coin, and these IP address registries state mission justifications and collection purposes similar to those in ICANN's Temporary Specification. See:

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

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

3) "Personal Data Privacy Considerations At ARIN": https://teamarin.net/2018/03/20/personal-data-privacy-considerations-at-arin/

4) ARIN "Data Accuracy": https://www.arin.net/reference/materials/accuracy/

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

6) ARIN Privacy Policy: https://www.arin.net/about/privacy/

b)      Agree on next steps

Wrap and confirm next meeting to be scheduled 
a)      Confirm action items

b)      The next LC Meeting will take place on Tuesday, 15 October at 14:00 UTC.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-legal/attachments/20190930/505b9648/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4620 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-epdp-legal/attachments/20190930/505b9648/smime-0001.p7s>