ICANN approves messy, unfinished Whois policy

With a week left on the GDPR compliance clock, ICANN has formally approved a new Whois policy that will hit all gTLD registries and registrars next Friday.
The Temporary Specification for gTLD Registration Data represents the first time in its history ICANN has invoked contractual clauses that allow it to create binding policy in a top-down fashion, eschewing the usual community processes.
The policy, ICANN acknowledges, is not finished and needs some work. I would argue that it’s also still sufficiently vague that implementation in the wild is likely to be patchy.
What’s in public Whois?
The policy is clearest, and mostly unchanged compared to previous drafts, when it comes to describing which data may be published in public Whois and which data must be redacted.
If you do a Whois query on a gTLD domain from next week, you will no longer see the name, address, phone/fax number or email address of the registrant, admin or tech contacts.
You will continue to see the registrant’s organization, if there is one, and the country in which they are based, as well as some information about the registrar and name servers.
In future, public RDAP-based Whois databases will have to output “REDACTED FOR PRIVACY” in these fields, but for now they can just be blank.
While the GDPR is only designed to protect the privacy of humans, rather than companies, and only those connected to the European Union, the ICANN policy generally assumes that all registrants will be treated the same.
It will be possible for any registrant to opt out of having their data redacted, if being contactable is more important to them than their privacy.
What about privacy services?
Since the May 14 draft policy, ICANN has added a carve-out for domains that are already registered using commercial privacy/proxy services.
Whois records for those domains are NOT going to change under the new policy, which now has the text:

in the case of a domain name registration where a privacy/proxy service used (e.g. where data associated with a natural person is masked), Registrar MUST return in response to any query full WHOIS data, including the existing proxy/proxy pseudonymized email.

In the near term, this will presumably require registries/registrars to keep track of known privacy services. ICANN is working on a privacy/proxy accreditation program, but it’s not yet live.
So how do you contact registrants?
The policy begins to get more complicated when it addresses the ability to actually contact registrants.
In place of the registrant’s email address in public Whois, registries/registrars will now have to publish an anonymized email address or link to a web-based contact form.
Neither one of these options should be especially complex to implement — mail forwarding is a staple service at most registrars — but they will take time and effort to put in place.
ICANN indicated earlier this week that it may give contracted parties some breathing room to get this part of the policy done.
Who gets to see the private data?
The policy begins to fall apart when it describes granting access to full, unexpurgated, thick Whois records to third parties.
It seems to do a fairly good job of specifying that known quantities such as URS/UDRP providers, escrow providers, law enforcement, and ICANN itself continue to get access.
But it’s fuzzier when it comes to entities that really would like to continue to access Whois data, such as trademark lawyers, security service providers and consumer protection concerns.
While ICANN is adamant that third parties with “legitimate interests” should get access, the new policy does not enumerate with any specificity who these third parties are and the mechanism(s) contracted parties must use to grant such access.
This is what the policy says:

Registrar and Registry Operator MUST provide reasonable access to Personal Data in Registration Data to third parties on the basis of a legitimate interests pursued by the third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the Registered Name Holder or data subject

This appears to give contracted parties the responsibility to make legal judgment calls — balancing the GDPR-based privacy rights of the registrant against the “legitimate interests” of the requester — every time they get a thick Whois request.
The policy goes on to say that when European privacy regulators, the courts, or other legislation or regulation has specifically approved a certain class of requester, ICANN will relay this news to the industry and it will have 90 days to make sure that class gets full Whois access.
But the policy does not specify any formal mechanism by which anyone goes about requesting a thick record.
Do they just phone up the registrar and ask? Does the registrar have to publish a contact address for this purpose? How does the registrar go about confirming the requester is who they say they are? Should they keep white-lists of approved requesters, or approve each request on a domain-by-domain basis? When does the right of a trademark owner outweigh the privacy right of an individual?
None of these questions are answered by the policy, but in a non-binding annex ICANN points to ongoing community work to create an “accreditation and access model”.
That work appears to be progressing at a fair rapid clip, but I suspect that’s largely because the trademarks lawyers are holding the pens and discussions are not following ICANN’s usual consensus-building policy development rules.
When the work is absorbed into the ICANN process, we could be looking at a year or more before something gets finalized.
How will transfers work?
Because Whois is used during the inter-registrar transfer process, ICANN has also had to tweak its Inter-Registrar Transfer Policy to take account of instances where registrars can’t access each other’s databases.
Basically, it’s scrapping the requirement for gaining registrars to obtain a Form of Authorization from the Whois-listed registrant before they start an inbound transfer.
This will remove one hoop registrants have to jump through when they switch registrars (though losing registrars still have to obtain an FOA from them) at the cost of making it marginally easier for domain theft to occur.
What happens next?
ICANN acknowledges, in seven bullet points appended to the policy, that the community has more work to do, mainly on the access/accreditation program.
Its board resolution “acknowledges that there are other implementation items that require further community conversation and that the Board encourages the community to resolve as quickly as possible”.
The board has also asked ICANN staff to produce more explanatory materials covering the policy.
It also temporarily called off its Governmental Advisory Committee consultation, which I wrote about here, after receiving a letter from the GAC.
But the big next step is turning this Temporary Policy into an actual Consensus Policy.
The Temporary Policy mechanism, which has never been used before, is set up such that it has to be renewed by the board every 90 days, up to a maximum of one year.
This gives the GNSO until May 25 next year to complete a formal Policy Development Process. In fact, it will be a so-called “Expedited” PDP or EPDP, that cuts out some of the usual community outreach in order to provide a speedier result.
This, too, will be an unprecedented test of an ICANN policy-making mechanism.
The GNSO will have the Temporary Policy baseline to work from, but the Temporary Policy is also subject to board-level changes so the goalposts may move while the game is being played.
It’s going to be a big old challenge, and no mistake.

Tweet

Tagged: .eu, article 29 working party, gdpr, gtlds, ICANN, privacy, rdap, whois, wp29