One of the challenges of dealing with interoperability issues with SPs is maintaining all the custom configuration rules needed to drive the IdP's behavior in all kinds of different ways. Traditionally most of these kinds of settings are concentrated in the relying-party.xml file and involve defining "overrides" for SPs or groups of SPs, often through manually maintained lists of entityIDs.
As discussed in the RelyingPartyConfiguration topic in the section on dynamically-driven configuration, V3.3 introduced an advanced capability to produce these settings on the fly at runtime, which creates opportunities for more flexible configuration, at some cost in complexity. One of the techniques currently described in that section involves the use of metadata "tags" (a shorthand name for the
<mdattr:EntityAttributes> extension feature) to embed signals in metadata that can drive configuration.
V3.4 introduces a built-in layer of code and Spring beans to enable the use of the metadata-driven approach to configuration in a systematic way that provides a set of conventions for tag names and values to use to drive a significant range of configuration settings. With a small amount of up-front adjustment to the relying-party.xml file, it's possible to enable comprehensive support for metadata-driven configuration that can be freely intermixed in most cases with more static settings as required.
All of these new features are optional and are essentially a "working example" of how to use the already-available features provided with V3.3 to do something useful. It is expected at the time of writing that an unofficial plugin may be available prior to the release of V3.4 to enable the same example features in the V3.3 release.
Examples (In Progress)
Signed Assertions vs. Responses
Enabling signed assertions is advisedly handled by turning on
WantAssertionsSigned in metadata, but isn't always possible and sometimes has to be combined with disabling signed responses (or just for efficiency).
Setting idp.encryption.optional is usually a workaround for handling the majority of SPs without encryption support, but there are a couple of scenarios in which it's useful to be able to manually disable it. Some federations (InCommon for one) have limitations such that SPs without encryption support are stuck registering keys they don't support. Some SPs support encryption but build in time-bombs by forcing flag day key rotations on all IdPs that cause outages or manual work.
There are metadata extensions that are meant to be used to signal algorithm support, but they're not widely used at this point. The most common scenario is to force SHA-1 for older systems.
A common use case is enabling SAML 1 for legacy systems, often combined with either enabling queries or attribute push (to eliminate the queries).
NameID Format Exceptions
<NameIDFormat> elements in metadata (which can also be added at runtime with a filter) is the normal way to trigger them, but the "unspecified" Format has to be triggered with a profile setting. That's not common, but it's easy to define a tag for just in case. The problem is that any two SPs using it are only coincidentally going to want the same data, so this isn't solely a matter of format selection.
Some of the other profile settings are workarounds for bugs, e.g., omitting the NotBefore attribute. Likely not very common but easily tag-driven. We could also supply basic scripts for driving things like additional Audience values so the script would run based on a tag but the values would still be local to the script.
Handling SPs that require MFA but can't request it requires IdP-side configuration.
Attribute Release Consent
Triggering consent based on the SP is pretty common.
The authorization checking flow is another case, though the checking condition would probably to be extended for each different service/scenario.
Not relying-party-driven, but a canonical case for using metadata tagging is to drive attribute release, occasionally via bundles a la R&S and also piecemeal. FIltering is ultimately going to perform proportional to the number of policies times their individual overhead, so if tag-based rules are sufficiently fast, a policy per attribute would ultimately match or exceed the approach of defining policies per service.