Scott Allan wrote:
> Thanks for acknowledging our efforts to stay "in bounds". We do take these
> issues seriously, as we are somewhat motivated to continue to provide
> service to you... :)
I respect you guys a lot for doing this. :-)
> >Curious. Because of how the client scripts, you give "manage
> >name for registrant" privileges to anyone who sets up a local
> >password database. This looked like a funny legal maneuver
> >so that we could have this ability without OpenSRS endorsing
> >it or providing tools.
>
> Well, not entirely true, it would be possible for a registrant to change
> hie U:P through the public manage interface, therefore locking the
reseller
> out of any control.
I could munge the password between my customer and the OpenSRS interface
thus preventing the user from ever knowing the REAL OpenSRS password and
being able to login via another interface.
Let me explain: Let say that, whenever I get a password from the user I
encode it and then pass that encoded value to OpenSRS. For simplicity's
sake, lets say that I reverse the characters in the password so that
"password" becomes "drowssap". So, when the user creates an account with a
password of "password", the actual OpenSRS password becomes "drowssap".
Whenever they login or change their password via my interface I'm careful to
reverse the password characters to make things work. But if they use a
different interface, they can't log in because only I have the password
encoding mechanics. This way the user must always use my interface and can't
"escape" having me in the middle.
Of course, reversing the characters in the password is a weak scheme. But I
could easily use an encryption mechanism to munge the password in a way the
user couldn't break even if they knew my algorithm.
> It is also a case of facilitation, not many resellers keep local copies of
> the passwords as it requires extra work. It has it's own barriers to
entry.
Interesting. I thought more people did it.
> >I'm not sure that having more domain registrations proves an RSP more
> >trustworthy. Many scummy business practices have come from large
> >companies. How does the RSP's size make a difference in the ICANN
> >legal agreements? But if this will satisfy ICANN, go for it. I'm sure
> >some RSPs would enjoy being freed from maintaining password
> >databases.
>
> Well, the theory is that in order you to have lots of registrations, you
> must conduct yourself in a responsible manner. I certainly concede that
> this is not bullet proof. None of these requirements is ICANN mandated or
> sanctioned, in fact most of these challenges exist as a result of ICANN
not
> understanding the market.
OK -- that makes some sense. Just make sure you run it by your lawyers. :-)
I understand that ICANN does not recognize us resellers in any way. Even
though we pay for the domain, the end user is viewed as the real owner of
the domain. I would like ICANN to recognize us resellers as a valid part of
the service chain in some way, but I feel that the domain name most be owned
by the end-user at all times.
To justify my access to my customer's domain name records and clearly state
the bounds in which I will operate, I've added the following to the
registration agreement:
}} 30. GRANT OF ACCESS. You grant DRH Internet Inc. access to
}} modify the details of your domain registration on your behalf. DRH
}} Internet Inc. expressly denies any claim of ownership to your
}} domain name which may be implied from this access. Customers
}} which have their domain registration and website hosted with
}} DRH Internet Inc. expressly grant DRH Internet Inc. permission
}} to modify the nameserver and technical contact information in
}} conjunction with the hosting service.
Since this registration agreement is actually between Tucows and the
registrant, it may be improper for me to have added this extra section. I
did run it by someone in OpenSRS a while ago and they thought it was a good
idea. Perhaps I should have a separate agreement between the registrant and
DRH Internet for their using my services that allows this grant of access.
I believe if us resellers are going to have access to modify domain details
(through a password database or a "trusted RSP" status), then I feel that
this legal text is important. Something needs to state that we are "helpers"
or "agents" for the end-user in dealing with Tucows (who is the actual
registrar) and define our actual role and permissions.
Perhaps this could help solve some of the legal problems? If the registrant
has contractually agreed to provide the RSP a limited grant of access, then
perhaps the RSP's access can be justified to ICANN. We are in a way the
"secondary admin contact" or whatever you want to call it.
> >I'm surprised that you placed "delete name" in the same category as
"manage
> >name for registrant"... well, that does make sense if the RSP deletes the
> >name instead of the client. BUT! What if the client deletes the name
through
> >a button on manage.cgi? This is then a client-initiated action and
perhaps
> >not needing RSP trust.
>
> Reseller deletes are different from end user deletions indeed.
I'm not understanding why they are so different. Why would the reseller ever
need to delete a name without the permission of an end user?
The following reasons for deletes have been brought up:
(a) Registrant typo in registration -- RSP and registrant agree.
(b) Registrant no longer needs name or must delete for legal reasons -- RSP
and registrant agree.
Well, the last reason breaks the pattern:
(c) Registrant has made bad on payment through credit card chargeback -- RSP
wants to delete, registrant will not agree.
Chargebacks become a hot issue whenever discussed. I'm not sure if the RSP
should be able to delete a name because of a chargeback. This is a thorny
issue I will leave to other more knowledgeable and braver souls to work out.
:-)
My point is that I think there could be a lot of benefit from having RSP &
registrant agreed deletions. Perhaps the RSP initiates the delete through
the RWI and the registrant agrees by logging into the manage.cgi interface
and clicking on a new button "approve delete request" that appears. This
avoids the whole "trust" issue and can be provided to all RSPs.
Then, if you wish, trusted RSPs can be given additional delete privileges,
but at least everyone gets basic delete functionality.
> Thanks for your comments - still working on my approach - good
> stuff though!
Thank you for listening and interacting! This is what helps keep me at
Tucows.
David
