Assurance

["Martin B. Smith" <>]

Hello all,

I have a specific question as it relates to our implementing the release 
of an AuthnContext class for silver. It's more of a SAML2 question than 
a Shibboleth specific one.

UF falls into the following case (from InCommon.org's assurance wiki):

"A deployment in which all users authenticate in a common way regardless 
of assurance level, such as a case in which all passwords are managed so 
as to meet InCommon Silver requirements. Users may or may not all be 
proofed at a level that meets a single assurance standard, but the 
authentication step is the same."

My big question is:

By including a silver IAQ (http://id.incommon.org/assurance/silver) as 
an AuthnContext class, it seems our SPs lose the ability to determine 
how the user authenticated (since for us, Silver doesn't imply two 
factor). Right?

Silver (for us) doesn't have anything to do with how the user 
authenticated (it could be a previous session, a username and password, 
etc). Some folks here think that we should simply assert an AuthnContext 
class of the silver IAQ if someone's identity is silver. Doesn't this 
make it also sometimes impossible to tell at an SP if a request included 
ForceAuthn was honored? Or impossible for the SP to tell if SSO was used?

It seems like always asserting an assurance/IAQ value as our 
authncontext class means we lose almost all of the value of authncontext 
classes, especially when the IAQs don't imply anything about how the 
principal authenticated to the attribute authority.

Does that also break any other functionality in SAML that you all can 
think of?

Thanks in advance,
--
Martin B. Smith

 - (352) 273-1374
CNS/Open Systems Group
University of Florida

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature