Re: Implementation of EPP AuthInfo
Vlad Dinculescu <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
Hi Francisco, Thanks for the reply, please see responses inline below. On 07 May 2013, at 8:33 AM, Francisco Obispo <[email protected]> wrote: > Hi Vlad, > > What are the problems you're trying to address with these measures? Simply put, we are attempting to avoid registrars performing updates on Contact information that are not authorised or requested by the Contact. We have found that "bringing out the big stick" doesn't work effectively, so now we are attempting to put the decision making where it belongs, in the hands of the registrant. > > Some thoughts below: > > > On May 6, 2013, at 11:23 PM, Vlad Dinculescu <[email protected]> wrote: > >> All, >> >> Please share your thoughts regarding the implementation of the Contact AuthInfo for the approval of initiated contact updates. >> >> Our current process looks to have the registrant provide the code as an indication of approval regarding the update of their information, completing the update instantly. Updates that are not provided with the code will not execute. >> > > Do you want to accept an update from a non-sponsoring registrar? > > If that's not the case, the AuthInfo will be available to the sponsoring registrar anyway. We did identify this issue as well, knowing that the sponsoring registrar would have access to the code. Does an implementation exist where the AuthInfo is used as an out-of-band means of authorisation from the registrant. > >> Further to this, we are looking to implement the Domain AuthInfo code as a definite measure for approving registrant changes to a linked domain. In this instance the current registrant must provide the Domain AuthInfo code as approval of the registrant change. >> > > > Same as above, but in addition, a contact object can be independently updated regardless if its used in a domain name or not, so the restriction will only have effect if you 'replace' the registrant with other ID, but not if you change the contact underlying data. > In this instance we are looking at the replacement of the associated domain registrant ID with a different one. This is a domain update where the current registrant can use the associated domain AuthInfo to approve the change of the registrant ID to a different one. > >> Regards, >> Vlad Dinculescu >> -------------------------------- >> Domain Name Services >> _______________________________________________ >> provreg mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/provreg > > Francisco Obispo > Director of Applications and Services - ISC > email: [email protected] > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID = B38DB1BE > _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg