TL;DR
The registrar transfer process for gTLDs needs to change once the public Whois “goes dark”. The end result will be a process that creates a more streamlined experience for domain owners, while continuing to be secure against domain theft. Moving forward, when an inbound registrar transfer is ordered, we will submit the transfer directly to the registry instead of waiting for the Form of Authorization to be completed.

Upcoming Changes to the Domain Transfer Process

Among the most noticeable and significant changes to result from the domain industry’s implementation of the GDPR are those to the Whois system. As we’ve written in past blog posts, as of May 25, 2018, Enom and many other domain registrars and registries will cease the display of personal data in the public Whois.

The industry discussion around the effects of the Whois “going dark” has largely focused on the possible lack of access that law enforcement or the security community members may have to Whois data, the potential problems this presents, and how parties with legitimate legal interest in the data may still be able to obtain it. However, the impact of the change goes beyond the simple ability for a person to look up a domain’s contact data. There are automated processes and systems which rely on access to the public Whois contact details in order to function, and we need to make accommodations for these processes as well.

The most significant impacted process, which we are working hard to ensure is not interrupted by these changes, is the registrar transfer process. Here, we’ll provide details about how we will modify the transfer process to accommodate new, heightened privacy measures for the handling of registrant contact data, and we’ll suggest some changes that our resellers may want to undertake. Ultimately, the updated transfer process will not only provide a work-around for the lack of a publicly displayed contact email, but will result in a simpler, more streamlined experience for the domain owner while continuing to protect against unauthorized transfers and ensure the privacy of personal data.

The Domain Transfer Process Today

Let’s start with a review of the registrar transfer process as it stands today. For reference, we’ve provided a flow chart which compares the current and updated transfer processes.

Step 1

The domain owner works with their current (losing) registrar to unlock the domain and obtain the transfer authorization code, also called an EPP Code. This step will remain the same even after the transfer process is updated since the current registrar can and should verify that the person unlocking the domain and requesting the authorization code truly has the authority to do so.

Step 2

Once the domain has been prepared for transfer, the domain owner works with the new registration service provider to initiate the transfer. Here at Enom, we’ve always required the authorization code to initiate inbound transfer orders. Contact information may also be provided as part of the transfer order; if this information is not included, the Enom system will automatically use the account contact info for the domain transfer.

Step 3

In the current transfer process, the gaining registrar sends the initial Form of Authorization (FOA) to the domain transfer contact email, which they acquire from the public Whois. The domain transfer contact email may be either the registrant or the administrative contact; at Enom, our current practice is to send the FOA to both contacts. This FOA must be responded to within five days, and the transfer will only proceed if it is approved at this stage (Step 3a). Once the transfer contact approves the transfer, the gaining registrar submits the transfer order to the registry, who then notifies the current registrar (Step 3b).

Step 4

The current (losing) registrar sends a secondary FOA, which is optional for the domain transfer contact to complete. If the domain transfer contact does not respond to it within five days, the transfer will proceed automatically at the end of this five-day period. Alternatively, the domain transfer contact can choose to use this step to cancel the transfer or confirm it again.

Step 5

The registry operator completes the transfer process by moving the domain to the gaining registrar’s credential, typically renewing the domain for one year. At this time, the domain is usually locked for 60 days, although standard procedure may differ among registries.

How Will Transfers Work Post-GDPR?

At present, the gaining registrar initiates a domain transfer by sending an FOA to the domain contact email, but once the public Whois “goes dark,” registrars may not be able to identify the contact email for a domain that isn’t under their accreditation. The question becomes, how can we securely and efficiently process a domain registrar transfer without a publicly accessible domain contact email? Many registrars have been thinking about this as part of their GDPR compliance work and have taken a collaborative approach to finding an industry-standard solution.

The TechOps Subcommittee of the Registrar and Registry Stakeholder Groups has proposed modifications to the current transfer process which are intended to resolve this issue; their March 8 letter can be read on the ICANN website. Enom will proceed with the changes to the inbound transfer process as described in that letter, to ensure that the inter-registrar transfer process continues to operate smoothly after contact data is no longer available via the public Whois.

Keeping Domain Transfers Secure

In the Enom platform, there will be no required changes to how resellers initiate inbound transfers (Step 2), since both the contact data and the transfer authorization code are already required. The only real change is that, in cases where we are the gaining registrar, once the transfer order has been submitted in our system we will move directly to submitting the transfer request to the registry (Step 3b). We are making the required change to deprecate the initial Form of Authorization, with no action needed by our resellers.

Registrar transfers for many ccTLDs already follow a process very close to this, where the authorization code for an unlocked domain is all that’s required before submitting the transfer to the registry. Making this change across the board allows us to ensure that inbound transfers continue to function for all domains coming into our platform.

Another security measure that we would encourage registrants to take is to keep the domain locked, using the “ClientTransferProhibited” status, at all times unless specifically intending to transfer to another registrar. As a registration service provider, you can help your customers maintain their domain security in several ways, including requiring strong account passwords, enabling 2-factor authentication, and locking domains by default until otherwise requested by the domain owner.

Additional Changes We’re Making at Enom

Moving forward, whenever a transfer into Enom is completed, the domain’s contact data will be updated to match that which was used for the transfer order. This is currently optional, but will become mandatory; we will no longer be able to rely on the registry-provided contact data to be correct and not include placeholder information, because other registrars may no longer share registrant contact data with registries. In cases where the owner contact is new to our platform, the registrant verification process will begin as soon as the transfer is complete.

To better illustrate the streamlined transfer process, we have created this diagram:

Enom Transfer process before & after

You can also review the updated inbound transfer approval email and landing page content:

Transfer In approval email

Transfer In approval landing page

Is This Really OK?

Adjusting the inter-registrar transfer process in response to GDPR-related industry changes is a priority for Enom. We believe that domain owners should continue to be able to choose their registrar and move between registrars at their discretion, as long as sufficient security measures to protect against domain theft remain in place. Absent an ICANN-approved transfer policy modification, our best option is to conform with this model proposed by leading registrars, including Enom.

The modified transfer process meets our requirements around security and anti-theft: only the authorized domain contact has the ability to unlock the domain and obtain the transfer authorization code, and only they may approve the transfer away from the current registrar.  

We can already point to examples of the transfer process working as it is described here, in use today. Most ccTLDs, .CA and .DE, to name a few, currently follow a process like the one we’ve outlined above, where the authorization code is required to initiate the transfer, but there is no Form of Authorization requirement for the gaining registrar.

And from the client’s perspective, this is just one less step for them to complete as part of the transfer process, making it easier for them to move to their preferred service provider. This change is something registrants have asked about for years, and it removes one of the barriers to transferring registrars without compromising the domain’s security.

How Does This Relate to the Consent Management Process?

There is, of course, a connection between this updated transfer process and the newly introduced consent management process — any domain coming into our system must have a consent settings profile that lets us know how to handle all personal data related to that domain. Transferring from one registrar to another, or from one Enom reseller to another reseller, will thus trigger a consent request to the domain owner, just like a new registration would.

Enom resellers who use the “pushdomain” API command or the “push” option in the Control Panel to move domains between distinct reseller accounts should keep this in mind so that clients are not surprised by consent requests resulting from a domain push.

When is This Happening, and How Should I Prepare?

We will adopt this new domain transfer process when our other GDPR-related changes go live, on or shortly before May 25, 2018. We appreciate that this will require our resellers to educate their support staff and we hope this post serves as a valuable resource.

While we cannot speak for other registrars or registry operators, who will no doubt soon be announcing their own plans for handling domain transfers in a post-GDPR world, we’d like to again emphasize the fact that the model we are following was born from the collaborative efforts of leading registrars, ourselves included, and has already proven to be secure and efficient when used for ccTLDs. It is our hope that other registrars will plan to follow this model, and that eventually ICANN and the community-led policy development process will bring us to an industry-wide standard; at such time as ICANN provides a working and mandatory transfer policy, we will certainly comply with it to the fullest extent that we are able. That said, our primary concern is that domain owners on our platform maintain full control over their private information, products and services, and the ability to select the registrar or service provider that they prefer, while we remain compliant with data privacy laws and ensure the appropriate levels of security are in place. These transfer process changes are significant, necessary, and ultimately create a streamlined process that benefits registrants, resellers, and registrars.

Learn more about the GDPR:

GDPR Updates – Understand Enom’s approach to the policy

• GDPR-Related Contract Changes (Published on Mar. 5, 2018)
• The GDPR’s Right to Be Forgotten (Published on Jan. 18, 2018)
• Consent and the GDPR (Published on Dec. 21, 2017)
• How will the GDPR impact Whois? (Published on Nov. 9, 2017)
• The GDPR Overview (Published on Oct. 30, 2017)

GDPR Resources – View third-party resources on a specific GDPR topic

• Right-to-be-forgotten-related resources (Published on Feb. 1, 2018)
• Consent-related resources (Published on Jan. 4, 2018)
• Whois-related resources (Published on Dec. 7, 2017)
• GDPR Basics & Best Practices Resources (Published on Nov. 9, 2017)