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

[Michael Palage]

Hello All,

 

So ICANN in a traditional Friday night news dump has published its long awaited three GDPR Interim Compliance Models, see https://www.icann.org/news/blog/data-protection-and-privacy-update-seeking-community-feedback-on-proposed-compliance-models . Before diving into the substance of this document and the specifics of the three models, I would like to offer some high level commentary.

 

During the ICANN meeting in Abu Dhabi meeting Göran made reference to models that ICANN was evaluating but which he did not disclose at that meeting.  Given the quickly evolving nature of all things GDPR I wanted to give ICANN’s CEO the benefit of the doubt. However, after the typical post ICANN meeting recovery period, I was disappointed when there was still no sharing of the ICANN models. During the ICANN IGF Session in Geneva last month, I specifically asked remotely about ICANN sharing its current best thinking on the three models so that the community could have maximum time to evaluate ICANN’s thinking.  Unfortunately, Göran was non-responsive to my question/request about sharing these models.  

 

Further disappointing from a process/transparency standpoint is that ICANN staff has proposed to only provide a seventeen (17) day comment period. I appreciate the tight timeline that ICANN is under given the looming May compliance date set forth in the GDPR. However, I myself and others would have been a little more understanding if ICANN would have shared their preliminary models with the community sooner as opposed to later. Again this was clearly the point of my second intervention during the ICANN IGF session last month.  An additional disappointment is that it does not appear that ICANN staff took the time to analyze and provide feedback into the third party models that were submitted by the January 10th deadline.  The fact that ICANN staff did not disclose these Models earlier, is proposing to act inconsistently with it stated public comment policy, and does not appear to have properly analyzed the models and legal analysis submit by the community conveys the impression that the final outcome is already a fait accompli.  

 

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. 

 

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?  

 

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. 

 

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.

 

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.

 

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. 

 

Model 1 

 

While not as complex to implement as Model 3, the need to distinguish between Natural and Legal persons is not a solution that can quickly be implemented across the whole domain name industry on an interim basis. Specifically in connection with the need for Registries to track consent at the registry level, i.e. when it is given and when it is withdrawn. In connection with Legal persons, Model 1 proposes to make all “thick” registrant data available just as it is available today, whereas Natural persons would be able to withhold the following Registrant data fields: (i) email and phone number of registrant AND (ii) name and postal address of technical and administrative contacts. However, if ICANN permits registrars to withhold data transfers to registries (as discussed above), what data would registries be required to display in their WHOIS/RDS output?  This model also does not seem to account for the need to protection personal data associated with employees of Legal persons who may appear in public WHOIS.  Additionally, while Legal person registrants often make a distinction between Registrant and Administrative contacts, most individual  registrants as such myself do not. Therefore, as an proposed “interim” solution I do not see how this is the most conservative approach for contracting parties to minimize their legal exposure.  I believe it would be prudent to engaged with all available DPA to see if this proposal is sufficient as a lowest common denominator before imposing substantial costs on Registrars and Registries for less than compliant interim Model.

 

Model 2 

 

This is the most conservative legal approach for Registries and Registrars concerned about potential legal exposure, allowing for the publication of the email for the Administrative and Technical contacts.  This is also potentially the quickest to implement from a data publication perspective. However, as noted above for many individuals (myself included), personal PII may still be included in these data fields when registering a domain name. 

 

Model 3 

 

This model seems to be nothing more than a straw man put forward by ICANN staff.  The technical and administrative burdens to analyze each individual data element and then make a determination if it includes personal data as part of an “interim” solution implemented by May 2018 is beyond herculean. In fact, it borders on nonsensical.  The proposed framework for access to non-public registrant data is also very draconian, and appears to be an attempt to alienate legal, LEA and business interests. Because this model has almost ZERO chance of receiving support from Registration Authorities (registries and registrars) it is hard to justify spending any additional time trying to analyze this model. 

 

Final Thoughts

 

Sadly, given these models as presented I see little chance of the ICANN community reaching a consensus on a single model. Therefore, Göran will need to make a legal decision to minimize ICANN Inc.’s legal exposure.  If you have been reading the tea leaves, and then take into account how ICANN has been less than forth coming in the publication of these models over the last couple of months, if I was a betting man I would probably place my GDPR bet on a modified Model 2. Specifically, ICANN permits the withholding of Registrant personal data in the public whois, but instead implements the self-certification model for access to non-public whois while throwing a bone to the IP and LEA community that it will diligently work on a formal accreditation process (do not hold your breath).  

 

The more likely result of this less than optimal solution is that European Registries and Registrars will wait until they complete their DPIAs and for ICANN to state its public position before engaging directly with their respective DPAs under Article 36.  An interesting question that may be posed to ICANN is - has it taken the suggestion posed in one of the Hamilton memos about engaging directly with a DPA to seek advice/guidance?  Since the ICANN bylaws require a minimum 21 day public comment period before the ICANN Board takes an action on a public policy decision (i.e. I would submit a compliance waiver from consensus policies should require Board approval), I do not see ICANN making any final statement before the Puerto Rico meeting in March. That will then result in a bunch of chaotic negotiations between contracting parties and DPAs shortly thereafter, or potential before.  In fact it would not surprise me if one of more DPAs wanted to proactively comment on ICANN’s compliance Model. Net result, less clarity and less business predictability. This is truly a test that will rock the foundation of the ICANN bottom-up multi-stakeholder model.   And while not intending to be the bearer of bad news, these types of national law conflicts are likely to occur with more regularity. I would encourage list participants to watch the IGF session on data localization as this is the next crisis that will be confronting ICANN, and it would be extremely prudent for ICANN to consider how any solution it adopts for national privacy laws also scales to meet the evolving national data localization requirements.

 

Best regards,

 

Michael Palage

 

P.S. Just to be clear these are my own personal opinions and not on behalf of any current, past or future client. Also please excuse any typos as most of this analysis was written between 12 AM and 4 AM Saturday morning. 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180113/2dcf15fc/attachment-0001.html>