Hi, Currently in pysaml2 for an SP one can configure want_response_signed to require that the authn response be signed and want_assertions_signed to require that the assertion(s) in the response be signed. There is no way, however, to configure the SP to consume a response and require that either the response is signed or the assertion(s) is (are) signed. I just submitted a pull request that adds the configuration directive want_assertions_or_response_signed The documentation is updated to read: Indicates that *either* the Authentication Response *or* the assertions contained within the response to this SP must be signed. Valid values are True or False. Default value is False. This configuration directive **does not** override ``want_response_signed`` or ``want_assertions_signed``. For example, if ``want_response_signed`` is True and the Authentication Response is not signed an exception will be thrown regardless of the value for this configuration directive. Thus to configure the SP to accept either a signed response or signed assertions set ``want_response_signed`` and ``want_assertions_signed`` both to False and this directive to True. Example:: "service": { "sp": { "want_response_signed": False, "want_assertions_signed": False, "want_assertions_or_response_signed": True } } Most of the logic is a refactoring of the _parse_response() method on the Entity class in entity.py. I think this is the "cleanest" way of adding this functionality without a major refactoring. The issue is that the signature checking and the parsing of the XML payload are tightly tied together and in a way that makes it difficult to get a representation of the payload or response and then apply requirements to it. For example, the only way to parse the response and determine if there is a signature is to require a signature and call the parsing method and see if it throws an exception or not. But if the signature wasn't really required then the parsing method has to be called again without the flag requiring a signature, otherwise the response is never fully parsed. I do think all of that logic needs to be refactored (sooner rather than later) but doing so is going to require some significant discussions on design (perhaps a topic for Vienna?). In the meantime this enhancement, while not particularly "elegant", allows an SP to be configured so that it can deal with IdPs in a federation where some IdPs only sign responses and some only sign assertions (I have an immediate use case for that now for a SATOSA proxy sitting in a well known federation). I tested all 8 combinations of configuration [1] for want_response_signed want_assertions_signed want_assertions_or_response_signed with all 4 combinations of an IdP sending signed/unsigned responses/assertions for a total of 32 tests and verified that SATOSA acted as expected (either consuming the response or throwing the appropriate error). I also verified that if you set all three of the configuration options to 'False' then you get a significant warning in the log output. Please let me know if you have any questions or concerns. Thanks, Scott K [1] Not all of the 8 configurations "make sense" given that the new option does not override the existing options. I verified that even in the "non-sensical" configuration the right things happen.