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

[Mike O'Connor]

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 at icann.org> wrote:

> Please find the draft COR policy attached and accept my apologies for a double email.
> 
> Kind regards,
> 
> Caitlin 
> 
> From: Caitlin Tubergen <caitlin.tubergen at icann.org>
> Date: Thursday, December 11, 2014 at 5:00 PM
> To: "gnso-impl-irtpc-rt at icann.org" <gnso-impl-irtpc-rt at icann.org>
> 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, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-impl-irtpc-rt/attachments/20141212/de96c640/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3630 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-impl-irtpc-rt/attachments/20141212/de96c640/smime.p7s>