Assurance

["Cantor, Scott" <>]

On 3/12/14, 8:08 PM, "Tom Scavo" 
<>
 wrote:
>
>I still think it's authentication. Some people call it step-up
>authentication. The SP already knows the user, but now wants
>additional, independent assurances that this is so. In distributed
>fashion, this requires the SP to pass the identity of the user in the
>AuthnRequest while requiring the IdP to authenticate the identified
>user with an additional factor. (Who said there's no use for
>AllowCreate="false" :)

There isn't, but regardless that's not what it's for. ;-)

It's solely about identifier creation, not authentication.

>Visualize numerous single-factor IdPs sprinkled across the
>network...multiple, single-factor IdPs supplying step-up
>authentication services if and when they're needed (where is not an
>issue). Easier to deploy but much harder to subvert.

It's not that simple. By separating the IdP from the application (i.e.
federation), you've just created a web SSO problem, which is inherently a
session problem in HTTP terms. What you have to do to solve the problem
the way Schneier described is to avoid offloading that and embed the
challenge directly in the application so that you're not switching domains
during the interactions. Or you do holder of key, I suppose, assuming you
had a key to start with. But without a key, you have a cookie, and once
you're there, you're back where you started.

This is all very specific to web apps, it doesn't necessarily apply in
other cases.

-- Scott