RE: [registrars] EPP Informed Consent - Game Set and Match ????

["Rob Hall" <rob@momentous.com>]

Mike,

Ok ... as a Registry Consultant, can you pull those stats ?

And as to .ca, I am not sure that the way they do it is any better.  In
fact, it is rather draconian and heavy-handed on the Registry side of things
that often pisses off our client's and frustrates them.

But here it is anyhow.

In the .ca world, the Registrant is ASSIGNED a userid and password by the
Registry.  The Userid is typically a 6 digit number like 185473 and the
password is always of the format 4 characters followed by 8 numbers.  ie:
rvec23163871. Obviously both are something that is almost impossible for the
Regsitrant to memorize.  They are set by the Registry and can not be chosen
by the Registrant.

To effect any critical changes to the domain, such as transfers or change of
admin contact, the Registrant must first go to the Registrar, and apply for
the changes.  The Registrar then sends the changes to the Registry using an
archaic (and proprietary) HTTPS XML command.

The Registrant must then log into the Registry using their userid and
password and acknowledge the change.  The Registry takes the view that only
the Registrant can authorize any changes, and the Registrar is not to be
trusted and can not authorize these changes.

The problems start to occur when the Registrant has no idea what his Userid
and Password are.  They are emailed directly to the Registrant by the
Registry when the domain is created.

To help solve this, the Registrar (in fact, any Registrar, including the
gaining Registrar) can send a command to the Registry asking the Registry to
resend the userid and password to the Admin Contact.  As they are a thick
Registry (VERY VERY thick!), they already have the admin email of the
Registrant and will resend out the userid and password.

The bigger problem comes when this admin email address is no longer valid.
Now the Registrant must start a process with the Registrar to have this
changed.  Because the change of this email address is considered "critical
information" by the Registry, the Registrant must log in and verify it with
the Registry.  Of course, they can't do this as they don't have the
password.  So now the Registry starts a process of emailing both the new
proposed admin contact and the old one, asking for verification.  This
manual email process takes a minimum of 7 days currently, but often takes as
long as 21 days.   Frankly, it just doesn't work and really frustrates
Registrants.

The other big problem is the losing Registrar has absolutely no way of
stopping the transfer.  Not even in cases of non-payment of fraud.

If the .ca Registry went to a system similar to .us or .info, where the
Registrar actually controls the domain, then some of their procedures might
be more tollerable.  It is also important to keep in mind that to be a .ca
Registrar, you do not need to be able to speak EPP or any other protocol
like it.  The Registry accepts ALL communications with them through their
proprietary XML system, AS WELL AS through a website AND EMAIL ! (yep ..
thats right, you can email the Registry any command and they will parse it,
and reply by email).

I think perhaps the only thing they do that might be beneficial in the .us
environment would be that they will email out the userid/password.  FOr
example, it might be beneficial if the .us Registry were to allow a
Registrar to ask that the AuthCode be emailed to the Registrant (by the
Registry).  This would stop Registrars from not giving it out to their
clients, or making it hard.  Any Registrar could then ask the Registry to
send out the AuthCode.  Then the only debate is what does that email look
like (it should be standardized), and who does it look like its coming from
(ie: the Registrar would typically want it to look like it is coming from
them, or at the least, not branded as anyone).

In addition, the .us Registry could always send out a new AuthCode that
could be used to effect the transfer, or change the AuthCode and send it
out, or keep a temporary "for transfers only" authcode that it generates.
This would be usefull in the cases where a losing Registrar is throwing up
roadblocks (other than for non-payment etc).

Hope this helps explain the .ca scenario.

Rob.






-----Original Message-----
From: Michael D. Palage [mailto:michael@palage.com]
Sent: Wednesday, December 04, 2002 11:35 AM
To: Rob Hall; registrars@dnso.org
Subject: RE: [registrars] EPP Informed Consent - Game Set and Match ????


Rob,

The point you raise is why I am modifying the .US proposal to match the .AU
policy that will require the gaining registrar to send the auth code to
registrant and administrative contact and ask for "re-verification." No
re-verification - no transfer. Thus the auth code alone will not initiate
the transfer.

The problems you talk about in connection with the Hosting Company is an
exact problem that Bruce has raised and why that reverification process is
so important in .AU.

Regarding common auth codes, that is why the PIR and .CN contracts require
registrars to provide unique auth codes.

I think you concerns have been addressed, or am I still missing something?

Regarding educating clients about Auth Codes that is something I think the
registrars are in an unique situation to do.

Mike

P.S. I am not a registry employee, I consult for Afilias to handle policy
and registrar accreditation issues. However, most of the problems that
Afilias has encountered in the use of Auth Codes has been the losing
registrar not timely providing it to the registrant. Beside that the Auth
Code works as intended. Based on you role with .CA perhaps you can share
some similar insight on transfers.



-----Original Message-----
From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
Behalf Of Rob Hall
Sent: Wednesday, December 04, 2002 10:42 AM
To: registrars@dnso.org
Subject: RE: [registrars] EPP Informed Consent - Game Set and Match ????


Mike,

I don't believe it is game, set and match.

How can you ensure that the Registrant that gave out his auth code is aware
of any transfer ?

While the authcode may be used to verify the IDENTITY of the Registrant, I
don't see how it can absolutely be used to verify that the Registrant agrees
to the specific transfer request.

I don't think Registrants realize what the authcode is really for. I also
bet most don't treat it like a PIN number or password at all.  I suspect
that if their hosting company was to ask for it, saying they needed it to
setup hosting, that most Registrants would give it.

In fact, I bet as a Registrar, I could ask for it for just about any reason
and they would give it to me.

Perhaps if the Registrar changes the AuthCode daily, it would provide better
security and more assurance that it hadn't been given out the year before
for something else.  But that doesn't solve the problem of what it is being
used for.

If an AuthCode is used in conjunction with a standardized transfer
authorization, then perhaps it is enough, but failing that, it doesn't
authorize the specific transfer.

It would be interesting to have some stats on this.  As a Registry employee,
can you pull some stats on how often the wrong authcode is sent to the
Registry for a given domain and transfer request.  Also, has it ever
happened where 2 transfer requests have come in from different registrars
with the same auth code (for the same domain?).

Rob.

-----Original Message-----
From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
Behalf Of Michael D. Palage
Sent: Tuesday, December 03, 2002 5:32 PM
To: Ross Wm. Rader; tim@godaddy.com; registrars@dnso.org
Subject: [registrars] EPP Informed Consent


Ross,

I think if you look at my .US proposal and then the constructive comments of
Bruce based upon .au policy, I think EPP has everything we need.

Regarding informed consent based on the .au model:

(1) the registrant and/or admin contact can only get the auth code from his
registrar (losing registrar), thus adequate safeguards can be implement
here;

NOTE: Under the PIR (.ORG) agreement and my .US proposal, the registrar auth
codes must be unique (added security)

(2) the registrant and/or admin contact must then submit this to the gaining
registrar;

(3) gaining registrar must send and receive confirmation email;

Game, set, match - bye, bye apparent authority - hello expressed authority
with no ambiguity

Mike


-----Original Message-----
From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
Behalf Of Ross Wm. Rader
Sent: Tuesday, December 03, 2002 5:11 PM
To: tim@godaddy.com; registrars@dnso.org
Subject: Re: [registrars] Transfers TF Report


> I would like to suggest though that EPP HAS become an issue. It has been
> implemented by three gTLD registries, and soon to be four. True, EPP is no
> magic bullet. But, as you point out, it does help to solve the issue of
> authorization and that is no small issue from our perspective. Properly
> implemented, an auth-code type solution, EPP or otherwise, could
streamline
> and simplify the transfer process.

Agreed - my implication re: EPP is that a) there is a lot that we don't know
about it, practically speaking and b) that it only solves half the problem
(ie - "authentication" and not "informed consent")



                       -rwr




"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright

Got Blog? http://www.byte.org/blog
----- Original Message -----
From: "Tim Ruiz" <tim@godaddy.com>
To: "Ross Wm. Rader" <ross@tucows.com>; <registrars@dnso.org>
Sent: Tuesday, December 03, 2002 4:39 PM
Subject: RE: [registrars] Transfers TF Report


> Ross,
>
> You present some persuasive arguments.
>
> I would like to suggest though that EPP HAS become an issue. It has been
> implemented by three gTLD registries, and soon to be four. True, EPP is no
> magic bullet. But, as you point out, it does help to solve the issue of
> authorization and that is no small issue from our perspective. Properly
> implemented, an auth-code type solution, EPP or otherwise, could
streamline
> and simplify the transfer process.
>
> That said, I do agree that what we have to decide now is whether what has
> been proposed in the report truly solves any problems today. We have been
> reviewing the report in detail and comparing it to the current situation.
> Our decision will based on that analysis.
>
> Tim
>
>
> -----Original Message-----
> From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
> Behalf Of Ross Wm. Rader
> Sent: Tuesday, December 03, 2002 2:28 PM
> To: registrars@dnso.org
> Subject: [registrars] Transfers TF Report
>
>
> Title: "Three or Four (or Six) Reasons Why We Should Support This
Report..."
> Summary: Please vote in favor of the motion that I just tabled.
>
>
> Reason #1 - "We have taken far too long in dealing with this issue." This
is
> simple. Its taken almost two years to get to this point. That is far too
> long. Further delay doesn't mean much more than "further delay". We should
> have had this cleared up more than a year ago, but we didn't. Let's not
> waste the opportunity that we have in front of us to clear the issue up
> *now*.
>
> Reason #2 - We will never have a perfect solution. As it currently stands,
> the perfect solution, in my books, is one that we can implement. These
> recommendations are implementable and therefore deserve our support.
Perfect
> solutions do not exist, but perfect solutions are more common than
practical
> ones that satisfy everyone's political sensibility. Let's not waste the
time
> and effort that has gone into this report. This solution is workable
without
> putting any registrar or registry out of business because of the attendant
> complexity.
>
> Reason #3 - Getting EPP working will create different problems. EPP isn't
a
> magic bullet. All EPP does is make it easier for registrars to figure out
> whether or not someone is authorized to request a transfer. EPP does not
> tell us if the person making that request is doing some from an informed
> perspective. In other words, EPP itself does not stop registrars from
> slamming through inappropriate marketing. In some respects, it almost
makes
> it easier. Let's deal with EPP when EPP becomes an issue. I fully believe
> that the recommendations of this report will allow us to avoid some of the
> "out-of-the-box" problems that EPP will pose, but if it doesn't, lets take
a
> look at the issue when we have some experience with EPP. Let's not defeat
> this report because of what we don't know about EPP, let's approve this
> report because of the problems that it will solve today.
>
> Reason #4 - This solution has buy-in outside the Constituency. Again very
> simple. Over the past two years, this is the only series of
recommendations
> that has buy-in from Registrars, Registries and Registrants. It is not
easy
> to get all of these parties to see eye-to-eye, lets not waste this
> opportunity to get what we all want. Voting to defeat this report would
> represent a sell-out of these groups to our own self-interest. Let's avoid
> the tremendous hit in credibility and vote to approve this report.
>
> Reason #5 - The recommendations can change after they are approved. The
> report advocates that ICANN take a look at how things are going every once
> in a while. If things aren't going well, the Constituency can always
change
> its mind and request that the NC take a second look at the policies. We
> don't have this opportunity now and we would stand to gain through some
> "learning by doing" policy development vs. the guess work that we are
doing
> now.
>
> Reason #6 - I take this directly from the report because it is important
and
> speaks for itself. " The recommendations contained in this report are the
> product of an open and transparent process that took place over the course
> of a year. Hundreds of hours of discussion were devoted to the topic, many
> proposals were considered, dozens of revisions were proposed and thousands
> of words debated the merits of specific recommendations and alternate
> approaches. In other words, a process took place by which the best
> recommendations were substantively discussed, clarified, compromised and
> eventually manifested themselves as the consensus recommendations
contained
> in this report.
>
> The Task Force believes that it is this approach, the process, which
> represents the single most compelling argument in favor of adopting these
> recommendations. The fact they do represent the best ideas of the
community,
> the ones upon which we most agree and perhaps most importantly, the ones
> with the most understood and refined impact. This is not to say that
> concepts and ideas that did not make it into this report were not good or
> well-considered, to the contrary, there were many that were. But, these
> bright ideas did not get the support of the community necessary to include
> them as a consensus recommendation of this report. Similarly there were
also
> many reasoned criticisms of these recommendations that were put forward.
> But, unless they were shared by a reasonable cross-section of the
community,
> it was equally impossible to put them forward as the consensus of the
> community. This is one of the features of the consensus policy development
> process - both the consensus support and consensus disagreement must be
> substantively dealt with. Again, the Task Force believes that it has
> fulfilled this required.
> However, we have no presumptions that new consensus ideas and dissent
won't
> emerge from the DNSO. Accordingly, we have attempted to temper these
> recommendations with very finite and predictable review mechanics that
will
> allow the DNSO to adjust or correct the policy over the short, medium and
> longer terms. We believe that a moderate approach of this nature ensures
> that the policy in effect will continue to reflect the will of the
community
> for the foreseeable future.
>
> The consensus policy development process is neither easy nor trivial. Nor
> should it be. Appropriate processes lead to appropriate results. Balanced
> processes lead to balanced results. The Task Force believes that the
> processes employed in the development of these recommendations are both
> balanced and appropriate, but to the extent that the results need to be
> adjusted, a similarly balanced and appropriate approach should be taken so
> as to ensure the continued integrity of the results."
>
> I remain available for questions or clarifications...
>
>                        -rwr
>
>
>
>
> "There's a fine line between fishing and standing on the shore like an
> idiot."
> - Steven Wright
>
> Got Blog? http://www.byte.org/blog
>
>