I disagree Alan, Speaking in my own capacity, (not as registries, as I have not canvassed them) what we call something here is especially important in light of the fact we are making reference to a specific legal framework, i.e. data protection with due regard to the GDPR, and where that framework (GDPR) is principles based ; the principles of access and disclosure are wholly separate and distinct. We must ensure our work supports clarity - clarity (to the data subject) but also clarity for the intended user of the UDM so as to prevent erroneous requests from those claiming a right of access, when in fact they are making a request for disclosure. IMHO We should just get used to calling it disclosure. Noting your comment re data subject requests, let's be clear that the data subject can request access to their data from* any* controller in the process (and indeed from the processor, who should have contractual obligations to the controller on how to refer to them). This is a wholly separate, and legally speaking, a much more vital process (which attracts the heftier level of fines). The UDM, which concerns itself with the minimum data set, which is a mere subset of the data that a data subject access request may encompass. So we should actually be be very, very clear not to confuse the two. As an aside, a centralized UDM will also need to feed into, support and form part of the individual controllers response to Data Access Requests... but that is a later and thornier issue that where we are currently at. Kind regards, Alan [image: Donuts Inc.] <http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ------------------------------ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://www.facebook.com/donutstlds> <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Fri, May 17, 2019 at 2:28 PM Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
Of course there will be rules associated with any such transfer and that will even apply to the data subject - someone will need to have a process by which the subject suitably identifies themselves to establish that they do have a legitimate right to that information. My point is that debating calling accessing or disclosing or widgetting or blivoting does not further our real work, and that for any transfer, there is a sender and receiver.
Alan
At 17/05/2019 05:21 AM, Mueller, Milton L wrote:
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
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team