prompter type question

[Greg Hudson]

To avoid misinterpretation, let me make sure the context is clear:

* Nico proposed three new prompt types directly related to Will's work:
>  - insert-token
>  - enter-PIN
>  - enter-PIN-on-the-smartcard's-PIN-pad

* I asked what pam_krb5 would do with the information provided by using
one of these three new prompt types.

* Jeff suggested, "it would be bad to record the answer to a PIN prompt
as if it were a password."   As Nico mentioned, this is already handled
by the existing preauth prompt type.  Jeff also later said, "[the
client] might be some kind of indirection or automation," which Nico
pointed out is too general of an answer.

* Nico said:
> Will [...] needs to distinguish "insert token" (in response to which
> the module should NOT send a PIN) from "enter PIN", and, ideally, we
> should have at least a different prompt for "enter PIN" vs. "enter PIN
> on your token's PIN pad" (again, the module should not respond to such
> a prompt with a cached PIN).

* Will said:
> Yes, what Nico and Jeffrey write is correct.  In addition there is a
> situation where our pam_krb5 module must restrict what is prompted 
> for (it must not prompt for a password, this is left to the
> pam_authtok_get module).

Let me explain why I'm being so picky about specific use cases.  Numeric
prompt types are a limited and poorly defined form of structured
information.  If we ask for "a PIN," we can't say what device we want
the PIN for, which means pam_krb5 can't really return a cached PIN
without possibly giving us one for a different device (which we know can
be harmful due to token lockout).  I do not want to create a soup of
prompt types under different conceptions of what a prompt type means,
only to find out later that they are inadequate for any productive
purpose.

Currently, I can understand wanting to distinguish between "do something
and tell me when you're done" and "give me some information."  That's
why I'm happy to add a "continue" prompt type, which I think would serve
for either "insert token" or "enter PIN on external device."  A caller
can use this to decide whether to expect string input from the user or
just a button press.

I have not yet been told what pam_krb5 might productively do with the
more specific knowledge that some PIN is needed (vs. just an unspecified
piece of preauth-related input), or what external user action is
requested (vs. just "ask the user to do this piece of text and tell me
when the user says it's done").