BC Comments on the Legal Analysis
Hi – In advance of tomorrow’s call, here are comments and questions submitted on behalf of the BC: Possible Legal Bases for Processing. Our comments on the legal bases topic have been influenced by both the 6(1)(f) memo and the recent EC communication, so we’ve broken our clarifying questions into 2 groupings, one for 6(1)(b) and one for 6(1)(e). * Performance of Contract – B&B should revisit its analysis in light of the recent EC Letter where it notes: “As explained in our comments, Art. 6(1)f GDPR (legitimate interest) is one of the six possible legal bases provided under Art. 6(1) GDPR. For instance, disclosure of nonpublic gTLD registration data could be necessary for compliance with a legal obligation to which the contracted parties are subject (see Art. 6(1)c GDPR).” This is consistent with the B&B memo that recognizes that a direct contract with the data subject is not necessary. * To identify 6(1)(b) as purpose for processing registration data, we should follow up on the B & B advice that- “it will be necessary to require that the specific third party or at least the processing by the third party is, at least abstractly, already known to the data subject at the time the contract is concluded and that the controller, as the contractual partner, informs the data subject of this prior to the transfer to the third party” * B&B should clarify why it believes that the only basis for providing WHOIS is for the prevention of DNS abuse. Its conclusion in Paragraph 10 does not consider the other purposes identified by the EPDP in Rec 1, and, in any event should consider the recent EC recognition that ICANN has a broad purpose to: ‘contribute to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN's mission’, which is at the core of the role of ICANN as the “guardian” of the Domain Name System.” * WHOIS in the Public Interest - Similarly, B&B should advise on the extent to which GDPR’s public interest basis 6(1)e is applicable, in light of the EC’s recognition that: “With regard to the formulation of purpose two, the European Commission acknowledges ICANN’s central role and responsibility for ensuring the security, stability and resilience of the Internet Domain Name System and that in doing so it acts in the public interest.” Natural-Legal: * The EDPD should explore with B&B the possible ways of protecting against an erroneous identification as a legal person. The policy recommendations could point to different practices that exist today (relying on the CCTLD research referenced in the EPDP Phase 1 report) that could enable the natural/legal person distinction to be made. For example, the EPDP could propose a verification component, based on a number of indicators that can determine whether the registrant is a legal entity. * Has B&B considered how the natural/legal person distinction is handled by ccTLDs? * With regard to concerns about emails possibly containing personal info – has B & B considered whether the risk could be mitigated if the registrant is asked if the email is “role based” or identifies an actual individual? Accuracy: Has B&B reviewed the statistics from the WHOIS ARS on accuracy levels or the findings of the 1st and 2nd WHOIS RT with regard to accuracy? This should factor into the summary conclusions in Paragraph 21. Thick WHOIS: Did B&B review the GNSO’s Final Report and analysis in support of the Thick WHOIS policy recommendations? Specifically, the consensus policy was based on recognized benefits to the Internet Ecosystem of having Thick WHOIS. For example, under the Thick WHOIS policy, the registry is the authoritative place for domain name registration records. Mark and I look forward to discussing these issues in more detail tomorrow. All the best, Margie and Mark
I would find the discussions of these two issues quite humorous if it was not for how much time we have and will spend on them, and the fact that the debates will take time and effort away from real issues. Access vs Disclosure They are the same thing, but from different perspectives. From the perspective of the entity holding the data (primarily the contracted parties in our case), information they hold and may be responsible for is being "disclosed". From the perspective of the entity requesting the data, it is a matter of them "accessing" it. We can certainly define new meanings for these words as suggested on slide 3. But long experience has shown that when you attempt to define existing words in a way that is different from the dictionary meaning (ie {"access" is only for the data subject) people always revert back to the dictionary definitions and cause untold confusion. Centralized vs Decentralized Any real world solution that will be usable by those who will need data, and be supportable by those who hold the data, will have components that are decentralized and components that a centralized (and yet perhaps replicated for reliability). For example there will likely be common places at which to make a request, and accreditation for a given type of requestor may be centralized, yet the data will almost certainly reside in highly decentralized places. Let's focus on how the work will be done and not worry about global labels. Alan
I want to differ a bit with Alan's analysis below. Access typically denotes a more general right to get something when one wants it. When I buy a subscription to a mobile phone service I am buying "access" to the network whenever I want to use it. A distinction between access demand and usage demand is a staple of information and communication economics. In this regard, as Janis's slide correctly stated, in data protection law and policy the right of access usually refers to the right of a data _subject_ to inspect their data to ensure its accuracy. This is a broader, less conditional right than, say, the interest of a trademark holder in seeing a third party's domain name registration data. The trademark holders occasionally have a legitimate interest to see redacted data of a suspected infringer. What the trademark holder wants is the disclosure of contact data he or she needs to serve legal process or to ascertain the legitimacy of the name's use. The trademark holder does _not_ have a right of access to any and all registration data; he has disclosure rights. So the insistence on the use of the term "disclosure" rather than "access" is not arbitrary, and we don't solve it with A/D. They are fundamentally different concepts and we need to keep them distinct. There are important differences in using one name or the other. whether we are talking UDM or some other form of DM when we talk about third parties we are talking about a disclosure model, not an access model. From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Alan Greenberg Sent: Wednesday, May 15, 2019 11:07 PM To: GNSO EPDP <gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Access vs Disclosure and Centralized vs Decentralized I would find the discussions of these two issues quite humorous if it was not for how much time we have and will spend on them, and the fact that the debates will take time and effort away from real issues. Access vs Disclosure They are the same thing, but from different perspectives. From the perspective of the entity holding the data (primarily the contracted parties in our case), information they hold and may be responsible for is being "disclosed". From the perspective of the entity requesting the data, it is a matter of them "accessing" it. We can certainly define new meanings for these words as suggested on slide 3. But long experience has shown that when you attempt to define existing words in a way that is different from the dictionary meaning (ie {"access" is only for the data subject) people always revert back to the dictionary definitions and cause untold confusion. Centralized vs Decentralized Any real world solution that will be usable by those who will need data, and be supportable by those who hold the data, will have components that are decentralized and components that a centralized (and yet perhaps replicated for reliability). For example there will likely be common places at which to make a request, and accreditation for a given type of requestor may be centralized, yet the data will almost certainly reside in highly decentralized places. Let's focus on how the work will be done and not worry about global labels. Alan
participants (3)
-
Alan Greenberg -
Margie Milam -
Mueller, Milton L