The IdP now defaults to the use of a modern data encryption algorithm family called AES-GCM to encrypt XML. Earlier versions dating back to V2.0 relied on an older variant called AES-CBC. This page outlines the reason for this change, the process of algorithm selection in the software, and (for those so inclined) how to accomplish a controlled migraton to AES-GCM for Shibboleth SPs and the very small number of other implementations that support it.
Background
SAML supports message-level encryption of XML at a few different layers, the most common being to encrypt the entire Assertion issued to an SP so that it travels through the browser confidentially. In a few cases this might be valuable to hide information from the actual subject, but more often it's done to protect against malware in the client.
Unfortunately, the original XML Encryption standard only defined, practically speaking, a single family of data encryption algorithms (AES-CBC), and this is the only algorithm implemented with any consistency even today. CBC-mode has a long history of attacks, and XML Encryption proved vulnerable to them in a paper published in 2011. The attacks make it practical in some cases for the data to be decrypted by an attacker. The only true mitigation for this attack is if the Assertion is left unsigned prior to encryption and the Response is signed. This is why this is also the default behavior of our software and the best practice in SAML, though it should have been the absolutely-required approach.
It took some time for the XML Encryption standard to be updated with a newer option called AES-GCM, which is an example of what's known as "authenticated encryption", in which it becomes impossible to manipulate the ciphertext without detection prior to any attempt to decrypt the data. This is effectively a "built in" response signature which doesn't require active enforcement by a SAML SP. It took even more years for AES-GCM to appear in important libraries in a usable form, and it remains virtually unsupported at any scale today outside of the Shibboleth Project.
Despite that lack of support, we concluded that we could not in good conscience continue to ship an insecure default, so have made the decision to alter the default for new deployments to use the only secure option available.