[Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case

Thu Aug 8 17:14:39 UTC 2019

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 at icann.org> on behalf of Hadia  Abdelsalam Mokhtar EL miniawi <Hadia at tra.gov.eg>
Sent: 03 August 2019 21:09
To: Caitlin Tubergen; gnso-epdp-team at 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 at icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen at icann.org>
Sent: 01 August 2019 19:44
To: gnso-epdp-team at 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-Abuse%20Investigation%20Use%20Case%20-%2011%20July%202019.docx?version=1&modificationDate=1562865007000&api=v2> (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/111389243/Consumer_Protection_Use_Case_ALAC%20-%20Online%20buyers.docx> (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_-do0vU5VJuw/edit)

·        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-drazek-21jun19-en.pdf). 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 at 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.