ICANN ICANN Email List Archives

[gnso-irtp-b-jun09]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [gnso-irtp-b-jun09] Identifcation

  • To: "Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>, "IRTP B Mailing List" <Gnso-irtp-b-jun09@xxxxxxxxx>
  • Subject: RE: [gnso-irtp-b-jun09] Identifcation
  • From: "Erdman, Kevin R." <Kevin.Erdman@xxxxxxxxxx>
  • Date: Mon, 3 May 2010 15:39:15 -0400

Comments on Michele's comments below.

Regarding proposed augmentations, 3.2 should be augmented to allow for the
Registrar to file within a time period of discovering a change in the domain
operation and 3.4.1 should also include a provision requiring an explanation
by the Registrant for any eTRP made after the 60-day Transfer Lock as to why
the hijacking was not discovered within the 60-day time period.
_____________________________________________________________________________
___________________________
Kevin R Erdman  T: 317.237.1029 | F: 317.237.8521 | C: 317.289.3934
Intellectual Property, Internet, and Information Attorney, Registered Patent
Attorney
BAKER & DANIELS LLP WWW.BAKERDANIELS.COM 300 N. MERIDIAN STREET, SUITE 2700 |
INDIANAPOLIS, IN 46204


-----Original Message-----
From: owner-gnso-irtp-b-jun09@xxxxxxxxx
[mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Michele Neylon ::
Blacknight
Sent: Monday, May 03, 2010 12:34 PM
To: IRTP B Mailing List
Subject: Re: [gnso-irtp-b-jun09] Identifcation



On 3 May 2010, at 17:24, Erdman, Kevin R. wrote:

> 
> Hi All,
> 
> Following up on my thoughts about busting the eTRP and addressing the
> identification issue, I find that they are somewhat related.  Here are a
> couple of thoughts to stir up the crowd for tomorrow's call.
> 
> Suppose someone hijacked a high volume web site, but did not disrupt the
> traffic.  Say hijacker A hacks into and changes the Registrant from
> BigCompany to individual A, but keeps the traffic running as usual.
> BigCompany never thinks to check the Registrant status, and 65 days after
> individual A hijacks the domain it is transferred to another Registrar.
Then
> at day 70, individual A starts to disrupt traffic to BigCompany's domain,
and
> BigCompany tries to invoke eTRP.  The new Registrar and the old Registrar
> would look to individual A as the Registrant and would not recognize
> BigCompany as the Registrant.  True that Registrant could use UDRP to
recover
> the domain if trademark rights were involved, but eTRP would not be
> available.

Yes, but that kind of scenario could probably be dealt with in a totally
different manner. 

>>From the perspective of the Registrant, they are a hijack victim that just
discovered the hijacking.  Any hijack can be dealt with by litigation, so if
we are proposing an eTRP to handle a situation where a Registrant can try to
get an immediate return of a hijacked domain that they just discovered.

> 
> On the subject of identification, I think that we are focusing on the wrong
> issue.  The issue is who is the true Registrant, not who is the individual
or
> corporation listed on the Registrant line.  

How can you differentiate between them? 
>>Using an automobile analogy, a person possesses a car and uses it with the
keys. The key holder may be the title holder, or the key holder may be making
payments to the title holder.  The hijacker hotwires the car and drives it
away.  We want to return the stolen car to the key holder (or maybe we want
to return the car to the title holder?).  In the domain world, I believe that
Registrars would like an easy way to confirm who the Registrant is through an
ICANN defined procedure rather than relying on national law (and whose
national law, the law of the Registrar or the law of the nation where the
Registrant claims to reside?).  I think this is an important distinction,
because lots of WHOIS information does not exactly comport with the actual
ownership/use of domains.  

> If in the Registration process
> the Registrar gave the Registrant a token that would uniquely identify the
> holder as the domain owner, then the Registrar would not need to comply
with
> any local law on proving identity.  In the situation above, the old
> Registrant could present the token to show that at one time it was the
> Registrant and invoke the eTRP.  Thus, rather than relying on local law to
> provide a way of verifying identity why couldn't we propose that the
> Registrar implement a token system for verifying Registrant status?

I can see problems with that

First off, say I register a domain name for a friend on my a/c with registrar
X. Using your process then you would see me as being the registrant and not
my friend. 

If my friend prefers to use registrar Y and moves the domain there (with
updated details at some point) then I'll still have your token ...

Or how about I register a domain and then sell it to someone else. Instead of
transferring the domain to another registrar the new holder moves the domain
to their account with the current registrar.

Also, what happens if an employee registers a domain using their personal
details and then corrects the error (or similar)?

>>There are potential problems with token administration, but at least it
would be an ICANN defined process (which would hopefully use technology
Registrars are familiar with) rather than relying on checking out passports
and corporate certificates from lands far and wide (which I would assume
would not be within the expertise of most Registrars).  A quick on-line
urgent return mechanism needs a quick way for a Registrar to determine if the
filing documents are in order.  Using the car analogy, the requestor must
show that they had the keys.  During the Registration process, would it be
possible or practical to deliver the token only to the Registrant and not to
the Administrative Contact?

> 
> There might then be an issue of false identification, but that is for a
> different discussion...
>
_____________________________________________________________________________
> ____________________________
> Kevin R Erdman  T: 317.237.1029 | F: 317.237.8521 | C: 317.289.3934
> Intellectual Property, Internet, and Information Attorney, Registered
Patent
> Attorney
> BAKER & DANIELS LLP WWW.BAKERDANIELS.COM 300 N. MERIDIAN STREET, SUITE 2700
|
> INDIANAPOLIS, IN 46204
> 
> -----Original Message-----
> From: owner-gnso-irtp-b-jun09@xxxxxxxxx
> [mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Matt Mansell
> Sent: Monday, May 03, 2010 6:43 AM
> To: Gnso-irtp-b-jun09@xxxxxxxxx
> Subject: [gnso-irtp-b-jun09] Identifcation
> 
> 
> Hi All
> 
> I've just been listening to last week's call in prep for tomorrow's.
> Apologies were sent but not noted. I wanted to add my thoughts re
> identification. 
> 
> I personally think it's a mute point. If a bad actor wants to commit
> fraud in stealing a name he is equally more than capable of providing
> faked identify. We see plenty of it as I'm sure everyone does and its
> increasingly hard to spot.
> 
> Essentially, without some sort of in-person, original documents process
> (Like applying for a Birth Certificate or Passport in the UK) I don't
> see how this can add any value, especially in digital form. We must
> remember that the receiving registrar will by virtue of fraudulent
> c/card data have the best checks they can already to verify the identify
> of their account holder. No registrar wants to unduly incur the costs of
> handling a chargeback or potential un-recoverable product costs. To put
> any liability on the registrar or registry to identify a transferee
> further will not reduce theft, particularly high value theft.
> 
> Rgds, Matt
> 
> 
> -----------------------------------------------
> Matt Mansell
> Mesh Digital Ltd
> Tel: +44 (0)1483 304030
> Fax: +44 (0)1483 304031
> Mbl: +44 (0)7715 168077
> Web: http://www.domainmonster.com
> 
> 
> 
>
-----------------------------------------------------------------------------
> ---
> This email (including attachments) is confidential and intended only for
the
> use of the addressee(s). If you are not an addressee you should not copy
it,
> re-transmit it, use it or disclose its contents, but should advise the
sender
> immediately and delete your copy from your system(s). Do not copy, use or
> disclose this email. Mesh Digital Ltd do not accept legal responsibility
for
> the contents of this message. Any views or opinions presented are solely
> those of the author and do not necessarily represent those of Mesh Digital
> Ltd. 
> 
> 
> 
> 
> ----------------------------
> ATTENTION:
> 
> To ensure compliance with applicable Internal Revenue Service Regulations,
> we inform you that any tax advice contained in this electronic message was
> not intended or written to be used, and cannot be used, for the purpose of
> avoiding penalties under the Internal Revenue Code.
> 
> 
> This message and all its attachments are PRIVATE and may contain
> information that is CONFIDENTIAL and PRIVILEGED.
> 
> If you received this message in error, please notify the sender by reply 
> e-mail and delete the message immediately.
> 

Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://mneylon.tel
Intl. +353 (0) 59  9183072
US: 213-233-1612 
UK: 0844 484 9361
Direct Dial: +353 (0)59 9183090
Fax. +353 (0) 1 4811 763
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845



----------------------------
ATTENTION:

To ensure compliance with applicable Internal Revenue Service Regulations,
we inform you that any tax advice contained in this electronic message was
not intended or written to be used, and cannot be used, for the purpose of
avoiding penalties under the Internal Revenue Code.


This message and all its attachments are PRIVATE and may contain
information that is CONFIDENTIAL and PRIVILEGED.

If you received this message in error, please notify the sender by reply 
e-mail and delete the message immediately.




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy