[Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case
Volker Greimann
vgreimann at key-systems.net
Fri Aug 9 10:00:45 UTC 2019
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 at 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 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.
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190809/27980f19/attachment-0001.html>
More information about the Gnso-epdp-team
mailing list