[Gnso-epdp-team] Notes and action items from EPDP Meeting #7 - 20 June 2019

[Caitlin Tubergen]

Dear All,

 

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

 

Safe travels to Marrakech.

 

Best regards,

 

Marika, Berry, and Caitlin

 

 

EPDP Meeting #7 20 June 2019 

 

Action Items

 
Alex Deacon and Chris Lewis-Evans to develop an additional use case(s) using this template to share with the EPDP Team at the face-to-face meeting at ICANN65. 
Reminder to please provide feedback on the Next Steps for Priority 2 items by Friday, 28 June.
 

Notes 

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/ZwPVBQ.

 

1. Roll Call & SOI Updates (5 minutes)
Attendance will be taken from Zoom
Remember to mute your microphones upon entry to Zoom, which is typically the first icon on the left on the bottom toolbar.
Please 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. Confirmation of agenda (Chair)

 

3. Welcome and housekeeping issues (Chair) (10 minutes)

 
Request for additional resources for F2F meetings submitted (see https://www.icann.org/en/system/files/correspondence/drazek-to-chalaby-12jun19-en.pdf)
·         This letter was sent to the Board on 12 June 2019, and we are awaiting a response. The letter includes tentative dates for a September face-to-face meeting.

·         There may be an opportunity to engage ICANN org re: interaction with EDPB during ICANN65 - please review the letter forwarded from Janis to the EPDP Team shortly before this meeting.

 

4. Topic c: Define user groups, criteria and purposes / lawful basis per user group

 

·         Question to CPH:  can CPH please respond regarding if there is any other group other than law enforcement that it believes could receive access/disclosure to non-public registration data?

·         CPH tried to provide very specific feedback on the purposes document.

·         At a high level, the CPH was hesitant to come up with positive feedback on many of the purposes due to the concern that a potential security researcher could knock on a registrar’s door and demand personal data with little specificity. 

·         CPH does not think law enforcement needs a specific purpose, as it is already accounted for in GDPR.

·         The point of the feedback of CPH was not to point out that there was only one legitimate purpose. Instead, the feedback was specific to the purposes as drafted in the document.

·         CPH believes it cannot define what legitimate purposes are. That is not to say these may not be legitimate purposes - it depends on what is being requested and for what purpose.

·         It may be helpful to start with the legal basis.

·         From now on, the Chair asks the Team to think of how we can move this forward and come up with proposals.

·         Using 6(1)(f) in very limited cases is correct. The Team needs to relate the legitimate interests back to the work done in Phase 1.

·         Proposal to move things forward - it may be helpful to sequence things slightly differently. It may be helpful to start with civil claims. Public authorities cannot use 6(1)(f). That will primarily put our focus on 6(1)(c) for law enforcement. The law enforcement needs a legal basis for making that request. Non-European law enforcement could use 6(1)(f), which means it could be easier for non-European law enforcement to receive data. It would be helpful to get clarity from outside counsel on European vs. non-European law enforcement.

·         What is consistent with ICANN’s mission? There could be millions of legitimate interests that are consistent with ICANN’s mission. One thing the Team needs to ensure is that it doesn’t stray from ICANN’s narrow mission. 

·         When the Team says “this is not a purpose because a balancing act will be performed” this presents a definitional problem. Regarding the assertion that you cannot show up and say that you are a security researcher and you need data - that seems to be an orthogonal discussion. From a policy perspective, once you have a discussion that the purpose is theoretically lawful, you can have a policy discussion about bias.

·         The Team should use the term purpose instead of legitimate interest. The other questions are ancillary questions. At this time, the Team should decide what the purposes are. This work is clearly within ICANN’s scope.

·         The GDPR defines in the recitals some purposes for security. When someone makes a request, the requestor needs to state their legitimate purpose.

·         The CPH comments were not meant to be obstructionist. If the Team is discussing legitimate interests, we are only talking about one thing - 6(1)(f). Disagree that we should use the word purposes just because it was used in the Charter - the Charter was not drafted by GDPR experts.

·         There is no purpose or group that is guaranteed, but we do need to start somewhere. 

·         Some have objected to the categorization of all third party request being 6(1)f. In certain cases 6(1)b may also apply some have argued. However, whether or not 6(1)b is applicable may depend on who the controller is for the data. This may be an issue for which further legal guidance may be required?

·         Public interest would require a legal act vesting ICANN / CPs with performing a task in the public interest. There does not seem to be any such legal act at this stage.

·         What about 6(1)d - vital interest of the data subject or another natural person? Can this also be used by LE or other parties? EPDP Team should further consider what other legal basis can be used. 

·         Proposed approach forward: move this into real life cases, similar to how this has done for the review use case. 

– Review use case prepared by Thomas Rickert (60 minutes)

a.            Overview of use case - Trademark owners requesting data to take legal action against cybersquatters (Thomas Rickert)

b.            EPDP Team input

c.             Confirm next steps – e.g. modification of template, identification of other use cases and volunteers to develop these further.

 

·         Note that there was a request from the IPC to defer this to the F2F meeting. Conduct first reading here, followed by a second reading during the F2F meeting. 

·         See observations shared by Thomas with the mailing list: 

·         1. The document I sent is an attempt to help our group’s discussions. It looked like we could not really agree on an approach to get your work started.

·         2. The use case is intentionally kept very limited in scope so that we can focus on one scenario without getting lost in detail or distracted. That is not to say that there can be associated requests or requests different in nature that warrant a different assessment. 

·         3. The document is based on the work Thomas did at eco when we drafted the eco GDPR domain industry playbook, so Thomas will not claim to have authored the entire document. The good ideas are from other playbook team members. Put the blame on Thomas for the things you do not like.

·         4. The document does not reflect an ISPCP position. It was an AI Thomas accepted in personal capacity and is a draft that will likely be subject to change based on EPDP Team deliberations.

·         Use case: trademark owners requesting data to take legal action against cybersquatters. (see template shared that defines the user groups / user characteristics, why is non-public registration data requested, lawful basis, general safeguards) 

·         This example focuses on trademark only, not patent or copyright.

·         The EDPB has specifically requested that ICANN’s disclosure model has specific safeguards in place, and, accordingly, a list of safeguards has been provided in this example.

·         Boolean searches and reverse look-up searches did not come from ICANN, but rather, from third party vendors, and therefore - those have not been included here.

·         Disclosure request must be directed at the contracted party who houses the data, unless there is a centralized model

·         Re: data elements that are necessary - name, organization, and postal address.  Email address, phone and fax are questionable and may not be necessary for this purpose.

·         Item F - last point to be discussed - how you can get eligibility for filing disclosure requests - providing evidence of ownership of intellectual property. 

 

                        Feedback from the Team:

·         Could this methodology work for other use cases? 

·         This methodology could be helpful for moving forward.

·         Figuring out where to start in this exercise can be challenging. It would be helpful to keep the use case as narrowly-scoped as possible and walk through it from start to finish.

·         Do any team members feel the template used by Thomas would not work? 

·         This is a great way to proceed at this point; however, how can we proceed afterwards? We do not have the resources to deal with every possible use case in this level of detail. 

·         Question to Team: are there volunteers to write up other use cases following this methodology?

·         Re: working with this template - the level of amendments may be to keep or eliminate some of the columns on the left. 

·         The template may evolve through the Team’s discussions.

·         Re: asking for volunteers to develop more use cases - disagree with that path forward. Instead, the Team should work on fleshing out this use case further. 

·         Proposal from Chair to go through the details of this proposed use case - will go line by line on Tuesday. However, we need volunteers for other use cases; otherwise, we will not make substantive progress by November. 

·         Support walking this example all the way through first. Following that, it will be helpful to go through the other big picture use cases. 

·         IPC volunteers to provide additional IP examples.

·         GAC will come forward with public safety examples.

·         What is the end point? If we are trying to document all potential use cases, that will be an infinite job. 

·         The goal is not to go through every use case, but instead, to see if we can identify commonalities. 

·         It may be helpful to put a limit on the number of use cases we are going to review at this point. While working on this, we need to look at how this work can be generalized. 

·         At the moment, we are discussing a maximum of five cases.

·         Thank you to Thomas for providing this example. We will move forward and await additional examples from IPC and GAC for discussion. 

5. ICANN65 EPDP Team F2F Meetings (15 minutes)

a.            Review proposed agenda

·         The draft ICANN65 agenda has been circulated - unless there is disagreement we will proceed as noted in the agenda.

·         The Tuesday meeting will be used to review any early input received - the deadline for input is tomorrow. 

·         We will also go through Thomas’ example in detail.

·         Michael Palage has reached out to EPDP Leadership regarding a unified access model, and similar to Steve Crocker, we will invite him to speak in Marrakech. 

·         On Thursday, ICANN org will join us to discuss engagement with DPAs. 

·         We will then continue discussion of Thomas’ example and building blocks for the SSAD.

b.    EPDP Team Input

·         Some groups have noted they may need more time for providing early input. When would be the last date the input could be provided, and noting the request, it may be helpful to remove this from the Tuesday agenda.

·         ALAC came to the conclusion that early input was asking for answers to all of the charter questions this Team is responsible for answering. Discussing this type of early input may be impractical at this stage.

·         The Team will review any input received by 21 June. If 30 minutes for this topic is not enough, we can adjust as necessary.

·         There is no requirement for any group to provide input if it is of the view that their input has already been provided.  The requirement is to ask for input, not for groups to provide input.

·         GAC is working on input, but the GAC is not following the questions directly. This is a much bigger undertaking than initially thought. However, the input may be better discussed on Thursday.

·         The Team will follow the provided agenda, but if need be, the agenda can be adjusted.

c.     Confirm next steps

 

6. Any other business (5 minutes)

a.            Priority 2 small team meetings update

-Reminder - Call schedule remaining priority 2 worksheets: TBC (post ICANN65)

Accuracy and WHOIS ARS

- Deadline for providing input for those that were not able to attend the

calls – proposed 20 June 2019.

 

·         We have had three scheduled meetings on Priority 2 worksheets. Members in attendance went through all six worksheets and they are finalized for review by the team. Please review the worksheets and the next steps by next Friday, 28 June. 

·         There will be no meeting the week after Marrakech. (Cancelled 4 July) The next meeting following ICANN65 will be 11 July. 

·         Feedback: the NCSG is concerned with the pace of Phase 2. Tackling multiple issues in parallel is proving difficult to keep up with - can leadership please reconsider this approach?

·         We will further discuss this concern in Marrakech as we build out the work plan. May need to consider if/how to delegate tasks to other group members for faster progress. 

 

7. Wrap and confirm next meeting taking place at ICANN65 (Meeting room:

Tichka) on Tuesday 25 June from 8.30 – 15.00 local time (5 minutes)

 

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/20190620/522ba582/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-team/attachments/20190620/522ba582/smime-0001.p7s>