Hi all, The slide deck is posted on the wiki agenda page: https://community.icann.org/x/7ISGBg, under background documents with title: RDDS Policy Framework Project Overview 2019-05-12.pdf Best, Terri From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Margie Milam <margiemilam@fb.com> Date: Thursday, June 13, 2019 at 3:22 PM To: Caitlin Tubergen <caitlin.tubergen@icann.org>, "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Call #6 - 13 June 2019 Hi Caitlin- Could you share a copy of Steve Crocker’s slide deck with the team? Thanks so much! All the best, Margie From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen@icann.org> Date: Thursday, June 13, 2019 at 11:41 AM To: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Notes and action items from EPDP Call #6 - 13 June 2019 Dear EPDP Team, Please find the notes and action item’s from today’s EPDP call below. As a reminder, the next EPDP Team meeting will be Thursday, 20 June at 14:00 UTC. The Priority 2 meeting for worksheets on OCTO purpose and feasibility of unique contacts for anonymized email addresses will be Monday, 17 June at 1300 UTC. Thank you. Best regards, Marika, Berry, and Caitlin -- EPDP Meeting #6 13 June 2019 Action Items 1. Thomas Rickert to provide an IP infringement scenario by Tuesday, 18 June to be discussed with the Team during a future meeting. Thomas to coordinate with EPDP Support Staff as necessary. 2. EPDP Team to review the list of third party purposes and provide additions, edits, and comments by Tuesday, 18 June. (Note: please be prepared to discuss Thomas’ example and the law enforcement example during the next meeting on Thursday, 20 June.) 3. EPDP Team members to please provide Google account info to the GNSO Secretariat (gnso-secs@icann.org<mailto:gnso-secs@icann.org>) as soon as possible. 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) a. Working definitions – confirm posting of updated version on wiki · Working definitions have been amended as previously discussed and have been posted on the wiki. This will be a reference document we refer to during our work. b. Legal advisory group – nominations received to date · During the last meeting, we agreed to have a representative legal committee, similar to the legal committee from Phase 1. Each group was invited to nominate one person for the representative legal committee and provide the nomination to the Chair in advance of this meeting. · Margie Milam and Laureen Kapin will be added to the list. · NCSG is concerned with the number of representatives from each group. During Phase 1, it was challenging for NCSG to only have one representative for the group. From a practical perspective, it would be helpful for the NCSG to have 2-3 members instead of one. · If a nominated representative cannot make the meeting, another member of that group could step in. Additionally, the legal committee’s proposals will go before the plenary team. · The Team should strive for how to get the maximum from legal counsel. The added value is not the outcome or the conclusion, but rather, the background work that would go before legal counsel. · Perhaps a mailing list could be set up for this group so that other groups can follow the work and can be continuously engaged. · The meetings of the legal committee will be public, so multiple members may attend, but only legal committee members will be invited to speak. The mailing list will also be publicly archived. · With that understanding, we will await nominations from NCSG and proceed as noted above. c. SSAD Priority 1 worksheet status · Support Staff distributed an email yesterday, noting that the updated worksheet was posted to the wiki. Three versions were posted: the clean version, the redline version, and the archived version. · For the updates made, Support Staff focused on comments regarding the order of topics. Proposed changes to charter questions were not considered at this time. Similarly, substantive comments on topics are visible in the archived version of the worksheet, but were not added to the clean version. · All members should have received an email from GNSO-Secs, asking for google account information so that only authorized users can edit and provide topics due to unauthorized users removing members’ comments. Please send your google account information to the GNSO-Secs at your earliest convenience. · The worksheet will be a living document. 4. SSAD – Topic c: Define user groups, criteria and purposes / lawful basis per user group (Marika) (40 minutes) a. Review purpose template developed by staff support team (see attached) · This document starts with third party purposes/legitimate interests · Further to the discussion during the last meeting, we used the spreadsheet of third party purposes previously submitted to ICANN. · There were a number of third party purposes that noted the ability to contact the registrant, but this seems to have been covered in the Phase 1 recommendations and is not included here. · Support Staff also attempted to develop a template for the third party purposes/legitimate interests. · Support Staff’s understanding is that third party legitimate interests do not have to be identical to the purposes for which the data is collected. · The charter questions refer to purposes for third parties, but the Team may want to consider using a different term. · If the EPDP Team wants to progress, discussion needs to be cooperative. There were some immediate reactions when Marika began to speak. Why is that reaction coming now? Why not provide feedback when the document was posted? We started with groups, then the Team told to use purposes, which is why the document is structured in this way. Please keep the conversation cooperative. b. EPDP Team input · Beginning with purposes makes sense. · Starting with user groups is problematic. We are walking a fine line by trying to create legitimate purposes. We should exercise caution here. · Third parties will need their own purposes for disclosure. With respect to the approach and starting point, we should not start from scratch with data elements that were collected in 2017. · The language during the last meeting was sloppy when we referred to purposes instead of legitimate interests. We need to look at the specific request for specific data elements. For example, for the sake of argument, academic research could be a legitimate third party interest. There is now a problem of people disguising themselves as academics to get data for another reason. What justifies this particular academic research? What about anonymization? · These discussions seem to go in circles. If we refer to the charter questions, they get us where we need to be. We can debate the terminology there, but we shouldn’t get wrapped up in other important details because they will be addressed later on. Suggest sticking to the framework of the charter without getting into the details that will be discussed later. · It may be helpful to talk through a scenario. · The Team does not have to be all-encompassing with the user groups. An ice cream truck may have a legitimate interest, but we may want to exclude certain groups b/c they can avail themselves through other means. Otherwise, we risk getting too granular. · Our presumption in doing this exercise is not that b/c you fall into a group, you automatically get data. Our presumption is that some groups may be easy ones (like a UDRP case) where human review may not be necessary. Academic researchers are so varied and require so much data that manual intervention will likely be necessary. Edge cases will be there, but that is not our problem today. · Third party requests will not be treated the same way they were in the past. The edge cases are instructive and a lot of bulk requests from the past will turn into edge cases. It’s useful to go through the ice cream truck example. · The group seems willing to review one scenario or purpose (preferably not use legal terminology at this stage) and go through a test case. The law enforcement example is interesting - GDPR has a different legal basis - 6(1)(c) - this may take the group down a rabbit hole. Suggestion: let’s look at a scenario that contracted parties deal with everyday. Companies go to contracted parties based on their trademarks due to cybersquatting. · Would it be possible to write up the scenario for our next meeting? · Would the Team be open to Thomas writing up a scenario re: IP infringement to be discussed at a future meeting. c. Confirm next steps · Thomas Rickert to provide a write up of an IP infringement scenario to be discussed with the Team during a future meeting. Thomas to coordinate with staff as necessary. · EPDP Team to review the list of purposes and provide additions, edits, and comments by Tuesday, 18 June. · EPDP Team to review the law enforcement example and be prepared to discuss by the next meeting. 5. Presentation by Steve Crocker (40 minutes) a. Presentation · This group is wrestling precisely the hard problems, but we are building tools that may be helpful. · An informal group, with no charter, no authority, and no funding has been meeting to discuss these issues. The members of the group have been asked not be named, and will be referred to as the Barbecue Group. · The basic intentions over time have been privacy vs. accuracy vs. efficiency. · GDPR has been like throwing dynamite into the logjam. It is a blunt instrument and does not provide detailed guidance. · BBQ is looking at all information - very wide spectrum from publicly available info (DNS records) to sensitive information (credit card info and account passwords). · This is intended to be descriptive, not prescriptive. · Policy flows from various authorities to contracted parties and registrants. · Data flows from the registrants through registrars and registries. · Then you have requests from various requestors. · When an individual registers a domain name, a lot of information is requested and that is the registrar policy. Some of that is determined by the registrar, but a lot of it is determined by the authorities it reports to. · .com and .info are subject to ICANN and GDPR · .cn is governed by national gov’t · The representation of the overhanging authorities is that they specify a set of policies. Registrars collect a lot of data internally that is not passed on to the registry. Registries may or may not leave it up to the registrar. · With an explicit representation of the policy sets and policies, it can point the inconsistencies and bring them to the surface. · Under collection and disclosure, the collection side of this is what data is collected starts with a dictionary of data elements - may include elements not in the Phase 1 report and what the purpose is of each data element. The policy defines whether the data element is required, optional, or forbidden. · On the disclosure side, typically, if you ask for the record related to a particular domain, the collection organization will give the record or not. This group is looking into the variation of this - public access, intermediate access, or law enforcement access. · Each data element has two sensitivity levels: disclosure level - public, if the disclosure level is above public, the acknowledgement level, which is no higher than the disclosure level · Slide 12 is a 100,000 foot level: the distinction b/w the blue and the green: the green is the policy of this particular organization (policy that the registrar has). The blue is the cumulative effect of a series of higher order authorities. · The account holder which is sometimes distinct from the registrant does not get mentioned in any of the policy issues. The registrar knows who the account holder is but that information is not typically passed to the registry. b. Q & A · Sensitivity levels of data/requests was mentioned earlier: sensitive data refers to categories of data in the GDPR. What does sensitivity of requests mean? · Answer: Registrar collects information, someone asks for the record - what they get depends on who they are and what they’re asking for. The requests are not down to “I want this data element but not this”. Instead, they ask for all of the data they can have based on who I am. The DNS records are public. Registrant contact information is sensitive, so there may be different levels of sensitivity. The other half of the question - who gets to see that, and who determines what their privilege is. That will not be determined within this framework. This framework focuses on decision processes. · A particular request would have a detailed request of what data elements are requested, and this was deemed unwieldy. · We require registrars to collect billing contacts - they do not use it for billing, and it is not published in WHOIS, yet we continue to insist that registrars collect that. Putting it all in the same place is helpful. · Is the work you presented funded in whole or in part from a third party or for the benefit of a third party? · Answer: There is no funding from a third party, and the benefit is for the internet. · Will the other BBQ participants disclose their identities? · Answer: It is not something that has been discussed that this time. · For a data request, you have to say who you are, what your legitimate interest, legal basis. · This is not intended to be a design that leads directly to implementation. It is a conceptual framework. It could include different kinds of requests that are below the level of discourse this group is handling. · How does the model take into consideration data flows that cross jurisdictions? · Answer: In some sense, the BBQ group is looking at a uniform picture of Rrs and Rts all over the world. Each Rr is controlled by one or more superior authorities. Can we lay out what the policy sets are for each of those groups. It is intended to apply equally to a ccTLD operating in Europe that is not subject to ICANN but is subject to GDPR and various national requirements. · Did this group do a data protection impact assessment (a DPIA)? Overcollection of data is classic overcollection, and if it still around anywhere (even data escrow), it has to be deleted. If you allow people or organizations to say do not release my data based on the sensitivity, but we have not done that yet. · Answer: This group has not performed a DPIA. · We have the TSG, the BBQ group, an announcement from PwC - question - how can we best synthesize all of these parallel tracks and proposals and synchronize them with the policy questions? · Answer: The other pieces are complementary. In terms of integration, that is a question to Janis. · This presentation is to stimulate the group’s thinking. 6. Any other business (5 minutes) a. Priority 2 small team meetings update Reminder - Call schedule remaining priority 2 worksheets: · Monday 17 June – 13:00 – 14:30 UTC Potential OCTO Purpose Feasibility of unique contacts to have a uniform anonymized email address · 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. * Confirm attendance for meeting on Thursday 20 June at 14.00 UTC · Confirmed - next meeting will be Thursday, 20 June at 14:00 UTC 7. Wrap and confirm next meeting to be scheduled for Thursday, 13 June at 14.00 UTC (5 minutes) * Confirm action items * Confirm questions for ICANN Org, if any