[gnso-rds-pdp-wg] ICANN's Three Compliance Models

[Rubens Kuhl]

> 
> Substantive Comments
> 
> In the section entitled “Commonalities Across All Models” I found it incredibly odd that ICANN used the word “may collect” and “may transfer” in points 1, 2 and 3.  For those lawyers, and those that play ones within ICANN’s PDP, the use of the words “may”, “shall”, “must” and “should” have significant legal significance.  My initial reading, and I am open to being corrected by ICANN staff or other community members, is that ICANN is looking to remove itself from mandating that its contracting parties collect any data.  However, when I got to Appendix #1, that document explicitly states that the Full Thick Data Set would be transferred from Registrars to Registries, and from Registrars and Registries to Escrow Agents.  I really think ICANN legal needs to clarify this choice of word and whether it is seeking to extricate itself from the Data Controller label that the Hamilton and WSGR bestowed upon it.

And that's one of the problems of having both policy and fiduciary responsibility: trying to minimize its own legal exposure is understandable for a corporation, but ICANN only puts the community it serves in more turmoil by trying to do so.

There is no general need for registrars to send identifiable data to registries; that could be useful to some registries in verifying eligibility and do compliance enforcement, but some registries might prefer not receiving PII exactly to avoid privacy complications. So letting registries determine whether they want that level of information or not, and letting registrars specify requirements that registries need to follow when sending that information, would be a better option than mandating an across the board flow of information.

> 
> While I appreciate the contributions made by three Hamilton memos, I was confused by how Hamilton in most circumstances would take incredibly conservative positions regarding most issues expect for in connection with the GDPR requirements concerning Data Minimization.  The question which I personally have not received a satisfactory answer to is the following, VeriSign has shown in connection with the operational of the .COM and .NET TLDs, that “most” registries do not need thick whois/RDS data so how can ICANN and the community defend its consensus policy calling for mandatory thick whois?

Fortunately the GDPR incident and this WG will be able to review the thick WHOIS policy so we can target goals (like homogenous and accessible information) instead of forcing of every data architect will tell someone not to do: n-uplicate information.


> 
> Territorial Applicability of the Different Models:
> 
> As part of its analysis ICANN attempts to distinguish each model on the basis of its territorial applicability.  Model 3 and Model 2B are touted as applying to all registrations on a global basis, whereas Models 1 and 2A undergo a three prong test. However, when you look at the extraterritorial scope of the GDPR, i.e. registry/registrars established in EEA; registry/registrar providing services targeting registrants in EEA; or process located within EEA, the net effect is the vast majority of gTLD domain name registrations being covered.  Therefore, it is probably best that ICANN move forward with any model(s) covering all registrations, as a piecemeal approach would likely lead to consumer confusion and business uncertainty for all economic actors in the eco-system.

One thing that surprised me would be the possibility of GDPR applying to a non-EEA registry servicing non-EEA registrants only by having a data escrow provider in EEA. I don't recall such being mentioned before in Hamilton or eco memos, but this what I would conclude from ICANN models.

> 
> Access to Non-Public Information (e.g. Tiered Access)
> 
> Unlike the territorial applicability discussed above which really provide little variation, there is a more substantial deviation among the models regarding access to non-public information. There are three basic variations discussed in the three models: self-certification (Model 1); formal accreditation (Model 2); legal due process (Model 3).  While ICANN has chosen to limit each type of non-public access programs to a specific model class, there appears to be no reason why different programs (e.g. self-certification/formal/legal-due process) could not apply to each Model.
> 
> Model 1 and Model 2 state” [r]egistries and registrars may, but would not be required by ICANN, to provide additional access to non-public WHOIS as long as it complies with GDPR and other applicable laws (emphasis added). This language appears to conflict with the preceding paragraph in Model 1 which stated that “[t]o access registration data not published in the public WHOIS, registries and registrars would respond to requests.” Model 2 has similar qualifying language, e.g. “would provide access.” Again I want everyone to focus on ICANN’s use of the word “would”, not “shall” or “must.”   If providing access to additional non-public WHOIS is optional, what is the incentive for Registries/Registrars to do so, other that charging for it as a value added service? Why would a Registry/Registrar do so voluntarily and potentially expose themselves to liability, because some self-certifying third party made a mistake in connection with their disclosure request.
> 
> My personal opinion, is that given that the future of WHOIS/RDS will be founded upon RDAP, it is probably best that all access to Registrant Data WHOIS/RDAP be done through a common set of credentials. Instead of law enforcement, IP attorneys, network operators having to create a set of credentials with thousands of registrars and registries, they should be able to obtain one set of credentials from ICANN that could be used across all registration authorities.   I would propose that ICANN be tasked with providing credentials to third parties and that the verification process would require both email and phone verification. This type of verification could be largely automated as is happens today with many major internet service offering.  Registrants, Registrars, and Registries would also have the ability to challenge a third party’s credential if they were able to establish a violation of the terms of use.


I would tweak that a little so ICANN could certify other credentials; for instance, informing contracted parties that PSWG is trusted for LEA credentials, INTA for IP interests, APWG and MAAWG for security interests etc. ; ICANN is usually shy of doing more operational tasks, and considering their overall flawed record in this regard, it might be a good idea to not go there.


> 
> Another personal comment is that instead of trying to distinguish between self-certification and formal accreditation, a better demarcation would be between one-off lookup queries and more complex queries (i.e. multi-field, wild card, multiple results, etc.).  With one-off lookup queries using a universal credential issued by ICANN there is less of a chance of data mining that takes place today, plus the ability of a third party to lose their credential if they abuse their access which registrars and registries would now be able to more closely monitor. The specifics of the program involving more complex queries and how to grant access to these entities (including a potential bonding requirement)  is something that is highly unlikely to take place in the near team, i.e. prior to May 2018.  However, the self-certification framework discussed above could provide ICANN valuable experience on how to design/implement such a program.

ICANN already has one self-certification program in place: CZDS access, where parties certify the usage they will make of the zone data. The experience on that is very disappointing, since zone data is the 1st step of the spam that every new registrant of a gTLD (legacy or new) gets these days, in direct violation of the CZDS usage requirements.


> 
> Registrant Consent
> 
> Both Models 1 and 2 include the text “unless the registrant otherwise grants permission, registrars and registries would be required to display the following minimum data in public WHOIS.”  I think this needs to be rewritten to provide more clarity about the Registrant’s right to withhold consent initially, and if the Registrant’s changes its mind at a later date.  I believe the data retention policies in all models may need to be adjusted ASAP once the registrant withdraws its previously given consent.

If that holds, it will be a significant implementation challenge. Changing only what is currently displayed is way easier.


Rubens

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180113/fdb4c798/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180113/fdb4c798/signature.asc>