...
- XML encryption MUST NOT be used
- Arguments in favor
- Simplifies operational practices because SPs do not need keys (no key rollover either)
- Signed Authn requests can DoS an IDP by consuming compute resources
- Signing requests rarely adds value
- Insecure algorithm (AES-CBC) doesn't provide confidentiality anyways
- TLS is sufficient confidentiality
- Simplifies the Deployment Profile by removing language around encryption
- Most attributes in a typical SAML assertion are not "private", though they are PII
- Simplifies operational practices because SPs do not need keys (no key rollover either)
- Arguments against
- SPs that currently require encryption may need manual reconfiguration
- Few SPs tend to require encryption, most will munch on the cleartext if they get it
- Few SPs tend to require encryption, most will munch on the cleartext if they get it
- SPs that currently require encryption may need manual reconfiguration
- Arguments in favor
- XML encryption MUST be used and MUST use AES-GCM
- Arguments in favor
- Improved enforcement of audience restriction / bearer semantics because only intended SP can decrypt assertion
- Increased confidentiality of attributes
- Organization's security policy may require encryption of even partially sensitive data
- NIST 800-63-3 requires encryption for Federation Assurance Level 2 or higher
- Profile compliance may be a lever to increase use of better algorithms
- Arguments against
- Some vendors/implementations can't meet this requirement, particularly if AES-CBC is disallowed
- A wholesale migration to AES-GCM across the federation will be very costly
- On the other hand, the profile doesn't require that everybody in the federation support it
- On the other hand, the profile doesn't require that everybody in the federation support it
- Arguments in favor
- SPs MUST support either XML encryption or plaintext (the current situation) except that AES-CBC is NOT allowed
- Arguments in favor
- Gives SPs that can't handle AES-GCM an escape clause
- Allows higher expectations for key handling and operational maturity for SPs if the rest can skip it
- Arguments against
- Forks profile with more complicated interoperability
- Likely requires federation signaling of whether encryption should be used (can't count on IdPs supporting Shibboleth's "optional encryption" feature)
- Leaves IdPs at the whim of the SPs in individual cases for their data protection profile
- Forks profile with more complicated interoperability
- Arguments in favor