An Access model to WHOIS Personal Data

[Tomslin Samme-Nlar]

It is significantly different from the Unified Access Model put forward by
ICANN org especially with regards to accreditation and legitimate purpose
definitions. I also love the idea of confederated servers.
I support its adoption.

Cheers,
Tomslin
https://www.linkedin.com/in/tomslin/

On Mon., 25 Jun. 2018, 12:29 farzaneh badii, <farzaneh.badii at gmail.com>
wrote:

> Dear all,
>
> This is an access model to WHOIS personal data which Internet Governance
> Project put forward and now it is getting support from some part of the
> community. I am sharing it here for discussion now and tomorrow at the NCSG
> Policy Committee session.
>
> It is good to adopt it as NCSG access model and advance it in our
> discussions during ICANN 62
>
> Here is the link for more background and the conditions are set out below:
>
> https://www.internetgovernance.org/2018/06/22/an-access-model-for-whois-data-that-respects-registrants-rights/
>
>
>
>
> Access to personal information of domain name registration WHOIS directory
> should take place under the following conditions:
> *A confederated RDAP*
>
> ICANN’s Temporary Specification requires registries implement RDAP. We
> think that is good. We also believe that the RDAP servers should be
> confederated so that queries can go to one source, which can hand it off to
> the Registrar that handles the domain.
> *No thick registries*
>
> All Registries should be thin registries. There is no justification to
> require registries to hold the personal data of domain name registrants.
> Registries do not need that information to perform their function, and
> therefore thick registries are presumptively noncompliant with GDPR and
> data protection/privacy principles more generally.
> *Registrars in charge of granting access*
>
> Registrars, not registries, should be the parties to whom requests are
> made and who provide the private data to requestors. Registrars are the
> organizations who have the direct relationship with the registrant. No
> other agency should be able to authorize or deliver access nor there should
> be any other organization that can approve third parties as legitimate
> interest holders except Law Enforcement. Registrars will not be held liable
> for not granting access based on valid reasons.
> *Law Enforcement Agencies develop their own accreditation *
>
> Criteria and methods for accrediting entities as bona fide law enforcement
> agencies (LEAs) should be developed by LEAs themselves. It can be done
> through GAC, Interpol, or any other LEA nexus. The ICANN community should
> be able to comment on it before it is adopted.
> *Narrow legitimate interest in line with ICANN’s mission*
>
> As long as access procedures are being led by ICANN,  it has to be in line
> with ICANN’s mission. There are various interpretations of ICANN mission
> and some prefer to interpret them broadly. ICANN mission should be
> interpreted narrowly by ICANN, if registrars recognize that there are other
> legitimate interests and third parties, they can in accordance with GDPR
> and their local laws allow for access on a case by case basis. We believe
> that legitimate interest must be defined in a narrow way consistent with
> ICANN’s mission. The release of the data must be needed to:
>
>    - Solve a crime or track down a criminal using the domain
>    - Respond to threats to DNS operations
>    - Respond to attacks on the confidentiality, integrity or availability
>    of Internet services that use the DNS as part of the attack infrastructure
>
> *Access restricted to individual queries*
>
> Access must be granted on an individual query basis, and based on a
> specific incident. Requests must be made for a particular domain – not a
> general license to search registration records. There is no need to ask for
> clarification on this point from the European Data Protection Board. ICANN
> has to apply this principle because it must respect the privacy of domain
> name registrants and also not interfere with the technical operation of
> DNS. Moreover, it can shield itself from liability, should access to the
> full database not be in compliance with GDPR.
> *Secondary queries*
>
> There should be an ability to run secondary queries based on identity
> characteristics uncovered in an initial query, but such queries must be
> limited to legitimate interests listed above.
> *Requestor’s accountability*
>
> Requestors must be held accountable for their use of special access.
> Requestor’s identity must be known and recorded. Requestors must provide a
> specific legitimate reason for the query, which shall be recorded at the
> time of the query. Domain name registrants should have recourse against
> abuse in queries. If the requestor exceeds the scope of access, domain name
> registrants should be able to file a complaint against requestors who abuse
> access on the grounds laid out by law and policy.
>
>    - There should be an Alternative Dispute Resolution mechanism in place
>    to file the complaint.
>    - The outcome will be binding on the defendant
>    - Those who abuse their access can be held accountable by having to
>    pay a fine.
>    - The fine can be enforced by having an escrow mechanism in place,
>    which requires the requestor to deposit an amount in the escrow prior to
>    access
>    - Domain registrants shall not surrender their right to go to court
>    for privacy violations
>
>
>
>
>
>
> Farzaneh
> --
> Farzaneh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20180625/14168994/attachment.htm>