Re: <info> Command and authInfo

[Rick H Wesson <wessorh@ar.com>]

Patrick,


On Thu, 17 Jan 2002, Patrick wrote:

> On Tue, Jan 15, 2002 at 10:28:50AM -0500, Hollenbeck, Scott took time to write:
> > I'm not so sure of the benefit in putting <authInfo> into the <update>,
> > <delete> and <renew> commands given the discussion we had on the list some
> > time ago (we DID have it that way, and then folks wanted it removed from all
> > but <transfer>), but I understand what you're saying about the dates and the
> > <info> command.
>
> I agree with Bruce on this : the authinfo should have a bigger scope.
>
> Right now it is only for transfers (and thus should have been called
> transfer auth or something like that, not auth info), and as we
> already see it with some Registries using EPP, transfers are hard.

so transfers are hard with auth-info, thats what i expected, it may take
some time for registrars and registrants to learn to deal with thisck
registries and epp based ones.

> The auth info does not help anything regarding transfers.
> It just complicates things (current Registrar not giving it, and if
> the new Registrar already asks contacts for approval, the authinfo is
> of nouse... since it will be given to contacts, thus same problems in
> both case of hijacking and such).


> IMNSHO auth info should enable someone having it to make
> modifications (that is update at least, maybe delete and renew)
> through any other ways (other Registrars, or even the Registry
> directly). Protocols should make that possible, and then
> local policies should specify if it is to be used or not, and if yes,
> how.


the consept is that auth-info aids in identifying an entity with
authorization to transfer. The EPP mind-set is that the sponsoring
registrar can updat their own objects; thus its the sponsoring registrar
to authenticate not the registry except in the case of a transfer where by
the gaining registrar authenticates with the registry by the use of the
auth-info token.

This approch seems reasonable because it MUST be up to the sponsoring
registrar to authenticate in this three-tear model. It mkaes the most
sense from a client-server perspective too.

-rick