<html>
<body>
Of course we must comply. But we also have to consider advice from the
GAC and our mission.<br><br>
My understanding is that data commissioners do not have the authority to
grant such waivers. Only the courts do.<br><br>
Alan<br><br>
At 17/04/2018 05:48 PM, Tijani BEN JEMAA wrote:<br>
<blockquote type=cite class=cite cite=""><font color="#002E7A">I forgot
to add that we must comply with GDPR, and try to negotiate with Article
29 in Brussels to have a waiver for a few more months to finalize our
interim model.</font><br><br>
-----------------------------------------------------------------------------<br>
<b>Tijani BEN JEMAA<br>
</b>Executive Director<br>
Mediterranean Federation of Internet Associations (<b>FMAI</b>)<br>
Phone: +216 98 330 114<br>
+216 52 385
114<br>
-----------------------------------------------------------------------------<br>
<br>
<br>
<blockquote type=cite class=cite cite="">Le 17 avr. 2018 à 22:39, Holly
Raiche
<<a href="mailto:h.raiche@internode.on.net">
h.raiche@internode.on.net</a>> a écrit :<br><br>
Hi Alan<br><br>
I am not disputing the ALAC’s rightful concern with making the DNS as
safe and reliable as possible. But we need to do that in the legal
framework we are given.<br><br>
So yes, the model Scott explained does try to provide access to those
entitled to access within a legal framework - both are
important..<br><br>
I do hope others comment because this is a very important
discussion<br><br>
Holly<br><br>
<br>
On 18 Apr 2018, at 6:06 am, Alan Greenberg
<<a href="mailto:alan.greenberg@mcgill.ca">alan.greenberg@mcgill.ca</a>
> wrote:<br><br>
<blockquote type=cite class=cite cite="">I said *I* would try to add some
comments tonight. Add to what you had said (on Wiki now that it is
there). Still hope to but time running out.<br><br>
To be clear, it IS *OUR* job to make sure that the DNS is safe and
reliable. That is our only job! Law enforcement, or anyone else that can
justify their need can get data only if we first collect it.<br><br>
But that is not relevant to the accreditation model as Scott
says.<br><br>
At 17/04/2018 07:13 AM, Holly Raiche wrote:<br>
<blockquote type=cite class=cite cite="">Hi Alan<br><br>
When you say ‘we can add some comments tonight’ my questions are
<ul>
<li>what comments?
<li>and add to what?
</ul>There is no link on the policy page to the accreditation
model.<br><br>
And next - I’d have to differ on your views. Article 29
starts from basic privacy principles - as followed in over 100 countries
around the globe with data protection regimes. First basic
principle: only collect personal information that is necessary to do YOUR
job. You don’t collect information you don’t need. Next
principle: You tell the data subject why you need their personal
information, and the circumstances in which that information will be
shared. It is to THAT limited use and disclosure that people
consent to giving their personal information. And it is in those LIMITED
circumstances in which personal information is disclosed. The fact
that others may want access is irrelevant.<br><br>
So that right away limits who gets information - and in limited
circumstances only.<br><br>
In almost every data protection regime, law enforcement will be a
circumstance in which personal information is made available. But
again - not blanket permission, but in circumstances where there is a
reasonable chance that illegal/harmful activity is or has taken
place. And a further read suggests that access would also be given
to Government/government authorised authorities as well. Two
examples in Australia would be ASIC, our prudential regulator, and the
ACCC, our competition and consumer watchdog. So the category of law
enforcement probably extends to other regulatory/enforcement agencies -
again, in situations where harm is suspected/occuring.<br><br>
So - far from having an outstanding lack of knowledge about the Internet
and ICANN, Article 29 know exactly what is going on. And it is what
now amounts to unlawful release of personal information - and not just in
the EU.<br><br>
If there is to be any even slightly middle ground, it will be close to
the model that Scott has already tested - access is possible, but to
specific, accredited people and for specific situations. And it is
in THAT context that the DNS will be protected. (and, as the cyber
security advisor to our Prime Minister said, when asked how to make the
Internet safe, replied that it isn’t possible to make it safe, only
safer.)<br><br>
Holly<br><br>
<br><br>
<br><br>
<br>
On 17 Apr 2018, at 4:58 pm, Alan Greenberg
<<a href="mailto:alan.greenberg@mcgill.ca">alan.greenberg@mcgill.ca</a>
> wrote:<br><br>
<blockquote type=cite class=cite cite="">Holly I have been travelling and
am ties up in meetings all day (Brussels time), but I hope to add some
comments later tonight.<br><br>
I caution care in interpreting the Article 29 letter. Despite some valid
concerns, it shows an astounding lack of knowledge of the Internet and
ICANN's mission. As a prime example is their advice to just focus on our
own business and not that of others such as law enforcement or those
combatting cyber issues. Our mission is to protect the DNS and that
includes making it reliable and safe. But we do not have the ability to
do that ourselves and thus must provide the tools for others to do that.
If we fail, we are NOT carrying out our mission. <br><br>
This will get more interesting in coming weeks.<br><br>
Alan<br><br>
<br><br>
At 16/04/2018 07:58 PM, Holly Raiche wrote:<br><br>
<blockquote type=cite class=cite cite="">Folks<br><br>
We are fast running out of time to develop any kind of response to the
accreditation model, even though the deadline for a response has been
extended to this Friday. And in the interim, ICANN has received advice
from Article 29 on the Interim model. (Article 29 is an advisory Group
made up of a data protection authority from each EU member state).
Their letter to ICANN, and Marby’s response, are on the home page of
ICANN - and for those interested in the issue, I highly recommend reading
both. Clearly, the implications of the Article 29 letter are that
the Interim Model that we did comment on still raises concerns with
them. Those concerns fall under the headings:
<ul>
<li>Breadth of purpose - saying the proposed purposes are too widely
drawn
<li>the link of purpose to processing - again, because the Whois data has
been used does not qualify it as a purpose
<li>publication of the data must be linked to the original (and narrowly
defined) purpose
<li>any access should be limited - not blanket access
<li>discussion about the length of retention of data
<li>discussion about the transfer of data
<li>Accreditation (particularly important in this context) - should only
be for legitimate purpose, limited to the original purpose, not blanket
access, and under limited conditions
</ul><br>
Below, I have copied in an email from Scott Hollenbeck, a long standing
member of ICANN and one of those involved in the development of the RDAP
(access protocol that would allow gated access to registration data) -
simply because he has been involved in this issue for a long time and
shows he has already worked on a technical solution to this issue - how
access to data could work under GDPR.<br><br>
I will try to attend as much as possible of the capacity building webinar
on this issue, but have been scheduled to attend an all-day course in the
Sydney CBD so may have to miss some of the discussion. I imagine
Tom will be very up to date on these issues, but I would like to have
been attending the whole of the webinar myself <br><br>
In any case, if at all possible, we should be saying something.
Quite apart from the original contribution from the IPC/BC model, the
NCSG and Registrars have also made comments (largely challenging the
IPC/BC model). I hope we are the one constituency that doesn’t make
comments - although I realise that agreement on what to say will be
difficult at the best of times.<br><br>
And if it isn’t too late - maybe put this issue on the ALAC policy page -
and with it, links to the Article 29 letter, Marby’s response, the
registrars’ response and the NCSG response (and any others I have missed
- I have copies if that helps)<br><br>
Holly<br><br>
<br><br>
<br><br>
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite=""><br>
Hi all.<br><br>
After reading the Article 29 WP letter to ICANN<br>
(<a href="awbs://www.icann.org/en/system/files/correspondence/jelinek-to-marby-">
awbs://www.icann.org/en/system/files/correspondence/jelinek-to-marby-</a>
<br>
11apr18-en.pdf), I started envisioning what process and system could<br>
achieve GDPR compliance. What I came to is a token-based system,
which<br>
would work like this:<br>
- Every request is analyzed by a human at an "RDS
Clearinghouse". Each<br>
request can be for a single data element (like "owner of domain
X") or to<br>
multiple data elements (like "domains owned by the same owner of
domain<br>
X"), but requests for multiple data elements are only foreseen to
be<br>
processed by contracted parties with "Search WHOIS" contract
requirements.<br>
- Clearinghouse issues a token with query parameters, data elements<br>
authorized for response, identity of authorized party, reason for<br>
authorization, validity (probably in the order of days), also
informing<br>
which endpoint to go to.<br>
- Authorized party uses that token to access that endpoint, managed by
the<br>
party with most data about that element (usually a registrar).<br><br>
Note that is not a replacement for credentialing; credentials would
still<br>
be necessary to get tokens. This is also orthogonal to discussions
like<br>
which use cases are legitimate or not, GDPR-compliant or not etc.;
it's<br>
just a more granular approach to authorization that looks more inline
with<br>
privacy-oriented guidelines including but not limited to
GDPR.</blockquote><br>
Rubens, at a high level you just described how OpenID and OAuth work,
except for the "Every request is analyzed by a human"
part.</blockquote><br>
Scott,<br><br>
I believe you are right, although most OAuth models I saw were not that
granular to the point of saying "example.TLD, owner, e-mail address,
valid until April 20 2018". That's not an OAuth limitation though,
just common usage, and it probably could be made to work like this. <br>
And some level of asynchronous communications could even make way for a
quick look human analysis. <br><br>
<br>
Rubens</blockquote><br>
I have this very model, with human involvement, up and running right now
as part of the gTLD RDAP Pilot. All of the attributes you mentioned can
be encoded as OAuth claims. The model is described in an Internet-Draft
that I first wrote in 2015. Just search for “draft Hollenbeck RDAP
OpenID” using your favorite search engine.<br>
Content-Type: text/plain; charset="us-ascii"<br>
Content-Transfer-Encoding: 7bit<br>
Content-Disposition: inline<br>
X-Microsoft-Exchange-Diagnostics:<br>
<x-tab> </x-tab>
1;YTOPR01MB0396;27:E+eV2ZOSHNubNtVECuy/VM/L0xhmfXbZcuSQZbzTXSXqae7LUG8EA97rPf+2WwLbTntAgo7cpRKp5nw8d8T6ebvY8Vy/iFaEy7AJW3LXmiMa8o52Hh4X6vuxt8b9Dc+H<br>
X-Microsoft-Antispam-Message-Info:<br>
<x-tab> </x-tab>
mbIfSQV0+eZC39ENiUAspKdQkF0+JSTZwhHzgGzIJcnMTMtI1YFjxfAYUWl5x8Xsb0hCkvQc7VzC4AbTCpUbUGRQU6RcE5UUx1wEGk3WXKVvz27yXSf3osNfP8UwExDIUIL1xB46d04FaxAvbFZx3V7Y2ZVoGnlOF9jsJrXvgUSoJT4DsABV8smZdk4vNHRjunBYHmX/Uyc08KK5W5zM0fDRY7NEhuy8gp+3GzVz4A/5TqlICRbEqPiDy4iZWnOAaPiE4ELCAfZPmhMusibjqJno9CcaR04f9ovSYOL+LGRVBVtQ1M9b/SxTHtnAjl+ENjnGKfOC/j1+ryUspB55Z6d0P1zabIZYAwo87l1z4xMWzu3tmPExSwczo7sS129laKLyfrpQKQl6gt36u0ia78/RPd+UH+swgobcmXrp+pNPCIV60r6mKu9CLHxwfljZtI62wcXHykdzvBpIoyKjBQ==<br>
<br>
_______________________________________________<br>
ALAC mailing list<br>
<a href="mailto:ALAC@atlarge-lists.icann.org">
ALAC@atlarge-lists.icann.org</a><br>
<a href="https://atlarge-lists.icann.org/mailman/listinfo/alac" eudora="autourl">
https://atlarge-lists.icann.org/mailman/listinfo/alac</a><br><br>
At-Large Online:
<a href="http://www.atlarge.icann.org/" eudora="autourl">
http://www.atlarge.icann.org</a><br>
ALAC Working Wiki:
<a href="https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC" eudora="autourl">
https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC</a>
)</blockquote></blockquote></blockquote></blockquote><br>
_______________________________________________<br>
ALAC mailing list<br>
<a href="mailto:ALAC@atlarge-lists.icann.org">
ALAC@atlarge-lists.icann.org</a><br>
<a href="https://atlarge-lists.icann.org/mailman/listinfo/alac" eudora="autourl">
https://atlarge-lists.icann.org/mailman/listinfo/alac</a><br><br>
At-Large Online:
<a href="http://www.atlarge.icann.org/" eudora="autourl">
http://www.atlarge.icann.org</a><br>
ALAC Working Wiki:
<a href="https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC" eudora="autourl">
https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC</a>
)</blockquote></blockquote></body>
</html>