ext Paul Madsen wrote:
>Hi John, if your proposed 'pre-authenticated password' class is meant to
>describe the 'poor man's Kerberos' scenario that Tim and Scott have been
>discussing, to my mind Liberty already has a class that describes it, namely
>PasswordProtectedTransport.
>
>
>
Sure....
>'The PasswordProtectedTransport class is identified when a Principal
>authenticates to an identity provider through the presentation of a password
>over a protected session.'
>
>Admittedly, this class doesn't capture how the IDP validates the password,
>ie. through a simple lookup or some proxied Kerberos authentication. Would
>this distinction matter to a Relying Party? If so, perhaps this could be a
>refinement of the passwordtype just as length is?
>
>
>
I see what you're saying - that maybe the relying party maybe doesn't
care whether Krb was used to validate the authentication - although I
believe Polar did mention a use-case for marking the Principal as being
untrusted if they choose to use their password in this way, so maybe the
information *is* useful :)
We could use PasswordProtectedTransport in this case, but also allow the
IdP to claim that they used Kerberos to validate that authentication -
by allowing a PrincipalAuthenticationMechanism statement to be added to
a conforming instance document of the PasswordProtectedTransport class
(currently the class *doesn't* allow this). What do you think of that?
>With respect to ii) below, makes sense to me.
>
>
OK.
- JohnK
