RE: AuthN and Credentials

["Mishra, Prateek" <pmishra@netegrity.com>]

>>
>>>>>>> "MP" == Mishra, Prateek <pmishra@netegrity.com> writes:
>>
>>    Me> Our high-level goal here is not to burden SAML with the actual
>>
>>    MP> Agreed. This was the main point of
>>    MP> ISSUE:[UC-5-03:AuthNThrough]; no expression of authentication
>>    MP> within SAML
>>
EP>>Agreed, and it seems that the overwhelming majority of people in the
EP>>subcommittee agree (10-1!). Unfortunately, some people felt that the
EP>>wording of the non-goal was unclear or incorrect (at least that's my
EP>>guess as to why they voted against the particular non-goal). I think
EP>>that we need to find a better formulation that the dissenters could
EP>>agree to. Any dissenters have a suggestion?
>>

Good point. It would be great to close out this issue with an explicit
(non)-requirement. Would the dissenters please give us a hand here?


EP>>My guess is that the quibble is about "authentication." If one is
EP>>being strictly formal, I think that accepting (say) an S2ML name
EP>>assertion as proof of identity is also a form of "authentication." Is
EP>>there a clear way we can state the difference?
EP>>
EP>>    MP> However, we are concerned with characterizing the "result" or
EP>>    MP> OUTPUT of an authentication step. This is the so-called
EP>>    MP> credential notion.
EP>>
EP>>Agreed again. Gotta stop myself from nit picking here, but my
EP>>understanding is that credentials can be -any- data presented to
EP>>establish identity (thanks, Jeff! B-). Is there a way that we can
EP>>differentiate the "right" kind of credential that you and I both know
EP>>we mean from the "wrong" one?


There is some terminological issues here that are causing us some 
distress. If we restrict the term credentials to the "inputs" 
to an authentication engine that are provided
by a subject, we then need a term to describe the outputs of an
authentication engine.
Notice that this may be completely different from the credentials presented 
as input to the Auth engine.

For the present, let us call this "AuthNData" -- stuff that is generated
as the result of authentication. Jeff H. can correct me on this, but I
dont believe we have a term for this in the glossary. So my interest here
is to focus on certain standard forms of "AuthNData". Distinguishing
between good and bad forms of AuthNData is difficult; some AuthNData
needs to be kept secret others can be public (e.g., the users public key).


EP>>    MP> I think my concern is that the way [R-AuthN] and [R-AuthZ] are
EP>>    MP> written there is no suggestion that we need to capture any
EP>>    MP> standard credential forms. [...] This is also the background
EP>>    MP> to [CR-5-01-1: StandardCreds].
EP>>
EP>>I voted for this one. B-) For my edification, what is the
EP>>difference between standard credentials and "descriptions of
EP>>authentication events"? 

A modest one. When you participate in a SSL-session the end-result of
authentication may be a certificate and an assertion of its validity by an
authenticator. This is the "AuthNData" against which future authorization
which take place. I would describe the "authn" event in such a case
in the following way"

	AuthEngine #234 has received sufficient proof at 9AM that
     the subject possesses this X509 certificate [Cert]. The subject
     used SSL technology to present proof.

There may be no other "AuthNData" required here; the certificate alone
describes
the subject. Similar considerations apply to objects like:

	public keys
     X509 DNs 
     identity token (just an opaque string)

My point here is that there are several standard forms of AuthNData that
the notion of AuthN event needs to include. Many Az engines are driven
off these standard syntaxes.


EP>>of this token," I see the point of descriptions of authn events to be
EP>>something along the lines of:
EP>>
EP>>        "The holder of this token is Evan Prodromou. At 
EP>>10:00:00.000AM 
EP>>         on 28 Feb 2001, I used biometric toe-smell measurements to
EP>>         make sure. Signed, the outlook.net security service."
EP>>
EP>>...and I'm not sure I see what the "credential" is, if not the full
EP>>statement (kind of like a letter of introduction).
EP>>

A typical phrasing for "is Evan Prodromou" might be:
		
     "uid=eprodromou,ou=people,dc=outlook,cn=Evan,cn=Prodromou"

with directory handle:
 
     OUTLOOK_MAIN_USER_STORE

In other words, the authentication engine has bound you to this "name"
based on certain evidence you have provided. Downstream Az engines
will use this name and their relationship to the issuer to decide your
privileges.
			
EP>>Or (I'm getting an "aha" feeling) is the name "Evan Prodromou" the
EP>>standard credential (I'd call it an identity)? Which could be, say, a
EP>>DN or some other kind of identity?

Precisely. A DN or a Cert or a public key or an opaque string or ...
Again my point here is that there are some standard forms of AuthNData
representation in use out there, we should re-use them not re-invent them.

- prateek