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 report, 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 because the gaining registrar has no idea who owns the domain. So today, here’s how a domain transfer works:
1. Customer 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 customer, 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 customer 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 because 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 about a transfer after it is completed. The working group is going to consider the concept of rollbacks later in the process; it would seem this should 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 customer request rather than keeping them active for all domains at all times. This ties into the requirement to notify customer 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 after 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 companies an opportunity to file a UDRP against the new domain before 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 new registrar if it’s transferred.
The goal of transfer locks is to prevent multiple transfers after a theft. But requiring rather than allowing registrars to lock domains for 30 (or currently 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 about 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 report will be open for public comment, and everyone in the domain community should take time to consider this important issue.
Note that additional transfer issues, including transfer locks due to changes made to the registrant, will be on the table in later parts of the process.