RE: [security-services] AssertionConsumerServiceIndex vs. AssertionConsumerURL

["Scott Cantor" <cantor.2@osu.edu>]

> Upon some thought I think we should rethink this model of protecting
> the assertion by using the <Recipient> subject confirmation to list the
> delivery URL for the assertion.
> 
> While this does help protect the security environment by telling the
> SP to not accept a token if presented on a different URL, it does NOT
> protect the potential leaking of information by the presentation of
> an assertion for the subject to an incorrect party.
>
> The information contained within an assertion does have privacy related
> information and we need to ensure that the IdP does not deliver the
> assertion to a party which shouldn't get it.

Umm, right... that was sort of what I was getting at before. That exposure
is dealt with using the mechanisms we already know about, either using
metadata to associate the URL with the SP, signing the request, or often
both.

In some "profiles" of the SAML 1.1 POST profile, there was a need to do this
sort of checking to prevent privacy exposures even though it wasn't
explicitly in the spec. Shibboleth does this, for example.

I guess I'm confused. Why does preventing impersonation using the Recipient
URL check in a fashion similar to SAML 1.1 somehow disallow the additional
measures we now have in place?

You could argue that it's unnecessary, I guess, but there are other examples
of that I could probably find if I looked, and that isn't the argument you
seem to be making, but maybe I misread that?

-- Scott