ICANN’s Transfer Policy Review Working Group has been hard at work since 2021, as we’ve discussed in our ICANN Policy series. The group’s Initial Report is now out for public comment and Tucows is preparing to submit our input by the September 30th deadline.
This post highlights some of the most significant updates being recommended to give you a sense of how the Transfer Policy is likely to change. We also want to invite you to share your feedback; it will help us ensure the comments we submit to the Working Group reflect your interests.
A bit of background
You may be having a déjà vu moment—didn’t this Working Group already issue their Initial Report? You’re not wrong! This group’s work was divided into three segments: Group 1a looked at the overall process of transferring a domain between registrars, Group 1b looked at the Change of Registrant (COR) process, and Group 2 covered transfer disputes and bulk transfers. The Initial Report we saw in June 2022 was for Group 1a only; the report we’re looking at now includes:
- Revised Group 1a recommendations (updated based on the comments provided in response to their 2022 report)
- Initial recommendations from Groups 1b and 2
The Transfer Policy is of significant importance to domain registrars and resellers for two reasons. For one, it ensures that domain owners have the freedom to choose their provider and change that decision as needed. Beyond that, it also protects against unauthorized transfers, commonly referred to as “domain hijacking.” The Transfer Policy must balance security against ease of use for the registrant—no simple task—and we think the Working Group has done a pretty good job of achieving this balance.
A look at the proposed changes
1. Transfer authorization code and approval process
Transfer Authorization Code
Now
The Transfer Authorization Code (authCode) is generated when the domain is created and can remain unchanged for the lifetime of the domain.
Proposed
The Transfer Authorization Code (TAC) is generated only when the domain owner requests it and lives only for 14 days. The domain owner is notified explicitly that the TAC has been issued.
Gaining Form of Authorization
Now
The Gaining Registrar sends a Form of Authorization (“Gaining FOA”) and the Registrant must use the link in the FOA to approve the transfer, otherwise it fails.
Proposed
Since ICANN’s “Temp Spec” came into effect in May 2018, we no longer send a Gaining FOA as the registrant data is not available to the Gaining Registrar. The Working Group is now formalizing this change: the transfer starts as soon as the domain owner submits the TAC. No more Gaining FOA 🎉.
Losing Form of Authorization
Now
The Losing Registrar sends a secondary Form of Authorization (“Losing FOA”) which can be used to cancel the transfer during the 5-day pending period.
Proposed
The Losing Registrar sends the renamed “Transfer Confirmation” with minor content changes to include the Gaining Registrar’s info; it can still be used to cancel the transfer during the 5-day pending period.
Summary
We support the changes to the Transfer Authorization Code lifecycle and the removal of the Gaining Form of Authorization; both will improve the security of the domain name and make the transfer process easier for registrants.
We would have preferred to see the Losing FOA no longer be required, as there are other security measures in place (mandatory lock periods, notifications, and TAC complexity and expiry). We’d also hoped to see a recommendation for a “fast-undo” process, which would allow the registrant to report hijacking and have their domain immediately returned to their previous registrar. Unfortunately, the Working Group did not reach consensus on whether such a process is needed and how it would work.
The Working Group is also recommending the creation of a new “Notification of Transfer Completion”, sent (as the name suggests) after a transfer is finished. It’s meant to ensure that the domain owner is aware of the transfer and includes when the transfer happened and which registrar the domain went to. The notice would also provide instructions for how to get support if they believe the transfer was invalid; we hope that this will be a useful notification.
2. Change of Registrant process
Process name
Now
Name: Change of Registrant (COR)
Proposed
Name: Change of Registrant Data (CORD)
Requirements
Now
Both a notification to and approval from both the original and the new owner are required.
Proposed
Only a notification is required, not approval.
Registrant opt-out
Now
The new owner can assign a Designated Agent (DA) to respond to Change of Registrant requests.
Proposed
Registrars can let the current owner opt out of receiving CORD notifications.
Summary
The existing Change of Registrant process caused a lot of confusion to domain owners. Some people didn’t understand why they got an approval email. Others forgot they had enabled us to act as their Designated Agent (DA) and then didn’t understand why they did not receive an approval email. Perhaps most frustratingly, people often discovered their DA completed the approval but didn’t opt out of the 60-day post-COR transfer lock, a pain for folks who were performing a Change of Registrant in preparation for transferring the domain to a new registrar.
The Working Group decided not to change the triggers for the Change of Registrant process: an update to the registrant name, organization, or email address is still considered a “material change.” One significant improvement the Working Group did recommend is removing the post-CORD lock, as we mentioned above. Under the proposed policy, a domain owner would be able to update the registrant data and then transfer to a new registrar right away; for security, the registrant will be notified several times through the update and transfer process to ensure they can get help if the transfer is unauthorized. We think this will improve the domain owner’s experience while ensuring that unexpected updates are flagged.
3. Lock period uniformity
Following registration
Now
Domains are locked for up to 60 days following registration; the specific timeframe depends on the TLD’s policy.
Proposed
All gTLDs are locked for 30 days following registration.
Following inter-registrar transfer
Now
Domains may be locked for 60 days after an inter-registrar transfer. It’s the registrar’s decision to apply or remove the lock.
Proposed
All gTLDs are locked for 30 days following a registrar transfer, but the registrar can remove that lock in limited circumstances at the registrant’s request.
Following a Change of Registrant
Now
When approving a Change of Registrant, the prior owner can opt out of the lock; otherwise, when the COR is completed, the domain is locked for 60 days.
Proposed
No lock is required after a Change of Registrant Data (CORD).
Summary
Domains can be locked to prevent an update or transfer, and that’s a useful security measure. The Working Group looked at the requirements for when a registrar must apply or remove a lock preventing inter-registrar transfer and decided that improvements were needed to achieve the best possible balance between security and ease of use.
Although we initially pushed for a shorter lock period than what the Working Group landed on, we’ve always been supportive of standardizing the lock period following new registration and registrar transfer. Having a 30-day lock period across the board—as opposed to unique durations for different TLDs— keeps things simple. It’s also a sufficient amount of time to raise a dispute under UDRP or with a payment provider. Finally, the shorter duration should reduce frustration for domain owners who do want to transfer again after a short period with their new registrar, as will the removal of the lock following a CORD.
Providing feedback
There are some areas where we would have liked to see bigger changes (this is why we said the Working Group did a “pretty good job”), and we plan to address these instances in our public comment. For example, we continue to believe transfers should go through immediately when the TAC has been provided to the gaining registrar; there’s no need for a five-day pending period, and it’s often a nuisance to registrants. We’ll also suggest that there needs to be leeway for a registrar to cancel a Transfer Authorization Code after it’s been issued, even without the registrant’s approval. Finally, we’ll talk about the need for a revised and expanded Transfer Dispute Resolution Policy.
We’d love to hear what you think about these highlights or any other aspects of the recommended changes to the Transfer Policy.
If you provide your feedback by 27 September, we can consider including your input when finalizing our own public comment. To provide feedback to the Tucows Domains Policy Team, please fill out this form. Your data will (as always) be processed in accordance with our Privacy Policy.
Alternatively, you can submit your comment to the Working Group directly. Anyone can do this, though you will first need to set up an ICANN account. We’re happy to help our resellers with this process—just reach out.