...
A typical SP today tends to ignore identity assurance or authentication quality issues because contracts and other compensating controls are used to deal with risks "out of band". An occasional exception is the checking of "authentication method" values from a SAML assertion to require stronger authentication such as hardware tokens or certificates. These are most commonly all or nothing exercises, usually internal to an organization, and thus subject to a lot of explicit configuration by the IdP to support.
A partial goal of an assurance program the Assurance Program is to move more of these considerations "in band" to support more complex requirements and in particular to support applications that need to negotiate for higher assurance in real time or that may have differing requirements based on what the user is trying to do.
At least in SAML, the theoretical basis for using the <saml:AuthnContext> construct to represent assurance is that the protocol already includes feautures features for requesting and negotiating the right result. In practice, this gets becomes complex as the use case becomes more complicated; some of the reasons can be found in the parallel discussion about regarding Identity ProvidersProvider Behavior.
Runtime Implications
...
Some SAML SP implementations do not support the use of <samlp:AuthnRequest> messages at all, or do not allow for the use of the <samlp:RequestedAuthnContext> element to specify the SP's requirements. In such a case, IdPs would have to allow for out of band configuration of their behavior based on the identity of the SP. It may also be possible to supplement the SP with application code that can generate a request on behalf of the broken implementation.
In turn, the SP implementation may or may not have the ability to actually consume the IdP's asserted <saml:AuthnContext> information, or affect application behavior based on it. In that scenario, obviously the SP is essentially back to relying entirely on out of band assumptions; this is essentially what most deployments do nowtoday.
So for our purposes let's assume these constraints don't hold, at least to some degree. Ideally , then, SPs that require a particular assurance level (or one of a set) will initiate the assurance flow by including the desired identity assurance qualifier (IAQ) in the <samlp:AuthnRequest> message. SPs should understand that asking for a particular IAQ implies that the result may be a SAML error rather than a successful authentication response, because the IdP may be unable to comply. (Errors are always possible of course, but they are more likely in the presence of <samlp:RequestedAuthnContext>.) To avoid such an error, the SP and the IdP will need to agree on a catch-all value that means "or anything you can handle". InCommon recommends using "urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified" for this purpose.
SPs will receive IAQs (either in response to a specific request, or sent unsolicited) in assertions from IdPs. Exactly one IAQ is available, but some IdPs may provide values that predate the assurance program (often a signal that the user authenticated with a password) or may provide an IAQ that the SP does not recognize.
...