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, resellers should use the “sw_register” API call for inbound transfers and include the transfer authorization code via the newly introduced “auth_info” parameter. We will then submit the transfer directly to the registry as soon as the order is placed in our system instead of waiting for the inbound Form of Authorization to be completed. The “simple_transfer” API call, which currently requires the authorization code, but not the domain contact data, will be temporarily suspended as of May 25, 2018. A quick summary of these changes is available in the OpenSRS Knowlege Base.

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, OpenSRS 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 a 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 workaround 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. The authorization code may be provided as part of initiating the transfer, or it may be provided as part of step three.

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 OpenSRS, we currently use the admin contact. 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 point, the domain is usually locked for 60 days, although the 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. OpenSRS 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 cases where OpenSRS is the gaining registrar, resellers will have the ability to provide the authorization code along with the transfer order (Step 2.), and if they do so, we will submit the transfer request to the registry as soon as the order has been submitted in our system, without first sending an email to the domain owner (Step 3b).

If the authorization code is not provided as part of the transfer initiation, then we will send an email to the owner contact provided on the transfer order. This new email will be sent instead of the FOA, with a simplified copy, requesting that the registrant provide the authorization code via an updated transfer approval landing page (Step 4).

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 OpenSRS

Alongside implementing the changes outlined above, OpenSRS will move to using the domain owner (registrant) contact as the domain transfer contact, rather than the administrative contact. We’ll use the owner contact both in order to provide the transfer authorization code to a registrant transferring away from our system and to send any transfer-related emails for both inbound and outbound transfers.

Moving forward, whenever a transfer into OpenSRS is completed, the domain’s contact data will be updated to match that which was provided in 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 domain owner contact is new to our platform, the registrant verification process will begin as soon as the inbound transfer is complete.

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

OpenSRS Transfer Process

You can also review the updated inbound transfer approval email and landing page content that will be presented to registrants:

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 OpenSRS. 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 OpenSRS.

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.

Technical details

In the OpenSRS platform, we have two API calls for transferring a domain: “sw_register”, and “simple_transfer”.

The “sw_register” API call has been updated to allow the inclusion of the authorization code: the new parameter is “auth_info” and the details for how to use this parameter are now included in our API Documentation.

The “simple_transfer” API call, which currently requires the authorization code but not the domain contact data, will be temporarily suspended as of May 25, 2018. This API call was reliant on registrant contact information being available from the registry or losing registrar. We would copy over this information for each domain automatically instead of requesting it at the time the transfer is initiated. As the registrant’s contact information can no longer be obtained in this manner, we will need to evaluate if and how we can reintroduce this call at a later stage.

Most of our transfers come through on the “sw_register” API call, so updating that call was a priority. We encourage any reseller using the “simple_transfer” API call to update to the “sw_register” command as soon as possible.

How does this relate to registrant consent?

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 OpenSRS reseller to another reseller, will thus trigger a consent request to the domain owner, just like a new registration would.

OpenSRS resellers who use the “rsp2rsp_push_transfer” 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 (we hope this post serves as a valuable resource!), but, as you’ll read below, our hope is that it will generate very minimal backend work for our resellers. We know this post was a lengthy one, so here are the action items that OpenSRS reseller partners should take away:

  1. Start including the “auth_info” parameter in the “sw_register” API call as soon as is feasible. However, rest assured that the transfer process will not be interrupted if you aren’t able to implement this change. In cases where the authorization code is not provided to us as part of the “sw_register” request, OpenSRS will simply contact the registrant to obtain the code via an email request.
  2. If you use the “simple_transfer” API call, update to use the “sw_register” call instead. If we do return to this “simple_transfer” API call in the future, the functionality will be different than it is today.

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 OpenSRS’ approach to the policy

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