OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [security-services] AssertionConsumerServiceIndex vs. AssertionConsumerURL

> 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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]