2018-08-07 EPDP Team call #2

Notes/ Action Items

These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/2IpHBQ.

1.     Welcome and Updates from EPDP Chair

• While it is not confirmed, the likely dates for the EPDP Face-to-Face would be Sept. 24 -26 (Mon – Wed) in Los Angeles due to the headquarters’ ability to accommodate the size of the group as well as meeting team ability to organize a meeting on such short notice. Please do not book travel yet, but tentatively pencil in these dates.

• Requests for Early Input were sent out to all SGs/Cs/ACs. This exercise is slightly redundant with the exercise we are already doing since this team is representative, but we are obliged to follow the PDP requirements. See https://community.icann.org/x/Ag9pBQ.

• Further to questions or concerns about Rafik Dammak as being the Vice-Chair, the GNSO Chair has agreed to step in, or designate a representative, if there is any sort of disagreement that involves the Vice-Chair / Liaison so that the remaining issues can be resolved.

• One alternate for ALAC has bad connectivity and as a result has difficulty following the audiocast – would it be possible to arrange dial-out instead   ?

2.     Roll Call & SOI Updates  

• Roll call will be taken from Adobe Connect.

3.     Overview of EPDP Input Survey Part 1 Results

• Part 1 of the Survey can be found at https://www.surveymonkey.com/r/CC6F9F8

• Thanks to all for the feedback that went into the responses – the rationale given was helpful and will be a useful tool in carrying the conversation forward in both the triage exercise and later in the process.

• The leadership team attempted to collate the survey results in a meaningful way, but due to the large amount of information, it may be difficult to display.  It may be helpful to look at (1) the spreadsheet of survey results, which was sent around yesterday, and (2) a copy of temporary specification separately during the conversation.

• Six takeaways from the survey results:

• There is not consensus for most sections of the Temp Spec, but the rationales provided were helpful.

• There were some suggestions to focus on legitimate purposes (4.4.1 – 4.4.13) first so that it will inform the discussion of other interrelated sections of the Temp Spec.

• Given the lack of consensus, it would be preferable to complete the triage report for the GNSO Council right away so that we can begin delving into the substance.

• The rationales provided in the survey will serve as the basis for the triage report.

• The goal for the triage report will be to create a summary of the issues detailed in the survey results.

• The originally-provided survey deadlines were very ambitious, and in response to feedback received, Part 2 will now be due Friday, 10 August and Parts 3 and 4 will be due Sunday, 19 August.

• Suggested path forward: triage is intended to be an abbreviated process that details the consensus levels of the Temporary Specification. The plan is to spend the next few meetings sharing thoughts and comments from the sections surveyed. The EPDP Leadership Team suggested some neutral wording; however, this is for discussion only, and feedback is welcome.

• To confirm, the EPDP Team’s next meeting will be Thursday 9 August at 13.00 UTC (as originally scheduled). The date for submission of Part 2 of the survey will be Friday 10 August at 19.00 UTC.

• Suggestion to reconsider the meeting schedule, as the current schedule requires a lot of hours.

4.     Substantive discussion of Temporary Specification

• In the interest of time, the EPDP Leadership Team grouped the issues for discussion.

• As an example of an issue summary, please note in Section 1 (Scope), may found the clause beginning with “unless ICANN determines…” to be problematic.

• In Section 3, the effective date of the Temp Spec is 25 May 2018, but was adopted on 17 May 2018, but can the Team get clarification on the exact expiry date of the Temp Spec?

• Action Item: ICANN Org to confirm precise expiry date of the Temp Spec.

• If the Board is considering any amendments to the Temp Spec, it would be helpful if the EPDP Team can be made aware of any proposed changes in advance.

• Action: EPDP Policy Support staff to capture questions in writing and send to the ICANN Org for response.

EPDP discussion:

• GDPR is not the only data protection system, and national data protection systems should not be subordinated by the GDPR.

• It appears the EPDP Team has consensus on the removal of “unless ICANN determines in its reasonable discretion” clause.  EPDP Team can “put a pin” in this and confirm if this can be removed this from the next iteration.

• The Temp Spec has various timelines within it (in 30 days, 90 days, etc.), and the team needs to pay attention to implementation timeline dates and how these might be affected if changes are made to the Policy Effective Date following the adoption of the policy recommendations.

• The next quadrant for discussion includes 4.1 – 4.4.2.

• Question: before we begin discussion, would it be possible to determine which determinations of lawfulness we can determine on our own, and which will be determined for us, i.e., in court cases? Do we have an agreed upon approach to how we find whether something is lawful?

• We do not yet have an agreed upon approach or a determination of what authority we have. At this state, however, we would like to summarize the rationales and compile the triage report.

• Ultimately the arbiter of what is a legitimate purpose will be determined by case law, so the EPDP Team should deal with the rationale of 4.4. The NCSG objected to facilitation for all kinds of third party interests. While the NCSG has agreed to access of certain data in the survey, it did this by looking at ICANN’s mission and role of security and stability of the DNS, rather than third party interests.

• Several responses indicated that the team should consider looking at the uses of the data first. Others suggested that rather than looking at uses, the team should first look at the ICANN’s mission and purpose.

• What type of security are we talking about when we refer to ICANN’s mission – network security?  Who determines that a purpose is legitimate? What is personal data? Is there anywhere to find the list of personal data?

• The RDS PDP WG failed to resolve these issues of purposes, and a post mortem on this would be very valuable as to why the RDS PDP WG went in circles. Since the RDS PDP WG discussions, ICANN has received more input from DPAs. It would be useful to consolidate the advice ICANN  has received and cut short the items where the EPDP Team is conflating the issue. EPDP Team has to figure out how the DPAs have already opined on some of these issues.

• Security is within ICANN’s remit – unless data is collected, it cannot be made available to other people. There are provisions in the GDPR that consider third party needs.

• If something is clearly not supported by the law, the group would be foolish to try to include it in the policy, but no court is ever going to add more purposes.  Rather, the courts will chip away at purposes in certain jurisdictions.

• The EDPB letter is asking ICANN to clearly note its purposes for collecting data. There is availability to process data that is already collected.

• Action item: consider creating table of data elements – what data elements are necessary for ICANN, how it is used, and what data elements are needed for third parties?

• Article 6 of GDPR does allow legitimate interest of controller or third party. A sweeping statement has been made about what happens if ICANN no longer has a mandate of collection and disclosure of data – how does the group envision that happening if ICANN is no longer in the picture?

• The above question reveals a misunderstanding – with a domain name registration, the registrar will always collect information, and law enforcement can always collect this information from the registrar, rather than from ICANN. ICANN will collect data for its own purposes, law enforcement will follow its process, but ICANN’s purpose is not to be law enforcement on the internet.

• In response to some of the questions raised on today’s call – it may be helpful to have trainings on the GDPR.

• Putting ICANN aside for a moment, when we leave from this room, law enforcement will make requests from Registrars/Registries, and businesses and trademark owners will do the same. The purpose of the team working together is not to work on validation of ICANN, but rather, work out mechanisms where legitimate purposes that meet the relevant threshold are accommodated in an economical and transparent way. The Temporary Specification is here, and there will be future requests for data: we need to find a way to evaluate the purposes and decide as a group how to accommodate them.

• Is ICANN Org and the Board hoping the EPDP Team will build the legal argument as to what legitimate purposes are? If there is internal work happening, this is crucial to the work to understand this.

• Outside the United States, due process in flawed. The process can take anywhere from 3-12 months. The group’s purpose here is not to replace WHOIS with something identical, but please be mindful of saying there are other mechanisms, because those mechanisms do not always work well.

• This is a two-step process: what are legitimate purposes, and which ones are not overridden by the GDPR?

• We are deep into the discussion that happens after the triage discussion. The slide on the screen shows summaries of the issues noted in the survey responses.

• Question: if we do not believe that the issue summarization text is necessarily complete, how can we best address this?  Red lines? Flagged during the call?

• Action item: EPDP Team to review issue summaries and share any proposed edits/additions with the mailing list for inclusion in the triage document.

• In sections 4.4.1 and 4.4.2, law enforcement needs to pass the relevant threshold – legitimate interest not overridden by fundamental rights.

• 4.4.2 seems to be a catch-all provision – this may address the GAC’s concern that the Temp Spec limits the number of legitimate purposes.

• In section 4.4, the balancing test is important, but some types of processing fall outside this scope and are not subject to the balancing test, so we need to understand that it’s not always the case that the balancing test is required.

• 4.4.2 does not entirely cure the problem – a legitimate interest is just one basis under GDPR, and there are other data protection sources that we are not gathering at the moment in different jurisdictions that will not be covered by 4.4.1 – 4.4.13.

• The best path forward may be to create the triage report on the sections we have reviewed so that the group can see what the triage report would look like.

• 4.4.1 is fine for the NCSG – this data needs to be collected for the purpose of the registration. 4.4.2 is an odd construct – the purpose is to provide access to the data. This statement is circular.  4.4.2 seems to say that anyone who wants the data can get it – this is begging the question – ICANN is in no position to determine what is legal.

• 4.4.2 opens the door that if you pass the GDPR test, you can add use of the data to this list, but there may be a better way of doing this.

• What we are missing here is that the WHOIS system provides a public service. Through the Temp Spec, we need to recognize the public interest served by WHOIS. As a whole, when you step back – we’re talking about ICANN’s role in the public interest that supports this directory service.

• The legitimate interest is not for the people trying to access the data, but rather, the legitimate interest of the processor of the data.

• The collection and publication of RDS data is done in the public interest and is not necessary for registrars to communicate with their customers. It is not necessary for registrars: WHOIS data is collected over and above the data registrars already have.

• How do you collect information of the registrant without name, address, etc.? The directory is necessary to establish the registrant’s right in the domain name. This is a legitimate and unassailable interest in ICANN requiring the collection of this data.

• Collection of data for purposes of publication in a directory is not needed to serve the customers or to register a domain name.

• There is no public interest definition in ICANN’s publication of a directory service.

• The legitimate interest does not only reference the controller. See Article 6(f) of the GDPR. It is important to note that third parties are considered in the GDPR in Article 6.

• What is a legitimate purpose? Can we get some criteria definitions around this?

• Registrars may also comply with other data protection law or where commercially necessary. This is a fundamental question.  How far can this exercise as an EPDP go? In a temporary specification you can attempt to comply with other laws, although we’re only focused on the GDPR at the moment, but it seems nonsensical to allow this where commercially feasible – it appears like we are only concerned with laws that have heavy financial penalties.  The situation could be remedied by adding something like “since GDPR appears to be leading the world in data protection as a model, parties should comply with the GDPR in other jurisdictions as required.”

• There are a number of national privacy laws that are proposed or in the works – it is impossible to predict where the landscape is going, so we’ll have to treat that as a known unknown – that the future laws will be mostly or entirely compatible with GDPR, or service providers.

• 4.4.3 appears to be a header for the next four sections since all have to do with registrants.

• Each purpose needs to be justified and compliant with GDPR. It is hard to know what precise amendment to propose because the level of principle is not reflected in the draft. Another important point for contracted parties is necessity of collection of data, while it may be necessary to collect, it may not be necessary to publish. We should go through collection, use, and disclosure.

• As referenced earlier, we could create a list of the data and how it’s used. It could be a matrix. The RDS PDP WG already did something similar so maybe that could serve as a basis?

• Section 4.4.5 should be read very carefully because ICANN does not regulate content.

• Knowing the term content raises red flags, there must have been some sort of reason why this included – let’s capture this question.

• Question for ICANN Org – is there a reason for the inclusion of the term content in section 4.4.5?

• In 4.4.3, we are talking about the reliability, but in 4.4.4. and 4.4.5 does not mention reliable.  We need to define who defines reliable; however, this word should be kept.

• SSAC believes content should stay in 4.4.5.  If your domain name is infected, it may be spewing out spam at high rates, and it is helpful to contact you with respect of that content.  Rather than the type of content, it is talking about content more generally.

• It would be helpful to hear from the team how we can best conduct these discussions to best get through the triage period. We propose to finish the rest of the surveys and assemble that material unless members have alternate suggestions.

5. Wrap and confirm next meeting to be scheduled for Thursday 9 August at 13.00 UTC

All Action Items:

1. ICANN Support Staff to capture any questions where a response is needed from ICANN Org (see above).

2. ICANN to draft first portion of Triage document to demonstrate how information will be organized and for EPDP Team review.

3. EPDP Team to review issue summaries and share any proposed edits/additions with the mailing list for inclusion in the triage document.

4. EPDP team to complete the second part of the survey by Friday, 10 August.

5. EPDP Leadership Team to look into creating a matrix of which data is used for which purpose to help inform subsequent deliberations (following triage), factoring in the work that has already been done on this by the RDS PDP WG.