prompter type question

[Nicolas Williams]

On Tue, Mar 23, 2010 at 12:14:03PM -0700, Jeffrey Hutzelman wrote:
> Actually, I missed mentioning another reason for having distinct
> prompt types for each piece of information, and for things like
> "insert token". The client may not necessarily be a PAM module.  In
> fact, it might be some kind of indirection or automation, in which
> case it would need separate prompt types in order to have a prayer
> of understanding what you're asking it to do.

If the krb5 gic prompts were only to go to the UI directly, then there'd
be no need for prompt type information.

The moment you have any "kind of indirection or automation", as you put
it, you need prompt type information.  The alternative would be to parse
the prompt strings, and that's a non-starter.

PAM definitely adds indirection, since the reply to a prompt may have
been cached from an earlier prompt or some source other than the user in
response to the current prompt.  In PAM's case the indirection comes
from mapping one pluggable authentication system with its own prompting
scheme to another pluggable authentication system's prompting scheme.
It could have been a mapping to SSHv2's userauth that had this effect
(except that there's not likely to be a hardware token on the server-
side for authenticating a remote user; a softtoken, however, could be
available).

I think the rule should be: all new krb5 gic prompts require a
corresponding new prompt type absent strong rationale for re-using an
existing one.  Corollary: there should be no generic prompt type.

Nico
--