Registrars and ICANN still discussing how to handle transfers after GDPR.
As domain name registrars and registries start masking email addresses in Whois to comply with GDPR, the domain name transfer process as we know it will break. The current owner’s email address is required to comply with the current ICANN process.
No email, no transfer*. At least not a compliant one.
Registrars are obviously worried about this. A big part of their business is convincing people to transfer domain names to them. So they came up with a proposal for how to handle transfers without email addresses. They have since modified the proposal so that an affirmative approval by the existing registrant is no longer required. Here’s the proposal in a nutshell:
1. Domain owner gets authorization code from losing registrar.
2. Domain owner provides authorization code to gaining registrar.
3. Losing registrar sends email to owner of record.
4. If owner of record does not cancel transfer, the transfer proceeds after five days.
This is what Tucows, the second largest domain name registrar, has already announced it will do.
But ICANN has not yet provided its blessing.
In a May 4 letter to the TechOps subcommittee of the Contracted Party House inside GNSO, which is making the interim transfer policy proposal described above, ICANN proposed an alternative way for gaining registrars to access the domain owner’s email address:
In order to provide the gaining registrar with access to the Transfer Contact’s email addresses, we propose that the authorization code be expanded to become the existing string plus the concatenation of the emails of the Registered Name Holder and the Administrative Contact with some separator to be defined (e.g., comma). For example, if the current authorization code for a given name is “NBGj67kGiPRRnGrP”, the registrant email is “[email protected]”, and the admin contact email is “[email protected]”, the new authorization code would be: “NBGj67kGiPRRnGrP,[email protected],[email protected]”. To be clear, every time there is a change in the registrant or admin contact, the authorization code would need to be updated appropriately. The first part of the new authorization code should continue to be renewed or updated as per current registrar procedures.
I’ll give credit to ICANN for thinking outside the box here. And if this idea had been floated many months ago, it might work. But it introduces technical issues (and a GDPR question about providing this data to the gaining registrar). These can’t be addressed before May 25, the TechOps subcommittee told ICANN.
So where does this leave us?
With our without ICANN’s blessing, we know that some gaining registrars will no longer send the currently required verification email (Form of Authorization) to the existing registrant and will just assume it’s a valid request.
This means you need to be extra vigilant about protecting both your email account and registrar account. I suppose that the most likely way someone would get your authorization codes is to hack your email or registrar account. And if they get access to either of those, they can hijack the approval process by changing the email address on record.
But Lord help us if a thief hacks a registrar’s database and can access the auth codes.
* Domain registrars can still access the email address in some instances, such as a thick Whois registry that provides the info via EPP call. However, this isn’t always the case, and won’t apply to .com and .net domains.
Why do the Registrars not come together and form a type of “Escrow” service for transfers and deal with it between themselves ?
Rubens Kuhl says
That would be a new data processor that either a legitimate use is shown or consent to send data would be required. With GDPR, less is more.
Luke Wayne says
Hi , thanks for your high quality post
As ICANN proposed alternative way , how can the gaining registrar believe the admin contact Email provide by the new Authorization Code is the real admin contact Email ？
I think this problem remains unresolved .