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

["Mike O'Connor" <mike@xxxxxxxxxx>]

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>
> 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>
> Cc: "gnso-impl-irtpc-rt@xxxxxxxxx" <gnso-impl-irtpc-rt@xxxxxxxxx>, Caitlin 
> Tubergen <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> 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> 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> 
>>> 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>
>>>> Date: Thursday, December 11, 2014 at 5:00 PM
>>>> To: "gnso-impl-irtpc-rt@xxxxxxxxx" <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, 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.)