Are you suggesting that there are "levels of broken" here, where an application that doesn't do audience validation will almost certainly screw up group membership assertion?
My experience is that many vendors will happily say "SAML 2.0 integration for SSO" when they mean only that they can pick a username out of an identity assertion. I personally haven't seen one which mismanages audience validation.
Above and beyond that, support is tremendously variable. Ability to do JIT provisioning/re-provisioning with user roles etc mapped to attribute assertions is something like nirvana and about as commonly realized.
"SSO once you have pre-provisioned the user out-of-band via our application-specific API" is more common (bonus marks for SCIM). Also "SSO assuming you can provide access to an LDAP server where we can look the user up".
OK, but my question was specific. You appeared to hint that anything that doesn't do audience validation is so horribly broken that it's unusable. That's not only very different from my experience (audience confusion, and particularly domain confusion bugs are super common), and I think there's a good reason for that. If your integration claims to be able to consume group assertions but it doesn't, that will be immediately visible to anyone trying the integration. If you screw up audience validation, no-one will notice until they perform a very specific test that the vast majority of vendorsec programs will never test for, and a good chunk of the ones that do will have signed a contract that prevents them from testing or at least publishing findings.
(Completely agreed that the vast majority of SSO integrations only let the IdP assert identities, not group memberships.)
More to the point - while signing certs are part of the SAML spec (and your IdP can choose to use a different one for each SP), looking at attributes in the Assertion and making decisions based off of them is one-off for every SP - a few do this, but they each do it differently than the last.
