- Gnso-epdp-team - lists.icann.org

Proposed agenda - EPDP Phase 2A Meeting #20 - 6 May 2021
by Caitlin Tubergen May 4, 2021

May 4, 2021

Dear EPDP Team, Please find below the proposed agenda for Thursday’s meeting. Best regards, Berry, Marika, and Caitlin -- EPDP Phase 2A - Meeting #20 Proposed Agenda Thursday 6 May 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Legal vs. natural (60 minutes) 1. Whether any updates are required to the EPDP Phase 1 recommendation on this topic (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so“); 2. What guidance, if any, can be provided to Registrars and/or Registries who differentiate between registrations of legal and natural persons. Bird & Bird Response to Question #3<https://community.icann.org/download/attachments/155191493/ICANN%20EDPB%202…> * High level overview (Becky) * EPDP Team to consider whether any aspects of the response warrant changes to the latest version of the write up or further consideration. * Confirm next steps Guidance write up * Consider remaining outstanding questions: Guidance #3 - As part of the implementation, Registrars should consider using a type of Example scenarios (note, these scenarios are intended to be illustrations for how a Registrar could apply the guidance above. These scenarios are NOT to be considered guidance in and of itself). 1. EPDP Team to consider whether or not these scenarios should remain or whether they should be replaced by the RrSG table as suggested by ALAC. If there is agreement that scenarios should remain as examples, EPDP Team to consider whether scenario #3 (Registrar determines type based on data provided) should remain as some concerns have been expressed by NCSG in relation to the Registrar making an initial assessment about whether or not the registrant is a legal or a natural person. Note, updates were made to ensure that the Registrant is requested to confirm this assessment. Scenario #2 - Data subject self-identification at time when registration is updated a. The Registrar collects Registration Data and provisionally redacts the data. b. The Registrar informs the Registrant (per guidance #3 above) and requests the Registrant (data subject) to designate legal or natural person type. The Registrar must also request the Registrant to confirm whether only non-personal data is provided for legal person type.[1] c. Registrant (data subject) indicates legal or natural person type and whether or not the registration contains personal information after registration is completed. For example, the Registrant may confirm person type at the time of initial data verification, in response to its receipt of the Whois data reminder email for existing registrations, or through a separate notice requesting self-identification.[2] d. If the data subject identifies as a legal person and confirms that the registration data does not include personal data, the Registrar should (i) contact the provided contact details to verify the Registrant claim[3] (ii) set the registration data set to automated disclosure in response to SSAD queries and (iii) publish the data. 2. The GAC has suggested that it might be helpful to add some timelines to this scenario. How could/should such a timeline look? Registrars shall not be prohibited from voluntarily utilizing a third party to verify that a registrant has correctly identified its data[4], provided that such verification is compliant with applicable data protection regulations. 3. Proposed language changes from Volker were applied to make clear that third party verification is not disallowed, but neither specifically recommended. NCSG has noted its objection to this rewrite as it would make scenario 3 ten times worse. EPDP Team to consider concerns and determine if/how these can be addressed. Note, the Bird & Bird advice specifically talks about the option to verify information provided by the registrant. 4. Homework assignments reminder (5 minutes) · By Friday 7 May, EPDP Team to review proposed feasibility of unique contacts write up for Initial Report<https://docs.google.com/document/d/1uA_gEGmfyokKOP0Xft7q__RXVK1Ns_IXzSRoPKu…>. Please provide comments, suggestions and proposed edits in the form of comments. · By Friday 7 May, EPDP Team to review updated version<https://docs.google.com/document/d/1tbk4x7LDzqAazO2ABzjPPkR3gsPcPuBSrECQRpg…> of legal/natural guidance write up and indicate which aspects, if any, your group cannot live with for inclusion in the Initial Report. · By Friday 7 May, GAC and RrSG Team to review updated version<https://docs.google.com/document/d/1tbk4x7LDzqAazO2ABzjPPkR3gsPcPuBSrECQRpg…> of write up and to indicate to EPDP Team if GAC updated proposal and RrSG table, respectively, need to be included, where it would be included and what aspects it would cover that are currently not addressed in the write up. Please provide your response via the mailing list. 5. Wrap and confirm next EPDP Team meeting (5 minutes): 1. EPDP Team Meeting #21 Tuesday 11 May at 14.00 UTC 2. Confirm action items 1. Confirm questions for ICANN Org, if any ________________________________ [1] Note that the confirmation that only non-personal data is provided could also happen at a later point in time. However, until the Registrant confirms that no personal data is present in the registration data, the Registrar does not set the registration data to automated disclosure. [2] Note, the implementation of EPDP Phase 1, recommendation #12 (Organization Field) may facilitate the process of self-identification. [3] Per the guidance<https://community.icann.org/download/attachments/155191493/ICANN%20-%20EPDP…> provided by Bird & Bird, “this verification method is advisable, and will help reduce risk. That risk reduction will be greatest if there is a reasonable grace period within which the objection can be lodged, before the data in question is published in the Registration Data” and “requiring an affirmative response to verification mailings seems over-cautious, unless and until studies show that the measures adopted are failing to keep very substantial amounts of personal data out of published Registration Data. However, if a verification email “bounces” (i.e. a Contracting Party knows it was not delivered), then it would be better if publication does not proceed”. [4] Per the guidance<https://community.icann.org/download/attachments/155191493/ICANN%20-%20EPDP…> provided by Bird & Bird, “a company registration number may be another means of verifying legal personhood”.

1 0

Notes and action items - EPDP Phase 2A Meeting #19 - 4 May 2020
by Caitlin Tubergen May 4, 2021

May 4, 2021

Dear EPDP Team, Please find below the notes and action items<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8Ad…> from today’s meeting. The next EPDP Phase 2A meeting will be Thursday, 6 May at 14:00 UTC. Best regards, Berry, Marika, and Caitlin -- 🚨🚨🚨🚨 Action Items 🚨🚨🚨🚨 Please refer to the project spreadsheet<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8Ad…> for action items. EPDP Phase 2A - Meeting #19 Proposed Agenda Tuesday 4 May 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Feasibility of unique contacts (30 minutes) 1. Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement. 2. If feasible, but not a requirement, what guidance, if any, can be provided to Contracted Parties who may want to implement uniform anonymized email addresses. * Review input received (groups that provided input to provide high level overview of their input – BC, RrSG, SSAC) * BC: Established that the creation of pseudonymous email addresses is technically feasible. BC believes this should be a requirement because it is a privacy-enhancing technology. The pseudonyms can be used for a variety of purposes, including contacting people. Webforms are not an ideal way to contact people because receipt is unclear and there are often character limits. Also, pseudonyms would help with correlation. For these benefits, creating these should be a requirement, and this group should work on refining the associated policy requirements. * RrSG: Acknowledge that it is technically feasible, but there are risks not only to the registrar, but also to the domain owner. There could be spam messages, and correlation could reveal sensitive information. The webform is sufficient. Have heard that webforms are insufficient – it may be helpful to includes more rules around webforms, but this does not mean they are not fit for purpose. Even having an email does not equate to mandatory responses. * SSAC: Uncomfortable with the idea of pseudonymous email addresses – do not know that it is safe and appropriate to do this. An alternate way to do the correlation is to have a trusted service and ask how many of these domain names are related to each other and have the service be able to do this. This would allow more control over evolution. There are better ways to accomplish this and trying to impose a pseudonymous algorithm on everyone is not the ideal way to move forward. * GAC: Uniform anonymized email is feasible but it has to be tempered with sufficient safeguards. Appreciate the concerns raised by other stakeholder groups with the current system – there are currently no safeguards baked in to make sure that the webform reaches the registrant and promotes a response. One concern is that there needs to be sufficient safeguards to protect the data. One scenario that comes to mind is registrars who use pseudonymized email addresses in privacy/proxy dealings. It may be helpful to know what functionality these services get. * ALAC: We have enough evidence that webforms as they are used today do not work. If we wanted to write rules for what webforms are supposed to do, we could, but not sure we are going to do that in this group. While you cannot guarantee that an email is read, but you can be sure it’s sent to a valid email box, which you cannot do with a webform. ALAC strongly supports pseudonymized email addresses. * Team has had multiple conversations on the topic of webforms. Remind the Team that if there are challenges with webforms, that should be dealt with in relation to the implementation of Phase I recommendations through the IRT or through ICANN compliance. * Cannot rely on an IRT to impose rules about webforms. If we had a new policy saying you can use webforms, but the details of what you can include must be set for the IRT. This is out of scope for an IRT. If an email is sent by forwarding or if a webform bounces, this is not relayed back to a requestor. If the registrar receives proof that the message was not delivered, this should be communicated to the requestor. * The question of whether an email address should be a requirement is being addressed in part because there is no other way to contact the registrant. The failure of webforms is evidence that this should be a requirement. * In Rec. 13 from Phase 1 is designed specifically to meet Purpose 3 – enable communication with the registered name holder. Many concerns raised note that there is no way to show that the relay has occurred. The Team discussed this in Phase 1, which is why logging of the relay is required. * IPC: remind that the B&B memo noted that the risks are low. The purpose of making this available is contactability and correlation. The UDRP gives complainants the opportunity to show a pattern of bad faith registrations. We need to find the correct balance between what can be disclosed but ensuring that pre-existing policies are still able to function properly. * Establishing a pattern of bad faith is not necessary for success in a UDRP case. * This group is conflating anonymized/pseudonymized email addresses with what is in WHOIS; these emails could be provided via the SSAD * NCSG: No further changes are needed. The claim of necessity for correlation of email addresses – simply because this was used does not make it lawful. Webforms are sufficient to contact the registrant. * ISPCP: Are pseudonymized emails desirable? No, because of risks with reverse-engineering. The purpose of processing is for contacting the registrant, and this can be achieved via webforms. Need to follow the principle of privacy by design. If the group chose to require email addresses, would recommend this is per domain name, not per registrant. Would further recommend that the per domain name email be rotated. * RySG: Contactability and correlation appear to be the two goals. In both of these cases, this is not the best way of achieving either of these goals. For contactability, Rec. 13 from Phase 1 should be sufficient. With respect to correlation, this does not seem to be a good way of achieving that goal as it creates additional risk and effort for contracted parties. * Members keep conflating anonymized and pseudonymized with reverse engineering – particularly via the SSAD. * Understand that one of the reasons why groups are pursing this as a path forward is to have the ability to correlate. This was made clear in the IPC comments. Believe what was said is to take efforts to prevent correlation. * Do not believe an IRT can set rules for webforms. Answer is nuanced because we need something better than what we have today. * If the Team can agree on the contactability point and use this as a starting point, perhaps we could build on that. * There does not appear to be consensus around if this should be a requirement. The Team may wish to consider what type of guidance could be provided. The Team could also provide guidance to the Phase 1 IRT regarding webforms/email addresses. The Team should consider the path forward. * In thinking about proportionality, if you think about RDS data fields, the email address is the least likely to be personal data, but we know that email addresses are free of charge and made up of any string of characters. Guidance we could give – tell registrants not to put personal data in their email address. * Seems to be the assumption that real registration data would be disclosed via the SSAD * Walk through of staff proposed write up of Initial Report text * Confirm next steps – proposed deadline for comments / suggestions / proposed edits Friday 7 May 2021 4. Legal vs. natural (45 minutes) 1. Whether any updates are required to the EPDP Phase 1 recommendation on this topic (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so“); 2. What guidance, if any, can be provided to Registrars and/or Registries who differentiate between registrations of legal and natural persons. Guidance write up * Consider outstanding questions: Guidance #3 - As part of the implementation, Registrars should consider using a type of flag in the RDDS or their own data sets that would indicate the type of data it concerns (personal or non-personal data) as this could facilitate review of disclosure requests via SSAD and the return of non-personal data of legal persons by systems other than SSAD (such as Whois or RDAP). A flagging mechanism could also assist in indicating changes to the type of data in the registration data field(s). 1. ALAC has suggested that more specificity should be provided to Registrars about how this implementation could work especially in relation to how a ‘flag’ could be applied. Would it be helpful to provide further guidance on how this could be implemented or does that make it too prescriptive? The current guidance already includes references to the use of a type of flag – what is missing that would be helpful for Registrars to know? * Contracted parties will have to do this already under Phase 2. Maybe we note that CPs will have to flag data one way or the other in their systems. * Follow-up question for ALAC – what does this suggestion mean in terms of implementation. If we are talking about a flag in the registrar’s system to indicate if there is personal or non-personal data, that would not be a flag in the RDDS. RDDS systems are generally query systems. Are you instead looking for an indication in the response to an RDDS query? The mention of a flag in confusing in this context. What is ALAC hoping to accomplish with this guidance? * The difference b/w a registrar field and an RDDS field is that one is just for a registrar, the other is not. Having a defined field in the RDDS is important because this conveys a lot of information that is completely lost in the registrar system. Believe this should be a public field. * Proposing three types of fields – differentiate b/w legal and natural registrants. The other fields differentiates b/w personal and non-personal data and one for protected and unprotected data. This is important across registries and registrars. * This is based on assumption that because it works at the registrar level, it will work at the registry level. Registry has an obligation to have a means of testing flags of every registrar. This is an extreme factor of complexity. Example scenarios (note, these scenarios are intended to be illustrations for how a Registrar could apply the guidance above. These scenarios are NOT to be considered guidance in and of itself). 2. EPDP Team to consider whether or not these scenarios should remain or whether they should be replaced by the RrSG table as suggested by ALAC. If there is agreement that scenarios should remain as examples, EPDP Team to consider whether scenario #3 (Registrar determines type based on data provided) should remain as some concerns have been expressed by NCSG in relation to the Registrar making an initial assessment about whether or not the registrant is a legal or a natural person. Note, updates were made to ensure that the Registrant is requested to confirm this assessment. Scenario #2 - Data subject self-identification at time when registration is updated a. The Registrar collects Registration Data and provisionally redacts the data. b. The Registrar informs the Registrant (per guidance #3 above) and requests the Registrant (data subject) to designate legal or natural person type. The Registrar must also request the Registrant to confirm whether only non-personal data is provided for legal person type.[1] c. Registrant (data subject) indicates legal or natural person type and whether or not the registration contains personal information after registration is completed. For example, the Registrant may confirm person type at the time of initial data verification, in response to its receipt of the Whois data reminder email for existing registrations, or through a separate notice requesting self-identification.[2] d. If the data subject identifies as a legal person and confirms that the registration data does not include personal data, the Registrar should (i) contact the provided contact details to verify the Registrant claim[3] (ii) set the registration data set to automated disclosure in response to SSAD queries and (iii) publish the data. 3. The GAC has suggested that it might be helpful to add some timelines to this scenario. How could/should such a timeline look? Registrars shall not be prohibited from voluntarily utilizing a third party to verify that a registrant has correctly identified its data[4], provided that such verification is compliant with applicable data protection regulations. 4. Proposed language changes from Volker were applied to make clear that third party verification is not disallowed, but neither specifically recommended. NCSG has noted its objection to this rewrite as it would make scenario 3 ten times worse. EPDP Team to consider concerns and determine if/how these can be addressed. Note, the Bird & Bird advice specifically talks about the option to verify information provided by the registrant. 5. Expected Homework assignments (5 minutes) · By Friday 7 May, EPDP Team to review proposed feasibility of unique contacts write up for Initial Report. Please provided comments, suggestions and proposed edits in the form of comments. · By Friday 7 May, EPDP Team to review updated version of write up and indicate which aspects, if any, your group cannot live with for inclusion in the Initial Report. · By Friday 7 May, GAC and RrSG Team to review updated version of write up and to indicate to EPDP Team if GAC updated proposal and RrSG table, respectively, need to be included, where it would be included and what aspects it would cover that are currently not addressed in the write up. Please provide your response via the mailing list. 6. Wrap and confirm next EPDP Team meeting (5 minutes): 1. EPDP Team Meeting #20 Thursday 6 May at 14.00 UTC 2. Confirm action items 1. Confirm questions for ICANN Org, if any ________________________________ [1] Note that the confirmation that only non-personal data is provided could also happen at a later point in time. However, until the Registrant confirms that no personal data is present in the registration data, the Registrar does not set the registration data to automated disclosure. [2] Note, the implementation of EPDP Phase 1, recommendation #12 (Organization Field) may facilitate the process of self-identification. [3] Per the guidance<https://community.icann.org/download/attachments/155191493/ICANN%20-%20EPDP…> provided by Bird & Bird, “this verification method is advisable, and will help reduce risk. That risk reduction will be greatest if there is a reasonable grace period within which the objection can be lodged, before the data in question is published in the Registration Data” and “requiring an affirmative response to verification mailings seems over-cautious, unless and until studies show that the measures adopted are failing to keep very substantial amounts of personal data out of published Registration Data. However, if a verification email “bounces” (i.e. a Contracting Party knows it was not delivered), then it would be better if publication does not proceed”. [4] Per the guidance<https://community.icann.org/download/attachments/155191493/ICANN%20-%20EPDP…> provided by Bird & Bird, “a company registration number may be another means of verifying legal personhood”.

1 0

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2A | Tuesday, 04 May 2021 at 14:00 UTC
by Terri Agnew May 4, 2021

May 4, 2021

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2A call held on Tuesday, 04 May 2021 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/2ASlCQ> (attendance included) and the GNSO Master calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call as a panelist, observers can join as an attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-team/> and the main wiki page<https://community.icann.org/x/IYEpBQ>. Thank you. With kind regards, Terri

1 0

Meeting Invitation | Observers | GNSO Temp Spec gTLD RD EPDP-P2A call | Thursday, 06 May 2021 at 14:00 UTC
by Terri Agnew May 4, 2021

May 4, 2021

Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2A is scheduled on Thursday, 06 May 2021 at 14:00 UTC for 90 minutes. Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 Passcode: Z@S07?t=v5 Going forward, observers will now join via zoom webinar. Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Before joining the call: Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the ICANN Expected Standards of Behavior [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> Visit the Wiki agenda page: https://community.icann.org/x/7oSUCQ Check your time zone: https://tinyurl.com/5h668suy The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar/2021 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…> If you are joining via audio only: One tap mobile US: +13126266799,,92181477886#,,,,,,0#,,3121016458# or +13462487799,,92181477886#,,,,,,0#,,3121016458# Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acVxz9PmJI [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acVxz9PmJI__;!!PtGJab4!p…> Thank you. Kind regards, Terri

1 0

EPDP Phase 2A legal guidance - legal v. natural (Q3)
by Caitlin Tubergen May 3, 2021

May 3, 2021

Dear EPDP Team, Attached, please find the memo from Bird & Bird on the third legal v. natural question. The text of the question is included in the memo. Best regards, Berry, Marika, and Caitlin

1 0

Proposed Agenda - EPDP Meeting #19 - 4 May 2021
by Caitlin Tubergen May 3, 2021

May 3, 2021

Dear EPDP Team, Please find below the proposed agenda for tomorrow’s EPDP Team meeting. We are aware that some groups have added or are adding input after the deadline to the document for agenda item #3a, so please come prepared to speak up during the meeting. The write up that has been produced by the Staff Support Team (see attached) is based on the input that was received by the deadline from the BC, RrSG and the SSAC; however, this does not prevent other groups from weighing in and providing specific suggestions for additions and/or changes when this document gets posted as a google doc following Tuesday’s meeting. Thank you. Best regards, Berry, Marika, and Caitlin -- EPDP Phase 2A - Meeting #19 Proposed Agenda Tuesday 4 May 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Feasibility of unique contacts (30 minutes) 1. Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement. 2. If feasible, but not a requirement, what guidance, if any, can be provided to Contracted Parties who may want to implement uniform anonymized email addresses. * Review input received (groups that provided input to provide high level overview of their input – BC, RrSG, SSAC) * Walk through of staff proposed write up of Initial Report text * Confirm next steps – proposed deadline for comments / suggestions / proposed edits Friday 7 May 2021 4. Legal vs. natural (45 minutes) 1. Whether any updates are required to the EPDP Phase 1 recommendation on this topic (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so“); 2. What guidance, if any, can be provided to Registrars and/or Registries who differentiate between registrations of legal and natural persons. Guidance write up * Consider outstanding questions: Guidance #3 - As part of the implementation, Registrars should consider using a type of flag in the RDDS or their own data sets that would indicate the type of data it concerns (personal or non-personal data) as this could facilitate review of disclosure requests via SSAD and the return of non-personal data of legal persons by systems other than SSAD (such as Whois or RDAP). A flagging mechanism could also assist in indicating changes to the type of data in the registration data field(s). 1. ALAC has suggested that more specificity should be provided to Registrars about how this implementation could work especially in relation to how a ‘flag’ could be applied. Would it be helpful to provide further guidance on how this could be implemented or does that make it too prescriptive? The current guidance already includes references to the use of a type of flag – what is missing that would be helpful for Registrars to know? Example scenarios (note, these scenarios are intended to be illustrations for how a Registrar could apply the guidance above. These scenarios are NOT to be considered guidance in and of itself). 2. EPDP Team to consider whether or not these scenarios should remain or whether they should be replaced by the RrSG table as suggested by ALAC. If there is agreement that scenarios should remain as examples, EPDP Team to consider whether scenario #3 (Registrar determines type based on data provided) should remain as some concerns have been expressed by NCSG in relation to the Registrar making an initial assessment about whether or not the registrant is a legal or a natural person. Note, updates were made to ensure that the Registrant is requested to confirm this assessment. Scenario #2 - Data subject self-identification at time when registration is updated a. The Registrar collects Registration Data and provisionally redacts the data. b. The Registrar informs the Registrant (per guidance #3 above) and requests the Registrant (data subject) to designate legal or natural person type. The Registrar must also request the Registrant to confirm whether only non-personal data is provided for legal person type.[1] c. Registrant (data subject) indicates legal or natural person type and whether or not the registration contains personal information after registration is completed. For example, the Registrant may confirm person type at the time of initial data verification, in response to its receipt of the Whois data reminder email for existing registrations, or through a separate notice requesting self-identification.[2] d. If the data subject identifies as a legal person and confirms that the registration data does not include personal data, the Registrar should (i) contact the provided contact details to verify the Registrant claim[3] (ii) set the registration data set to automated disclosure in response to SSAD queries and (iii) publish the data. 3. The GAC has suggested that it might be helpful to add some timelines to this scenario. How could/should such a timeline look? Registrars shall not be prohibited from voluntarily utilizing a third party to verify that a registrant has correctly identified its data[4], provided that such verification is compliant with applicable data protection regulations. 4. Proposed language changes from Volker were applied to make clear that third party verification is not disallowed, but neither specifically recommended. NCSG has noted its objection to this rewrite as it would make scenario 3 ten times worse. EPDP Team to consider concerns and determine if/how these can be addressed. Note, the Bird & Bird advice specifically talks about the option to verify information provided by the registrant. 5. Expected Homework assignments (5 minutes) · By Friday 7 May, EPDP Team to review proposed feasibility of unique contacts write up for Initial Report (to be posted as google doc after meeting). Please provide comments, suggestions and proposed edits in the form of comments. · By Friday 7 May, EPDP Team to review updated version of legal/natural guidance write up (to be circulated after meeting) and indicate which aspects, if any, your group cannot live with for inclusion in the Initial Report. · By Friday 7 May, GAC and RrSG Team to review updated version of write up (link to be circulated after meeting) and to indicate to EPDP Team if GAC updated proposal and RrSG table, respectively, need to be included, where it would be included and what aspects it would cover that are currently not addressed in the write up. Please provide your response via the mailing list. 6. Wrap and confirm next EPDP Team meeting (5 minutes): 1. EPDP Team Meeting #20 Thursday 6 May at 14.00 UTC 2. Confirm action items 3. Confirm questions for ICANN Org, if any ________________________________ [1] Note that the confirmation that only non-personal data is provided could also happen at a later point in time. However, until the Registrant confirms that no personal data is present in the registration data, the Registrar does not set the registration data to automated disclosure. [2] Note, the implementation of EPDP Phase 1, recommendation #12 (Organization Field) may facilitate the process of self-identification. [3] Per the guidance<https://community.icann.org/download/attachments/155191493/ICANN%20-%20EPDP…> provided by Bird & Bird, “this verification method is advisable, and will help reduce risk. That risk reduction will be greatest if there is a reasonable grace period within which the objection can be lodged, before the data in question is published in the Registration Data” and “requiring an affirmative response to verification mailings seems over-cautious, unless and until studies show that the measures adopted are failing to keep very substantial amounts of personal data out of published Registration Data. However, if a verification email “bounces” (i.e. a Contracting Party knows it was not delivered), then it would be better if publication does not proceed”. [4] Per the guidance<https://community.icann.org/download/attachments/155191493/ICANN%20-%20EPDP…> provided by Bird & Bird, “a company registration number may be another means of verifying legal personhood”.

1 0

**REMINDER** Meeting Invitation | Observers | GNSO Temp Spec gTLD RD EPDP-P2A call | Tuesday, 04 May 2021 at 14:00 UTC
by Julie Bisland May 3, 2021

May 3, 2021

Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2A is scheduled on Tuesday, 04 May 2021 at 14:00 UTC for 90 minutes. Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 Going forward, observers will now join via zoom webinar. Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Before joining the call: Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the ICANN Expected Standards of Behavior [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> Visit the Wiki agenda page: https://community.icann.org/x/2ASlCQ Check your time zone: https://tinyurl.com/yj2xkwzc [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/yj2xkwzc__;!!PtGJab4!p4iuOTX…> The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar/2021 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…> If you are joining via audio only: One tap mobile US: +13126266799,,92181477886#,,,,,,0#,,3121016458# or +13462487799,,92181477886#,,,,,,0#,,3121016458# Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acVxz9PmJI [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acVxz9PmJI__;!!PtGJab4!p…> Thank you. Kind regards, Andrea

1 0

Reminder of homework assignments due today, Friday 30 April
by Marika Konings April 30, 2021

April 30, 2021

Dear EPDP Team, Hereby a reminder of the homework assignments that are due by the end of today, Friday 30 April (see also https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8Ad…) · By Friday 30 April<x-apple-data-detectors://5>, please put forward your group’s proposed response to the feasibility of unique contacts questions (i. Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement. ii. If feasible, but not a requirement, what guidance, if any, can be provided to Contracted Parties who may want to implement uniform anonymized email addresses). Please note here that we have been given specific advice from B&B with a risk continuum, so we will work within that, and we will not entertain discussions seeking to obviate risk altogether. The staff support team has set up a google doc to provide your suggestions (see https://docs.google.com/document/d/1lqLOkF1jaA2NK1hmYtG4jiY4x7V432maFh1Xlv5…) Based on the input received, leadership with the support of the staff support team will aim to develop proposed draft language for inclusion in the Initial Report. · By Friday 30 April, please finalize your review and input on the remaining edits / suggestions that were provided on the write up (#16 – 22 + RrSG table & GAC updated proposal that can be found at the end of the document). If you disagree with a comment or proposed addition, please provide a proposed update that factors in the concern identified. As always, please provide updates in comment form. See https://docs.google.com/document/d/1mHNvYWeyTGFhb--yDfWfTYNx_RVe1Bkl/edit Best regards, Caitlin, Berry and Marika

1 0

Notes and action items - EPDP Phase 2A Meeting #18 - 29 Apr 2021
by Caitlin Tubergen April 29, 2021

April 29, 2021

Dear EPDP Team, Please find below the notes and action items<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8Ad…> from today’s EPDP Phase 2A Team meeting. The next EPDP Phase 2A meeting will be Tuesday, 4 March 2021 at 14:00 UTC. Best regards, Berry, Marika, and Caitlin 🚨🚨🚨 Action Items 🚨🚨🚨 Please refer to the project spreadsheet<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8Ad…> for action items. EPDP Phase 2A - Meeting #18 Proposed Agenda Thursday 29 April 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Legal vs. natural (75 minutes) i. Whether any updates are required to the EPDP Phase 1 recommendation on this topic (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so“); ii. What guidance, if any, can be provided to Registrars and/or Registries who differentiate between registrations of legal and natural persons. Consideration of question i. Whether any updates are required to the EPDP Phase 1 recommendation on this topic (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so“); a. Each group to provide a high-level summary of responses to questions (seehttps://docs.google.com/document/d/1gMV29jRPQEFGv2psZ2py2_F8cr93OeeA/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1gMV29jRPQEFG…>): - Each group will have five minutes without interruption to respond to the questions. Respectfully ask the groups not sharing to listen respectfully and not intervene in chat during the presentations. - Note that there may be additional Phase 1 changes as a result of this discussion, for example, should there be an additional legal/natural field - This is an opportunity to have groups put all of their cards on the table. This will assist in documentation for the Initial Report. 1. ALAC - In order to consider the answer to this question, we need to rely on the information we have received: (i) B&B memo and (ii) ICANN Study. The B&B memo notes that in certain circumstances, if CPs differentiate, it would reduce their liability, and the liability would only be in relation to a CP’s failure to respond to a complaint. In relation to practical implementation, the ICANN study goes into this. In addition to consent, it would be helpful to differentiate between the registrant types – as a requirement, not an option. Differentiation b/w registrant type alone does not put any additional risk to CPs. ALAC sees no reason to differentiate first b/w the registrant type before differentiating b/w data type. Differentiation b/w data type may be optional. - During Phase 2, the team discussed the way in which queries would be processed. CPs noted they could not look at data before determining if the query has a valid legal basis. The B&B memo says the opposite of that. If there is a legal entity, the data should not be released, it should be made public. There may have to be a multi-year process for existing registrations, but this process needs to start. For new registrations, this needs to be done at registration time. The RAA makes is clear that responsibility needs to be passed to the resellers. 2. BC - The DNS is critical infrastructure, and, as such, the ownership of the critical infrastructure should be as transparent as possible. The majority or significant majority of domain names are owned by legal persons. In the interest of transparency, the data of these domain names owned by legal persons should be published. A global policy would result in the most consistency. The NIS-2 has further convinced the BC of this fact. However, this has been the BC position all along. - In terms of requirement, the BC stands behind the requirement of publication of data that relates to legal persons. As we’ve gone through this work, understand that where someone has self-designated as a legal person, all of their contact information should be published unless there is natural person data associated with it. There should also be a mechanism to correct the self-designation. For example, if there is a problem with a registration (such as WHOIS inaccuracy or DNS abuse notification), that may serve as a trigger point to reevaluate the initial designation. 3. GAC - The GAC’s position is fairly consistent with ALAC and BC colleagues. Would like to emphasize that if we take a few steps back, recognize that information is currently masked that is not protected by the GDPR. This starting point is foundational – the current policy protects information that should be public. How can we move forward in a way that is consistent with the law but that also serves the public interest for protecting against cybercrime, investigating criminal behavior, etc. The Team can debate about statistics, but that is not productive. With respect to flexibility about business models and timing, this needs to take into account the realities of when things happen with the contracted party that is actually collecting the information and interacting with the registrant. Understand that this is almost always done during a registration; therefore, that would be the best time to deal with this. If there is a registrar that has a reseller, it still seems to point to at registration. 4. IPC - A distinction needs to be made because the data is useful, it’s in the public interest, and it’s largely unavailable without justification. From the CP perspective, concerned about secondary liability. Concerned about an outcome that results in CPs being liable for the bad things that happen on websites. The availability and access to WHOIS data has historically been the reason that CPs have not been held liable for this. Concern that if CPs say that they cannot make a distinction and redact all data, that will not play well. 5. ISPCP - There should be as much uniformity in the treatment of registration data as possible. Registrants should be protected irrespective of where they are. If there is a standardized process, a distinction can be made. However, the distinction b/w legal and natural may not be the appropriate distinction. The starting point should be personal data v. no personal data being present. Since GDPR is the highest common denominator, do not share the position that the risk is not just with CPs – it is also with ICANN org. Need to make sure we do not create legal issues or exposure for ICANN org. - From the perspective of running an ISP, a broadband connection can be used for nefarious purposes. There is not currently a requirement to delineate b/w a business of personal account, nor to publish legal person details for a broadband connection. For that reason, cannot in good faith support this type of requirement. As ISPs aware of fluidity of technology, may use broadband connection for business and personal use. When it comes down to it, domain names may not be used for a fixed use. 99% or more businesses are small, so legal v. natural person data is oftentimes the same. 97% of companies are sole proprietorships. Usage is full of grey areas and it is often hard to distinguish. 6. NCSG - The preference of the NCSG is clear – do not believe that there should be a requirement for differentiation. However, there is a willingness to move from this position in the interest of consensus. If guidance is produced regarding non-mandatory differentiation, we have two ideas – one would allow registrants to self-designate as legal so long as consequences are clear. NCSG is flexible on the nature of the guidance but the main interest is finding consensus agreement because if nothing changes, NCSG is OK with that. - NCSG is OK with “optional”. NCSG is divided with the topic of providing guidance; some think registrants are easily able to make the distinction between legal and natural persons. The default should be on protection; a valid request will mean info will be disclosed. 7. RrSG - Members of RrSG will continue to participate in good faith. Members of the RrSG have voiced strong opposition to mandatory differentiation. Have heard vocal support for a mandatory differentiation from other groups, but the RrSG has not heard a reason that is compelling. It has become clear through this process that there should be no requirement. Continue to believe guidance for registrars who wish to differentiate is a valuable and helpful exercise. Reject the notion that the majority of domain names are registered by legal persons. 8. RySG - Understand the task to review the study and the legal guidance. The study by ICANN identified pros and cons of differentiating and the legal guidance noted that there are steps that CPs can undertake to reduce risks, but that the risk still remains with the contracted party. Do not think updates are required. The existing language regarding permitting differentiation is appropriate based on the ICANN org study and B&B guidance. Understand why it is desirable for some groups to have free and unfettered access to domain name registration data, but believe status quo is appropriate based on what was heard so far. - If this will be a mandatory policy, we will need to make sure that the policy is tested with the EDPB. 9. SSAC - Strongly in favor of the maximum amount of data available and yet the question regarding mandatory requirement is a distraction. It should be desirable to differentiate and it should be mandatory to include a field to record the distinction, but also to include “unknown” as an intermediate for existing domain names. Recognize that the larger purpose is how to fulfill the various needs like security and public interest – that rests on access to non-public data. Efficient and effective differentiated access must be in the plan at some sort of date certain. Open Mic: - We have a couple of variables that are still unknown in terms of their ultimate impact: (i) the final disposition of the NIS-2 proposed directive; (ii) status of the SSAD recommendations. These are two variables where we need to see where they end up. As we consider the current state of our landscape, it may be that within one year or 18 months, we will have a greater understanding of NIS-2 and SSAD. One or both of the those could change the dynamics of the group. - Need to be exceptionally clear that when we reference CPs, it is not just a CP – it about how a registrar can respond and a registry can respond. This is very layered. If the registry is trying to decide or delineate b/w what is legal or natural, have to rely on contractual partners (registrars). If it’s optional, the registry can choose or not to rely on statements by registrars. When it comes to the registry – how feasible is it for registries to mandatorily do this or whether there is actually a need for this if it’s being done at a registry level. - As NCSG indicated, the status quo is perfectly fine with NC users as a whole. But, there is concern that simply saying the CPs can do this in whatever they want. Most CPs in this EPDP team are very privacy friendly and want to comply with data protection law. However, there are registrars what do not. Some kind of guidance would be preferable so long as it’s the right kind of guidance. - Some NCSG members believe that providing guidance on this difficult matter gets too far into providing advice to registrants regarding their legal situation and this is fraught with peril. This is easy for some, and not easy for others and can range across a variety of domain names. The default must be sent on protection and if guidance is going to push to automated disclosure, do not provide guidance under the policy. Does not mean no guidance can be provided, but not under this policy. - If the Team is talking about guidance to a registrar for how it could or should consider differentiate – there is a concern that the guidance doesn’t stray into advice to a registrant. - The ALAC firmly believes that we should be differentiating – immediately for new registrations and have a plan for existing registrations. If we can’t get agreement on that, it’s essential that we provide guidance. Do not understand why when we talk about guidance the critical part of how to present these questions so that registrars, particularly the smaller ones, don’t have to reinvent this from scratch. - Guidance does not constitute legal advice – that is an invalid assertion. It is already established policy that CPs have the discretion to differentiate – the question is do we include guidance or have no guidance and leave this for registrars to do this on their own? Cannot understand why anyone would argue for no guidance. - There is a thin line between providing guidance to registrars; however, there are many that will pick the easiest default which would be disclosure. Should be protecting registrants and default should be on protection not disclosure. - Arguing for the right type of guidance. There should be guidance. - The key question around guidance – there is a distinction b/w existing registrations and new registrations. If we look at over the next 2-3 years, what guidance could we be telling registrars to consider in terms of their practices to best differentiate at their choice or prepare for the future in the event it becomes a requirement. - The phrase “data will be available upon request” does not land well with those who have worked hard on SSAD to increase the access. The data suggests that the data is not available upon request. - Have heard about the difficulty of differentiation. Have heard about small registrars with no legal counsel. This all points in the direction of providing guidance. - Requiring a field for designation and enlarging the set of values possible in the field “unknown” will lay the foundation for evolution over time. - The issue of how to deal with existing registrations is an important one – the “unknown” field would be helpful for existing registrations but not for new registrations – it might be counterproductive for new registrations. There is a strong difference of opinion over what should be mandatory and what could be guidance. Should be focusing guidance on what could be mandatory. The guidance should be mandatory, should be clearly identified so that we can get public comment on that issue. - Need to be clear when talking about mandatory guidance – a public comment does not make guidance legal. Not saying that we cannot go down that road but if there will guidance, this should not be mandatory. We should not be stating that if you follow this guidance, you will not run afoul of the law. Art. 36 prior consultation – there is a method and means to go to the EDPB. We should do this – can we give this out as guidance? Would this pass muster? As a group outside of the EPDP, we should be looking at an Art. 40 so that everyone can work together and help ICANN sort this issue out appropriately under the law. - We either have requirements that are mandated by a policy or guidance. Mandatory guidance is conflating separate terms. b. EPDP Team to consider next steps to develop response to question i. - Helpful if all follow-up emails include a reminder – here is the spreadsheet for action items. - Could consider putting the most recent version on top c. Confirm next steps 4. Reminder of Homework assignments (5 minutes) · By Friday 30 April<x-apple-data-detectors://5>, please put forward your group’s proposed response to the feasibility of unique contacts questions (i. Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement. ii. If feasible, but not a requirement, what guidance, if any, can be provided to Contracted Parties who may want to implement uniform anonymized email addresses). Please note here that we have been given specific advice from B&B with a risk continuum, so we will work within that, and we will not entertain discussions seeking to obviate risk altogether. The staff support team has set up a google doc to provide your suggestions (see https://docs.google.com/document/d/1lqLOkF1jaA2NK1hmYtG4jiY4x7V432maFh1Xlv5… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1lqLOkF1jaA2N…>). Based on the input received, leadership with the support of the staff support team will aim to develop proposed draft language for inclusion in the Initial Report. · By Friday 30 April, please finalize your review and input on the remaining edits / suggestions that were provided on the write up (#16 – 22 + RrSG table & GAC updated proposal that can be found at the end of the document). If you disagree with a comment or proposed addition, please provide a proposed update that factors in the concern identified. As always, please provide updates in comment form. See https://docs.google.com/document/d/1mHNvYWeyTGFhb--yDfWfTYNx_RVe1Bkl/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1mHNvYWeyTGFh…> 5. Wrap and confirm next EPDP Team meeting (5 minutes): a. EPDP Team Meeting #19 Tuesday 4 May at 14.00 UTC b. Confirm action items a. Confirm questions for ICANN Org, if any

1 0

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2A | Thursday, 29 April 2021 at 14:00 UTC
by Andrea Glandon April 29, 2021

April 29, 2021

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2A call held on Thursday, 29 April 2021 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/4oSUCQ> (attendance included) and the GNSO Master calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call as a panelist, observers can join as an attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-team/> and the main wiki page<https://community.icann.org/x/IYEpBQ>. Thank you. With kind regards, Andrea

1 0