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

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

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
>
>