> You mean is that the security model you have in mind does not require that
> SAML assertions be signed?  We may have an additional software layering
> problem- specifically, if they are present, and you're using a SAML library to
> parse the messages, from a practical standpoint, an error may be returned.

That shouldn't be a concern, or if it is you've got much bigger problems 
because the assumptions about trust and key management that such broken code 
would make will be a problem in their own right.

> However, I think what you're alluding to is that the lack of a signature 
> itself is
> part of the problem of returning attributes from 3rd parties, since the
> associated connectivity of the AAA transport is providing authenticity and not
> the signature.

I think it's more that if you stick with the simple case, you don't need them, 
and if you do need them,  a host of more complex concerns become important.

>       Another source of complexity surrounds how an IDP links an assertion to
>       a subject. What confidence is the RP asserting that the additional
>       assertion describes the same principal as the access-accept message.
> 
> On this point - the IdP either is or is not authoritative for knowing at the 
> very
> least where the information is going to come from.  The only question here is
> whether or not it is willing to vouch for the information itself.

Some people (I should be clear I'm not one of them) believe that without a 
uniform subject identifier across all such assertions, you lose any hope of 
auditing the linkability of the identies later. And achieving that uniformity 
does some tortuous things to the SAML flows needed to get the assertions built.

I agree with Eliot that the issues associated with knowing what attributes to 
get, what sources to use, etc., are general problems, not confined to this use 
of SAML, or to SAML itself.

But usually when aggregation is involved, there is less need for a fully 
dynamic system without administrative intervention, in my experience.

-- Scott

_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab

Reply via email to