[gnso-irtp-pdp-jun08] Background information from Issues Report

[Marika Konings <marika.konings@xxxxxxxxx>]

Dear All,

In order to put the deliberations of the Working Group further in context, I 
thought it could be helpful to share the relevant information from the issues 
report with you prior to our next meeting (see below).

With best regards,

Marika

Issue I - Inter-Registrar access to Registrant email addresses

 *   Issue A. (Issue #1) Whether there could be a way for registrars to make 
Registrant Email Address data available to one another.

Currently there is no way of automating approval from the Registrant, as the 
Registrant Email Address is not a required field in the registrar Whois. This 
slows down and/or complicates the process for registrants, especially since the 
Registrant can overrule the Admin Contact.

 *   Section 1.1 of the Transfer Policy identifies the Registrant and the 
Administrative Contact as parties who can authorize a transfer, and notes that 
the Registrant's authority supersedes that of the Administrative Contact. 
Accordingly, an authorization from the Registrant provides a reliable ground 
for executing a transfer, while an authorization from the Administrative 
Contact can be contested by the Registrant, in spite of being recognized as a 
valid ground for a transfer. A convenient means to acquire Registrant 
authorization could thus enable a reduction of the number of contested 
transfers.
 *   During its deliberations, the Transfers Working Group noted that the issue 
is related to the Whois provisions, since the email address of the 
Administrative Contact is a required field in Whois, in contrast to the 
Registrant email address. However, in the context of a PDP focused on the 
Transfer Policy, any proposed policy change affecting Whois policy (for example 
requiring registrant email information in the Whois) would be outside the scope 
of the PDP. The issue to address is thus limited to other means of keeping, 
maintaining and exchanging registrant email information between the relevant 
Registrars. This invokes procedural, administrative and security aspects.


Issue II - Options for electronic authentication

 *   Issue B. (Issue #3) Whether there is need for other options for electronic 
authentication (e.g., security token in FOA) due to security concerns on use of 
email addresses (potential for hacking or spoofing).
 *   The original Transfers Task Force mentioned this issue as follows in its 
Final Report:

19. In the event that the Gaining Registrar must rely on a physical process to 
obtain this authorization, a paper copy of the Standardized Form of 
Authorization will suffice insofar as it has been signed by the Registrant or 
Administrative Contact and is accompanied by a physical copy of the Losing 
Registrar's Whois output for the domain name in question.
a - b [...references to physical documents, of no relevance here. ]
c. The Task Force notes support for the concept that in the event of an 
electronic authorization process, recommended forms of identity would include;-
- Electronic signature in conformance with national legislation, for instance, 
the United States e-Sign Act
- Email address matching Registrant or Administrative Contact email address 
found in authoritative Whois database.
        In relation to the first bullet point above, it can be noted that the 
current extent of Registrars' use of digital signature means for transfers is 
unknown. Such information could be useful                                       
                               to collect as background for deliberations in a 
future PDP covering this issue.

 *   The Transfers WG noted the issue in its report as follows:

According to the policy, the Gaining Registrar is required to obtain the FOA 
from the Registrant or Administrative Contact before initiating a transfer 
request. The Registrar of Record also has the option to send an FOA to confirm 
the transfer request. Policy issues relating to the FOA include:
1. Whether there is need for other options for electronic authentication (e.g., 
security token in FOA) due to security concerns on use of email addresses 
(potential for hacking or spoofing).

 *   Regarding the risk of spoofing mentioned by the Transfers WG, useful 
background information is provided in the SSAC report on domain name hijacking, 
available at http://www.icann.org/announcements/hijacking-report-12jul05.pdf . 
Recommendation 10 of this report states: "ICANN should consider whether to 
strengthen the identity verification requirements in electronic correspondence 
to be commensurate with the verification used when the correspondence is by 
mail or in person."
 *   The SSAC report was produced in 2005 and it should be noted that, since 
then, EPP1 has been deployed by all gTLD registries that have implemented the 
Transfer Policy. Since EPP requires an authorization ("AuthInfo") code, EPP 
deployment may have had an impact from a security standpoint and recent data in 
this respect could be useful as background for a future PDP covering this issue.
 *   It can also be noted that some ccTLDs do use electronic authentication 
methods for transfers, for example through digital signatures for 
authentication of e-mail requests. The .UK registry operator Nominet uses PGP2 
as described at http://www.nic.uk/registrars/systems/auto/pgp/ . Another 
example is the .SE registry operator, IIS, featuring a certificate-based web 
interface ("Domänhanteraren" - in English "The Domain Handler") for the 
registrant, where the registrant can effectuate changes of domain information, 
including change of Registrar, see https://domanhanteraren.iis.se/start/welcome 
. There may be other such examples of interest as references for this issue.

Issue III - Provisions for partial bulk transfers between Registrars

 *   Issue C. (Issue #12) Whether the policy should incorporate provisions for 
handling "partial bulk transfers" between registrars - that is, transfers 
involving a number of names but not the entire group of names held by the 
losing registrar.
 *   This aspect was not touched upon by the Transfers Task Force, but 
identified as a potential issue (under "Other") by the Transfers WG in its 
report.
 *   Part B of the Transfer Policy governs bulk transfers, meaning transfer of 
all domains sponsored by one Registrar to another Registrar, for example as a 
consequence of one Registrar acquiring another. According to the policy, bulk 
transfers can only take place under certain specific conditions, for 
information see part B in http://www.icann.org/transfers/policy-12jul04.htm.
 *   While different from bulk transfers in the "complete" sense, i.e. transfer 
of a Registrar's complete domain portfolio to another Registrar, the need for 
"partial" bulk transfers can arise due to, for example, company takeovers, 
where the acquiring company wishes to transfer some or all of the acquired 
company's domains to its own Registrar of Record. There is no prescribed way of 
doing so in the Inter Registrar Transfer Policy other than domain by domain, 
although Registrars are free to accept, for example, fax lists with numerous 
domains to transfer, while still having to follow the 
authentication/verification practices of the policy. The extent of such 
"voluntary provisions to facilitate partial bulk transfers" in practice is 
unknown.
 *   NeuLevel,Inc., the registry operator of .BIZ, has proposed the launch of a 
partial bulk transfer service, which has been approved by ICANN through the 
RSTEP3 procedure. This service proposal was prompted by two Registrars' request 
for a partial bulk transfer between them. For further information, see 
http://www.icann.org/registries/rsep/NeuLevel_request.pdf
 *   For information, there are provisions in place for partial bulk transfers 
in some ccTLDs. The .UK registry, Nominet, has a procedure for "mass 
transfers", described at http://www.nic.uk/registrants/maintain/transfer/mass/ 
and also for PGP-signed "bulk" operations at the registrar level, described at 
http://www.nic.uk/registrars/systems/auto/bulk/ (see especially Example 9 
therein, of relevance for partial bulk transfers). There may be other such 
examples of interest as references for this issue.