October 2018 - Gnso-epdp-team

Recordings, Attendance & AC chat from the GNSO Temp Spec gTLD RD EPDP held Thursday, 04 October 2018
by Andrea Glandon Oct. 4, 2018

Oct. 4, 2018

Dear all, Please find the attendance and AC chat attached to this email. The MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Thursday, 04 October 2018 at 13:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/KAWrBQ MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-04oct18… <https://urldefense.proofpoint.com/v2/url?u=https-3A__audio.icann.org_gnso_g…> AC Recording: https://participate.icann.org/p63f1t7bdy9/<https://participate.icann.org/p63f1t7bdy9/?OWASP_CSRFTOKEN=0d3562f1d64cdcdc…> ** Please let me know if your name has been left off the list ** Mailing list archives of the GNSO Temp Spec gTLD RD EPDP : https://mm.icann.org/pipermail/gnso-epdp-team/ Main wiki page for the working group: https://community.icann.org/x/IYEpBQ Thank you. Kind Regards, Andrea Glandon

1 0

Data minimization and use of technical/admin contacts
by Alan Greenberg Oct. 4, 2018

Oct. 4, 2018

I am sometimes amazed at our ability to debate issues where it is not warranted. We spend a significant amount of time on Tuesday on Tech and Admin contacts (both voice and a lot in the chat). Among other things, the principle of data minimization was sited. The EDPB letter of 05 July 2018 says: >The EDPB considers that registrants should in >principle not be required to provide personal data >directly identifying individual employees (or >third parties) fulfilling the administrative or technical >functions on behalf of the registrant. Instead, >registrants should be provided with the option of >providing contact details for persons other than >themselves if they wish to delegate these functions· >and facilitate direct communication with the >persons concerned. It should therefore be made clear, >as part of the registration process, that the >registrant is free to ( 1) designate the same person as the >registrant (or its representative) as the >administrative or technical contact; or (2) provide contact >information which does not directly identify the >administrative or technical contact person >concerned (e.g. admin @company.com). For the >avoidance of doubt, the EDPB recommends >explicitly clarifying this within future updates >of the Temporary Specification. We are told that in one case, 30% of registration done by resellers use those field for unique data. We know many legal persons do. If the EDPB is ok with such collection (with appropriate warnings), and many registrants use the fields, why do we need to re-debate it. Aren't there enough substantive issues to focus on? Alan

1 0

FW: EPDP questions for ICANN Org
by Caitlin Tubergen Oct. 4, 2018

Oct. 4, 2018

Dear All, Please find the data elements workbook for Purpose F attached. Thank you. Best regards, Marika, Berry and Caitlin On 10/3/18, 5:35 PM, "Trang Nguyen" <trang.nguyen(a)icann.org> wrote: Hi Marika, Caitlin, and Berry, Please see attached the completed purpose F workbook in word and pdf formats in response to question #6 below. As a reminder, Jennifer Scott from ICANN Contractual Compliance is available to join the EPDP Team call tomorrow to speak on behalf of ICANN Contractual Compliance. If you could, please send her a calendar invite for the call tomorrow when you have a chance. Thank you, Trang

1 0

Purpose N Worksheet
by Rosette, Kristina Oct. 4, 2018

Oct. 4, 2018

All, Attached please find a completed Purpose N worksheet in advance of our meeting tomorrow. K Kristina Rosette Senior Corporate Counsel, IP - Domains rosettek(a)amazon.com<mailto:rosettek@amazon.com> | 703.407.1354

1 0

Proposed Agenda - EPDP Team meeting #17
by Caitlin Tubergen Oct. 3, 2018

Oct. 3, 2018

Dear All, Please find below the proposed agenda for the next meeting of the EPDP Team, which is scheduled for Thursday, 4 October at 13.00 UTC. Best regards, Marika, Berry and Caitlin ================ EPDP Meeting #17 Agenda Thursday, 4 October 2018 Roll Call & SOI Updates Welcome and Updates from EPDP Team Chair Review data elements workbook for Purpose E (Ry Escrow, EBERO) Objective of discussion: (1) Review data elements workbook for purpose E as completed by registries (2) Agree on data elements needed for this purpose as well as responses to different questions in data elements workbook Review data elements workbook for purpose E Discuss any outstanding items / questions Finalize data elements workbook for purpose E Review data elements workbook for Purpose F (ICANN Compliance) Objective of discussion: (1) Review data elements workbook for purpose F as completed by ICANN org (2) Agree on data elements needed for this purpose as well as responses to different questions in data elements workbook Review data elements workbook for purpose F Discuss any outstanding items / questions Finalize data elements workbook for purpose F Review data elements workbook for Purpose N (registry eligibility requirements) Objective of discussion: (1) Review data elements workbook for purpose N as completed by registries (2) Agree on data elements needed for this purpose as well as responses to different questions in data elements workbook Review data elements workbook for purpose N Discuss any outstanding items / questions Finalize data elements workbook for purpose N Review data elements workbook for new purpose (research) Objective of discussion: (1) Review data elements workbook for research purpose as completed by Benedict/Farzaneh (2) Agree on data elements needed for this purpose as well as responses to different questions in data elements workbook Review data elements workbook for research purpose Discuss any outstanding items / questions Finalize data elements workbook for research purpose Wrap and confirm next meeting to be scheduled for Tuesday, 9 October at 13.00 UTC. Confirm action items Confirm questions for ICANN Org, if any

1 0

Recordings, Attendance & AC chat from the GNSO Temp Spec gTLD RD EPDP Small Team Meeting #1 held Wednesday, 03 October 2018
by Andrea Glandon Oct. 3, 2018

Oct. 3, 2018

Dear all, Please find the attendance and AC chat attached to this email. The MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP Small Team #1 call held on Wednesday, 03 October 2018 at 13:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/6gO8BQ MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-03oct18… <https://urldefense.proofpoint.com/v2/url?u=https-3A__audio.icann.org_gnso_g…> AC Recording: https://participate.icann.org/p3oxdr97dvi/<https://participate.icann.org/p3oxdr97dvi/?OWASP_CSRFTOKEN=0d3562f1d64cdcdc…> ** Please let me know if your name has been left off the list ** Mailing list archives of the GNSO Temp Spec gTLD RD EPDP : https://mm.icann.org/pipermail/gnso-epdp-team/ Main wiki page for the working group: https://community.icann.org/x/IYEpBQ Thank you. Kind Regards, Andrea Glandon

1 0

Notes and action items from small team #1 meeting
by Marika Konings Oct. 3, 2018

Oct. 3, 2018

Dear All, For your information, please find below the notes and action items of small team #1 which met earlier today to discuss: h) Applicability of Data Processing Requirements h3) Should Contracted Parties be allowed or required to treat legal and natural persons differently, and what mechanism is needed to ensure reliable determination of status? h4) Is there a legal basis for Contracted Parties to treat legal and natural persons differently? h5) What are the risks associated with differentiation of registrant status as legal or natural persons across multiple jurisdictions? (See EDPB letter of 5 July 2018). Best regards, Caitlin, Berry and Marika Small Team #1 Meeting Wednesday, 4 October 2018 Notes and Action Items High-level Notes/Actions: Action item #1: Staff to put the possible draft recommendation up as a google doc and provide editing rights to the small team to further refine the language. Action item #2: Small team to review and refine language by Friday 5 October COB. Following that take it back to the EPDP Team for input and consideration (early next week). 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. Roll Call & SOI Updates (5 minutes) * Attendance will be taken from Adobe Connect - attendees: Alex Deacon (IPC), Ben Butler (SSAC), David Plumb (CBI), Gina Bartlett (CBI), James Bladel (RrSG), Marc Anderson (RySG), Margie Milam (BC), Laureen Kapin (GAC), Stephanie Perrin (NCSG) * 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. h) Applicability of Data Processing Requirements h3) Should Contracted Parties be allowed or required to treat legal and natural persons differently, and what mechanism is needed to ensure reliable determination of status? h4) Is there a legal basis for Contracted Parties to treat legal and natural persons differently? h5) What are the risks associated with differentiation of registrant status as legal or natural persons across multiple jurisdictions? (See EDPB letter of 5 July 2018). * See background document that was shared. * Initial input on charter questions: * Margie/BC: GDPR does not apply to legal persons. Has a large impact on records that are redacted. It is reasonable to make distinction and can be done through self-designation - this is already done in a ccTLD context and some gTLDs (for example, .NYC has filed an RSEP to allow for this). Consider step in process flow for registration to allow for self-designation and explain what difference between legal / natural person is and its implications, as well as obtain consent for including any personal information. Legal persons are usually engaged in commercial activity so it also links to other areas such as consumer protection. * James / RrSG: Agree with a number of Margie's point. Need to do a better job at distinguishing between legal / natural person. Field current used is registrant organization, but this is overloaded and a bit of a mess. This EPDP could recommend contracted parties to distinguish between the two. Guidance from EDPB did note that even for registration for a legal person personal data could be provided, which makes it more complicated. Other privacy legislation, like e-privacy, does not distinguish between natural and legal person, so any recommendation made needs to be future proof Should contracted parties be allowed: YES, should they be required: NO. Does not scale to require this. * Marc/RySG: Agree with a number of the previous points. Jurisdictional challenges need to be considered. Need flexibility to deal with different requirements in different jurisdictions. The organization field could be used, but it has never been used to differentiate between natural and legal person. Have a huge existing base of existing registrations where it is not easy to say whether it concerns a natural or legal person - backfilling requirement would be problematic and not an easy lift. * Alex / IPC: sounds like there is a path forward as many agrees that there is a need to distinguish. May disagree on whether this should required. Legal persons should be encouraged to not use personal information when providing contact information. Need to provide information about the purposes. Consent should be an avenue. GDPR also provides for ability to correct information. * Laureen / GAC: Effort has been focused on GDPR and future proofing, but reality is that we can never anticipate the contours of future privacy laws. Need to focus on current landscape which does distinguish between natural and legal person and as such would have preference for requirement. But would be willing to explore how communication is going out to existing customers - is there a way to leverage and inform customer base about difference and how to update? As well as recommend not using personal information. Could have requirement for going forward, but have flexibility for retroactive application. Additional comments: * Changes to systems are inevitable - could discuss staging of implementation, for example, initially only requirement to new registrations and deal later on with existing registrations, for example through annual WHOIS notice. Explore how this could be done in a phased process. * Regarding distinction between legal/natural using the "Registrant Org" field is not optimal. Could consider using it but it would be "a hack". As such would prefer something more specific here. Should have clear data fields that asks what type of registration is this (for individual/ natural person, or business/legal entity. In the latter case, you could even ask for further information like in what type of legal entity and in which legal jurisdiction. * Agree that this needs to change, but devil will be in the details. Caution again interfaces, need to keep it general and allow for implementers to suit the circumstances. * Annual WHOIS notices are result of existing policy. Is a challenge - to get anywhere above 10% participation. * Everyone seems to agree that there should be a way to distinguish between legal and natural persons. May need to have some flexibility. * What mechanisms might work? Having certain data fields? Annual WHOIS notices may be less successful? What other mechanisms could be recommended to be responsive to this? Should probably look at what recommended additional data fields in RDDS would need to be captured, for example, registrant type / status. Based on what type of registrant is identified, it would pivot to the type of information that is collected. For a legal entity, it would include title of person who would be the contact, opposed to the name. * In ideal world, this would apply from a point in the future, and at the time of renewal convert old registrations to this new system. * What policy recommendations do we want to make to the full EPDP Team to achieve the desired goal? Let's focus on what can be said. * Possible policy recommendations: Further work to continue to consider this issue, there should be a follow on effort convening a group that would look at the operational issues with restructuring RDDS to distinguish between legal and natural person, collect this information reliable at registration and renewal, and how this could be enforced eventually by ICANN. * Need to be aware of limitations of what can be done within this EPDP. * Detail and timing of implementation is definitely another phase, but could define the policy requirements /goals now in the EPDP. Understand that implementation could take some time, but important to get a commitment on the policy recommendations to distinguish between legal and natural person. * Is there agreement to have a requirement to distinguish between natural and legal person, provided that the implementation process is satisfactory? * Should be high level recommendation in this EPDP that would kick off implementation work - it is desirable / necessary to make this distinction in WHOIS, need to look at the operational options and build an implementation plan to make this happen going forward as well as looking at it retroactively. Extended period of time may be needed to implement this in practice. * Require registrars to ask the question, yes, require registries to put this in their systems, yes, require registrants to answer truthfully, and understand the difference - probably more complicated. Who would be accountable if registrant gets this wrong? * Can agree in principle (desirable to differentiate), but implementation would require much more detail. Would be aspirational, not necessarily implementable. * What would be high level language to puts a bit more * There is rough consensus around the idea that capturing this distinction and making it available is necessary. Principle 2: Rys/Rrs/ICANN should make training/educational resources available to registrants that help registrants understand the distinction b/w a DN that is registered by a natural person and a legal person (since the majority of people do not understand). Third principle: look at what changes would be necessary in terms of the data fields that are defined and collected in WHOIS or successor RDS system and how they differ depending on how a Rt categorizes itself. Fourth - set future date whereby all registrants would be subject to this framework, and a future, future date where transfers and renewals would be subject to this framework. * Could ask staff to start investigating how ccTLDs do this – no need to recreate the wheel if this is already successfully implemented, especially since many registrars also sell those names. * Charter Question 4 - is there a legal basis for this distinction? * Yes, based on GDPR. * Yes, GDPR makes this distinction, though it is not a blanket distinction. Generally, there is utility in making this distinction. * Yes within the GDPR, though this is complicated. Proposal: to get around this problem - corporations are large entities that want to provide data and have an identity theft problem - there should be an authentication required. Rights are protected in the GDPR in the charter for vulnerable groups (journalistic associations, etc.) - it's difficult to distinguish the categories of those groups. It's easier to filter out the big corporations rather than try to distinguish the smaller entities. * Important to remember the contentious debate b/w commercial and noncommercial websites - this was not about legal and natural persons. This is related, but separate. * Possible draft recommendation: * EPDP Team recommends that: * Distinction between legal and natural persons is necessary and useful. * Contracted parties, in consultation with others interested parties, will recommend which data fields must be added to accomplish this distinction. * Registries, registrars, ICANN should make (educational) resources available that help registrants understand the distinction between a domain name that is registered by a natural person vs. legal person / entity. (educational resources) * Follow-on work to this EPDP will determine the timing of implementation phases. * Consultation with ccTLDs will be helpful in implementation. That consultation should begin now. * Good start. Take this back to the full group. More work to do. * Does not capture the agreement that it would be a requirement for new registrants, but for legacy registrations it would be phased in. Timing between the two would need to be captured further. * Add notes section so that additional comments can be made included. * Small group to review and modify language by Sunday COB with the objective to circulate this early next week. Action item #1: Staff to put the possible draft recommendation up as a google doc and provide editing rights to the small team to further refine the language. Action item #2: Small team to review and refine language by Friday 5 October COB. Following that take it back to the EPDP Team for input and consideration. Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

1 0

FW: EPDP questions for ICANN Org
by Caitlin Tubergen Oct. 3, 2018

Oct. 3, 2018

Dear All, Below, please find the recent EPDP questions and answers from ICANN Org. Thank you. Best regards, Marika, Berry and Caitlin ** QUESTION: With respect to ICANN’s references to dispute resolution policies within the Temporary Specification, is there a reason only the URS and UDRP were included and not other dispute resolution procedures such as RDDRP, PDDRP and PICDRP? RESPONSE: The RDDRP, PDDRP, and PICDRP <https://newgtlds.icann.org/en/program-status/pddrp> are dispute resolution procedures where the gTLD registry operators themselves are the respondents. Under the Registrar Transfer Dispute Resolution Policy <https://www.icann.org/resources/pages/tdrp-2016-06-01-en> the respondents are registrars. This is different from URS and UDRP proceedings where individual domain registrants are the respondents. (Note: gTLD registry agreements may also contain other dispute resolution procedures, for example, .NAME has an “Eligibility Requirements Dispute Resolution Policy” <https://www.icann.org/resources/pages/appendix-11-2013-07-08-en>.) QUESTION: With respect to data retention: For how long and why, should data escrow agents retain old deposits (if at all) in order to fulfill their contractually-required obligations? For how long and why, should data be retained by registries and registrars from the perspective of ICANN Org for purpose A (Establish the rights of a Registered Name Holder in a Registered Name and ensuring that the Registered Name Holder may exercise its rights in respect of the Registered Name)? RESPONSE: Under the Registrar Data Escrow Specification deposits older than one year must be destroyed, unless a longer period is agreed to by the registrar and the escrow agent. Also, under the base agreement for new gTLDs each escrow deposit must be kept for one year. Legacy gTLD agreements vary; for example the .ASIA, .BIZ, .INFO, and .ORG agreements specify that at least four weeks of deposits must be kept. The purpose of safeguarding a set of prior deposits is to protect registrants in the event a registry or registrar fails or is terminated and the database needs to be reconstituted. In situations where the registration database has to be reconstituted and deposits have not been made in a number of months, safeguarding multiple deposits increases the likelihood that at least one reliable deposit will be available. Also, having multiple deposits increases the likelihood that a reliable deposit is available in the event that the compliance/termination process is contested by the registry operator or registrar. Perhaps registry operators and registrars with operational experience could provide input as to how far back deposits should be kept to ensure that registration databases can be reconstituted when needed. QUESTION: Apart from ICANN Org Compliance, do any other ICANN departments require access to registration data and, as such, might require a specific purpose? If so, please describe in detail sufficient to provide a legal basis for such data processing. RESPONSE: This question seems to be asking about any use by ICANN Org of registration data that is now masked pursuant to the Temporary Specification. One example of an ICANN Org activity that previously used WHOIS data elements that may now be redacted pursuant to the Temporary Specification is the WHOIS Accuracy Reporting System, which is currently under review as discussed with the EPDP Team on 26 September 2018. If additional information is needed it would be helpful if the EPDP Team could please clarify if the question is for information related to such past uses of now-masked registration data, or to any current ICANN Org (apart from Contractual Compliance) uses of non-public data, or to any future uses of non-public registration data that may be needed in order to implement GNSO-recommended policies. Also, in discussions that the EPDP Team has had regarding purposes, ICANN Office of the CTO (OCTO) has been mentioned. To inform the EPDP Team’s continued discussion on this topic, ICANN Org would like to clarify that ICANN OCTO does not require personal data in domain name registration data for its work. For example, OCTO’s Domain Abuse Activity Reporting (DAAR) project <https://www.icann.org/octo-ssr/daar> uses only the registrar and nameserver information. QUESTION: ICANN Org to provide EPDP Team with copy of agreements with UDRP/URS providers in to demonstrate GDPR compliance in relation to data protection / transfer of data including relevant data protection policies that dispute resolution providers have in place. RESPONSE: ICANN has used Memoranda of Understanding to govern the relationship with each of the selected URS providers, in which each of the URS providers agree to implement the URS services in accordance with the procedures laid out in the New gTLD Applicant Guidebook, as they might be amended from time to time. Copies of the MOUs are available here: https://newgtlds.icann.org/en/applicants/urs. ICANN does not have agreements or MOUs with UDRP providers. Additional discussion on why ICANN has taken this approach with UDRP providers is available here: https://www.icann.org/en/system/files/files/uniformity-process-19jul13-en.p…. In light of the recent changes in data protection laws and the requirements in the Temporary Specification requiring contracted parties to give full registration data to the dispute resolution providers when presented with a complaint if the contact details are not published in WHOIS, ICANN is in discussions with the dispute resolution providers to more fully understand the safeguards they have put in place for the processing of personal data. For example, WIPO has updated its FAQ page concerning the GDPR as it relates to the UDRP: http://www.wipo.int/amc/en/domains/gdpr/, and other providers have reviewed/are in the process of reviewing their supplemental rules in light of changes in privacy laws. ICANN will publish any updates to a provider’s supplemental rules on its website.

1 0

First draft of Initial Report Section on charter questions and preliminary recommendations
by Marika Konings Oct. 3, 2018

Oct. 3, 2018

Dear All, As discussed during the LA F2F meeting, staff has taken a first stab at developing the draft section of the Initial Report that would cover the EPDPP Team’s responses to the charter questions as well as preliminary recommendations. You can view this first draft here: https://docs.google.com/document/d/10VIcHv1NqdVHZbAlhxuEZFi1f__UP-m7PU5P_aJ…. Highlighted in yellow are those areas that will require updating following the EPDP Team’s completion of work on the data elements workbooks. Highlighted in blue are those areas that require further deliberation before a response / preliminary recommendations can be drafted (these areas have also been called out in the meeting planning document). To facilitate any input or edits you may want to provide, staff has created a separate google doc organized by charter question which you can use to start providing your feedback. See https://docs.google.com/document/d/1SoNTnvvadNQ8nX_-OxN4mtsd-gfLNxT54GXSXyG…. Note that it is staff’s intent to update the draft section of the Initial Report on an ongoing basis as deliberations continue so you are able to track what updates are being made as a result of the EPDP Team’s efforts. We look forward to receiving your feedback. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

1 0

Notes & action items from today's meeting
by Marika Konings Oct. 3, 2018

Oct. 3, 2018

Dear All, Please find below the notes and action items from today’s meeting. In order to facilitate the signing up for the small teams, please use the following link https://docs.google.com/document/d/1ChEYy-cZmT3qTD62-HsoVmddD96m6cbkSOv5dmA…. As a reminder, please self-organize and assign max. 1 member from each group per small team. Call details will be sent to all, but only designated members are expected to attend (view only AC will be available for others interested to follow the deliberations). Best regards, Caitlin, Berry and Marika ============= EPDP Team Meeting #16 Tuesday, 2 October 2018 Notes and Action Items High-level Notes/Actions: Action item #1: add to Purpose C a second processing activity that is focused on disclosure of technical contacts to third parties t to communicate or notify RNH of technical and/or administrative issues (third parties 6.1(f)). Action item #2: Regarding the Legal Basis document, RySG to provide additional data processing steps by Wednesday 3 October COB. Action item #3: EPDP Team to review lawful basis memo and proposed designations for each purpose and processing activity and communicate by Wednesday COB any objections to the proposed designations Action item #4: Leadership to develop methodology to be developed to further consider idea of ICANN having direct contract with registrants. Action item #5: Alan Greenberg to write statement why optional provision of admin/tech contact is important. Action item #6: EPDP Team to review planning and schedule and share any feedback on the list. Questions for ICANN Org from the EPDP Team: None 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. Roll Call & SOI Updates (5 minutes) * 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 (5 minutes) * Recap EPDP Team F2F meeting - see high level notes circulated and posted on the wiki (https://community.icann.org/x/rQarBQ) Feedback welcome on what worked well and what didn't. * Meeting schedule going forward - to be discussed under item 5 on the agenda. * Review of outstanding action items - see https://community.icann.org/x/NwSNBQ * Other updates, if applicable 3. Legal basis for purposes and related processing activities Objective of discussion: (1) Agree on legal basis for different purposes and related processing activities a) Review legal basis memo outlining how to differentiate between Art 6.1(b) and Art 6.1(f) and discuss how this can be applied to purposes identified and related processing activities b) Agree on legal basis for purposes and related processing activities * See memo that was circulated prior to this meeting * Lawful test designed by Thomas facilitated the discussions but there was still confusion around what it means "necessary for performance of a contract" * Example found from the UK Information Commissioner's Office - processing must be necessary for the delivery of your part of the contract. If the processing is only necessary to maintain your business model more generally, this lawful basis will not apply. * Lawful test in combination with example applies to the EPDP Team purposes. Highlighted in blue is where small team came to agreement on lawful basis, those in orange, based on leadership team assessment. * For purpose A, does this just concern data for WHOIS or is it broader than that - this is focused on the data that is collected by the registrar, regardless of where it is. * Purpose C - focused on registrar communication, but this is mainly for other parties, why is that not included? If it is for other parties, the lawful basis would be 6.1(f). Add second processing activity focused on third parties (6.1(f)). May also be captured under purpose B? * May need to distinguish between what is collected and what goes into an RDDS? For example, in relation to Purpose N. Purpose N not limited to Spec 13, would also include Spec 12 gTLDs. Policy recommendations to cover the circumstances and purposes through which additional data elements are collected, even if those are not published or disclosed through RDDS. * In Purpose A, is a processing activity missing? Responding to requests from Registered Name Holder for purpose A. Should RNH be mentioned as a separate party? RNH is the data subject. * For Purpose A, transmission of registration data - why is this both 6.1(b) and 6.1(f) - isn't protecting against abuse a necessary part of the contract? * For Purpose E, isn't this also 6.1(b) as it is part of the broader requirements? Small team discussed what would present best case for success presenting this to DPAs and agreed on 6.1(f). * BC would support ICANN Org having a direct relationship with registrant to allow for 6.1(b) if this is currently prevented because ICANN does not have a direct contractual relationship with registrants. * For purpose F, why not 6.1(b)? In theory you could abolish contractual compliance and domain name registration would still work, hence 6.1(f) argument. * Need additional processing activity in M for party that files complaint and needs access to information. Needs to be further considered. * Helpful way to lay this out visually, makes it easier to understand. Groups need a bit more time to review and comment. * EPDP Team to review memo and especially link to CIO web-site. * Also note that there where disagreement may persist, this could be called out in the Initial Report as a question for which specific input is requested especially from DPAs. Action item #1: add to Purpose C a second processing activity that is focused on disclosure of technical contacts to third parties access to this information to communicate or notify RNH of technical and/or administrative issues (third parties 6.1(f)). Action item #2: Regarding the Lawful Basis document, RySG to provide additional data processing steps EPDP Team to review this document and come back with feedback by Wednesday 3 October COB. Action item #3: EPDP Team to review Lawful Basis memo and proposed designations for each purpose and processing activity and communicate by Wednesday COB any objections to the proposed designations Action item #4: Leadership to develop methodology to be developed Small team to further consider idea of ICANN having direct contract with registrants. 4. Review data elements workbook for purpose C - Enable communication or notification to the Registered Name Holder and/or their delegated parties of technical and/or administrative issues with a Registered Name (see https://community.icann.org/x/5AC8BQ) Objective of discussion: (1) Review data elements workbook for purpose C as completed by small team during LA F2F meeting (2) Agree on data elements needed for this purpose as well as responses to different questions in data elements workbook a) Review data elements workbook for purpose C b) Discuss any outstanding items / questions c) Finalize data elements workbook for purpose C * See data elements workbook for purpose C (see https://community.icann.org/x/5AC8BQ) * Mandatory fields to be collected under 6.1b, optional fields to be collected under 6.1(a) - consent. * What does optional mean? If no admin/tech contact info is provided, does it then default back to the registrant information? * If admin/tech contact info is provided, consent will need to be provided by the admin/tech contact. * If there is no reason to collect the data, would it go against the principle of data minimisation? Is option that is provided to RNH, only those that want to make use of this would opt for it, not a requirement. * In practice it is often a duplicate and no unique information is provided. * You could define two different products: 1 where the registrant acts for all contacts 2 where he / she wishes to designate additional contacts. In such case, both could be 6 I b and collection of third party that would occur based on Art. 14. * Why is making it an optional field problematic? As no one is required to do anything? Under GDPR you will still need to explain why data is collected. Action item #5: Alan Greenberg to write statement why optional provision of admin/tech contact is important. 5. Share list of outstanding issues and plan for addressing these * See planning document circulated prior to the meeting * How to sign up for small groups? Groups expected to self-organize - ideally max. 1 rep per group. Could use google doc to have an idea of attendance. Action item #6: EPDP Team to review planning and schedule and share any feedback on the list. 6. Wrap and confirm next meeting to be scheduled for Thursday 4 October at 13.00 UTC. a) Confirm action items b) Confirm questions for ICANN Org, if any Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

2 2