[Gnso-epdp-team] Notes and action items EPDP Team meeting #19 - Thursday, 11 October

Thu Oct 11 17:17:41 UTC 2018

Dear All,

Please find below the notes and action items from today’s EPDP Team meeting.

Best regards,

Marika, Berry and Caitlin

High-level Notes/Actions

1. The Leadership Team will be circulating a draft agenda for the High Interest Topic session in Barcelona to the EPDP Team. EPDP Team volunteers are required to come forward to present during the high interest session. 2. If you have been appointed as a lead, please complete the data elements workbooks homework by Monday, October 15. As a reminder, the objective for appointed leads is to review the workbook, flag any updates that need to be made, and flag any outstanding issues that may need to be discussed in Barcelona. 3. Benedict and Farzaneh to submit the completed workbook for the research purpose as soon as possible. 4. The next steps for Purpose B following today’s call are as follows: 
Please take the time to read the Purpose B workbook that was sent this morning more carefully. 
If you would like to volunteer to assist in the updated purpose statement and accompanying workbook exercise, please reach out to the Leadership Team, who will put you in touch with Benedict Addis, or you may reach out to Benedict directly. 
Please consider any policy items the team could put in its initial report with respect to today’s discussion.

Notes & Action items

EPDP Meeting #19

11 October 2018

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. Roll Call & SOI Updates
Attendance will be taken from Adobe Connect
Please remember to mute your microphones when not speaking, and state your name before speaking for transcription purposes.
Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team.

2. Welcome and Updates from EPDP Team Chair
The Leadership Team is looking for volunteers to present during the High Interest Session. 
Action: Volunteers to come forward to present during the high interest session.
Action: Please remember to complete the data elements workbooks homework. Updates are due Monday, October 15. Objective is for appointed leads to go through the workbooks. to flag any updates that need to be made and any outstanding issues that may need to be discussed in Barcelona.
Action for Benedict and Farzaneh -  please submit worksheet for the research purpose.

3. Recap the F2F agreements in relation to lawful disclosure to third parties (Purpose B) 

AGREED NEXT STEPS IN RELATION TO LAWFUL DISCLOSURE OF REGISTRATION DATA TO THIRD PARTIES (Purpose B)

Facilitate lawful access for legitimate 3rd party interests to data that is already collected and identified herein 
This is a registry/registrar purpose
The group has different viewpoints whether this is also an ICANN Purpose – we will analyze that more.
We agree that we want third parties with legitimate interests to be able to have predictable, lawful access, and the EPDP policy must make that clear. (we didn’t define what ‘predictable’ means).
We are all going to bring this back to our constituencies.

4. Review data elements workbook for Purpose B (facilitate lawful access)

Kristina Rosette distributed the updated Purpose B workbook shortly before this meeting.
The updated Purpose B workbook is a joint product of the Ry/Rr Members.

Please see latest version of Purpose B Workbook.

Objective of discussion:

(1) Review data elements workbook for purpose B as completed by registries/registrars

Ry (Alan Woods review of workbook):

There seems to be a disconnect in what the word purpose means. 
This is categorically a purpose for ICANN, but that does not mean that this GDPR compliant.
The exercise involved answering the questions in isolation.
Question 1 - is this lawful as tested against GDPR? The Temp Spec says this is an ICANN purpose. Since ICANN does not have the data, it functionally makes it a Ry/Rr purpose.
Question 2 - is the purpose in violation of ICANN's bylaws? Perhaps.
Question 3: Description of processing activities:
Collection of rt data (Ry/Rr)
Storage of rt data (Ry/Rr)
Disclosure of rt data (Ry/Rr)
Question 4 - is the processing necessary to achieve the purpose? No, b/c it up to the individual contracted party to decide.
Question 5 - is there a transfer? Yes - Rr to Ry
Question 6 - is publication required? Disclosure of data is publication; however, it is more straightforward to achieve the required balance with data subjects fundamental rights if that disclosure is on a 1:1 basis.
Question 8 - what are the data retention requirements to meet the purpose? life of registration + 35 days to allow for the completion of the lifecycle (RGP + pending delete)
Question 7 - are there picket fence considerations? The new requirement needs to be formalized in a JCA/DPA.

As the team moves through the queue, keep two ideas in mind:

1. legality and how a regulator would look at this under GDPR

2. what is important to you as a stakeholder in the ICANN ecosystem?

EPDP Team feedback on Purpose B document:

The EPDB in its 5 July letter says not to conflate purposes, but it does not say to ignore the purposes. 
It is unfair to respond to this with such little time to review this. How did Ry/Rr come up with how disclosure is not part of the ICANN contract? The group is trying to specify the purposes through this exercise. This purpose is stated in the ICANN bylaws.
Clarifying question: lawfulness of processing question - under question 1, Rys/Rrs indicate this is not a CPH purpose, how is this purpose lawful under 6(1)(b)?
The green box with the lawful basis was prepopulated to assist the groups in identifying the legal basis, so even if 6(1)(b) is noted in the box, that is not what the group is purporting the purpose is.
The argument under question 1 about purpose is circular. There are implicitly parts of the ICANN contract that data needs to be made available to third parties. Under question 4, what are the purposes? The current purpose at the top of the page needs to be reworded; however, the purpose used to be detailed and all of the details were taken out during the F2F. Under question 5, why is transfer from registrar to registry necessary to meet this purpose? Under question 6, that is addressing who can get the data, but the real issue is can anyone get the data, if not - there is no purpose.
The primary purpose of the purpose was to focus on the facilitating/enabling part. The EPDB has the expectation that ICANN will have a model that focuses on legitimate enabling of access.
Would it be beneficial to reword the purpose? 
The purpose is meant for the facilitation, and this is a 6(1)(b) purpose, and both parties are joint controllers: the contracted parties are 6(1)(b) and ICANN would be 6(1)(f).
Any documents to be discussed should be available 24 hours before the meeting. If law enforcement is not a purpose, what is it?
The data collected to fulfill a registration agreement, the lawful access part is applied to other contracts as well.
There is no reason why law enforcement cannot get this data b/c LEA has a legal right to access data. CPH may not always listen to LEA, but LEA does not need a purpose to access data.

One of the ways the team could think aloud: how could the team potentially reframe the purpose so that it more accurately fits as an ICANN purpose?

The group changed the purpose to be more vague, and now the vagueness is causing issues.
Perhaps the team could go back to discussing: Facilitate lawful access for legitimate 3rd party interests, including those related to consumer protection, cybercrime, law enforcement, DNS Abuse or potential or alleged intellectual property violations, to RDS data that is already collected and identified herein. 
Part of the reason this is difficult is that many public authorities have their basis in laws. ICANN's public policy purpose is more legally unclear. While it may be sincerely held, it does not offer the same amount of legal cover as others. If any CP is approached by LEA, it would follow a legal obligation to disclose the data. It may be helpful to think about sharing 1:1 pursuant to a legal obligation and then there is publication on a public register - these are two forms of sharing data.
CP are concerned that if you go down this path, you are paving the way for centralized model, and that is a concern for several stakeholder groups.
How can the Team ignore mitigation of DNS abuse?
If the Team uses this language or language close to it, the Team has met the purpose test. The Team still has to go through the processing activity. 1. For prevention, 2. network and information security, 3. indicating possible criminal acts or threats to public security
The data subject needs to be made aware of how the data will be processed - being specific would be better in this case. Is this the work product of Rys/Rrs? 
Yes, this was a joint effort b/w Rys/Rrs.
There was a discussion last night about why this team needs legal counsel. The Team continues to conflate the legitimate interests of third parties (LEA, cybercrime, etc.) with the purpose of processing, which is a primary relationship b/w the individual getting a name and the delegated party that provides the ability to register the domain name. The purpose of ICANN is not to set up WHOIS, it is to permit the setting up of domain names.
Some of the third party access argument is ICANN after its own purposes but outsourcing it to others - they may not answer everyone's needs. 
ICANN's mission is not to just register domain names, but to do it in a way that is reliable and secure.
ICANN is a private sector entity registered as a corp. in CA - it has not been delegated as a law enforcement authority. The problem is the instrument, and ICANN setting itself up as an instrument. An example would be banks - there are strict limits under banking regulations to get into personal details of individuals. Unfortunately, ICANN does not have the remit that a bank does. 
Does ICANN have a purpose here?
There is a disagreement here over ICANN's remit.
Purpose is a loaded term to this group. Even if the group believes it's an ICANN purpose does not give it standing under GDPR.
What should accompany this discussion as policy language from this group? 
Next steps: read what was sent this morning more carefully. 2. some could put together a purpose statement that benedict put in the chat or from LA and run the exercise through the data elements worksheet. 3. are there policy items the team could put in its initial report?
(2) Agree on wording of the purpose:

(a) is sufficiently specific to meet GDPR requirements

(b) anticipates disclosure of data to intended audience for limited purpose

(3)  Agree on responses to different questions in data elements workbook

a) Review data elements workbook for purpose B

b) Discuss any outstanding items / questions

c) Finalize data elements workbook for purpose B

5. Wrap and confirm next meeting to be scheduled for Tuesday, 16 October at 13.00 UTC.

a) Confirm action items

b) Confirm questions for ICANN Org, if any

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