At least one

Kim Cameron writes (actually wrote, it's quite an old post)

I think the SAML protocol suffers from having a single-token design.

A snippet from SAML 2.0's protocol schema seems appropo

<element name="Response" type="samlp:ResponseType"/>
<complexType name="ResponseType">
    <complexContent>
        <extension base="samlp:StatusResponseType">
            <choice minOccurs="0" maxOccurs="unbounded">
                <element ref="saml:Assertion"/>
                <element ref="saml:EncryptedAssertion"/>
            </choice>
        </extension>
    </complexContent>
</complexType>

In the same vein, from the SAML 2.0 profiles.

the <Response> element MUST conform to the following:

    - It MUST contain at least one <Assertion>.

Kim's post discusses delegation, specifically (for him) better support for delegation in WS-Trust/WS-Fed than in SAML because of the ability to carry multiple tokens.

The above makes it clear that there is no such distinction in the browser SSO case - a SAML IDP can return as many assertions as necessary, each of which with a different subject identity.

What's more, in a SOAP service invocation scenario, WSS/STP don't constrain how many SAML Assertions would be included in the security header either.

So, go to town. You want an assertion for your Aunt Ida? Sure, toss it in.