[ALAC] ALAC Response to Accreditation Model - due date 20 April

Tue Apr 17 08:26:51 UTC 2018

In my own view the expectations by ICANN from the request to Article 29 WP
folks presaged either a woeful misunderstanding of the role/function of the
Article 29 WP in the EU/EC framework or the first move in a fiendishly
clever ploy to get them on record for purpose.

Because quite frankly, them fellas didn't say anything that a moderately
sentient observer that is conversant with the issues and have some time in
place could not have anticipated.

-Carlton

==============================
*Carlton A Samuels*

*Mobile: 876-818-1799Strategy, Planning, Governance, Assessment &
Turnaround*
=============================

On Mon, Apr 16, 2018 at 6:58 PM, Holly Raiche <h.raiche at internode.on.net>
wrote:

> Folks
>
> 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:
>
>    - Breadth of purpose - saying the proposed purposes are too widely
>    drawn
>    - the link of purpose to processing - again, because the Whois data
>    has been used does not qualify it as a purpose
>    - publication of the data must be linked to the original (and narrowly
>    defined) purpose
>    - any access should be limited - not blanket access
>    - discussion about the length of retention of data
>    - discussion about the transfer of data
>    - Accreditation (particularly important in this context) - should only
>    be for legitimate purpose, limited to the original purpose, not blanket
>    access, and under limited conditions
>
>
> 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.
>
> 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
>
> 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.
>
> 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)
>
> Holly
>
>
>
>
>
>
> Hi all.
>
> After reading the Article 29 WP letter to ICANN
> (awbs://www.icann.org/en/system/files/correspondence/jelinek-to-marby-
> 11apr18-en.pdf), I started envisioning what process and system could
> achieve GDPR compliance. What I came to is a token-based system, which
> would work like this:
> - Every request is analyzed by a human at an "RDS Clearinghouse". Each
> request can be for a single data element (like "owner of domain X") or to
> multiple data elements (like "domains owned by the same owner of domain
> X"), but requests for multiple data elements are only foreseen to be
> processed by contracted parties with "Search WHOIS" contract requirements.
> - Clearinghouse issues a token with query parameters, data elements
> authorized for response, identity of authorized party, reason for
> authorization, validity (probably in the order of days), also informing
> which endpoint to go to.
> - Authorized party uses that token to access that endpoint, managed by the
> party with most data about that element (usually a registrar).
>
> Note that is not a replacement for credentialing; credentials would still
> be necessary to get tokens. This is also orthogonal to discussions like
> which use cases are legitimate or not, GDPR-compliant or not etc.; it's
> just a more granular approach to authorization that looks more inline with
> privacy-oriented guidelines including but not limited to GDPR.
>
>
> Rubens, at a high level you just described how OpenID and OAuth work,
> except for the "Every request is analyzed by a human" part.
>
>
> Scott,
>
> 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.
> And some level of asynchronous communications could even make way for a
> quick look human analysis.
>
>
> Rubens
>
>
> 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.
>
> _______________________________________________
> ALAC mailing list
> ALAC at atlarge-lists.icann.org
> https://atlarge-lists.icann.org/mailman/listinfo/alac
>
> At-Large Online: http://www.atlarge.icann.org
> ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+
> Advisory+Committee+(ALAC)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/alac/attachments/20180417/0b11f787/attachment.html>