Assurance

["Cantor, Scott" <>]

On 4/19/12 11:18 AM, "Martin B. Smith" 
<>
 wrote:

>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?

Yes, but that's got nothing to do with SAML either, it's the basis of
800-63's notion of assurance, as reused by FICAM, as adopted by InCommon.
If you (meaning an SP) care, you're not accepting their approach to the
problem space.

(That's fine, BTW, I'm just laying out first principles.)

SAML doesn't take a position on this question either. The IdP doesn't,
except insofar as it naturally can only build in defaults that are
technology-centric, not knowing anything about policy.

>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.

Well, you can only do that to the extent that the SP's request permits it.
If the SP asks for "HardwareToken", you ain't got a choice. You can't
assert "Silver".

As far as requests that lack a particular requirement, then yes, I can see
why that would be sensible to people. Consider one possible counter: if in
some future world you get paid to assert Silver, some SPs might not want
to pay unless they ask for it. Fantasy, I know.

> 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?

You can't tell that from AuthnContext anyway. Nobody uses the
PreviousSession class, it makes no sense in practice. It has the opposite
problem, you then lose the ability to tell anything about the original
authentication, which is what people care about if they do allow SSO.

The way you enforce ForceAuthn at a (Shibboleth) SP is by requiring a
limited time between AuthnInstant and the present time. If that's more
than a minute or whatever, you kick it. There's an SP setting for exactly
that rule.

Some SPs use signed requests, and they track requests and correlate
responses. In that model, you might bypass the check, but you still
wouldn't base it on AuthnContext. (And, note that doesn't work with
IdP-initiated SSO, which is why I didn't implement that approach to date.)

>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.

See above. You're starting from a different premise. The purpose of
AuthnContext is to communicate "what the SP cares about". If your SPs
don't care about assurance as defined by 800-63, Silver isn't an
appropriate solution.

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

I don't think it breaks any. The problem is 800-63 isn't how a lot of
people think about the problem.

-- Scott