RE: [gnso-impl-irtpc-rt] Outstanding Issue from today's IRT Call (email/account holder)

[Michele Neylon - Blacknight <michele@xxxxxxxxxxxxxx>]

Both emails came through ..


--
Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Domains
http://www.blacknight.host/
http://blog.blacknight.com/
http://www.blacknight.press/
http://www.technology.ie/
Intl. +353 (0) 59  9183072
Direct Dial: +353 (0)59 9183090
Social: http://mneylon.social
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845

From: owner-gnso-impl-irtpc-rt@xxxxxxxxx 
[mailto:owner-gnso-impl-irtpc-rt@xxxxxxxxx] On Behalf Of Mike O'Connor
Sent: Saturday, December 20, 2014 8:55 AM
To: gnso-impl-irtpc-rt@xxxxxxxxx
Subject: Fwd: [gnso-impl-irtpc-rt] Outstanding Issue from today's IRT Call 
(email/account holder)

i'm having a sinking feeling that i'm not subscribed to the list, so this is 
just a repeat of the note i sent a minute ago.  pls ignore...

m

Begin forwarded message:


From: Mike O'Connor <mike@xxxxxxxxxx<mailto:mike@xxxxxxxxxx>>
Subject: Re: [gnso-impl-irtpc-rt] Outstanding Issue from today's IRT Call 
(email/account holder)
Date: December 20, 2014 at 7:41:35 AM CST
To: Mike O'Connor <mike@xxxxxxxxxx<mailto:mike@xxxxxxxxxx>>
Cc: "gnso-impl-irtpc-rt@xxxxxxxxx<mailto:gnso-impl-irtpc-rt@xxxxxxxxx>" 
<gnso-impl-irtpc-rt@xxxxxxxxx<mailto:gnso-impl-irtpc-rt@xxxxxxxxx>>, Caitlin 
Tubergen <caitlin.tubergen@xxxxxxxxx<mailto:caitlin.tubergen@xxxxxxxxx>>

i finally circled back to this and realized that i wrote language that is 
almost as flawed as the original.

basically, this is a use case and i'm not sure actual policy language is 
required - since we didn't specify how the exchange of credentials was 
accomplished. since this customer is doing both sides of the transaction within 
the same registrar, it seems to me that the "independently verifiable" angle 
kicks in. here is what i propose

3.4 In the case where an Account Holder wishes to update an email address they 
can no longer access and thus cause a Change of Registrant, the exchange of the 
Change of Registrant Credential as described in section 3.2 must be transacted 
and validated through other verifiable means.

change of registrant does NOT include change of registrar (that's the whole 
underlying point of splitting these processes apart) - so their registrar can 
develop whatever processes that are needed to facilitate the exchange of 
credentials.  clearly email as the medium of exchange won't work in this use 
case, something else will be needed instead.  but registrars already have 
processes that they use to verify people's identity when email isn't available 
(Simonetta rattled a few off on the call but i've forgotten what they were).  
isn't that all that's required?

On Dec 12, 2014, at 9:33 AM, Mike O'Connor 
<mike@xxxxxxxxxx<mailto:mike@xxxxxxxxxx>> wrote:


oops - i forgot to attach the revised draft too.

<Draft Change of Registrant Policy_11Dec-MO1.docx>

On Dec 12, 2014, at 9:26 AM, Mike O'Connor 
<mike@xxxxxxxxxx<mailto:mike@xxxxxxxxxx>> wrote:


hi all,

here's a first-try at the revision:
3.4 The 60-day transfer lock will be required if an Account Holder updates 
their email address, thus effectively causing a Change of Registrant and 
simultaneously rendering impossible the exchange of the Change of Registrant 
Credential as described in section 3.2.   If the Account Holder wishes to opt 
out of the lock, they can validate the change of address through other 
verifiable means.

On Dec 11, 2014, at 7:22 PM, Caitlin Tubergen 
<caitlin.tubergen@xxxxxxxxx<mailto:caitlin.tubergen@xxxxxxxxx>> wrote:


Please find the draft COR policy attached and accept my apologies for a double 
email.

Kind regards,

Caitlin

From: Caitlin Tubergen 
<caitlin.tubergen@xxxxxxxxx<mailto:caitlin.tubergen@xxxxxxxxx>>
Date: Thursday, December 11, 2014 at 5:00 PM
To: "gnso-impl-irtpc-rt@xxxxxxxxx<mailto:gnso-impl-irtpc-rt@xxxxxxxxx>" 
<gnso-impl-irtpc-rt@xxxxxxxxx<mailto:gnso-impl-irtpc-rt@xxxxxxxxx>>
Subject: Outstanding Issue from today's IRT Call (email/account holder)

Hi, All,

Thank you to everyone who attended the call;  it was a very robust discussion.

For those who were unable to attend, I have attached instructions on how to 
listen to the recording.

At the start of the call, I presented a scenario whereby a Prior Registrant 
would be unable to ACK/affirm a Change of Registrant request (COR) request 
because their email account no longer exists. (Perhaps they left their company, 
university, etc.)  Similarly, if someone were to move and suddenly have a new 
address, telephone, email address, ISP provider, it would be impossible to ACK 
a COR via email, postal mail, phone, etc.  While this is narrow use case, ICANN 
staff and the IRT are trying to ensure that we are not creating an unworkable 
scenario where a Prior Registrant cannot update his or her email address.

Section 3.4 of the draft COR Policy would allow a registrant to log into their 
account and update their information via their verified account.  This gets 
around the non-existent email address issue, but some have expressed concerns 
about the risk of hijacking since resellers, hosting providers, et. al., may be 
an account holder.

ICANN staff is currently seeking solutions to the problem mentioned above.  
Specifically, we are looking for alternative authentication methods besides the 
exchange of pin.

A couple of suggestions mentioned on the call include:
            * FOAs for change of registrant.  (The Prior Registrant would 
receive an informative FOA at its email address (listed in Whois) and if it 
doesn't contact the registrar within a certain number of days, the email change 
would go through.)
            * Alternative authentication depending on the type of registrant 
change, i.e., a different authentication method could be used if the name is 
staying in the same account rather than a "push" between accounts
Please feel free to elaborate on the above or provide new suggestions entirely. 
 We discussed the difficulty with the resolution of this particular problem and 
how this may need to back to the GNSO for more guidance if it cannot be 
resolved within the IRT, particularly since the IRT is not a representative 
body of the ICANN community.

Please provide any suggestions to me by COB Thursday, 18 December.  Thank you 
in advance for your feedback.

Kind regards,

Caitlin
<Draft Change of Registrant Policy_11Dec.docx>


PHONE: 651-647-6109, FAX: 866-280-2356, WEB: 
www.haven2.com<http://www.haven2.com/>, HANDLE: OConnorStP (ID for Twitter, 
Facebook, LinkedIn, etc.)



PHONE: 651-647-6109, FAX: 866-280-2356, WEB: 
www.haven2.com<http://www.haven2.com/>, HANDLE: OConnorStP (ID for Twitter, 
Facebook, LinkedIn, etc.)



PHONE: 651-647-6109, FAX: 866-280-2356, WEB: 
www.haven2.com<http://www.haven2.com/>, HANDLE: OConnorStP (ID for Twitter, 
Facebook, LinkedIn, etc.)



PHONE: 651-647-6109, FAX: 866-280-2356, WEB: 
www.haven2.com<http://www.haven2.com>, HANDLE: OConnorStP (ID for Twitter, 
Facebook, LinkedIn, etc.)