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

[Mike O'Connor]

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 at haven2.com>
> 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 at haven2.com>
> Cc: "gnso-impl-irtpc-rt at icann.org" <gnso-impl-irtpc-rt at icann.org>, Caitlin Tubergen <caitlin.tubergen at icann.org>
> 
> 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 at haven2.com> 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 at haven2.com> 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 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.)
>>> 
>> 
>> 
>> PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
>> 
> 
> 
> PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
> 


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/20141220/d43e335e/attachment.html>