Shibboleth Developers

["Scott Cantor" <>]

> The nested SSO assertion is not used as an authentication token, but
> rather for access control.

Even if you ignore subject confirmation on this basis, if you follow SAML
processing rules you will not be able to accept it because you're not the
Audience. There are rules in SAML for issuing (and not issuing) forwardable
assertions, that's all I'm pointing out.

> The RP can verify the signature and check
> the conditions (to keep the SP honest),

At which point you're dead. You can ignore the rules any time, but as an
IdP, my response to finding out you were doing it might be to potentially
cut you off for forwarding information improperly.

> If the SSO assertion is constructed carefully, there is no privacy leak.

And you know that I disagree with that, but I'm speaking mostly to the
technical side of this.
 
> Putting (at most) non-identity attributes in the
> nested SSO assertion is equivalent to what the IdP does today in
> IdP-first scenarios or for unauthenticated SPs.

That depends both on the default ARP and on whether you even allow that to
happen (the IdP can block that now, and some sites do). But regardless, it's
not the same because the IdP is giving it to the relying party in that case.
What I'm saying is that you as the RP cannot just turn around and give it to
somebody else without violating the spec and the expectations of the
asserting party.

It's not all just about creating a usable authentication protocol, it's also
basic constraints on the flow of information.

-- Scott