Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019
Dear EPDP Team: Please find notes and action items from today’s EPDP Team meeting below. As a reminder, the next EPDP Team meeting will be Thursday, 8 August at 14:00 UTC. Thank you. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #11 Thursday, 1 August 2019 at 14.00 UTC Action Items EPDP Team to review the early input documents (the SSAD worksheet and the Google doc) that have been posted. Leadership will devote time to going over the input at the EPDP Team meeting in two weeks’ time. Further to the EPDP Team request, Staff support will put up the use cases as google doc, with the understanding that the author will hold the pen in making updates / changes based on the input provided. EPDP Team to provide additional input, via the comment functionality, to the google sheet for the SSAC use case ideally by Friday, August 2, but at the latest by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. EPDP Team to provide additional input, via the comment functionality, to the google sheet for the ALAC use case ideally by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. SSAC to incorporate feedback from the EPDP Team in advance of the next EPDP Team meeting; the updates should also include an example of how accreditation can be done and by whom. Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ. EPDP Phase 2 - Meeting #11 Proposed Agenda Thursday, 1 August 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) · Attendance will be taken from Zoom · Remember to mute your microphones upon entry to Zoom. · Please state your name before speaking for transcription purposes. · Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Confirmation of agenda (Chair) · Following comments made after the previous call regarding postponement of the accreditation discussion, EPDP Leadership proposed to continue discussion of use cases. · No objections to the agenda. 3. Welcome and housekeeping issues (Chair) (10 minutes) 1. Early input review – next steps · Some groups noted a further discussion of the early input submitted was needed. · Question to the Team: when will groups be prepared to discuss the early input received from the different groups? EPDP Team Feedback: · GAC will be sending in its early input today. · Support Staff was planning to review the input and take it into account when drafting recommendations for the Initial Report. When drafting, Support Staff plans to flag any opposing views or areas of disagreement that may need further discussion within the EPDP Team. · With respect to requirements around early input, there is an expectation that early input is reviewed by the Working Group. The Support Team has used the early input review tool to facilitate this review: https://community.icann.org/x/zIWGBg. In short, did the WG agree, disagree, and/or how does the WG plan to respond to the input. · Is there a way to incorporate the feedback into the worksheets and review the input as the WG deliberates on the respective topics? Answer: yes, Support Staff already incorporated the early input into the SSAD worksheets per the previous request of the EPDP Team. · The RrSG provided its early input prior to the deadline and also provided comments to a Google Doc - was this homework submitted properly? Answer: yes, the RrSG comments were received. · Not clear on what the purpose of this exercise is. · This is a GNSO requirement. · There seems to be a low level of interest in reviewing early input. Perhaps the Team can defer reviewing the early input as such and review it when the respective topics are discussed within the SSAD worksheet. · There are two separate activities Support Staff undertook at the request of the Team: (1) incorporate the early input into the SSAD worksheet, noting the relevant categories/topics; (2) create a Google Doc that allows groups to provide feedback on the early input received. Some of the input may relate to additional Charter questions, so the group may want to consider additional questions or topics as a result of feedback rather than assuming all input relates to topics already noted in the worksheet. · Chair proposal: · ACTION: EPDP Team to review the early input documents (both the SSAD worksheet and the Google Doc for providing feedback). Leadership will devote some time to going over the input in two weeks time. 4. Use Cases Categorization (10 minutes) Review results of the survey · The document on the screen represents the survey sent next week. · This categorization of use cases was put together by a small team - with the understanding that it may be possible to derive common conclusions from use cases that are deemed similar. · The objective of the survey was to identify the use case that was deemed the most representative of the group. Note: this does not mean the other use cases would not be considered. · Six groups responded to the survey. Some of the use cases were very close, so EPDP Leadership made some suggestions. · The proposed schedule also includes proposed deadlines. By Friday after the first reading, all proposed EPDP Team edits/concerns need to be submitted to the list. This will allow the author, with Staff Support assistance (if desired), to update the use case in advance of the next meeting, during which the second reading will occur. · The use case review will continue into late August. Then the group will need to consider what other use cases need to be considered or reviewed. Toward the end of August/early September, Leadership and Staff Support hope to share draft policy principles derived from the commonalities, which can serve as the basis for the F2F discussion. Confirm review order and schedule · Could SSAC-3 be reviewed next week? · The purpose of today’s reading is to raise concerns and not necessarily to answer them, which means Greg will have the ability to review the concerns and address them during the second reading, which will be next week. · Procedural suggestion: it is difficult to go back and forth in an email thread. Perhaps the group can consider using Google Docs? · Staff support will put it up the use cases as a google doc, with the understanding that the author will hold the pen in making updates / changes based on the input provided. · ALAC is not sure it would be a good use of time to review the ALAC use case today. · Groups should not be advocating a use case where something is always right/data will always be disclosed - these should be generic cases, wherein another member or alternate in the group should be able to discuss. In terms of manual balancing tests, this activity still needs to be discussed. 5. Use case – first reading continued: Investigation of criminal activity where domain names are used. Typical specific example: phishing attack (45 minutes) Input from EPDP Team – questions, concerns, proposed modifications · The purpose of this reading is to continue last week’s discussion. Subsection B · With respect to phishing, non-law enforcement parties are concerned with taking down the domain name to block or mitigate phishing. They may not be interested in attribution and/or prosecution. These activities may need to be broken down into those specific cases in which disclosure of nonpublic information is necessary. · Attribution is necessary here to capture the gamut of domain names involved in the phishing enterprise. · With respect to task 3, accuracy of contact data is always desirable. With respect to inaccurate information, though, this may not be a sign of bad faith or criminal activity. With respect to cross-field address validation, there are many false positives. Cross-field address validation does not solve the issue; it sometimes exacerbates the issue. · If the Team is discussing a generic SSAC use case, this includes the need for disclosure of RDS data. · There is a challenge that if the use case is too specific, there will be too many use cases, but if they are too generic, there is an argument that it may not be specific enough. · Not arguing for proliferation of use cases, but rather discussing when disclosure is necessary. For example - Task 4 - suspending a domain name does not require disclosure. Task 2 - IP address is public in WHOIS records, so no disclosure is needed for that. Task 5 - borderline case - you could need disclosure, but perhaps it could be turned over to law enforcement. Task 3 - agree with GoDaddy that this is a completely different use case and is not part of mitigation of phishing. The tasks should be winnowed down to those that actually require disclosure. The tasks that are thrown out do not need to become new use cases. · Necessary under GDPR means reasonably necessary. With respect to Task 3, just because data is inaccurate does not mean there is fraud; however, when data is falsified, that typically does indicate fraud. · With respect to Task 4, how data is handled once it has been processed is important to consider. The way this use case is laid out allows the Team to see how the data is handled when it has already been disclosed. · Need a better understanding on what the Team will do with the use cases, and how do they trickle up to policy recommendations. · The use cases will be provided as an illustration for how the EPDP Team got to its recommendations. · While this is a useful case as a discussion instrument, request adding a footnote that this is a discussion instrument only. Secondly, on the accuracy issue - if inaccurate data shows criminal intent, we should consider taking down credit reporting bureaus. If this group has no delegation under law to prosecute, it cannot collect personal data. Just because this happens does not make it correct. Subsection C · Is tech contact still collected? If so, this should be removed from this report. · Tech contact may still be collected under Phase 1 recommendations. · Tech contact physical address was eliminated in Phase 1. · The specific data elements to be requested should be limited to the request at hand - if they are not needed for the specific investigation, they should not be requested/disclosed. Subsection D/E · Issue with the number of lawful bases for the parties here. Vital interest is a very difficult lawful basis - very few instances where this lawful basis can be used, so it is probably unrealistic for phishing. 6(1)(f) or 6(1)(c) may be better. · Subsection D looks like a shotgun approach to applying a lawful basis. This increases rather than decreases the vulnerability that this will be challenged. · How does 6(1)(b) apply to this use case? There is no description in Subsection E for how this will apply. · It may be of interest to look at BC-1 when reviewing these lawful bases, specifically 6(1)(b) and 6(1)(d). In this case, human trafficking may be involved, though in BC-1, BC elected not to include 6(1)(d). · As written, Subsections D and E do look like a shotgun approach. In the overwhelming majority of these cases, SSAC recognizes that 6(1)(f) would be the applicable lawful basis. There are limited edge cases, where a contract for phishing mitigation or similar is used and where 6(1)(b) would be applicable. · When writing these use cases, some of this discussion is premature until the Team receives further legal advice about lawful basis. · All lawful bases need to be deleted except 6(1)(f). The other lawful bases may be relevant for different use cases, but not this one. Subsection F · Be careful with the term code of conduct as this is a term of art in GDPR. Data processing agreement may be the more appropriate term here. Subsection G · No comments. Subsection H · With respect to the last sentence, this is already a requirement in the Registration Accreditation Agreement - curious why it needs to be included here. · Under the Temp Spec, the WHOIS inaccuracy process isn’t able to be utilized. · The WHOIS accuracy program has not changed, so the above statement is not correct re: the program not being utilized. Subsection I · Reverse search and wildcard search are not currently offered and this should not become part of the requirements. · These additional capabilities and functions were never part of the RDS functions - they were provided by third party data harvesting firms and should not be included here. · Functionality that hasn’t existed in the past should not be deleted as a safeguard just because it did not previously exist. · Item one for I is not being asked as a policy recommendation - simply pointing out that if there were a legal way to do this under GDPR, it would be helpful. Point 1 can be removed for purposes of this exercise. · Beware of making broad statements that certain activity is illegal or unethical. BC-2 shows where a wildcard search would be acceptable. · Wild card searches create a new role under this system as it could track registrant behavior across TLDs and registrars. We need to be careful about putting ICANN or whoever is ultimately responsible in that position. · Phishing attacks need to be mitigated quickly - and this is a factor in addressing them. Subsection J · Accreditation and authentication of users identifies who the requester of the data is. It does not and cannot mean that the request does not have to be checked. · Action: SSAC to provide an example of how accreditation can be done by whom. · There would not be a separate accreditation for an anti-phishing working group. There would not be special recognition given to groups; there would just be generic accreditation. Subsection M - P Confirm next steps · ACTION: EPDP Team to provide additional input, via the comment functionality, to the google sheet for the SSAC use case ideally by Friday, August 2, but at the latest by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 6. Use case – first reading: Online buyers identifying and validating the source or services/ Internet users validating the legitimacy of an email or a website to protect themselves (60 minutes) 1. Introduction of use case (ALAC) · Because the group is not currently distinguishing b/w legal and natural persons, the use case may need to be altered when it does discuss legal vs. natural. · Consumer protection is within ICANN’s mission. · This use case touches on online buyers or internet users who are trying to purchase services or goods in order to verify the legitimacy of the website they are dealing with. This use case is referencing commercial websites. · The data elements that would be required for this use case is the contact information. The lawful basis for this would be 6(1)(f). · There is a wider public benefit here - for ordinary users to confirm the legitimacy of a website is a benefit to the users to report a website before they are victims. · There is likely no need for accreditation here. Input from EPDP Team – questions, concerns, proposed modifications · The key issue here that suggests that this is a use case that should be discarded is the distinction b/w ex-post and ex ante checking. Being able to not find information on a website is not, in and of itself, a crime unless it is in a jx that requires the posting of information. As a consumer, you have the right to refuse to do business if you do not feel comfortable with the validity of the website. If a consumer has been defrauded (ex-post), that is another use case. · Clarifying question: the user makes a typical 6(1)(f) request, and the data controller will look at it - if the controller has a legal vs. natural distinction ability, they would use this. What if they don’t? · There is a fundamental flaw in this use case in that it conflates the registrant of the domain name and the operator of the website, particularly in marketplaces which connect buyers and sellers (like eBay, for example). Holding up WHOIS data vs. use/adoption of SSL certificates is worrisome. If a consumer is defrauded, that would be a different use case, which is probably LEA. · It is time to move on - the conflation of domain name provider and operator of the business is a problem. Consumers should not be encouraged to get data via WHOIS. If you cannot tell who you are dealing with via the website, the consumer should choose not to deal with them. Web presence is not within ICANN’s remit. · The case will also be published on Google Docs for those who would like to include comments. · The FTC issued a statement re: how the WHOIS database is critical to consumers. · The intent of this use case is not to be speculative, but rather, an egregious case. Perhaps the earlier sections need to be reworded. Local law enforcement will not take a case against an organization that is likely outside of its jurisdiction. Confirm next steps ACTION: EPDP Team to provide additional input, via the comment functionality, to the google sheet for the ALAC use case ideally by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 7. Any other business (5 minutes) 1. Priority 2 small team meetings update · Accuracy and WHOIS ARS (see https://docs.google.com/document/d/1pS9Pibanj-Hp6LztZpeERtxdoLsnp4y_-do0vU5V...) · Input received on other priority 2 items from RrSG (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-June/002174.html) · Leadership to recommend next steps via mailing list 2. Council request for input on org letter requesting clarification on Data Accuracy and Phase-2 (see https://gnso.icann.org/sites/default/files/file/field-file-attach/marby-to-d...). EPDP Team to provide input on the mailing list. Confirm deadline for input. 8. Wrap and confirm next EPDP Team meeting on Thursday 8 August 2019 at 14.00 UTC (5 minutes) Confirm action items Confirm questions for ICANN Org, if any
Hello Team, Please find below my reply to the concerns raised in relation to the online buyers use case Concern:The key issue here that suggests that this is a use case that should be discarded is the distinction b/w ex-post and ex ante checking. Being able to not find information on a website is not, in and of itself, a crime unless it is in a jx that requires the posting of information. As a consumer, you have the right to refuse to do business if you do not feel comfortable with the validity of the website. If a consumer has been defrauded (ex-post), that is another use case. Reply:Yes the whole point about this use case is to have a path through which Internet users are able to do ex-ante checking about a website that they are about to make a purchase/get a service from. If a customer suspects that there, is an attempt to steel information from him/her there should be a path through which he can try to validate the website and hence report it. Being able to report domain names before becoming actual victims has a wider public benefit. In addition, absent of such a mechanism users will always prefer well known online sellers, leaving very little room for competition and smaller businesses. This use case is one of the means to protect customers from fraud, giving online buyers a proactive role. Having such a mechanism is of benefit to both business owners and customers, enhancing online buyers trust in the electronic marketplace. Clarifying question: the user makes a typical 6(1)(f) request, and the data controller will look at it - if the controller has a legal vs. natural distinction ability, they would use this. What if they don’t? Reply:The whole point about this use case is not to rely on the distinction between legal vs natural persons. GDPR does not cover the processing of personal information of legal persons and thus if we are to rely on the legal vs natural distinction for disclosure the legal basis won’t be 6(1)f because it is allowed and would also require no balancing test. The requester is required to prove that he/she is trying to make a commercial activity with the specified domain name (that does not mean that the domain name has to be registered as a legal entity). The controller is to look into the request and if he finds it legitimate (regardless of whether the organization is registered as a legal entity or not) then the data could be disclosed under 6(1)f, where preventing fraud is a legitimate interest under GDPR (recital 47) Concern:There is a fundamental flaw in this use case in that it conflates the registrant of the domain name and the operator of the website, particularly in marketplaces which connect buyers and sellers (like eBay, for example). Holding up WHOIS data vs. use/adoption of SSL certificates is worrisome. If a consumer is defrauded, that would be a different use case, which is probably LEA. It is time to move on - the conflation of domain name provider and operator of the business is a problem. Consumers should not be encouraged to get data via WHOIS. If you cannot tell who you are dealing with via the website, the consumer should choose not to deal with them. Web presence is not within ICANN’s remit. Reply:Marketplaces that connect buyers and sellers usually have customer support through which buyers can seek help or ask questions, they also provide tips on how to know your seller better. In all cases, the marketplace does not only depend on those who connect buyers and sellers. Giving the consumers the opportunity of having a proactive role is important. ICANN’s remit certainly includes consumer protection and enhancing competition, which this use case enables. Best Hadia ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen@icann.org> Sent: 01 August 2019 19:44 To: gnso-epdp-team@icann.org Subject: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 Dear EPDP Team: Please find notes and action items from today’s EPDP Team meeting below. As a reminder, the next EPDP Team meeting will be Thursday, 8 August at 14:00 UTC. Thank you. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #11 Thursday, 1 August 2019 at 14.00 UTC Action Items 1. EPDP Team to review the early input documents (the SSAD worksheet and the Google doc) that have been posted. Leadership will devote time to going over the input at the EPDP Team meeting in two weeks’ time. 2. Further to the EPDP Team request, Staff support will put up the use cases as google doc, with the understanding that the author will hold the pen in making updates / changes based on the input provided. 3. EPDP Team to provide additional input, via the comment functionality, to the google sheet for the SSAC use case ideally by Friday, August 2, but at the latest by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 4. EPDP Team to provide additional input, via the comment functionality, to the google sheet for the ALAC use case ideally by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 5. SSAC to incorporate feedback from the EPDP Team in advance of the next EPDP Team meeting; the updates should also include an example of how accreditation can be done and by whom. Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ. EPDP Phase 2 - Meeting #11 Proposed Agenda Thursday, 1 August 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) · Attendance will be taken from Zoom · Remember to mute your microphones upon entry to Zoom. · Please state your name before speaking for transcription purposes. · Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Confirmation of agenda (Chair) · Following comments made after the previous call regarding postponement of the accreditation discussion, EPDP Leadership proposed to continue discussion of use cases. · No objections to the agenda. 3. Welcome and housekeeping issues (Chair) (10 minutes) 1. Early input review – next steps · Some groups noted a further discussion of the early input submitted was needed. · Question to the Team: when will groups be prepared to discuss the early input received from the different groups? EPDP Team Feedback: · GAC will be sending in its early input today. · Support Staff was planning to review the input and take it into account when drafting recommendations for the Initial Report. When drafting, Support Staff plans to flag any opposing views or areas of disagreement that may need further discussion within the EPDP Team. · With respect to requirements around early input, there is an expectation that early input is reviewed by the Working Group. The Support Team has used the early input review tool to facilitate this review: https://community.icann.org/x/zIWGBg. In short, did the WG agree, disagree, and/or how does the WG plan to respond to the input. · Is there a way to incorporate the feedback into the worksheets and review the input as the WG deliberates on the respective topics? Answer: yes, Support Staff already incorporated the early input into the SSAD worksheets per the previous request of the EPDP Team. · The RrSG provided its early input prior to the deadline and also provided comments to a Google Doc - was this homework submitted properly? Answer: yes, the RrSG comments were received. · Not clear on what the purpose of this exercise is. · This is a GNSO requirement. · There seems to be a low level of interest in reviewing early input. Perhaps the Team can defer reviewing the early input as such and review it when the respective topics are discussed within the SSAD worksheet. · There are two separate activities Support Staff undertook at the request of the Team: (1) incorporate the early input into the SSAD worksheet, noting the relevant categories/topics; (2) create a Google Doc that allows groups to provide feedback on the early input received. Some of the input may relate to additional Charter questions, so the group may want to consider additional questions or topics as a result of feedback rather than assuming all input relates to topics already noted in the worksheet. · Chair proposal: · ACTION: EPDP Team to review the early input documents (both the SSAD worksheet and the Google Doc for providing feedback). Leadership will devote some time to going over the input in two weeks time. 4. Use Cases Categorization (10 minutes) * Review results of the survey · The document on the screen represents the survey sent next week. · This categorization of use cases was put together by a small team - with the understanding that it may be possible to derive common conclusions from use cases that are deemed similar. · The objective of the survey was to identify the use case that was deemed the most representative of the group. Note: this does not mean the other use cases would not be considered. · Six groups responded to the survey. Some of the use cases were very close, so EPDP Leadership made some suggestions. · The proposed schedule also includes proposed deadlines. By Friday after the first reading, all proposed EPDP Team edits/concerns need to be submitted to the list. This will allow the author, with Staff Support assistance (if desired), to update the use case in advance of the next meeting, during which the second reading will occur. · The use case review will continue into late August. Then the group will need to consider what other use cases need to be considered or reviewed. Toward the end of August/early September, Leadership and Staff Support hope to share draft policy principles derived from the commonalities, which can serve as the basis for the F2F discussion. * Confirm review order and schedule · Could SSAC-3 be reviewed next week? · The purpose of today’s reading is to raise concerns and not necessarily to answer them, which means Greg will have the ability to review the concerns and address them during the second reading, which will be next week. · Procedural suggestion: it is difficult to go back and forth in an email thread. Perhaps the group can consider using Google Docs? · Staff support will put it up the use cases as a google doc, with the understanding that the author will hold the pen in making updates / changes based on the input provided. · ALAC is not sure it would be a good use of time to review the ALAC use case today. · Groups should not be advocating a use case where something is always right/data will always be disclosed - these should be generic cases, wherein another member or alternate in the group should be able to discuss. In terms of manual balancing tests, this activity still needs to be discussed. 5. Use case – first reading continued: Investigation of criminal activity where domain names are used. Typical specific example: phishing attack<https://community.icann.org/download/attachments/111386876/SSAC%20Crime-Abus...> (45 minutes) * Input from EPDP Team – questions, concerns, proposed modifications · The purpose of this reading is to continue last week’s discussion. Subsection B · With respect to phishing, non-law enforcement parties are concerned with taking down the domain name to block or mitigate phishing. They may not be interested in attribution and/or prosecution. These activities may need to be broken down into those specific cases in which disclosure of nonpublic information is necessary. · Attribution is necessary here to capture the gamut of domain names involved in the phishing enterprise. · With respect to task 3, accuracy of contact data is always desirable. With respect to inaccurate information, though, this may not be a sign of bad faith or criminal activity. With respect to cross-field address validation, there are many false positives. Cross-field address validation does not solve the issue; it sometimes exacerbates the issue. · If the Team is discussing a generic SSAC use case, this includes the need for disclosure of RDS data. · There is a challenge that if the use case is too specific, there will be too many use cases, but if they are too generic, there is an argument that it may not be specific enough. · Not arguing for proliferation of use cases, but rather discussing when disclosure is necessary. For example - Task 4 - suspending a domain name does not require disclosure. Task 2 - IP address is public in WHOIS records, so no disclosure is needed for that. Task 5 - borderline case - you could need disclosure, but perhaps it could be turned over to law enforcement. Task 3 - agree with GoDaddy that this is a completely different use case and is not part of mitigation of phishing. The tasks should be winnowed down to those that actually require disclosure. The tasks that are thrown out do not need to become new use cases. · Necessary under GDPR means reasonably necessary. With respect to Task 3, just because data is inaccurate does not mean there is fraud; however, when data is falsified, that typically does indicate fraud. · With respect to Task 4, how data is handled once it has been processed is important to consider. The way this use case is laid out allows the Team to see how the data is handled when it has already been disclosed. · Need a better understanding on what the Team will do with the use cases, and how do they trickle up to policy recommendations. · The use cases will be provided as an illustration for how the EPDP Team got to its recommendations. · While this is a useful case as a discussion instrument, request adding a footnote that this is a discussion instrument only. Secondly, on the accuracy issue - if inaccurate data shows criminal intent, we should consider taking down credit reporting bureaus. If this group has no delegation under law to prosecute, it cannot collect personal data. Just because this happens does not make it correct. Subsection C · Is tech contact still collected? If so, this should be removed from this report. · Tech contact may still be collected under Phase 1 recommendations. · Tech contact physical address was eliminated in Phase 1. · The specific data elements to be requested should be limited to the request at hand - if they are not needed for the specific investigation, they should not be requested/disclosed. Subsection D/E · Issue with the number of lawful bases for the parties here. Vital interest is a very difficult lawful basis - very few instances where this lawful basis can be used, so it is probably unrealistic for phishing. 6(1)(f) or 6(1)(c) may be better. · Subsection D looks like a shotgun approach to applying a lawful basis. This increases rather than decreases the vulnerability that this will be challenged. · How does 6(1)(b) apply to this use case? There is no description in Subsection E for how this will apply. · It may be of interest to look at BC-1 when reviewing these lawful bases, specifically 6(1)(b) and 6(1)(d). In this case, human trafficking may be involved, though in BC-1, BC elected not to include 6(1)(d). · As written, Subsections D and E do look like a shotgun approach. In the overwhelming majority of these cases, SSAC recognizes that 6(1)(f) would be the applicable lawful basis. There are limited edge cases, where a contract for phishing mitigation or similar is used and where 6(1)(b) would be applicable. · When writing these use cases, some of this discussion is premature until the Team receives further legal advice about lawful basis. · All lawful bases need to be deleted except 6(1)(f). The other lawful bases may be relevant for different use cases, but not this one. Subsection F · Be careful with the term code of conduct as this is a term of art in GDPR. Data processing agreement may be the more appropriate term here. Subsection G · No comments. Subsection H · With respect to the last sentence, this is already a requirement in the Registration Accreditation Agreement - curious why it needs to be included here. · Under the Temp Spec, the WHOIS inaccuracy process isn’t able to be utilized. · The WHOIS accuracy program has not changed, so the above statement is not correct re: the program not being utilized. Subsection I · Reverse search and wildcard search are not currently offered and this should not become part of the requirements. · These additional capabilities and functions were never part of the RDS functions - they were provided by third party data harvesting firms and should not be included here. · Functionality that hasn’t existed in the past should not be deleted as a safeguard just because it did not previously exist. · Item one for I is not being asked as a policy recommendation - simply pointing out that if there were a legal way to do this under GDPR, it would be helpful. Point 1 can be removed for purposes of this exercise. · Beware of making broad statements that certain activity is illegal or unethical. BC-2 shows where a wildcard search would be acceptable. · Wild card searches create a new role under this system as it could track registrant behavior across TLDs and registrars. We need to be careful about putting ICANN or whoever is ultimately responsible in that position. · Phishing attacks need to be mitigated quickly - and this is a factor in addressing them. Subsection J · Accreditation and authentication of users identifies who the requester of the data is. It does not and cannot mean that the request does not have to be checked. · Action: SSAC to provide an example of how accreditation can be done by whom. · There would not be a separate accreditation for an anti-phishing working group. There would not be special recognition given to groups; there would just be generic accreditation. Subsection M - P * Confirm next steps · ACTION: EPDP Team to provide additional input, via the comment functionality, to the google sheet for the SSAC use case ideally by Friday, August 2, but at the latest by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 6. Use case – first reading: Online buyers identifying and validating the source or services/ Internet users validating the legitimacy of an email or a website to protect themselves<https://community.icann.org/display/EOTSFGRD/d.+Use+Cases?preview=/111386876...> (60 minutes) 1. Introduction of use case (ALAC) · Because the group is not currently distinguishing b/w legal and natural persons, the use case may need to be altered when it does discuss legal vs. natural. · Consumer protection is within ICANN’s mission. · This use case touches on online buyers or internet users who are trying to purchase services or goods in order to verify the legitimacy of the website they are dealing with. This use case is referencing commercial websites. · The data elements that would be required for this use case is the contact information. The lawful basis for this would be 6(1)(f). · There is a wider public benefit here - for ordinary users to confirm the legitimacy of a website is a benefit to the users to report a website before they are victims. · There is likely no need for accreditation here. Input from EPDP Team – questions, concerns, proposed modifications · The key issue here that suggests that this is a use case that should be discarded is the distinction b/w ex-post and ex ante checking. Being able to not find information on a website is not, in and of itself, a crime unless it is in a jx that requires the posting of information. As a consumer, you have the right to refuse to do business if you do not feel comfortable with the validity of the website. If a consumer has been defrauded (ex-post), that is another use case. · Clarifying question: the user makes a typical 6(1)(f) request, and the data controller will look at it - if the controller has a legal vs. natural distinction ability, they would use this. What if they don’t? · There is a fundamental flaw in this use case in that it conflates the registrant of the domain name and the operator of the website, particularly in marketplaces which connect buyers and sellers (like eBay, for example). Holding up WHOIS data vs. use/adoption of SSL certificates is worrisome. If a consumer is defrauded, that would be a different use case, which is probably LEA. · It is time to move on - the conflation of domain name provider and operator of the business is a problem. Consumers should not be encouraged to get data via WHOIS. If you cannot tell who you are dealing with via the website, the consumer should choose not to deal with them. Web presence is not within ICANN’s remit. · The case will also be published on Google Docs for those who would like to include comments. · The FTC issued a statement re: how the WHOIS database is critical to consumers. · The intent of this use case is not to be speculative, but rather, an egregious case. Perhaps the earlier sections need to be reworded. Local law enforcement will not take a case against an organization that is likely outside of its jurisdiction. 1. Confirm next steps * ACTION: EPDP Team to provide additional input, via the comment functionality, to the google sheet for the ALAC use case ideally by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 7. Any other business (5 minutes) 1. Priority 2 small team meetings update · Accuracy and WHOIS ARS (see https://docs.google.com/document/d/1pS9Pibanj-Hp6LztZpeERtxdoLsnp4y_-do0vU5V...) · Input received on other priority 2 items from RrSG (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-June/002174.html) · Leadership to recommend next steps via mailing list 2. Council request for input on org letter requesting clarification on Data Accuracy and Phase-2 (see https://gnso.icann.org/sites/default/files/file/field-file-attach/marby-to-d...). EPDP Team to provide input on the mailing list. Confirm deadline for input. 8. Wrap and confirm next EPDP Team meeting on Thursday 8 August 2019 at 14.00 UTC (5 minutes) * Confirm action items * Confirm questions for ICANN Org, if any
Hello Team, The GDPR makes a distinction between legal and natural persons and because we are making our own laws, and not applying this distinction, we find ourselves compelled to present the online buyers use case. This use case and I assume many others that are not explored yet, only exist because we do not make the distinction between legal and natural persons. We insist on protecting legal persons, which GDPR does not apply to. Under GDPR what we are asking for through this use case is totally permissible. Best Hadia Elminiawi ________________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> Sent: 03 August 2019 21:09 To: Caitlin Tubergen; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 Hello Team, Please find below my reply to the concerns raised in relation to the online buyers use case Concern:The key issue here that suggests that this is a use case that should be discarded is the distinction b/w ex-post and ex ante checking. Being able to not find information on a website is not, in and of itself, a crime unless it is in a jx that requires the posting of information. As a consumer, you have the right to refuse to do business if you do not feel comfortable with the validity of the website. If a consumer has been defrauded (ex-post), that is another use case. Reply:Yes the whole point about this use case is to have a path through which Internet users are able to do ex-ante checking about a website that they are about to make a purchase/get a service from. If a customer suspects that there, is an attempt to steel information from him/her there should be a path through which he can try to validate the website and hence report it. Being able to report domain names before becoming actual victims has a wider public benefit. In addition, absent of such a mechanism users will always prefer well known online sellers, leaving very little room for competition and smaller businesses. This use case is one of the means to protect customers from fraud, giving online buyers a proactive role. Having such a mechanism is of benefit to both business owners and customers, enhancing online buyers trust in the electronic marketplace. Clarifying question: the user makes a typical 6(1)(f) request, and the data controller will look at it - if the controller has a legal vs. natural distinction ability, they would use this. What if they don’t? Reply:The whole point about this use case is not to rely on the distinction between legal vs natural persons. GDPR does not cover the processing of personal information of legal persons and thus if we are to rely on the legal vs natural distinction for disclosure the legal basis won’t be 6(1)f because it is allowed and would also require no balancing test. The requester is required to prove that he/she is trying to make a commercial activity with the specified domain name (that does not mean that the domain name has to be registered as a legal entity). The controller is to look into the request and if he finds it legitimate (regardless of whether the organization is registered as a legal entity or not) then the data could be disclosed under 6(1)f, where preventing fraud is a legitimate interest under GDPR (recital 47) Concern:There is a fundamental flaw in this use case in that it conflates the registrant of the domain name and the operator of the website, particularly in marketplaces which connect buyers and sellers (like eBay, for example). Holding up WHOIS data vs. use/adoption of SSL certificates is worrisome. If a consumer is defrauded, that would be a different use case, which is probably LEA. It is time to move on - the conflation of domain name provider and operator of the business is a problem. Consumers should not be encouraged to get data via WHOIS. If you cannot tell who you are dealing with via the website, the consumer should choose not to deal with them. Web presence is not within ICANN’s remit. Reply:Marketplaces that connect buyers and sellers usually have customer support through which buyers can seek help or ask questions, they also provide tips on how to know your seller better. In all cases, the marketplace does not only depend on those who connect buyers and sellers. Giving the consumers the opportunity of having a proactive role is important. ICANN’s remit certainly includes consumer protection and enhancing competition, which this use case enables. Best Hadia ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen@icann.org> Sent: 01 August 2019 19:44 To: gnso-epdp-team@icann.org Subject: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 Dear EPDP Team: Please find notes and action items from today’s EPDP Team meeting below. As a reminder, the next EPDP Team meeting will be Thursday, 8 August at 14:00 UTC. Thank you. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #11 Thursday, 1 August 2019 at 14.00 UTC Action Items 1. EPDP Team to review the early input documents (the SSAD worksheet and the Google doc) that have been posted. Leadership will devote time to going over the input at the EPDP Team meeting in two weeks’ time. 2. Further to the EPDP Team request, Staff support will put up the use cases as google doc, with the understanding that the author will hold the pen in making updates / changes based on the input provided. 3. EPDP Team to provide additional input, via the comment functionality, to the google sheet for the SSAC use case ideally by Friday, August 2, but at the latest by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 4. EPDP Team to provide additional input, via the comment functionality, to the google sheet for the ALAC use case ideally by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 5. SSAC to incorporate feedback from the EPDP Team in advance of the next EPDP Team meeting; the updates should also include an example of how accreditation can be done and by whom. Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ. EPDP Phase 2 - Meeting #11 Proposed Agenda Thursday, 1 August 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) · Attendance will be taken from Zoom · Remember to mute your microphones upon entry to Zoom. · Please state your name before speaking for transcription purposes. · Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Confirmation of agenda (Chair) · Following comments made after the previous call regarding postponement of the accreditation discussion, EPDP Leadership proposed to continue discussion of use cases. · No objections to the agenda. 3. Welcome and housekeeping issues (Chair) (10 minutes) 1. Early input review – next steps · Some groups noted a further discussion of the early input submitted was needed. · Question to the Team: when will groups be prepared to discuss the early input received from the different groups? EPDP Team Feedback: · GAC will be sending in its early input today. · Support Staff was planning to review the input and take it into account when drafting recommendations for the Initial Report. When drafting, Support Staff plans to flag any opposing views or areas of disagreement that may need further discussion within the EPDP Team. · With respect to requirements around early input, there is an expectation that early input is reviewed by the Working Group. The Support Team has used the early input review tool to facilitate this review: https://community.icann.org/x/zIWGBg. In short, did the WG agree, disagree, and/or how does the WG plan to respond to the input. · Is there a way to incorporate the feedback into the worksheets and review the input as the WG deliberates on the respective topics? Answer: yes, Support Staff already incorporated the early input into the SSAD worksheets per the previous request of the EPDP Team. · The RrSG provided its early input prior to the deadline and also provided comments to a Google Doc - was this homework submitted properly? Answer: yes, the RrSG comments were received. · Not clear on what the purpose of this exercise is. · This is a GNSO requirement. · There seems to be a low level of interest in reviewing early input. Perhaps the Team can defer reviewing the early input as such and review it when the respective topics are discussed within the SSAD worksheet. · There are two separate activities Support Staff undertook at the request of the Team: (1) incorporate the early input into the SSAD worksheet, noting the relevant categories/topics; (2) create a Google Doc that allows groups to provide feedback on the early input received. Some of the input may relate to additional Charter questions, so the group may want to consider additional questions or topics as a result of feedback rather than assuming all input relates to topics already noted in the worksheet. · Chair proposal: · ACTION: EPDP Team to review the early input documents (both the SSAD worksheet and the Google Doc for providing feedback). Leadership will devote some time to going over the input in two weeks time. 4. Use Cases Categorization (10 minutes) * Review results of the survey · The document on the screen represents the survey sent next week. · This categorization of use cases was put together by a small team - with the understanding that it may be possible to derive common conclusions from use cases that are deemed similar. · The objective of the survey was to identify the use case that was deemed the most representative of the group. Note: this does not mean the other use cases would not be considered. · Six groups responded to the survey. Some of the use cases were very close, so EPDP Leadership made some suggestions. · The proposed schedule also includes proposed deadlines. By Friday after the first reading, all proposed EPDP Team edits/concerns need to be submitted to the list. This will allow the author, with Staff Support assistance (if desired), to update the use case in advance of the next meeting, during which the second reading will occur. · The use case review will continue into late August. Then the group will need to consider what other use cases need to be considered or reviewed. Toward the end of August/early September, Leadership and Staff Support hope to share draft policy principles derived from the commonalities, which can serve as the basis for the F2F discussion. * Confirm review order and schedule · Could SSAC-3 be reviewed next week? · The purpose of today’s reading is to raise concerns and not necessarily to answer them, which means Greg will have the ability to review the concerns and address them during the second reading, which will be next week. · Procedural suggestion: it is difficult to go back and forth in an email thread. Perhaps the group can consider using Google Docs? · Staff support will put it up the use cases as a google doc, with the understanding that the author will hold the pen in making updates / changes based on the input provided. · ALAC is not sure it would be a good use of time to review the ALAC use case today. · Groups should not be advocating a use case where something is always right/data will always be disclosed - these should be generic cases, wherein another member or alternate in the group should be able to discuss. In terms of manual balancing tests, this activity still needs to be discussed. 5. Use case – first reading continued: Investigation of criminal activity where domain names are used. Typical specific example: phishing attack<https://community.icann.org/download/attachments/111386876/SSAC%20Crime-Abus...> (45 minutes) * Input from EPDP Team – questions, concerns, proposed modifications · The purpose of this reading is to continue last week’s discussion. Subsection B · With respect to phishing, non-law enforcement parties are concerned with taking down the domain name to block or mitigate phishing. They may not be interested in attribution and/or prosecution. These activities may need to be broken down into those specific cases in which disclosure of nonpublic information is necessary. · Attribution is necessary here to capture the gamut of domain names involved in the phishing enterprise. · With respect to task 3, accuracy of contact data is always desirable. With respect to inaccurate information, though, this may not be a sign of bad faith or criminal activity. With respect to cross-field address validation, there are many false positives. Cross-field address validation does not solve the issue; it sometimes exacerbates the issue. · If the Team is discussing a generic SSAC use case, this includes the need for disclosure of RDS data. · There is a challenge that if the use case is too specific, there will be too many use cases, but if they are too generic, there is an argument that it may not be specific enough. · Not arguing for proliferation of use cases, but rather discussing when disclosure is necessary. For example - Task 4 - suspending a domain name does not require disclosure. Task 2 - IP address is public in WHOIS records, so no disclosure is needed for that. Task 5 - borderline case - you could need disclosure, but perhaps it could be turned over to law enforcement. Task 3 - agree with GoDaddy that this is a completely different use case and is not part of mitigation of phishing. The tasks should be winnowed down to those that actually require disclosure. The tasks that are thrown out do not need to become new use cases. · Necessary under GDPR means reasonably necessary. With respect to Task 3, just because data is inaccurate does not mean there is fraud; however, when data is falsified, that typically does indicate fraud. · With respect to Task 4, how data is handled once it has been processed is important to consider. The way this use case is laid out allows the Team to see how the data is handled when it has already been disclosed. · Need a better understanding on what the Team will do with the use cases, and how do they trickle up to policy recommendations. · The use cases will be provided as an illustration for how the EPDP Team got to its recommendations. · While this is a useful case as a discussion instrument, request adding a footnote that this is a discussion instrument only. Secondly, on the accuracy issue - if inaccurate data shows criminal intent, we should consider taking down credit reporting bureaus. If this group has no delegation under law to prosecute, it cannot collect personal data. Just because this happens does not make it correct. Subsection C · Is tech contact still collected? If so, this should be removed from this report. · Tech contact may still be collected under Phase 1 recommendations. · Tech contact physical address was eliminated in Phase 1. · The specific data elements to be requested should be limited to the request at hand - if they are not needed for the specific investigation, they should not be requested/disclosed. Subsection D/E · Issue with the number of lawful bases for the parties here. Vital interest is a very difficult lawful basis - very few instances where this lawful basis can be used, so it is probably unrealistic for phishing. 6(1)(f) or 6(1)(c) may be better. · Subsection D looks like a shotgun approach to applying a lawful basis. This increases rather than decreases the vulnerability that this will be challenged. · How does 6(1)(b) apply to this use case? There is no description in Subsection E for how this will apply. · It may be of interest to look at BC-1 when reviewing these lawful bases, specifically 6(1)(b) and 6(1)(d). In this case, human trafficking may be involved, though in BC-1, BC elected not to include 6(1)(d). · As written, Subsections D and E do look like a shotgun approach. In the overwhelming majority of these cases, SSAC recognizes that 6(1)(f) would be the applicable lawful basis. There are limited edge cases, where a contract for phishing mitigation or similar is used and where 6(1)(b) would be applicable. · When writing these use cases, some of this discussion is premature until the Team receives further legal advice about lawful basis. · All lawful bases need to be deleted except 6(1)(f). The other lawful bases may be relevant for different use cases, but not this one. Subsection F · Be careful with the term code of conduct as this is a term of art in GDPR. Data processing agreement may be the more appropriate term here. Subsection G · No comments. Subsection H · With respect to the last sentence, this is already a requirement in the Registration Accreditation Agreement - curious why it needs to be included here. · Under the Temp Spec, the WHOIS inaccuracy process isn’t able to be utilized. · The WHOIS accuracy program has not changed, so the above statement is not correct re: the program not being utilized. Subsection I · Reverse search and wildcard search are not currently offered and this should not become part of the requirements. · These additional capabilities and functions were never part of the RDS functions - they were provided by third party data harvesting firms and should not be included here. · Functionality that hasn’t existed in the past should not be deleted as a safeguard just because it did not previously exist. · Item one for I is not being asked as a policy recommendation - simply pointing out that if there were a legal way to do this under GDPR, it would be helpful. Point 1 can be removed for purposes of this exercise. · Beware of making broad statements that certain activity is illegal or unethical. BC-2 shows where a wildcard search would be acceptable. · Wild card searches create a new role under this system as it could track registrant behavior across TLDs and registrars. We need to be careful about putting ICANN or whoever is ultimately responsible in that position. · Phishing attacks need to be mitigated quickly - and this is a factor in addressing them. Subsection J · Accreditation and authentication of users identifies who the requester of the data is. It does not and cannot mean that the request does not have to be checked. · Action: SSAC to provide an example of how accreditation can be done by whom. · There would not be a separate accreditation for an anti-phishing working group. There would not be special recognition given to groups; there would just be generic accreditation. Subsection M - P * Confirm next steps · ACTION: EPDP Team to provide additional input, via the comment functionality, to the google sheet for the SSAC use case ideally by Friday, August 2, but at the latest by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 6. Use case – first reading: Online buyers identifying and validating the source or services/ Internet users validating the legitimacy of an email or a website to protect themselves<https://community.icann.org/display/EOTSFGRD/d.+Use+Cases?preview=/111386876...> (60 minutes) 1. Introduction of use case (ALAC) · Because the group is not currently distinguishing b/w legal and natural persons, the use case may need to be altered when it does discuss legal vs. natural. · Consumer protection is within ICANN’s mission. · This use case touches on online buyers or internet users who are trying to purchase services or goods in order to verify the legitimacy of the website they are dealing with. This use case is referencing commercial websites. · The data elements that would be required for this use case is the contact information. The lawful basis for this would be 6(1)(f). · There is a wider public benefit here - for ordinary users to confirm the legitimacy of a website is a benefit to the users to report a website before they are victims. · There is likely no need for accreditation here. Input from EPDP Team – questions, concerns, proposed modifications · The key issue here that suggests that this is a use case that should be discarded is the distinction b/w ex-post and ex ante checking. Being able to not find information on a website is not, in and of itself, a crime unless it is in a jx that requires the posting of information. As a consumer, you have the right to refuse to do business if you do not feel comfortable with the validity of the website. If a consumer has been defrauded (ex-post), that is another use case. · Clarifying question: the user makes a typical 6(1)(f) request, and the data controller will look at it - if the controller has a legal vs. natural distinction ability, they would use this. What if they don’t? · There is a fundamental flaw in this use case in that it conflates the registrant of the domain name and the operator of the website, particularly in marketplaces which connect buyers and sellers (like eBay, for example). Holding up WHOIS data vs. use/adoption of SSL certificates is worrisome. If a consumer is defrauded, that would be a different use case, which is probably LEA. · It is time to move on - the conflation of domain name provider and operator of the business is a problem. Consumers should not be encouraged to get data via WHOIS. If you cannot tell who you are dealing with via the website, the consumer should choose not to deal with them. Web presence is not within ICANN’s remit. · The case will also be published on Google Docs for those who would like to include comments. · The FTC issued a statement re: how the WHOIS database is critical to consumers. · The intent of this use case is not to be speculative, but rather, an egregious case. Perhaps the earlier sections need to be reworded. Local law enforcement will not take a case against an organization that is likely outside of its jurisdiction. 1. Confirm next steps * ACTION: EPDP Team to provide additional input, via the comment functionality, to the google sheet for the ALAC use case ideally by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 7. Any other business (5 minutes) 1. Priority 2 small team meetings update · Accuracy and WHOIS ARS (see https://docs.google.com/document/d/1pS9Pibanj-Hp6LztZpeERtxdoLsnp4y_-do0vU5V...) · Input received on other priority 2 items from RrSG (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-June/002174.html) · Leadership to recommend next steps via mailing list 2. Council request for input on org letter requesting clarification on Data Accuracy and Phase-2 (see https://gnso.icann.org/sites/default/files/file/field-file-attach/marby-to-d...). EPDP Team to provide input on the mailing list. Confirm deadline for input. 8. Wrap and confirm next EPDP Team meeting on Thursday 8 August 2019 at 14.00 UTC (5 minutes) * Confirm action items * Confirm questions for ICANN Org, if any _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Hadia, actually, this distinction is - as we have said again and again - incorrect. The GDPR does not "make a distinction between legal and natural persons", it protects the _data_ of natural persons, where ever and in what ever form it may reside. Thus, legal person data can contain or consist entirely of personal data of natural persons and there is not automated method of figuring out if it does or not (to my knowledge). This is a discussion that has been had over and over again in various ICANN working groups and the decision has been - every time - to not make a differentiation. We could now open up this box of Pandora again and re-fight this issue again, wasting valuable weeks in our race to meet the aspirational goal for doing our work, or we can finally let the dead horse rest and simply refer to the previous work of the community. We have little enough time as it is and I cannot see the outcome changing. I also re-iterate by firm belief that any consumer buying goods on a website that does not contain any information on who operates it and how to contact the operator has no one to blame but himself. Following from that, I agree that a legal entity or an entity engaging in commercial activities should put this information on their websites for their customers to see as not doing so reduces the level of trust a consumer should put in them. I know I am pampered by European legislation requiring the same, but seriously, this should be best practice everywhere even if not required by law. Whois is not and never was intended to be a good tool for consumer protection. -- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Thu, Aug 8, 2019 at 7:18 PM Hadia Abdelsalam Mokhtar EL miniawi < Hadia@tra.gov.eg> wrote:
Hello Team,
The GDPR makes a distinction between legal and natural persons and because we are making our own laws, and not applying this distinction, we find ourselves compelled to present the online buyers use case. This use case and I assume many others that are not explored yet, only exist because we do not make the distinction between legal and natural persons. We insist on protecting legal persons, which GDPR does not apply to. Under GDPR what we are asking for through this use case is totally permissible.
Best Hadia Elminiawi ________________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> Sent: 03 August 2019 21:09 To: Caitlin Tubergen; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019
Hello Team,
Please find below my reply to the concerns raised in relation to the online buyers use case
Concern:The key issue here that suggests that this is a use case that should be discarded is the distinction b/w ex-post and ex ante checking. Being able to not find information on a website is not, in and of itself, a crime unless it is in a jx that requires the posting of information. As a consumer, you have the right to refuse to do business if you do not feel comfortable with the validity of the website. If a consumer has been defrauded (ex-post), that is another use case.
Reply:Yes the whole point about this use case is to have a path through which Internet users are able to do ex-ante checking about a website that they are about to make a purchase/get a service from. If a customer suspects that there, is an attempt to steel information from him/her there should be a path through which he can try to validate the website and hence report it. Being able to report domain names before becoming actual victims has a wider public benefit. In addition, absent of such a mechanism users will always prefer well known online sellers, leaving very little room for competition and smaller businesses. This use case is one of the means to protect customers from fraud, giving online buyers a proactive role. Having such a mechanism is of benefit to both business owners and customers, enhancing online buyers trust in the electronic marketplace.
Clarifying question: the user makes a typical 6(1)(f) request, and the data controller will look at it - if the controller has a legal vs. natural distinction ability, they would use this. What if they don’t?
Reply:The whole point about this use case is not to rely on the distinction between legal vs natural persons. GDPR does not cover the processing of personal information of legal persons and thus if we are to rely on the legal vs natural distinction for disclosure the legal basis won’t be 6(1)f because it is allowed and would also require no balancing test. The requester is required to prove that he/she is trying to make a commercial activity with the specified domain name (that does not mean that the domain name has to be registered as a legal entity). The controller is to look into the request and if he finds it legitimate (regardless of whether the organization is registered as a legal entity or not) then the data could be disclosed under 6(1)f, where preventing fraud is a legitimate interest under GDPR (recital 47)
Concern:There is a fundamental flaw in this use case in that it conflates the registrant of the domain name and the operator of the website, particularly in marketplaces which connect buyers and sellers (like eBay, for example). Holding up WHOIS data vs. use/adoption of SSL certificates is worrisome. If a consumer is defrauded, that would be a different use case, which is probably LEA.
It is time to move on - the conflation of domain name provider and operator of the business is a problem. Consumers should not be encouraged to get data via WHOIS. If you cannot tell who you are dealing with via the website, the consumer should choose not to deal with them. Web presence is not within ICANN’s remit.
Reply:Marketplaces that connect buyers and sellers usually have customer support through which buyers can seek help or ask questions, they also provide tips on how to know your seller better. In all cases, the marketplace does not only depend on those who connect buyers and sellers. Giving the consumers the opportunity of having a proactive role is important. ICANN’s remit certainly includes consumer protection and enhancing competition, which this use case enables.
Best
Hadia
________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen@icann.org> Sent: 01 August 2019 19:44 To: gnso-epdp-team@icann.org Subject: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019
Dear EPDP Team:
Please find notes and action items from today’s EPDP Team meeting below.
As a reminder, the next EPDP Team meeting will be Thursday, 8 August at 14:00 UTC.
Thank you.
Best regards,
Marika, Berry, and Caitlin
--
EPDP Phase 2 - Meeting #11
Thursday, 1 August 2019 at 14.00 UTC
Action Items
1. EPDP Team to review the early input documents (the SSAD worksheet and the Google doc) that have been posted. Leadership will devote time to going over the input at the EPDP Team meeting in two weeks’ time. 2. Further to the EPDP Team request, Staff support will put up the use cases as google doc, with the understanding that the author will hold the pen in making updates / changes based on the input provided. 3. EPDP Team to provide additional input, via the comment functionality, to the google sheet for the SSAC use case ideally by Friday, August 2, but at the latest by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 4. EPDP Team to provide additional input, via the comment functionality, to the google sheet for the ALAC use case ideally by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 5. SSAC to incorporate feedback from the EPDP Team in advance of the next EPDP Team meeting; the updates should also include an example of how accreditation can be done and by whom.
Notes
These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ.
EPDP Phase 2 - Meeting #11
Proposed Agenda
Thursday, 1 August 2019 at 14.00 UTC
1. Roll Call & SOI Updates (5 minutes)
· Attendance will be taken from Zoom
· Remember to mute your microphones upon entry to Zoom.
· Please state your name before speaking for transcription purposes.
· Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team.
2. Confirmation of agenda (Chair)
· Following comments made after the previous call regarding postponement of the accreditation discussion, EPDP Leadership proposed to continue discussion of use cases.
· No objections to the agenda.
3. Welcome and housekeeping issues (Chair) (10 minutes)
1. Early input review – next steps
· Some groups noted a further discussion of the early input submitted was needed.
· Question to the Team: when will groups be prepared to discuss the early input received from the different groups?
EPDP Team Feedback:
· GAC will be sending in its early input today.
· Support Staff was planning to review the input and take it into account when drafting recommendations for the Initial Report. When drafting, Support Staff plans to flag any opposing views or areas of disagreement that may need further discussion within the EPDP Team.
· With respect to requirements around early input, there is an expectation that early input is reviewed by the Working Group. The Support Team has used the early input review tool to facilitate this review: https://community.icann.org/x/zIWGBg. In short, did the WG agree, disagree, and/or how does the WG plan to respond to the input.
· Is there a way to incorporate the feedback into the worksheets and review the input as the WG deliberates on the respective topics? Answer: yes, Support Staff already incorporated the early input into the SSAD worksheets per the previous request of the EPDP Team.
· The RrSG provided its early input prior to the deadline and also provided comments to a Google Doc - was this homework submitted properly? Answer: yes, the RrSG comments were received.
· Not clear on what the purpose of this exercise is.
· This is a GNSO requirement.
· There seems to be a low level of interest in reviewing early input. Perhaps the Team can defer reviewing the early input as such and review it when the respective topics are discussed within the SSAD worksheet.
· There are two separate activities Support Staff undertook at the request of the Team: (1) incorporate the early input into the SSAD worksheet, noting the relevant categories/topics; (2) create a Google Doc that allows groups to provide feedback on the early input received. Some of the input may relate to additional Charter questions, so the group may want to consider additional questions or topics as a result of feedback rather than assuming all input relates to topics already noted in the worksheet.
· Chair proposal:
· ACTION: EPDP Team to review the early input documents (both the SSAD worksheet and the Google Doc for providing feedback). Leadership will devote some time to going over the input in two weeks time.
4. Use Cases Categorization (10 minutes)
* Review results of the survey
· The document on the screen represents the survey sent next week.
· This categorization of use cases was put together by a small team - with the understanding that it may be possible to derive common conclusions from use cases that are deemed similar.
· The objective of the survey was to identify the use case that was deemed the most representative of the group. Note: this does not mean the other use cases would not be considered.
· Six groups responded to the survey. Some of the use cases were very close, so EPDP Leadership made some suggestions.
· The proposed schedule also includes proposed deadlines. By Friday after the first reading, all proposed EPDP Team edits/concerns need to be submitted to the list. This will allow the author, with Staff Support assistance (if desired), to update the use case in advance of the next meeting, during which the second reading will occur.
· The use case review will continue into late August. Then the group will need to consider what other use cases need to be considered or reviewed. Toward the end of August/early September, Leadership and Staff Support hope to share draft policy principles derived from the commonalities, which can serve as the basis for the F2F discussion.
* Confirm review order and schedule
· Could SSAC-3 be reviewed next week?
· The purpose of today’s reading is to raise concerns and not necessarily to answer them, which means Greg will have the ability to review the concerns and address them during the second reading, which will be next week.
· Procedural suggestion: it is difficult to go back and forth in an email thread. Perhaps the group can consider using Google Docs?
· Staff support will put it up the use cases as a google doc, with the understanding that the author will hold the pen in making updates / changes based on the input provided.
· ALAC is not sure it would be a good use of time to review the ALAC use case today.
· Groups should not be advocating a use case where something is always right/data will always be disclosed - these should be generic cases, wherein another member or alternate in the group should be able to discuss. In terms of manual balancing tests, this activity still needs to be discussed.
5. Use case – first reading continued: Investigation of criminal activity where domain names are used. Typical specific example: phishing attack< https://community.icann.org/download/attachments/111386876/SSAC%20Crime-Abus...> (45 minutes)
* Input from EPDP Team – questions, concerns, proposed modifications
· The purpose of this reading is to continue last week’s discussion.
Subsection B
· With respect to phishing, non-law enforcement parties are concerned with taking down the domain name to block or mitigate phishing. They may not be interested in attribution and/or prosecution. These activities may need to be broken down into those specific cases in which disclosure of nonpublic information is necessary.
· Attribution is necessary here to capture the gamut of domain names involved in the phishing enterprise.
· With respect to task 3, accuracy of contact data is always desirable. With respect to inaccurate information, though, this may not be a sign of bad faith or criminal activity. With respect to cross-field address validation, there are many false positives. Cross-field address validation does not solve the issue; it sometimes exacerbates the issue.
· If the Team is discussing a generic SSAC use case, this includes the need for disclosure of RDS data.
· There is a challenge that if the use case is too specific, there will be too many use cases, but if they are too generic, there is an argument that it may not be specific enough.
· Not arguing for proliferation of use cases, but rather discussing when disclosure is necessary. For example - Task 4 - suspending a domain name does not require disclosure. Task 2 - IP address is public in WHOIS records, so no disclosure is needed for that. Task 5 - borderline case - you could need disclosure, but perhaps it could be turned over to law enforcement. Task 3 - agree with GoDaddy that this is a completely different use case and is not part of mitigation of phishing. The tasks should be winnowed down to those that actually require disclosure. The tasks that are thrown out do not need to become new use cases.
· Necessary under GDPR means reasonably necessary. With respect to Task 3, just because data is inaccurate does not mean there is fraud; however, when data is falsified, that typically does indicate fraud.
· With respect to Task 4, how data is handled once it has been processed is important to consider. The way this use case is laid out allows the Team to see how the data is handled when it has already been disclosed.
· Need a better understanding on what the Team will do with the use cases, and how do they trickle up to policy recommendations.
· The use cases will be provided as an illustration for how the EPDP Team got to its recommendations.
· While this is a useful case as a discussion instrument, request adding a footnote that this is a discussion instrument only. Secondly, on the accuracy issue - if inaccurate data shows criminal intent, we should consider taking down credit reporting bureaus. If this group has no delegation under law to prosecute, it cannot collect personal data. Just because this happens does not make it correct.
Subsection C
· Is tech contact still collected? If so, this should be removed from this report.
· Tech contact may still be collected under Phase 1 recommendations.
· Tech contact physical address was eliminated in Phase 1.
· The specific data elements to be requested should be limited to the request at hand - if they are not needed for the specific investigation, they should not be requested/disclosed.
Subsection D/E
· Issue with the number of lawful bases for the parties here. Vital interest is a very difficult lawful basis - very few instances where this lawful basis can be used, so it is probably unrealistic for phishing. 6(1)(f) or 6(1)(c) may be better.
· Subsection D looks like a shotgun approach to applying a lawful basis. This increases rather than decreases the vulnerability that this will be challenged.
· How does 6(1)(b) apply to this use case? There is no description in Subsection E for how this will apply.
· It may be of interest to look at BC-1 when reviewing these lawful bases, specifically 6(1)(b) and 6(1)(d). In this case, human trafficking may be involved, though in BC-1, BC elected not to include 6(1)(d).
· As written, Subsections D and E do look like a shotgun approach. In the overwhelming majority of these cases, SSAC recognizes that 6(1)(f) would be the applicable lawful basis. There are limited edge cases, where a contract for phishing mitigation or similar is used and where 6(1)(b) would be applicable.
· When writing these use cases, some of this discussion is premature until the Team receives further legal advice about lawful basis.
· All lawful bases need to be deleted except 6(1)(f). The other lawful bases may be relevant for different use cases, but not this one.
Subsection F
· Be careful with the term code of conduct as this is a term of art in GDPR. Data processing agreement may be the more appropriate term here.
Subsection G
· No comments.
Subsection H
· With respect to the last sentence, this is already a requirement in the Registration Accreditation Agreement - curious why it needs to be included here.
· Under the Temp Spec, the WHOIS inaccuracy process isn’t able to be utilized.
· The WHOIS accuracy program has not changed, so the above statement is not correct re: the program not being utilized.
Subsection I
· Reverse search and wildcard search are not currently offered and this should not become part of the requirements.
· These additional capabilities and functions were never part of the RDS functions - they were provided by third party data harvesting firms and should not be included here.
· Functionality that hasn’t existed in the past should not be deleted as a safeguard just because it did not previously exist.
· Item one for I is not being asked as a policy recommendation - simply pointing out that if there were a legal way to do this under GDPR, it would be helpful. Point 1 can be removed for purposes of this exercise.
· Beware of making broad statements that certain activity is illegal or unethical. BC-2 shows where a wildcard search would be acceptable.
· Wild card searches create a new role under this system as it could track registrant behavior across TLDs and registrars. We need to be careful about putting ICANN or whoever is ultimately responsible in that position.
· Phishing attacks need to be mitigated quickly - and this is a factor in addressing them.
Subsection J
· Accreditation and authentication of users identifies who the requester of the data is. It does not and cannot mean that the request does not have to be checked.
· Action: SSAC to provide an example of how accreditation can be done by whom.
· There would not be a separate accreditation for an anti-phishing working group. There would not be special recognition given to groups; there would just be generic accreditation.
Subsection M - P
* Confirm next steps
· ACTION: EPDP Team to provide additional input, via the comment functionality, to the google sheet for the SSAC use case ideally by Friday, August 2, but at the latest by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc.
6. Use case – first reading: Online buyers identifying and validating the source or services/ Internet users validating the legitimacy of an email or a website to protect themselves< https://community.icann.org/display/EOTSFGRD/d.+Use+Cases?preview=/111386876...> (60 minutes)
1. Introduction of use case (ALAC)
· Because the group is not currently distinguishing b/w legal and natural persons, the use case may need to be altered when it does discuss legal vs. natural.
· Consumer protection is within ICANN’s mission.
· This use case touches on online buyers or internet users who are trying to purchase services or goods in order to verify the legitimacy of the website they are dealing with. This use case is referencing commercial websites.
· The data elements that would be required for this use case is the contact information. The lawful basis for this would be 6(1)(f).
· There is a wider public benefit here - for ordinary users to confirm the legitimacy of a website is a benefit to the users to report a website before they are victims.
· There is likely no need for accreditation here.
Input from EPDP Team – questions, concerns, proposed modifications
· The key issue here that suggests that this is a use case that should be discarded is the distinction b/w ex-post and ex ante checking. Being able to not find information on a website is not, in and of itself, a crime unless it is in a jx that requires the posting of information. As a consumer, you have the right to refuse to do business if you do not feel comfortable with the validity of the website. If a consumer has been defrauded (ex-post), that is another use case.
· Clarifying question: the user makes a typical 6(1)(f) request, and the data controller will look at it - if the controller has a legal vs. natural distinction ability, they would use this. What if they don’t?
· There is a fundamental flaw in this use case in that it conflates the registrant of the domain name and the operator of the website, particularly in marketplaces which connect buyers and sellers (like eBay, for example). Holding up WHOIS data vs. use/adoption of SSL certificates is worrisome. If a consumer is defrauded, that would be a different use case, which is probably LEA.
· It is time to move on - the conflation of domain name provider and operator of the business is a problem. Consumers should not be encouraged to get data via WHOIS. If you cannot tell who you are dealing with via the website, the consumer should choose not to deal with them. Web presence is not within ICANN’s remit.
· The case will also be published on Google Docs for those who would like to include comments.
· The FTC issued a statement re: how the WHOIS database is critical to consumers.
· The intent of this use case is not to be speculative, but rather, an egregious case. Perhaps the earlier sections need to be reworded. Local law enforcement will not take a case against an organization that is likely outside of its jurisdiction.
1. Confirm next steps * ACTION: EPDP Team to provide additional input, via the comment functionality, to the google sheet for the ALAC use case ideally by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc.
7. Any other business (5 minutes)
1. Priority 2 small team meetings update
· Accuracy and WHOIS ARS (see https://docs.google.com/document/d/1pS9Pibanj-Hp6LztZpeERtxdoLsnp4y_-do0vU5V... )
· Input received on other priority 2 items from RrSG (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-June/002174.html)
· Leadership to recommend next steps via mailing list
2. Council request for input on org letter requesting clarification on Data Accuracy and Phase-2 (see https://gnso.icann.org/sites/default/files/file/field-file-attach/marby-to-d...). EPDP Team to provide input on the mailing list. Confirm deadline for input.
8. Wrap and confirm next EPDP Team meeting on Thursday 8 August 2019 at 14.00 UTC (5 minutes)
* Confirm action items * Confirm questions for ICANN Org, if any
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hello all, Our SSAC team has a few points to contribute to this discussion. Volker stated that the legal/natural distinction, and options to deal with personal data contained in corporate records, has "been had over and over again in various ICANN working groups and the decision has been - every time - to not make a differentiation.” That is factually incorrect. The issue is currently unresolved, has been deferred at points, and some previous ICANN efforts did recommend differentiation mechanisms. So, let’s keep those facts in mind as discussions take place. 1. The ICANN Board resolved in May to have the ePDP “determine and resolve the Legal vs. Natural issue in Phase 2." https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b Because the issue is not decided. 1. The EWG recommended a differentiation solution -- that registrants be required to identify as a Registrant Type, with Legal Person and Natural Person among the options. It also required that a mandatory Business PBC be published for “Registrants that self-identify as Legal Persons engaged in commercial activity" (pages 42-44 of final report). 1. ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Law was reviewed by the GNSO and revised in mid-2017. A goal of the Procedure was “to resolve the problem in a manner that preserves the ability of the registrar/registry to comply with its [current] contractual WHOIS obligations to the greatest extent possible”. So -- to publish as much data as possible as allowed by law. 1. Under that Procedure, about the only precedent was the .TEL case, which addressed concerns raised by UK privacy law. In that case, the WHOIS service was made to differentiate between natural and legal persons. Some public WHOIS data was limited for natural persons who had elected to withhold their personal information from disclosure by the WHOIS service, records for Legal Persons had to return full and complete WHOIS data (including applicable personal data), and Legal Persons were not permitted to opt out of disclosing such information. The GDPR is definitely a different law and may yield a different policy. But the .TEL case did show that it’s possible to tell the difference between a natural person’s data and a legal person’s data, and to control where that data appears. As a technical reality, not all domain names that a person may interact with in a commercial context have a website. Many domains are used solely for email and nameserver names, and a significant portion of DNS infrastructure, IoT command and control, and other “backend” services appear only in requests for addressing to be used within their particular protocols. Yet all such domains may come under scrutiny for their traffic that appears on networks, may be compromised, or when used for malicious purposes. There is no authoritative data source about domain registrations other than the RDS. ------ On Fri, Aug 9, 2019 at 6:01 AM Volker Greimann <vgreimann@key-systems.net> wrote:
Hi Hadia,
actually, this distinction is - as we have said again and again - incorrect. The GDPR does not "make a distinction between legal and natural persons", it protects the _data_ of natural persons, where ever and in what ever form it may reside. Thus, legal person data can contain or consist entirely of personal data of natural persons and there is not automated method of figuring out if it does or not (to my knowledge). This is a discussion that has been had over and over again in various ICANN working groups and the decision has been - every time - to not make a differentiation.
We could now open up this box of Pandora again and re-fight this issue again, wasting valuable weeks in our race to meet the aspirational goal for doing our work, or we can finally let the dead horse rest and simply refer to the previous work of the community. We have little enough time as it is and I cannot see the outcome changing.
I also re-iterate by firm belief that any consumer buying goods on a website that does not contain any information on who operates it and how to contact the operator has no one to blame but himself. Following from that, I agree that a legal entity or an entity engaging in commercial activities should put this information on their websites for their customers to see as not doing so reduces the level of trust a consumer should put in them. I know I am pampered by European legislation requiring the same, but seriously, this should be best practice everywhere even if not required by law. Whois is not and never was intended to be a good tool for consumer protection.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*
T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
On Thu, Aug 8, 2019 at 7:18 PM Hadia Abdelsalam Mokhtar EL miniawi < Hadia@tra.gov.eg> wrote:
Hello Team,
The GDPR makes a distinction between legal and natural persons and because we are making our own laws, and not applying this distinction, we find ourselves compelled to present the online buyers use case. This use case and I assume many others that are not explored yet, only exist because we do not make the distinction between legal and natural persons. We insist on protecting legal persons, which GDPR does not apply to. Under GDPR what we are asking for through this use case is totally permissible.
Best Hadia Elminiawi ________________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> Sent: 03 August 2019 21:09 To: Caitlin Tubergen; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019
Hello Team,
Please find below my reply to the concerns raised in relation to the online buyers use case
Concern:The key issue here that suggests that this is a use case that should be discarded is the distinction b/w ex-post and ex ante checking. Being able to not find information on a website is not, in and of itself, a crime unless it is in a jx that requires the posting of information. As a consumer, you have the right to refuse to do business if you do not feel comfortable with the validity of the website. If a consumer has been defrauded (ex-post), that is another use case.
Reply:Yes the whole point about this use case is to have a path through which Internet users are able to do ex-ante checking about a website that they are about to make a purchase/get a service from. If a customer suspects that there, is an attempt to steel information from him/her there should be a path through which he can try to validate the website and hence report it. Being able to report domain names before becoming actual victims has a wider public benefit. In addition, absent of such a mechanism users will always prefer well known online sellers, leaving very little room for competition and smaller businesses. This use case is one of the means to protect customers from fraud, giving online buyers a proactive role. Having such a mechanism is of benefit to both business owners and customers, enhancing online buyers trust in the electronic marketplace.
Clarifying question: the user makes a typical 6(1)(f) request, and the data controller will look at it - if the controller has a legal vs. natural distinction ability, they would use this. What if they don’t?
Reply:The whole point about this use case is not to rely on the distinction between legal vs natural persons. GDPR does not cover the processing of personal information of legal persons and thus if we are to rely on the legal vs natural distinction for disclosure the legal basis won’t be 6(1)f because it is allowed and would also require no balancing test. The requester is required to prove that he/she is trying to make a commercial activity with the specified domain name (that does not mean that the domain name has to be registered as a legal entity). The controller is to look into the request and if he finds it legitimate (regardless of whether the organization is registered as a legal entity or not) then the data could be disclosed under 6(1)f, where preventing fraud is a legitimate interest under GDPR (recital 47)
Concern:There is a fundamental flaw in this use case in that it conflates the registrant of the domain name and the operator of the website, particularly in marketplaces which connect buyers and sellers (like eBay, for example). Holding up WHOIS data vs. use/adoption of SSL certificates is worrisome. If a consumer is defrauded, that would be a different use case, which is probably LEA.
It is time to move on - the conflation of domain name provider and operator of the business is a problem. Consumers should not be encouraged to get data via WHOIS. If you cannot tell who you are dealing with via the website, the consumer should choose not to deal with them. Web presence is not within ICANN’s remit.
Reply:Marketplaces that connect buyers and sellers usually have customer support through which buyers can seek help or ask questions, they also provide tips on how to know your seller better. In all cases, the marketplace does not only depend on those who connect buyers and sellers. Giving the consumers the opportunity of having a proactive role is important. ICANN’s remit certainly includes consumer protection and enhancing competition, which this use case enables.
Best
Hadia
________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen@icann.org> Sent: 01 August 2019 19:44 To: gnso-epdp-team@icann.org Subject: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019
Dear EPDP Team:
Please find notes and action items from today’s EPDP Team meeting below.
As a reminder, the next EPDP Team meeting will be Thursday, 8 August at 14:00 UTC.
Thank you.
Best regards,
Marika, Berry, and Caitlin
--
EPDP Phase 2 - Meeting #11
Thursday, 1 August 2019 at 14.00 UTC
Action Items
1. EPDP Team to review the early input documents (the SSAD worksheet and the Google doc) that have been posted. Leadership will devote time to going over the input at the EPDP Team meeting in two weeks’ time. 2. Further to the EPDP Team request, Staff support will put up the use cases as google doc, with the understanding that the author will hold the pen in making updates / changes based on the input provided. 3. EPDP Team to provide additional input, via the comment functionality, to the google sheet for the SSAC use case ideally by Friday, August 2, but at the latest by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 4. EPDP Team to provide additional input, via the comment functionality, to the google sheet for the ALAC use case ideally by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 5. SSAC to incorporate feedback from the EPDP Team in advance of the next EPDP Team meeting; the updates should also include an example of how accreditation can be done and by whom.
Notes
These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ.
EPDP Phase 2 - Meeting #11
Proposed Agenda
Thursday, 1 August 2019 at 14.00 UTC
1. Roll Call & SOI Updates (5 minutes)
· Attendance will be taken from Zoom
· Remember to mute your microphones upon entry to Zoom.
· Please state your name before speaking for transcription purposes.
· Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team.
2. Confirmation of agenda (Chair)
· Following comments made after the previous call regarding postponement of the accreditation discussion, EPDP Leadership proposed to continue discussion of use cases.
· No objections to the agenda.
3. Welcome and housekeeping issues (Chair) (10 minutes)
1. Early input review – next steps
· Some groups noted a further discussion of the early input submitted was needed.
· Question to the Team: when will groups be prepared to discuss the early input received from the different groups?
EPDP Team Feedback:
· GAC will be sending in its early input today.
· Support Staff was planning to review the input and take it into account when drafting recommendations for the Initial Report. When drafting, Support Staff plans to flag any opposing views or areas of disagreement that may need further discussion within the EPDP Team.
· With respect to requirements around early input, there is an expectation that early input is reviewed by the Working Group. The Support Team has used the early input review tool to facilitate this review: https://community.icann.org/x/zIWGBg. In short, did the WG agree, disagree, and/or how does the WG plan to respond to the input.
· Is there a way to incorporate the feedback into the worksheets and review the input as the WG deliberates on the respective topics? Answer: yes, Support Staff already incorporated the early input into the SSAD worksheets per the previous request of the EPDP Team.
· The RrSG provided its early input prior to the deadline and also provided comments to a Google Doc - was this homework submitted properly? Answer: yes, the RrSG comments were received.
· Not clear on what the purpose of this exercise is.
· This is a GNSO requirement.
· There seems to be a low level of interest in reviewing early input. Perhaps the Team can defer reviewing the early input as such and review it when the respective topics are discussed within the SSAD worksheet.
· There are two separate activities Support Staff undertook at the request of the Team: (1) incorporate the early input into the SSAD worksheet, noting the relevant categories/topics; (2) create a Google Doc that allows groups to provide feedback on the early input received. Some of the input may relate to additional Charter questions, so the group may want to consider additional questions or topics as a result of feedback rather than assuming all input relates to topics already noted in the worksheet.
· Chair proposal:
· ACTION: EPDP Team to review the early input documents (both the SSAD worksheet and the Google Doc for providing feedback). Leadership will devote some time to going over the input in two weeks time.
4. Use Cases Categorization (10 minutes)
* Review results of the survey
· The document on the screen represents the survey sent next week.
· This categorization of use cases was put together by a small team - with the understanding that it may be possible to derive common conclusions from use cases that are deemed similar.
· The objective of the survey was to identify the use case that was deemed the most representative of the group. Note: this does not mean the other use cases would not be considered.
· Six groups responded to the survey. Some of the use cases were very close, so EPDP Leadership made some suggestions.
· The proposed schedule also includes proposed deadlines. By Friday after the first reading, all proposed EPDP Team edits/concerns need to be submitted to the list. This will allow the author, with Staff Support assistance (if desired), to update the use case in advance of the next meeting, during which the second reading will occur.
· The use case review will continue into late August. Then the group will need to consider what other use cases need to be considered or reviewed. Toward the end of August/early September, Leadership and Staff Support hope to share draft policy principles derived from the commonalities, which can serve as the basis for the F2F discussion.
* Confirm review order and schedule
· Could SSAC-3 be reviewed next week?
· The purpose of today’s reading is to raise concerns and not necessarily to answer them, which means Greg will have the ability to review the concerns and address them during the second reading, which will be next week.
· Procedural suggestion: it is difficult to go back and forth in an email thread. Perhaps the group can consider using Google Docs?
· Staff support will put it up the use cases as a google doc, with the understanding that the author will hold the pen in making updates / changes based on the input provided.
· ALAC is not sure it would be a good use of time to review the ALAC use case today.
· Groups should not be advocating a use case where something is always right/data will always be disclosed - these should be generic cases, wherein another member or alternate in the group should be able to discuss. In terms of manual balancing tests, this activity still needs to be discussed.
5. Use case – first reading continued: Investigation of criminal activity where domain names are used. Typical specific example: phishing attack< https://community.icann.org/download/attachments/111386876/SSAC%20Crime-Abus...> (45 minutes)
* Input from EPDP Team – questions, concerns, proposed modifications
· The purpose of this reading is to continue last week’s discussion.
Subsection B
· With respect to phishing, non-law enforcement parties are concerned with taking down the domain name to block or mitigate phishing. They may not be interested in attribution and/or prosecution. These activities may need to be broken down into those specific cases in which disclosure of nonpublic information is necessary.
· Attribution is necessary here to capture the gamut of domain names involved in the phishing enterprise.
· With respect to task 3, accuracy of contact data is always desirable. With respect to inaccurate information, though, this may not be a sign of bad faith or criminal activity. With respect to cross-field address validation, there are many false positives. Cross-field address validation does not solve the issue; it sometimes exacerbates the issue.
· If the Team is discussing a generic SSAC use case, this includes the need for disclosure of RDS data.
· There is a challenge that if the use case is too specific, there will be too many use cases, but if they are too generic, there is an argument that it may not be specific enough.
· Not arguing for proliferation of use cases, but rather discussing when disclosure is necessary. For example - Task 4 - suspending a domain name does not require disclosure. Task 2 - IP address is public in WHOIS records, so no disclosure is needed for that. Task 5 - borderline case - you could need disclosure, but perhaps it could be turned over to law enforcement. Task 3 - agree with GoDaddy that this is a completely different use case and is not part of mitigation of phishing. The tasks should be winnowed down to those that actually require disclosure. The tasks that are thrown out do not need to become new use cases.
· Necessary under GDPR means reasonably necessary. With respect to Task 3, just because data is inaccurate does not mean there is fraud; however, when data is falsified, that typically does indicate fraud.
· With respect to Task 4, how data is handled once it has been processed is important to consider. The way this use case is laid out allows the Team to see how the data is handled when it has already been disclosed.
· Need a better understanding on what the Team will do with the use cases, and how do they trickle up to policy recommendations.
· The use cases will be provided as an illustration for how the EPDP Team got to its recommendations.
· While this is a useful case as a discussion instrument, request adding a footnote that this is a discussion instrument only. Secondly, on the accuracy issue - if inaccurate data shows criminal intent, we should consider taking down credit reporting bureaus. If this group has no delegation under law to prosecute, it cannot collect personal data. Just because this happens does not make it correct.
Subsection C
· Is tech contact still collected? If so, this should be removed from this report.
· Tech contact may still be collected under Phase 1 recommendations.
· Tech contact physical address was eliminated in Phase 1.
· The specific data elements to be requested should be limited to the request at hand - if they are not needed for the specific investigation, they should not be requested/disclosed.
Subsection D/E
· Issue with the number of lawful bases for the parties here. Vital interest is a very difficult lawful basis - very few instances where this lawful basis can be used, so it is probably unrealistic for phishing. 6(1)(f) or 6(1)(c) may be better.
· Subsection D looks like a shotgun approach to applying a lawful basis. This increases rather than decreases the vulnerability that this will be challenged.
· How does 6(1)(b) apply to this use case? There is no description in Subsection E for how this will apply.
· It may be of interest to look at BC-1 when reviewing these lawful bases, specifically 6(1)(b) and 6(1)(d). In this case, human trafficking may be involved, though in BC-1, BC elected not to include 6(1)(d).
· As written, Subsections D and E do look like a shotgun approach. In the overwhelming majority of these cases, SSAC recognizes that 6(1)(f) would be the applicable lawful basis. There are limited edge cases, where a contract for phishing mitigation or similar is used and where 6(1)(b) would be applicable.
· When writing these use cases, some of this discussion is premature until the Team receives further legal advice about lawful basis.
· All lawful bases need to be deleted except 6(1)(f). The other lawful bases may be relevant for different use cases, but not this one.
Subsection F
· Be careful with the term code of conduct as this is a term of art in GDPR. Data processing agreement may be the more appropriate term here.
Subsection G
· No comments.
Subsection H
· With respect to the last sentence, this is already a requirement in the Registration Accreditation Agreement - curious why it needs to be included here.
· Under the Temp Spec, the WHOIS inaccuracy process isn’t able to be utilized.
· The WHOIS accuracy program has not changed, so the above statement is not correct re: the program not being utilized.
Subsection I
· Reverse search and wildcard search are not currently offered and this should not become part of the requirements.
· These additional capabilities and functions were never part of the RDS functions - they were provided by third party data harvesting firms and should not be included here.
· Functionality that hasn’t existed in the past should not be deleted as a safeguard just because it did not previously exist.
· Item one for I is not being asked as a policy recommendation - simply pointing out that if there were a legal way to do this under GDPR, it would be helpful. Point 1 can be removed for purposes of this exercise.
· Beware of making broad statements that certain activity is illegal or unethical. BC-2 shows where a wildcard search would be acceptable.
· Wild card searches create a new role under this system as it could track registrant behavior across TLDs and registrars. We need to be careful about putting ICANN or whoever is ultimately responsible in that position.
· Phishing attacks need to be mitigated quickly - and this is a factor in addressing them.
Subsection J
· Accreditation and authentication of users identifies who the requester of the data is. It does not and cannot mean that the request does not have to be checked.
· Action: SSAC to provide an example of how accreditation can be done by whom.
· There would not be a separate accreditation for an anti-phishing working group. There would not be special recognition given to groups; there would just be generic accreditation.
Subsection M - P
* Confirm next steps
· ACTION: EPDP Team to provide additional input, via the comment functionality, to the google sheet for the SSAC use case ideally by Friday, August 2, but at the latest by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc.
6. Use case – first reading: Online buyers identifying and validating the source or services/ Internet users validating the legitimacy of an email or a website to protect themselves< https://community.icann.org/display/EOTSFGRD/d.+Use+Cases?preview=/111386876...> (60 minutes)
1. Introduction of use case (ALAC)
· Because the group is not currently distinguishing b/w legal and natural persons, the use case may need to be altered when it does discuss legal vs. natural.
· Consumer protection is within ICANN’s mission.
· This use case touches on online buyers or internet users who are trying to purchase services or goods in order to verify the legitimacy of the website they are dealing with. This use case is referencing commercial websites.
· The data elements that would be required for this use case is the contact information. The lawful basis for this would be 6(1)(f).
· There is a wider public benefit here - for ordinary users to confirm the legitimacy of a website is a benefit to the users to report a website before they are victims.
· There is likely no need for accreditation here.
Input from EPDP Team – questions, concerns, proposed modifications
· The key issue here that suggests that this is a use case that should be discarded is the distinction b/w ex-post and ex ante checking. Being able to not find information on a website is not, in and of itself, a crime unless it is in a jx that requires the posting of information. As a consumer, you have the right to refuse to do business if you do not feel comfortable with the validity of the website. If a consumer has been defrauded (ex-post), that is another use case.
· Clarifying question: the user makes a typical 6(1)(f) request, and the data controller will look at it - if the controller has a legal vs. natural distinction ability, they would use this. What if they don’t?
· There is a fundamental flaw in this use case in that it conflates the registrant of the domain name and the operator of the website, particularly in marketplaces which connect buyers and sellers (like eBay, for example). Holding up WHOIS data vs. use/adoption of SSL certificates is worrisome. If a consumer is defrauded, that would be a different use case, which is probably LEA.
· It is time to move on - the conflation of domain name provider and operator of the business is a problem. Consumers should not be encouraged to get data via WHOIS. If you cannot tell who you are dealing with via the website, the consumer should choose not to deal with them. Web presence is not within ICANN’s remit.
· The case will also be published on Google Docs for those who would like to include comments.
· The FTC issued a statement re: how the WHOIS database is critical to consumers.
· The intent of this use case is not to be speculative, but rather, an egregious case. Perhaps the earlier sections need to be reworded. Local law enforcement will not take a case against an organization that is likely outside of its jurisdiction.
1. Confirm next steps * ACTION: EPDP Team to provide additional input, via the comment functionality, to the google sheet for the ALAC use case ideally by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc.
7. Any other business (5 minutes)
1. Priority 2 small team meetings update
· Accuracy and WHOIS ARS (see https://docs.google.com/document/d/1pS9Pibanj-Hp6LztZpeERtxdoLsnp4y_-do0vU5V... )
· Input received on other priority 2 items from RrSG (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-June/002174.html)
· Leadership to recommend next steps via mailing list
2. Council request for input on org letter requesting clarification on Data Accuracy and Phase-2 (see https://gnso.icann.org/sites/default/files/file/field-file-attach/marby-to-d...). EPDP Team to provide input on the mailing list. Confirm deadline for input.
8. Wrap and confirm next EPDP Team meeting on Thursday 8 August 2019 at 14.00 UTC (5 minutes)
* Confirm action items * Confirm questions for ICANN Org, if any
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Tara: Responses inline below: 1. The ICANN Board resolved in May to have the ePDP “determine and resolve the Legal vs. Natural issue in Phase 2." https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b Because the issue is not decided. Not quite correct. The Board noted that EPDP’s own Recommendation said that we would resolve the issue in Phase 2. The board did not tell us to do so. The resolution also notes the “Potential liability of a registered name holder's incorrect self-identification of a natural or legal person, which ultimately results in public display of personal data.” This concern was one of several that motivated our reluctance to attempt differentiation. 1. The EWG recommended a differentiation solution -- that registrants be required to identify as a Registrant Type, with Legal Person and Natural Person among the options. It also required that a mandatory Business PBC be published for “Registrants that self-identify as Legal Persons engaged in commercial activity" (pages 42-44 of final report). This option _was_ discussed and discarded in Phase 1. It was noted that to the vast majority of ordinary people the distinction between legal and natural has no meaning, and that there would be liability consequences if there were incorrect identification (see above). And besides, the recommendation of the EWG was made prior to GDPR and has no bearing on EPDP. 1. ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Law was reviewed by the GNSO and revised in mid-2017. A goal of the Procedure was “to resolve the problem in a manner that preserves the ability of the registrar/registry to comply with its [current] contractual WHOIS obligations to the greatest extent possible”. So -- to publish as much data as possible as allowed by law. Now you are way off base. Contractual Whois obligations in 2017 were not compliant with GDPR. The Conflicts with Privacy Law procedure is completely irrelevant to our proceedings. 1. Under that Procedure, about the only precedent was the .TEL case, which addressed concerns raised by UK privacy law. In that case, the WHOIS service was made to differentiate between natural and legal persons. Some public WHOIS data was limited for natural persons who had elected to withhold their personal information from disclosure by the WHOIS service, records for Legal Persons had to return full and complete WHOIS data (including applicable personal data), and Legal Persons were not permitted to opt out of disclosing such information. The GDPR is definitely a different law and may yield a different policy. But the .TEL case did show that it’s possible to tell the difference between a natural person’s data and a legal person’s data, and to control where that data appears. Same comment as above.
Hello All, The ALAC online buyers online case is a real life scenario for why there needs to be a distinction between natural and legal persons. I shall not get into this debate. However, I note that consumers identity and even location is now available to buyers through many online applications, GDPR protects personal information of natural persons and not legal persons. It is only fair to Internet end users to allow them to have the contact information of the online businesses. This is particularly important in case Internet end users are dealing with small businesses online. You can find online businesses contact details now through some existing applications. What and who are we trying to protect by not allowing this use case. Commercial websites should be encouraged to indicate who they are and publish their information. The architecture of the web inherently does not require real identity, but having a complete anonymous system is always an invitation to problems, making people feel less accountable and diminishing the trust in the network. A survey conducted by Bright Local showed that 60% of customers prefer to call small businesses on the phone. The survey also showed that consumers now look beyond websites, RDS is only one tool of many however, prohibiting it to exist works against the norm. I also note that getting clarity in relation to the contracted parties liability in this regard is very important and if implemented information should only be provided if the case is absolutely clear. I attach the updated user case, which is also available through the google doc Best Hadia el-Miniawi From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Mueller, Milton L Sent: Monday, August 19, 2019 5:27 PM To: Tara Whalen; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case Tara: Responses inline below: 1. The ICANN Board resolved in May to have the ePDP “determine and resolve the Legal vs. Natural issue in Phase 2." https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b Because the issue is not decided. Not quite correct. The Board noted that EPDP’s own Recommendation said that we would resolve the issue in Phase 2. The board did not tell us to do so. The resolution also notes the “Potential liability of a registered name holder's incorrect self-identification of a natural or legal person, which ultimately results in public display of personal data.” This concern was one of several that motivated our reluctance to attempt differentiation. 1. The EWG recommended a differentiation solution -- that registrants be required to identify as a Registrant Type, with Legal Person and Natural Person among the options. It also required that a mandatory Business PBC be published for “Registrants that self-identify as Legal Persons engaged in commercial activity" (pages 42-44 of final report). This option _was_ discussed and discarded in Phase 1. It was noted that to the vast majority of ordinary people the distinction between legal and natural has no meaning, and that there would be liability consequences if there were incorrect identification (see above). And besides, the recommendation of the EWG was made prior to GDPR and has no bearing on EPDP. 1. ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Law was reviewed by the GNSO and revised in mid-2017. A goal of the Procedure was “to resolve the problem in a manner that preserves the ability of the registrar/registry to comply with its [current] contractual WHOIS obligations to the greatest extent possible”. So -- to publish as much data as possible as allowed by law. Now you are way off base. Contractual Whois obligations in 2017 were not compliant with GDPR. The Conflicts with Privacy Law procedure is completely irrelevant to our proceedings. 1. Under that Procedure, about the only precedent was the .TEL case, which addressed concerns raised by UK privacy law. In that case, the WHOIS service was made to differentiate between natural and legal persons. Some public WHOIS data was limited for natural persons who had elected to withhold their personal information from disclosure by the WHOIS service, records for Legal Persons had to return full and complete WHOIS data (including applicable personal data), and Legal Persons were not permitted to opt out of disclosing such information. The GDPR is definitely a different law and may yield a different policy. But the .TEL case did show that it’s possible to tell the difference between a natural person’s data and a legal person’s data, and to control where that data appears. Same comment as above.
Thanks Hadia, but everything that needed to be said with regard to this use case has been said already and instead of r-iterating every argument I merely point towards what has been discussed before. This use case is not fit for RDS access. Best, Volker Am 26.08.2019 um 17:37 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
Hello All,
The ALAC online buyers online case is a real life scenario for why there needs to be a distinction between natural and legal persons. I shall not get into this debate. However, I note that consumers identity and even location is now available to buyers through many online applications, GDPR protects personal information of natural persons and not legal persons. It is only fair to Internet end users to allow them to have the contact information of the online businesses. This is particularly important in case Internet end users are dealing with small businesses online. You can find online businesses contact details now through some existing applications. What and who are we trying to protect by not allowing this use case. Commercial websites should be encouraged to indicate who they are and publish their information. The architecture of the web inherently does not require real identity, but having a complete anonymous system is always an invitation to problems, making people feel less accountable and diminishing the trust in the network. A survey conducted by Bright Local showed that 60% of customers prefer to call small businesses on the phone. The survey also showed that consumers now look beyond websites, RDS is only one tool of many however, prohibiting it to exist works against the norm. I also note that getting clarity in relation to the contracted parties liability in this regard is very important and if implemented information should only be provided if the case is absolutely clear.
I attach the updated user case, which is also available through the google doc
Best
Hadia el-Miniawi
*From:*Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] *On Behalf Of *Mueller, Milton L *Sent:* Monday, August 19, 2019 5:27 PM *To:* Tara Whalen; gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case
Tara:
Responses inline below:
1. The ICANN Board resolved in May to have the ePDP “determine and resolve the Legal vs. Natural issue in Phase 2." https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b Because the issue is not decided.
Not quite correct. The Board noted that EPDP’s own Recommendation said that we would resolve the issue in Phase 2. The board did not tell us to do so. The resolution also notes the “Potential liability of a registered name holder's incorrect self-identification of a natural or legal person, which ultimately results in public display of personal data.” This concern was one of several that motivated our reluctance to attempt differentiation.
2. The EWG recommended a differentiation solution -- that registrants be required to identify as a Registrant Type, with Legal Person and Natural Person among the options. It also required that a mandatory Business PBC be published for “Registrants that self-identify as Legal Persons engaged in commercial activity" (pages 42-44 of final report).
This option _/was/_ discussed and discarded in Phase 1. It was noted that to the vast majority of ordinary people the distinction between legal and natural has no meaning, and that there would be liability consequences if there were incorrect identification (see above). And besides, the recommendation of the EWG was made prior to GDPR and has no bearing on EPDP.
3. ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Law was reviewed by the GNSO and revised in mid-2017. A goal of the Procedure was “to resolve the problem in a manner that preserves the ability of the registrar/registry to comply with its [current] contractual WHOIS obligations to the greatest extent possible”. So -- to publish as much data as possible as allowed by law.
Now you are way off base. Contractual Whois obligations in 2017 were not compliant with GDPR. The Conflicts with Privacy Law procedure is completely irrelevant to our proceedings.
4. Under that Procedure, about the only precedent was the .TEL case, which addressed concerns raised by UK privacy law. In that case, the WHOIS service was made to differentiate between natural and legal persons. Some public WHOIS data was limited for natural persons who had elected to withhold their personal information from disclosure by the WHOIS service, records for Legal Persons had to return full and complete WHOIS data (including applicable personal data), and Legal Persons were not permitted to opt out of disclosing such information. The GDPR is definitely a different law and may yield a different policy. But the .TEL case did show that it’s possible to tell the difference between a natural person’s data and a legal person’s data, and to control where that data appears.
Same comment as above.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
+1 Volker -- Ayden ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, 26 August 2019 17:55, Volker Greimann <vgreimann@key-systems.net> wrote:
Thanks Hadia, but everything that needed to be said with regard to this use case has been said already and instead of r-iterating every argument I merely point towards what has been discussed before. This use case is not fit for RDS access.
Best,
Volker
Am 26.08.2019 um 17:37 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
Hello All,
The ALAC online buyers online case is a real life scenario for why there needs to be a distinction between natural and legal persons. I shall not get into this debate. However, I note that consumers identity and even location is now available to buyers through many online applications, GDPR protects personal information of natural persons and not legal persons. It is only fair to Internet end users to allow them to have the contact information of the online businesses. This is particularly important in case Internet end users are dealing with small businesses online. You can find online businesses contact details now through some existing applications. What and who are we trying to protect by not allowing this use case. Commercial websites should be encouraged to indicate who they are and publish their information. The architecture of the web inherently does not require real identity, but having a complete anonymous system is always an invitation to problems, making people feel less accountable and diminishing the trust in the network. A survey conducted by Bright Local showed that 60% of customers prefer to call small businesses on the phone. The survey also showed that consumers now look beyond websites, RDS is only one tool of many however, prohibiting it to exist works against the norm. I also note that getting clarity in relation to the contracted parties liability in this regard is very important and if implemented information should only be provided if the case is absolutely clear.
I attach the updated user case, which is also available through the google doc
Best
Hadia el-Miniawi
From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Mueller, Milton L Sent: Monday, August 19, 2019 5:27 PM To: Tara Whalen; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case
Tara:
Responses inline below:
- The ICANN Board resolved in May to have the ePDP “determine and resolve the Legal vs. Natural issue in Phase 2." https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b Because the issue is not decided.
Not quite correct. The Board noted that EPDP’s own Recommendation said that we would resolve the issue in Phase 2. The board did not tell us to do so. The resolution also notes the “Potential liability of a registered name holder's incorrect self-identification of a natural or legal person, which ultimately results in public display of personal data.” This concern was one of several that motivated our reluctance to attempt differentiation.
- The EWG recommended a differentiation solution -- that registrants be required to identify as a Registrant Type, with Legal Person and Natural Person among the options. It also required that a mandatory Business PBC be published for “Registrants that self-identify as Legal Persons engaged in commercial activity" (pages 42-44 of final report).
This option _was_ discussed and discarded in Phase 1. It was noted that to the vast majority of ordinary people the distinction between legal and natural has no meaning, and that there would be liability consequences if there were incorrect identification (see above). And besides, the recommendation of the EWG was made prior to GDPR and has no bearing on EPDP.
- ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Law was reviewed by the GNSO and revised in mid-2017. A goal of the Procedure was “to resolve the problem in a manner that preserves the ability of the registrar/registry to comply with its [current] contractual WHOIS obligations to the greatest extent possible”. So -- to publish as much data as possible as allowed by law.
Now you are way off base. Contractual Whois obligations in 2017 were not compliant with GDPR. The Conflicts with Privacy Law procedure is completely irrelevant to our proceedings.
- Under that Procedure, about the only precedent was the .TEL case, which addressed concerns raised by UK privacy law. In that case, the WHOIS service was made to differentiate between natural and legal persons. Some public WHOIS data was limited for natural persons who had elected to withhold their personal information from disclosure by the WHOIS service, records for Legal Persons had to return full and complete WHOIS data (including applicable personal data), and Legal Persons were not permitted to opt out of disclosing such information. The GDPR is definitely a different law and may yield a different policy. But the .TEL case did show that it’s possible to tell the difference between a natural person’s data and a legal person’s data, and to control where that data appears.
Same comment as above.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org
https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy ( https://www.icann.org/privacy/policy ) and the website Terms of Service ( https://www.icann.org/privacy/tos ). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH
T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
Hi, The issue many of us have with this use case isn’t that Internet users should not be entitled to know who they elect to do business with over the web, so I don’t believe it is necessary to keep pushing that point. The issue is that in situations where entities conducting commerce over the Web do not have their contact information readily published on their websites, ICANN/gTLD policy is an inappropriate substitute to resolve this, due to ICANN’s narrow mission. Speaking for myself, even if it were legal for ICANN to adopt policies that are beyond the scope of its mission (which I don’t think is the case here), it is undesirable for it to do so. Not having a clearly drawn line in the sand on what ICANN can regulate online via contractual compliance with Registries and Registrars, including selling and purchasing goods and services, is a prospect that I find to be very unappealing. It creates a great deal of uncertainty for both Contracted Parties providing domain name registration services, as well as registrants who utilize these services. My interpretation of consumer protection from an ICANN perspective is that registrants are THE consumers of services in the ICANN context. In that context, proposing policy recommendations beyond the scope of ICANN’s mission is bad, not good, for consumer protection. …, and like I said…, I don’t believe it to be complaint with data protection regulation, such as the GDPR, anyway. Thanks. Amr
On Aug 26, 2019, at 5:37 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Hello All,
The ALAC online buyers online case is a real life scenario for why there needs to be a distinction between natural and legal persons. I shall not get into this debate. However, I note that consumers identity and even location is now available to buyers through many online applications, GDPR protects personal information of natural persons and not legal persons. It is only fair to Internet end users to allow them to have the contact information of the online businesses. This is particularly important in case Internet end users are dealing with small businesses online. You can find online businesses contact details now through some existing applications. What and who are we trying to protect by not allowing this use case. Commercial websites should be encouraged to indicate who they are and publish their information. The architecture of the web inherently does not require real identity, but having a complete anonymous system is always an invitation to problems, making people feel less accountable and diminishing the trust in the network. A survey conducted by Bright Local showed that 60% of customers prefer to call small businesses on the phone. The survey also showed that consumers now look beyond websites, RDS is only one tool of many however, prohibiting it to exist works against the norm. I also note that getting clarity in relation to the contracted parties liability in this regard is very important and if implemented information should only be provided if the case is absolutely clear.
I attach the updated user case, which is also available through the google doc
Best
Hadia el-Miniawi
From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Mueller, Milton L Sent: Monday, August 19, 2019 5:27 PM To: Tara Whalen; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case
Tara:
Responses inline below:
- The ICANN Board resolved in May to have the ePDP “determine and resolve the Legal vs. Natural issue in Phase 2." https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b Because the issue is not decided.
Not quite correct. The Board noted that EPDP’s own Recommendation said that we would resolve the issue in Phase 2. The board did not tell us to do so. The resolution also notes the “Potential liability of a registered name holder's incorrect self-identification of a natural or legal person, which ultimately results in public display of personal data.” This concern was one of several that motivated our reluctance to attempt differentiation.
- The EWG recommended a differentiation solution -- that registrants be required to identify as a Registrant Type, with Legal Person and Natural Person among the options. It also required that a mandatory Business PBC be published for “Registrants that self-identify as Legal Persons engaged in commercial activity" (pages 42-44 of final report).
This option _was_ discussed and discarded in Phase 1. It was noted that to the vast majority of ordinary people the distinction between legal and natural has no meaning, and that there would be liability consequences if there were incorrect identification (see above). And besides, the recommendation of the EWG was made prior to GDPR and has no bearing on EPDP.
- ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Law was reviewed by the GNSO and revised in mid-2017. A goal of the Procedure was “to resolve the problem in a manner that preserves the ability of the registrar/registry to comply with its [current] contractual WHOIS obligations to the greatest extent possible”. So -- to publish as much data as possible as allowed by law.
Now you are way off base. Contractual Whois obligations in 2017 were not compliant with GDPR. The Conflicts with Privacy Law procedure is completely irrelevant to our proceedings.
- Under that Procedure, about the only precedent was the .TEL case, which addressed concerns raised by UK privacy law. In that case, the WHOIS service was made to differentiate between natural and legal persons. Some public WHOIS data was limited for natural persons who had elected to withhold their personal information from disclosure by the WHOIS service, records for Legal Persons had to return full and complete WHOIS data (including applicable personal data), and Legal Persons were not permitted to opt out of disclosing such information. The GDPR is definitely a different law and may yield a different policy. But the .TEL case did show that it’s possible to tell the difference between a natural person’s data and a legal person’s data, and to control where that data appears.
Same comment as above.
<Consumer_Protection_Use_Case_ALAC - Online buyers_Update_2.docx>
Hey Amr and all, I can’t speak authoritatively for ALAC’s intent, but I read this use case as allowing internet users to request (not have an entitlement to receive) information about a website they might do business with, a link they might click, etc. I think we’re merely talking about allowing an internet user to ask the question, without presupposing any access outcome. Does that change your perspective? I’m sympathetic to concerns raised about the bounds of ICANN’s remit, and I might find those concerns more persuasive if we were talking about guaranteed access in this case. Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Amr Elsadr Sent: Tuesday, August 27, 2019 7:28 AM To: Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case Hi, The issue many of us have with this use case isn’t that Internet users should not be entitled to know who they elect to do business with over the web, so I don’t believe it is necessary to keep pushing that point. The issue is that in situations where entities conducting commerce over the Web do not have their contact information readily published on their websites, ICANN/gTLD policy is an inappropriate substitute to resolve this, due to ICANN’s narrow mission. Speaking for myself, even if it were legal for ICANN to adopt policies that are beyond the scope of its mission (which I don’t think is the case here), it is undesirable for it to do so. Not having a clearly drawn line in the sand on what ICANN can regulate online via contractual compliance with Registries and Registrars, including selling and purchasing goods and services, is a prospect that I find to be very unappealing. It creates a great deal of uncertainty for both Contracted Parties providing domain name registration services, as well as registrants who utilize these services. My interpretation of consumer protection from an ICANN perspective is that registrants are THE consumers of services in the ICANN context. In that context, proposing policy recommendations beyond the scope of ICANN’s mission is bad, not good, for consumer protection. …, and like I said…, I don’t believe it to be complaint with data protection regulation, such as the GDPR, anyway. Thanks. Amr On Aug 26, 2019, at 5:37 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hello All, The ALAC online buyers online case is a real life scenario for why there needs to be a distinction between natural and legal persons. I shall not get into this debate. However, I note that consumers identity and even location is now available to buyers through many online applications, GDPR protects personal information of natural persons and not legal persons. It is only fair to Internet end users to allow them to have the contact information of the online businesses. This is particularly important in case Internet end users are dealing with small businesses online. You can find online businesses contact details now through some existing applications. What and who are we trying to protect by not allowing this use case. Commercial websites should be encouraged to indicate who they are and publish their information. The architecture of the web inherently does not require real identity, but having a complete anonymous system is always an invitation to problems, making people feel less accountable and diminishing the trust in the network. A survey conducted by Bright Local showed that 60% of customers prefer to call small businesses on the phone. The survey also showed that consumers now look beyond websites, RDS is only one tool of many however, prohibiting it to exist works against the norm. I also note that getting clarity in relation to the contracted parties liability in this regard is very important and if implemented information should only be provided if the case is absolutely clear. I attach the updated user case, which is also available through the google doc Best Hadia el-Miniawi From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Mueller, Milton L Sent: Monday, August 19, 2019 5:27 PM To: Tara Whalen; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case Tara: Responses inline below: 1. The ICANN Board resolved in May to have the ePDP “determine and resolve the Legal vs. Natural issue in Phase 2." https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_board-2Dmaterial_resolutions-2D2019-2D05-2D15-2Den-231.b&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=B8MS1O2ZkevjBW6hFhUe1Tfw1xhaFLotkSAAZ3g3DYQ&s=IAoMV6Yy5PfTOTRJ7D6oVAm1m5bFZMOIZHmnJjr4Gnk&e=> Because the issue is not decided. Not quite correct. The Board noted that EPDP’s own Recommendation said that we would resolve the issue in Phase 2. The board did not tell us to do so. The resolution also notes the “Potential liability of a registered name holder's incorrect self-identification of a natural or legal person, which ultimately results in public display of personal data.” This concern was one of several that motivated our reluctance to attempt differentiation. 1. The EWG recommended a differentiation solution -- that registrants be required to identify as a Registrant Type, with Legal Person and Natural Person among the options. It also required that a mandatory Business PBC be published for “Registrants that self-identify as Legal Persons engaged in commercial activity" (pages 42-44 of final report). This option _was_ discussed and discarded in Phase 1. It was noted that to the vast majority of ordinary people the distinction between legal and natural has no meaning, and that there would be liability consequences if there were incorrect identification (see above). And besides, the recommendation of the EWG was made prior to GDPR and has no bearing on EPDP. 1. ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Law was reviewed by the GNSO and revised in mid-2017. A goal of the Procedure was “to resolve the problem in a manner that preserves the ability of the registrar/registry to comply with its [current] contractual WHOIS obligations to the greatest extent possible”. So -- to publish as much data as possible as allowed by law. Now you are way off base. Contractual Whois obligations in 2017 were not compliant with GDPR. The Conflicts with Privacy Law procedure is completely irrelevant to our proceedings. 1. Under that Procedure, about the only precedent was the .TEL case, which addressed concerns raised by UK privacy law. In that case, the WHOIS service was made to differentiate between natural and legal persons. Some public WHOIS data was limited for natural persons who had elected to withhold their personal information from disclosure by the WHOIS service, records for Legal Persons had to return full and complete WHOIS data (including applicable personal data), and Legal Persons were not permitted to opt out of disclosing such information. The GDPR is definitely a different law and may yield a different policy. But the .TEL case did show that it’s possible to tell the difference between a natural person’s data and a legal person’s data, and to control where that data appears. Same comment as above. <Consumer_Protection_Use_Case_ALAC - Online buyers_Update_2.docx>
Hi Brian, I'm not sure that it makes a difference - wether disclosure can or cannot be presupposed as an outcome. If we, as a Team developing gTLD policy recommendations, tackle an issue concerning web content, reach a conclusion (any conclusion) on it, send a recommendation to the GNSO Council, which is adopted and then sent to the ICANN Board, which adopts it yet again, then what is the outcome? To me, the answer to that question would be that the EPDP Team, the GNSO Council and the ICANN Board have all contributed to creating contractual obligations on Contracted Parties that ICANN should have no business creating. To me, this is also a means of pulling topics out-of-scope of ICANN's mission in to it, because although this scope is defined by the Bylaws, there are also Bylaws granting the GNSO responsibility for developing gTLD policy. Would create a bit of a messy constitutional sort of situation, I think. Also, at some point in the future, the Consensus Policy we are in the process of developing recommendations for will be reviewed, and amendments may be sought. Reviewing Consensus Policies could potentially be initiated by either the GNSO or GDD (if you're following the current Council conversation on reviews of implemented Consensus Policies). So even if we are not presupposing any outcome of disclosure in this use case now, we open the door to further policy development on this topic at some point in a future iteration. On a topic that should have been flagged as out-of-scope of ICANN's mission to begin with!! Ideally, we would not submit any recommendations concerning web content at all. If we did, it'd be nice to know that there are checks and balances in place that initiate some kind of course correction. For instance, the GNSO Council or the ICANN Board would respond saying, wait a minute, why are you sending us a policy recommendation on a topic outside of ICANN's scope?! Speaking for myself, unfortunately, I very much doubt that would happen. It's probably also noteworthy that even if we, as an EPDP Team, reject this use case, and do not address the topic in our recommendations, there is still nothing preventing an Internet user from requesting information about a website they might do business with from a registrar, as you suggest. Our use of these use cases should focus on helping respondents to disclosure requests understand how best to deal with whatever disclosure requests they receive. We can't cover every single potential use case anyway, so the ones we do work out should at least provide some guidance on how to deal with unforeseen circumstances. With that in mind, I believe there is value in addressing this use case, and rejecting it, as opposed to not looking at it at all. This is my personal perspective, and apologies if it was slightly lengthier than it needed to be, but you asked. ;-) Thanks. Amr ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, August 28, 2019 8:25 PM, King, Brian <Brian.King@markmonitor.com> wrote:
Hey Amr and all,
I can’t speak authoritatively for ALAC’s intent, but I read this use case as allowing internet users to request (not have an entitlement to receive) information about a website they might do business with, a link they might click, etc.
I think we’re merely talking about allowing an internet user to ask the question, without presupposing any access outcome. Does that change your perspective?
I’m sympathetic to concerns raised about the bounds of ICANN’s remit, and I might find those concerns more persuasive if we were talking about guaranteed access in this case.
Brian J. King Director of Internet Policy and Industry Affairs
T +1 443 761 3726[markmonitor.com](http://www.markmonitor.com)
MarkMonitorProtecting companies and consumers in a digital world
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Amr Elsadr Sent: Tuesday, August 27, 2019 7:28 AM To: Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case
Hi,
The issue many of us have with this use case isn’t that Internet users should not be entitled to know who they elect to do business with over the web, so I don’t believe it is necessary to keep pushing that point. The issue is that in situations where entities conducting commerce over the Web do not have their contact information readily published on their websites, ICANN/gTLD policy is an inappropriate substitute to resolve this, due to ICANN’s narrow mission.
Speaking for myself, even if it were legal for ICANN to adopt policies that are beyond the scope of its mission (which I don’t think is the case here), it is undesirable for it to do so. Not having a clearly drawn line in the sand on what ICANN can regulate online via contractual compliance with Registries and Registrars, including selling and purchasing goods and services, is a prospect that I find to be very unappealing. It creates a great deal of uncertainty for both Contracted Parties providing domain name registration services, as well as registrants who utilize these services.
My interpretation of consumer protection from an ICANN perspective is that registrants are THE consumers of services in the ICANN context. In that context, proposing policy recommendations beyond the scope of ICANN’s mission is bad, not good, for consumer protection. …, and like I said…, I don’t believe it to be complaint with data protection regulation, such as the GDPR, anyway.
Thanks.
Amr
On Aug 26, 2019, at 5:37 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Hello All,
The ALAC online buyers online case is a real life scenario for why there needs to be a distinction between natural and legal persons. I shall not get into this debate. However, I note that consumers identity and even location is now available to buyers through many online applications, GDPR protects personal information of natural persons and not legal persons. It is only fair to Internet end users to allow them to have the contact information of the online businesses. This is particularly important in case Internet end users are dealing with small businesses online. You can find online businesses contact details now through some existing applications. What and who are we trying to protect by not allowing this use case. Commercial websites should be encouraged to indicate who they are and publish their information. The architecture of the web inherently does not require real identity, but having a complete anonymous system is always an invitation to problems, making people feel less accountable and diminishing the trust in the network. A survey conducted by Bright Local showed that 60% of customers prefer to call small businesses on the phone. The survey also showed that consumers now look beyond websites, RDS is only one tool of many however, prohibiting it to exist works against the norm. I also note that getting clarity in relation to the contracted parties liability in this regard is very important and if implemented information should only be provided if the case is absolutely clear.
I attach the updated user case, which is also available through the google doc
Best
Hadia el-Miniawi
From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Mueller, Milton L Sent: Monday, August 19, 2019 5:27 PM To: Tara Whalen; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case
Tara:
Responses inline below:
- The ICANN Board resolved in May to have the ePDP “determine and resolve the Legal vs. Natural issue in Phase 2." [https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b](https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_board-2Dmaterial_resolutions-2D2019-2D05-2D15-2Den-231.b&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=B8MS1O2ZkevjBW6hFhUe1Tfw1xhaFLotkSAAZ3g3DYQ&s=IAoMV6Yy5PfTOTRJ7D6oVAm1m5bFZMOIZHmnJjr4Gnk&e=) Because the issue is not decided.
Not quite correct. The Board noted that EPDP’s own Recommendation said that we would resolve the issue in Phase 2. The board did not tell us to do so. The resolution also notes the “Potential liability of a registered name holder's incorrect self-identification of a natural or legal person, which ultimately results in public display of personal data.” This concern was one of several that motivated our reluctance to attempt differentiation.
- The EWG recommended a differentiation solution -- that registrants be required to identify as a Registrant Type, with Legal Person and Natural Person among the options. It also required that a mandatory Business PBC be published for “Registrants that self-identify as Legal Persons engaged in commercial activity" (pages 42-44 of final report).
This option _was_ discussed and discarded in Phase 1. It was noted that to the vast majority of ordinary people the distinction between legal and natural has no meaning, and that there would be liability consequences if there were incorrect identification (see above). And besides, the recommendation of the EWG was made prior to GDPR and has no bearing on EPDP.
- ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Law was reviewed by the GNSO and revised in mid-2017. A goal of the Procedure was “to resolve the problem in a manner that preserves the ability of the registrar/registry to comply with its [current] contractual WHOIS obligations to the greatest extent possible”. So -- to publish as much data as possible as allowed by law.
Now you are way off base. Contractual Whois obligations in 2017 were not compliant with GDPR. The Conflicts with Privacy Law procedure is completely irrelevant to our proceedings.
- Under that Procedure, about the only precedent was the .TEL case, which addressed concerns raised by UK privacy law. In that case, the WHOIS service was made to differentiate between natural and legal persons. Some public WHOIS data was limited for natural persons who had elected to withhold their personal information from disclosure by the WHOIS service, records for Legal Persons had to return full and complete WHOIS data (including applicable personal data), and Legal Persons were not permitted to opt out of disclosing such information. The GDPR is definitely a different law and may yield a different policy. But the .TEL case did show that it’s possible to tell the difference between a natural person’s data and a legal person’s data, and to control where that data appears.
Same comment as above.
<Consumer_Protection_Use_Case_ALAC - Online buyers_Update_2.docx>
Hi Amr, First let me confirm that the ALAC case is about giving the online Internet buyers their right granted to them under the GDPR. As to your point about this case not abiding by ICANN's mission let me briefly explain how you are conflating two different issues. In 2009 ICANN published the Affirmation of Commitments, where its said “The Internet is a transformative technology that will continue to empower people around the globe, spur innovation, facilitate trade and commerce” It also said “This document affirms key commitments by DOC and ICANN, including commitments to: (a) ensure that decisions made related to the global technical coordination of the DNS are made in the public interest and are accountable and transparent; (b) preserve the security, stability and resiliency of the DNS; (c) promote competition, consumer trust, and consumer choice in the DNS marketplace; and (d) facilitate international participation in DNS technical coordination” (Examples of consumer protection would include protecting trademark rights holders from domain name abuses.) However, according to how we understand ICANN’s role in relation to the Internet and the public interest some might see that protecting Internet users from online fraud is not within ICANN’s mission. So let us not debate this part and move on. In accordance to Annex G-1 of ICANN’s mission, ICANN is responsible for the maintenance and access to accurate and up-to-date information concerning registered names and name servers. Now many stakeholders have claimed that WHOIS is one of the first tools that they would use in identifying wrongdoers or protecting Internet users. In addition, some surveys have also indicated that Internet users most often use legal persons’ contact information when dealing with small online businesses. Moreover, although complaints like Malware, Phishing, Web hosting, Website content and Spam are handled by other organizations, these organizations rely on the registration data maintained by ICANN. For that, it is ICANN’s responsibility to maintain a registration data system that is not only accurate and up to date but also useful and fair to all stakeholders. ICANN in its role in coordinating the DNS acts for the benefit of the global Internet users. The policy recommendation regarding the online Internet consumers that we are talking about is in relation to the role of the gTLD registration data in serving the online community and maintaining a healthy Internet ecosystem, which is strictly within ICANN’s mission. Best Hadia ________________________________ From: Amr Elsadr <aelsadr@icannpolicy.ninja> Sent: 28 August 2019 21:30 To: King, Brian Cc: Hadia Abdelsalam Mokhtar EL miniawi; gnso-epdp-team@icann.org Subject: RE: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case Hi Brian, I'm not sure that it makes a difference - wether disclosure can or cannot be presupposed as an outcome. If we, as a Team developing gTLD policy recommendations, tackle an issue concerning web content, reach a conclusion (any conclusion) on it, send a recommendation to the GNSO Council, which is adopted and then sent to the ICANN Board, which adopts it yet again, then what is the outcome? To me, the answer to that question would be that the EPDP Team, the GNSO Council and the ICANN Board have all contributed to creating contractual obligations on Contracted Parties that ICANN should have no business creating. To me, this is also a means of pulling topics out-of-scope of ICANN's mission in to it, because although this scope is defined by the Bylaws, there are also Bylaws granting the GNSO responsibility for developing gTLD policy. Would create a bit of a messy constitutional sort of situation, I think. Also, at some point in the future, the Consensus Policy we are in the process of developing recommendations for will be reviewed, and amendments may be sought. Reviewing Consensus Policies could potentially be initiated by either the GNSO or GDD (if you're following the current Council conversation on reviews of implemented Consensus Policies). So even if we are not presupposing any outcome of disclosure in this use case now, we open the door to further policy development on this topic at some point in a future iteration. On a topic that should have been flagged as out-of-scope of ICANN's mission to begin with!! Ideally, we would not submit any recommendations concerning web content at all. If we did, it'd be nice to know that there are checks and balances in place that initiate some kind of course correction. For instance, the GNSO Council or the ICANN Board would respond saying, wait a minute, why are you sending us a policy recommendation on a topic outside of ICANN's scope?! Speaking for myself, unfortunately, I very much doubt that would happen. It's probably also noteworthy that even if we, as an EPDP Team, reject this use case, and do not address the topic in our recommendations, there is still nothing preventing an Internet user from requesting information about a website they might do business with from a registrar, as you suggest. Our use of these use cases should focus on helping respondents to disclosure requests understand how best to deal with whatever disclosure requests they receive. We can't cover every single potential use case anyway, so the ones we do work out should at least provide some guidance on how to deal with unforeseen circumstances. With that in mind, I believe there is value in addressing this use case, and rejecting it, as opposed to not looking at it at all. This is my personal perspective, and apologies if it was slightly lengthier than it needed to be, but you asked. ;-) Thanks. Amr ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, August 28, 2019 8:25 PM, King, Brian <Brian.King@markmonitor.com> wrote: Hey Amr and all, I can’t speak authoritatively for ALAC’s intent, but I read this use case as allowing internet users to request (not have an entitlement to receive) information about a website they might do business with, a link they might click, etc. I think we’re merely talking about allowing an internet user to ask the question, without presupposing any access outcome. Does that change your perspective? I’m sympathetic to concerns raised about the bounds of ICANN’s remit, and I might find those concerns more persuasive if we were talking about guaranteed access in this case. Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Amr Elsadr Sent: Tuesday, August 27, 2019 7:28 AM To: Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case Hi, The issue many of us have with this use case isn’t that Internet users should not be entitled to know who they elect to do business with over the web, so I don’t believe it is necessary to keep pushing that point. The issue is that in situations where entities conducting commerce over the Web do not have their contact information readily published on their websites, ICANN/gTLD policy is an inappropriate substitute to resolve this, due to ICANN’s narrow mission. Speaking for myself, even if it were legal for ICANN to adopt policies that are beyond the scope of its mission (which I don’t think is the case here), it is undesirable for it to do so. Not having a clearly drawn line in the sand on what ICANN can regulate online via contractual compliance with Registries and Registrars, including selling and purchasing goods and services, is a prospect that I find to be very unappealing. It creates a great deal of uncertainty for both Contracted Parties providing domain name registration services, as well as registrants who utilize these services. My interpretation of consumer protection from an ICANN perspective is that registrants are THE consumers of services in the ICANN context. In that context, proposing policy recommendations beyond the scope of ICANN’s mission is bad, not good, for consumer protection. …, and like I said…, I don’t believe it to be complaint with data protection regulation, such as the GDPR, anyway. Thanks. Amr On Aug 26, 2019, at 5:37 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hello All, The ALAC online buyers online case is a real life scenario for why there needs to be a distinction between natural and legal persons. I shall not get into this debate. However, I note that consumers identity and even location is now available to buyers through many online applications, GDPR protects personal information of natural persons and not legal persons. It is only fair to Internet end users to allow them to have the contact information of the online businesses. This is particularly important in case Internet end users are dealing with small businesses online. You can find online businesses contact details now through some existing applications. What and who are we trying to protect by not allowing this use case. Commercial websites should be encouraged to indicate who they are and publish their information. The architecture of the web inherently does not require real identity, but having a complete anonymous system is always an invitation to problems, making people feel less accountable and diminishing the trust in the network. A survey conducted by Bright Local showed that 60% of customers prefer to call small businesses on the phone. The survey also showed that consumers now look beyond websites, RDS is only one tool of many however, prohibiting it to exist works against the norm. I also note that getting clarity in relation to the contracted parties liability in this regard is very important and if implemented information should only be provided if the case is absolutely clear. I attach the updated user case, which is also available through the google doc Best Hadia el-Miniawi From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Mueller, Milton L Sent: Monday, August 19, 2019 5:27 PM To: Tara Whalen; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case Tara: Responses inline below: 1. The ICANN Board resolved in May to have the ePDP “determine and resolve the Legal vs. Natural issue in Phase 2." https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_board-2Dmaterial_resolutions-2D2019-2D05-2D15-2Den-231.b&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=B8MS1O2ZkevjBW6hFhUe1Tfw1xhaFLotkSAAZ3g3DYQ&s=IAoMV6Yy5PfTOTRJ7D6oVAm1m5bFZMOIZHmnJjr4Gnk&e=> Because the issue is not decided. Not quite correct. The Board noted that EPDP’s own Recommendation said that we would resolve the issue in Phase 2. The board did not tell us to do so. The resolution also notes the “Potential liability of a registered name holder's incorrect self-identification of a natural or legal person, which ultimately results in public display of personal data.” This concern was one of several that motivated our reluctance to attempt differentiation. 1. The EWG recommended a differentiation solution -- that registrants be required to identify as a Registrant Type, with Legal Person and Natural Person among the options. It also required that a mandatory Business PBC be published for “Registrants that self-identify as Legal Persons engaged in commercial activity" (pages 42-44 of final report). This option _was_ discussed and discarded in Phase 1. It was noted that to the vast majority of ordinary people the distinction between legal and natural has no meaning, and that there would be liability consequences if there were incorrect identification (see above). And besides, the recommendation of the EWG was made prior to GDPR and has no bearing on EPDP. 1. ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Law was reviewed by the GNSO and revised in mid-2017. A goal of the Procedure was “to resolve the problem in a manner that preserves the ability of the registrar/registry to comply with its [current] contractual WHOIS obligations to the greatest extent possible”. So -- to publish as much data as possible as allowed by law. Now you are way off base. Contractual Whois obligations in 2017 were not compliant with GDPR. The Conflicts with Privacy Law procedure is completely irrelevant to our proceedings. 1. Under that Procedure, about the only precedent was the .TEL case, which addressed concerns raised by UK privacy law. In that case, the WHOIS service was made to differentiate between natural and legal persons. Some public WHOIS data was limited for natural persons who had elected to withhold their personal information from disclosure by the WHOIS service, records for Legal Persons had to return full and complete WHOIS data (including applicable personal data), and Legal Persons were not permitted to opt out of disclosing such information. The GDPR is definitely a different law and may yield a different policy. But the .TEL case did show that it’s possible to tell the difference between a natural person’s data and a legal person’s data, and to control where that data appears. Same comment as above. <Consumer_Protection_Use_Case_ALAC - Online buyers_Update_2.docx>
Hi Hadia, It’s difficult not to debate wether or not protecting Internet users from online fraud is within the scope of ICANN’s mission, since this is key to the topic and use case we’re discussing. I’m also not seeing how I’ve conflated any issues. Apologies if I’m failing to understand this, and am happy to be corrected, if I am mistaken. There doesn’t seem to be anything in the section of the AoC that you referenced, which contradicts what I’ve said either. Describing the Internet as a transformative technology that empowers people, spurs innovation, facilitates trade and commerce is one thing. I pretty much agree with this statement, but it doesn’t suggest that every aspect of the Internet and its benefits to society is within ICANN’s mission and scope to meddle in. Aren’t references to the AoC a little outdated, anyway? I’m also aware of the work that took place in Work Stream 1 of the CCWG on Enhancing ICANN Accountability (specifically, on ICANN’s mission, commitments and core values, and the changes to the ICANN Bylaws that occurred as a result of it. For instance, a quick read of [Article 1 Sections 1.1(b) and (c)](https://www.icann.org/resources/pages/governance/bylaws-en/#article1) say:
(b) ICANN shall not act outside its Mission.
(c) ICANN shall not regulate (i.e., impose rules and restrictions on) services that use the Internet's unique identifiers or the content that such services carry or provide, outside the express scope of Section 1.1(a). For the avoidance of doubt, ICANN does not hold any governmentally authorized regulatory authority.
Thanks. Amr
On Aug 29, 2019, at 1:09 AM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> wrote:
Hi Amr,
First let me confirm that the ALAC case is about giving the online Internet buyers their right granted to them under the GDPR. As to your point about this case not abiding by ICANN's mission let me briefly explain how you are conflating two different issues.
In 2009 ICANN published the Affirmation of Commitments, where its said
“The Internet is a transformative technology that will continue to empower people around the globe, spur innovation, facilitate trade and commerce”
It also said
“This document affirms key commitments by DOC and ICANN, including commitments to: (a) ensure that decisions made related to the global technical coordination of the DNS are made in the public interest and are accountable and transparent; (b) preserve the security, stability and resiliency of the DNS; (c) promote competition, consumer trust, and consumer choice in the DNS marketplace; and (d) facilitate international participation in DNS technical coordination”
(Examples of consumer protection would include protecting trademark rights holders from domain name abuses.)
However, according to how we understand ICANN’s role in relation to the Internet and the public interest some might see that protecting Internet users from online fraud is not within ICANN’s mission. So let us not debate this part and move on.
In accordance to Annex G-1 of ICANN’s mission, ICANN is responsible for the maintenance and access to accurate and up-to-date information concerning registered names and name servers. Now many stakeholders have claimed that WHOIS is one of the first tools that they would use in identifying wrongdoers or protecting Internet users. In addition, some surveys have also indicated that Internet users most often use legal persons’ contact information when dealing with small online businesses. Moreover, although complaints like Malware, Phishing, Web hosting, Website content and Spam are handled by other organizations, these organizations rely on the registration data maintained by ICANN. For that, it is ICANN’s responsibility to maintain a registration data system that is not only accurate and up to date but also useful and fair to all stakeholders. ICANN in its role in coordinating the DNS acts for the benefit of the global Internet users. The policy recommendation regarding the online Internet consumers that we are talking about is in relation to the role of the gTLD registration data in serving the online community and maintaining a healthy Internet ecosystem, which is strictly within ICANN’s mission.
Best
Hadia
________________________________ From: Amr Elsadr <aelsadr@icannpolicy.ninja> Sent: 28 August 2019 21:30 To: King, Brian Cc: Hadia Abdelsalam Mokhtar EL miniawi; gnso-epdp-team@icann.org Subject: RE: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case
Hi Brian,
I'm not sure that it makes a difference - wether disclosure can or cannot be presupposed as an outcome. If we, as a Team developing gTLD policy recommendations, tackle an issue concerning web content, reach a conclusion (any conclusion) on it, send a recommendation to the GNSO Council, which is adopted and then sent to the ICANN Board, which adopts it yet again, then what is the outcome? To me, the answer to that question would be that the EPDP Team, the GNSO Council and the ICANN Board have all contributed to creating contractual obligations on Contracted Parties that ICANN should have no business creating.
To me, this is also a means of pulling topics out-of-scope of ICANN's mission in to it, because although this scope is defined by the Bylaws, there are also Bylaws granting the GNSO responsibility for developing gTLD policy. Would create a bit of a messy constitutional sort of situation, I think.
Also, at some point in the future, the Consensus Policy we are in the process of developing recommendations for will be reviewed, and amendments may be sought. Reviewing Consensus Policies could potentially be initiated by either the GNSO or GDD (if you're following the current Council conversation on reviews of implemented Consensus Policies). So even if we are not presupposing any outcome of disclosure in this use case now, we open the door to further policy development on this topic at some point in a future iteration. On a topic that should have been flagged as out-of-scope of ICANN's mission to begin with!!
Ideally, we would not submit any recommendations concerning web content at all. If we did, it'd be nice to know that there are checks and balances in place that initiate some kind of course correction. For instance, the GNSO Council or the ICANN Board would respond saying, wait a minute, why are you sending us a policy recommendation on a topic outside of ICANN's scope?! Speaking for myself, unfortunately, I very much doubt that would happen.
It's probably also noteworthy that even if we, as an EPDP Team, reject this use case, and do not address the topic in our recommendations, there is still nothing preventing an Internet user from requesting information about a website they might do business with from a registrar, as you suggest. Our use of these use cases should focus on helping respondents to disclosure requests understand how best to deal with whatever disclosure requests they receive. We can't cover every single potential use case anyway, so the ones we do work out should at least provide some guidance on how to deal with unforeseen circumstances. With that in mind, I believe there is value in addressing this use case, and rejecting it, as opposed to not looking at it at all.
This is my personal perspective, and apologies if it was slightly lengthier than it needed to be, but you asked. ;-)
Thanks.
Amr
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, August 28, 2019 8:25 PM, King, Brian <Brian.King@markmonitor.com> wrote:
Hey Amr and all,
I can’t speak authoritatively for ALAC’s intent, but I read this use case as allowing internet users to request (not have an entitlement to receive) information about a website they might do business with, a link they might click, etc.
I think we’re merely talking about allowing an internet user to ask the question, without presupposing any access outcome. Does that change your perspective?
I’m sympathetic to concerns raised about the bounds of ICANN’s remit, and I might find those concerns more persuasive if we were talking about guaranteed access in this case.
Brian J. King Director of Internet Policy and Industry Affairs
T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com>
MarkMonitor Protecting companies and consumers in a digital world
From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Amr Elsadr Sent: Tuesday, August 27, 2019 7:28 AM To: Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case
Hi,
The issue many of us have with this use case isn’t that Internet users should not be entitled to know who they elect to do business with over the web, so I don’t believe it is necessary to keep pushing that point. The issue is that in situations where entities conducting commerce over the Web do not have their contact information readily published on their websites, ICANN/gTLD policy is an inappropriate substitute to resolve this, due to ICANN’s narrow mission.
Speaking for myself, even if it were legal for ICANN to adopt policies that are beyond the scope of its mission (which I don’t think is the case here), it is undesirable for it to do so. Not having a clearly drawn line in the sand on what ICANN can regulate online via contractual compliance with Registries and Registrars, including selling and purchasing goods and services, is a prospect that I find to be very unappealing. It creates a great deal of uncertainty for both Contracted Parties providing domain name registration services, as well as registrants who utilize these services.
My interpretation of consumer protection from an ICANN perspective is that registrants are THE consumers of services in the ICANN context. In that context, proposing policy recommendations beyond the scope of ICANN’s mission is bad, not good, for consumer protection. …, and like I said…, I don’t believe it to be complaint with data protection regulation, such as the GDPR, anyway.
Thanks.
Amr
On Aug 26, 2019, at 5:37 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote:
Hello All,
The ALAC online buyers online case is a real life scenario for why there needs to be a distinction between natural and legal persons. I shall not get into this debate. However, I note that consumers identity and even location is now available to buyers through many online applications, GDPR protects personal information of natural persons and not legal persons. It is only fair to Internet end users to allow them to have the contact information of the online businesses. This is particularly important in case Internet end users are dealing with small businesses online. You can find online businesses contact details now through some existing applications. What and who are we trying to protect by not allowing this use case. Commercial websites should be encouraged to indicate who they are and publish their information. The architecture of the web inherently does not require real identity, but having a complete anonymous system is always an invitation to problems, making people feel less accountable and diminishing the trust in the network. A survey conducted by Bright Local showed that 60% of customers prefer to call small businesses on the phone. The survey also showed that consumers now look beyond websites, RDS is only one tool of many however, prohibiting it to exist works against the norm. I also note that getting clarity in relation to the contracted parties liability in this regard is very important and if implemented information should only be provided if the case is absolutely clear.
I attach the updated user case, which is also available through the google doc
Best
Hadia el-Miniawi
From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Mueller, Milton L Sent: Monday, August 19, 2019 5:27 PM To: Tara Whalen; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case
Tara:
Responses inline below:
1. The ICANN Board resolved in May to have the ePDP “determine and resolve the Legal vs. Natural issue in Phase 2." https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_board-2Dmaterial_resolutions-2D2019-2D05-2D15-2Den-231.b&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=B8MS1O2ZkevjBW6hFhUe1Tfw1xhaFLotkSAAZ3g3DYQ&s=IAoMV6Yy5PfTOTRJ7D6oVAm1m5bFZMOIZHmnJjr4Gnk&e=> Because the issue is not decided.
Not quite correct. The Board noted that EPDP’s own Recommendation said that we would resolve the issue in Phase 2. The board did not tell us to do so. The resolution also notes the “Potential liability of a registered name holder's incorrect self-identification of a natural or legal person, which ultimately results in public display of personal data.” This concern was one of several that motivated our reluctance to attempt differentiation.
1. The EWG recommended a differentiation solution -- that registrants be required to identify as a Registrant Type, with Legal Person and Natural Person among the options. It also required that a mandatory Business PBC be published for “Registrants that self-identify as Legal Persons engaged in commercial activity" (pages 42-44 of final report).
This option _was_ discussed and discarded in Phase 1. It was noted that to the vast majority of ordinary people the distinction between legal and natural has no meaning, and that there would be liability consequences if there were incorrect identification (see above). And besides, the recommendation of the EWG was made prior to GDPR and has no bearing on EPDP.
1. ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Law was reviewed by the GNSO and revised in mid-2017. A goal of the Procedure was “to resolve the problem in a manner that preserves the ability of the registrar/registry to comply with its [current] contractual WHOIS obligations to the greatest extent possible”. So -- to publish as much data as possible as allowed by law.
Now you are way off base. Contractual Whois obligations in 2017 were not compliant with GDPR. The Conflicts with Privacy Law procedure is completely irrelevant to our proceedings.
1. Under that Procedure, about the only precedent was the .TEL case, which addressed concerns raised by UK privacy law. In that case, the WHOIS service was made to differentiate between natural and legal persons. Some public WHOIS data was limited for natural persons who had elected to withhold their personal information from disclosure by the WHOIS service, records for Legal Persons had to return full and complete WHOIS data (including applicable personal data), and Legal Persons were not permitted to opt out of disclosing such information. The GDPR is definitely a different law and may yield a different policy. But the .TEL case did show that it’s possible to tell the difference between a natural person’s data and a legal person’s data, and to control where that data appears.
Same comment as above.
<Consumer_Protection_Use_Case_ALAC - Online buyers_Update_2.docx>
Even allowing the request may be too much as that request will have to be reviewed and handled by someone, taking away resources from the request that have a more realistic chance for a positive response and a concrete need for the data, such as local LEAs and holders of rights being actively infringed upon by the domain holder. If you have to look at RDAP/WHOIS to find out whom you are doing business with, you probably should not buy there in the first place. That info belongs with the content. Volker Am 28.08.2019 um 20:25 schrieb King, Brian via Gnso-epdp-team:
Hey Amr and all,
I can’t speak authoritatively for ALAC’s intent, but I read this use case as allowing internet users to /request/ (not have an entitlement to receive) information about a website they might do business with, a link they might click, etc.
I think we’re merely talking about allowing an internet user to ask the question, without presupposing any access outcome. Does that change your perspective?
I’m sympathetic to concerns raised about the bounds of ICANN’s remit, and I might find those concerns more persuasive if we were talking about guaranteed access in this case.
*Brian J. King * Director of Internet Policy and Industry Affairs
T +1 443 761 3726_ markmonitor.com <http://www.markmonitor.com>_
*MarkMonitor *Protecting companies and consumers in a digital world
*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *Amr Elsadr *Sent:* Tuesday, August 27, 2019 7:28 AM *To:* Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg> *Cc:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case
Hi,
The issue many of us have with this use case isn’t that Internet users should not be entitled to know who they elect to do business with over the web, so I don’t believe it is necessary to keep pushing that point. The issue is that in situations where entities conducting commerce over the Web do not have their contact information readily published on their websites, ICANN/gTLD policy is an inappropriate substitute to resolve this, due to ICANN’s narrow mission.
Speaking for myself, even if it were legal for ICANN to adopt policies that are beyond the scope of its mission (which I don’t think is the case here), it is undesirable for it to do so. Not having a clearly drawn line in the sand on what ICANN can regulate online via contractual compliance with Registries and Registrars, including selling and purchasing goods and services, is a prospect that I find to be very unappealing. It creates a great deal of uncertainty for both Contracted Parties providing domain name registration services, as well as registrants who utilize these services.
My interpretation of consumer protection from an ICANN perspective is that registrants are THE consumers of services in the ICANN context. In that context, proposing policy recommendations beyond the scope of ICANN’s mission is bad, not good, for consumer protection. …, and like I said…, I don’t believe it to be complaint with data protection regulation, such as the GDPR, anyway.
Thanks.
Amr
On Aug 26, 2019, at 5:37 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia@tra.gov.eg <mailto:Hadia@tra.gov.eg>> wrote:
Hello All,
The ALAC online buyers online case is a real life scenario for why there needs to be a distinction between natural and legal persons. I shall not get into this debate. However, I note that consumers identity and even location is now available to buyers through many online applications, GDPR protects personal information of natural persons and not legal persons. It is only fair to Internet end users to allow them to have the contact information of the online businesses. This is particularly important in case Internet end users are dealing with small businesses online. You can find online businesses contact details now through some existing applications. What and who are we trying to protect by not allowing this use case. Commercial websites should be encouraged to indicate who they are and publish their information. The architecture of the web inherently does not require real identity, but having a complete anonymous system is always an invitation to problems, making people feel less accountable and diminishing the trust in the network. A survey conducted by Bright Local showed that 60% of customers prefer to call small businesses on the phone. The survey also showed that consumers now look beyond websites, RDS is only one tool of many however, prohibiting it to exist works against the norm. I also note that getting clarity in relation to the contracted parties liability in this regard is very important and if implemented information should only be provided if the case is absolutely clear.
I attach the updated user case, which is also available through the google doc
Best
Hadia el-Miniawi
*From:*Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org]*On Behalf Of*Mueller, Milton L *Sent:*Monday, August 19, 2019 5:27 PM *To:*Tara Whalen;gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> *Subject:*Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case
Tara:
Responses inline below:
1. The ICANN Board resolved in May to have the ePDP “determine and resolve the Legal vs. Natural issue in Phase 2." https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> Because the issue is not decided.
Not quite correct. The Board noted that EPDP’s own Recommendation said that we would resolve the issue in Phase 2. The board did not tell us to do so. The resolution also notes the “Potential liability of a registered name holder's incorrect self-identification of a natural or legal person, which ultimately results in public display of personal data.” This concern was one of several that motivated our reluctance to attempt differentiation.
2. The EWG recommended a differentiation solution -- that registrants be required to identify as a Registrant Type, with Legal Person and Natural Person among the options. It also required that a mandatory Business PBC be published for “Registrants that self-identify as Legal Persons engaged in commercial activity" (pages 42-44 of final report).
This option _/was/_ discussed and discarded in Phase 1. It was noted that to the vast majority of ordinary people the distinction between legal and natural has no meaning, and that there would be liability consequences if there were incorrect identification (see above). And besides, the recommendation of the EWG was made prior to GDPR and has no bearing on EPDP.
3. ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Law was reviewed by the GNSO and revised in mid-2017. A goal of the Procedure was “to resolve the problem in a manner that preserves the ability of the registrar/registry to comply with its [current] contractual WHOIS obligations to the greatest extent possible”. So -- to publish as much data as possible as allowed by law.
Now you are way off base. Contractual Whois obligations in 2017 were not compliant with GDPR. The Conflicts with Privacy Law procedure is completely irrelevant to our proceedings.
4. Under that Procedure, about the only precedent was the .TEL case, which addressed concerns raised by UK privacy law. In that case, the WHOIS service was made to differentiate between natural and legal persons. Some public WHOIS data was limited for natural persons who had elected to withhold their personal information from disclosure by the WHOIS service, records for Legal Persons had to return full and complete WHOIS data (including applicable personal data), and Legal Persons were not permitted to opt out of disclosing such information. The GDPR is definitely a different law and may yield a different policy. But the .TEL case did show that it’s possible to tell the difference between a natural person’s data and a legal person’s data, and to control where that data appears.
Same comment as above.
<Consumer_Protection_Use_Case_ALAC - Online buyers_Update_2.docx>
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
participants (8)
-
Amr Elsadr -
Ayden Férdeline -
Caitlin Tubergen -
Hadia Abdelsalam Mokhtar EL miniawi -
King, Brian -
Mueller, Milton L -
Tara Whalen -
Volker Greimann