Proposed for domain transfers — Big changes
Working group considers big changes to the domain transfer process.
Significant changes could be coming to domain name transfers, although it’s still early and a lot could change.
The first recommendations of an ICANN working group reviewing the Inter-Registrar Transfer Policy are due out for next week’s ICANN 74 Prep Week. A draft (pdf) of that note, which may well be the final form, proposes notable changes.
First, it would eliminate the need for the winning or losing registrars to send a “Form of Authorization” (FOA) for domain transfers. Until GDPR obscured Whois data, the gaining registrar would send an FOA to the contact in Whois to verify they wanted to transfer the domain. GDPR put that requirement on pause since the gaining registrar has no idea who owns the domain. So today, here’s how a domain transfer works:
1. Client gets an authorization code from their existing registrar and provides it to the gaining registrar
2. Gaining registrar verifies the transfer request and initiates transfer
3. Losing registrar sends notice of pending transfer to client, giving them up to 5 days to cancel the request
The working group proposes an additional simplification: removing the losing registrar’s pre-transfer notification with the cancellation option.
Instead, the losing registrar is required to send a message to its client within 10 minutes of receiving a request for a Transfer Authorization Code and within 24 hours of a transfer-out being completed.
This is interesting since a domain transfer can be completed within minutes if there’s no five-day hold. It seems that many domain owners would only find out regarding a transfer following it is completed. The working group is going to consider the concept of rollbacks later in the process; it would seem this ought to be considered in conjunction with such a critical transfer policy change.
Speaking of authorization codes, the group recommends requiring that registrars only generate the codes by client request rather than keeping them active for all domains at all times. This ties into the requirement to notify client transfer code requests.
The other major proposed policy change is around locks. Right now, locks can differ by top level domain and by registrar. For example, when you register a .com domain, the registry requires the registrar to lock it from transfer for 60 days. Registrars also have the option, but not the requirement, to lock .com domains when they are transferred in.
The working group recommends requiring registrars to lock all generic top level domains for 30 days following registration or transfer.
It has two justifications for the initial lock. First, the registrar can discover credit card/payment issues. I’m curious how much of a problem this is; if someone registrars a domain at Registrar X with a bad payment method and wants to transfer it to Registrar Y, they will have to make yet another payment for the transfer. Second, the lock gives firms an opportunity to file a UDRP against the fresh domain ahead of it’s transferred. I don’t see many UDRPs filed for domains that quickly, and I’m not sure why they couldn’t just file it naming the fresh registrar if it’s transferred.
The goal of transfer locks is to prevent multiple transfers following a theft. But requiring rather than allowing registrars to lock domains for 30 (or right now 60) days could make it more difficult for escrow services that take control of domain names to transfer domains.
Internet Commerce Association held a members-only call earlier this month asking for feedback regarding domain transfers. The call included three members of the working group representing various stakeholders: Intellectual Property, Registrars, and the Business Constituency. ICA General Counsel Zak Muscovitch noted that transfer policy is a challenge in balancing security versus portability of domain names.
The initial note will be open for public comment, and everyone in the domain community ought to take time to consider this notable issue.
Note that additional transfer issues, counting transfer locks due to changes made to the registrant, will be on the table in later parts of the process.
