Re: HIDDEN-USER

[Anders Andersson <[e-mail]>]

Peter writes:
>Yes, there is. I do feel that complete anonymity may be necessary.

It may be, but is there a need to have a dedicated keyword for that
in the protocol?

>The problem with removing "HIDDEN-USER" from the draft is that then if
>some sysadmin gets a request to implement a way for someone to become
>completely anonymous, he will have two choices, stop running an IDENT
>server or hack the Ident server to return NO-USER or UNKNOWN-ERROR or
>some other error. That will make it completely impossible to distinguish
>between users requesting anonymosity and other errors.

I don't think returning an error is the only way to implement anonymity.
It's not even a good way, as existing errors essentially boil down to
invalid queries, network problems, or server malfunction, i.e. technical
obstacles to providing a meaningful reply.  Using HIDDEN-USER, UNKNOWN-
ERROR or any other error code to indicate anonymity means introducing
various policy considerations into the 'case of error' area.

Isn't it better to handle anonymity as an OTHER case with some (possibly
encrypted) token?  If the server grants anonymity to the user, it can
simply avoid encoding any user information into the token, or the server
operator can refuse to disclose the information even if he has access to
it (say, if the need for anonymity turns up only after the fact, and the
user manages to convince his operator not to disclose it).

This way, actual code to support anonymity will only be needed in the
server, but not in the protocol nor the clients.  With HIDDEN-USER in
the protocol, the servers won't need to support it, but all clients will
need to, and it will essentially boil down to being handled just like
an encrypted OTHER token anyway.  Then there may be other policy-related
situations requiring their 'error codes' too (say, CLASSIFIED-DATA)...
Should the protocol and all clients be made to support them as well as
they are invented?

As a client operator, it's not really my business *why* the server
choses to withhold the user's full name and SSN (encrypted usernames
being the general rule at that site, specific user request, government
intervention or whatever).  The fewer special cases to handle, the
better for me.

>I think it is much better to have HIDDEN-USER in the draft, but not enabled
>by default in the servers.

I think the possible use of encrypted tokens to provide anonymity should
be pointed out in the draft, in order to forestall undesirable solutions
such as using either existing or invented (X-) error codes for this
particular purpose.  We can't dictate exactly what servers should look
like, but I agree that code to support user-requested anonymity should
be only optionally enabled in them (i.e. so the server operator will
know that the anonymity feature exists before his users start using it
to his disadvantage--witness the Internet Worm and the sendmail debug
feature).
--
Anders Andersson, Dept. of Computer Systems, Uppsala University
Paper Mail: Box 520, S-751 20 UPPSALA, Sweden
Phone: [phone]   EMail: [e-mail]