An Access model to WHOIS Personal Data

[Salanieta Tamanikaiwaimaro]

I don't support the "No Thick Registries" approach and don't think that a
one size fits all approach should become the view of all Non-Commercial
Stakeholders.




On Mon, Jun 25, 2018 at 7:48 PM, Tomslin Samme-Nlar <mesumbeslin at gmail.com>
wrote:

> 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/dc017761/attachment.htm>