Under Web Browser SSO with the HTTP POST binding, why is a signature over only the <samlp:Response> not enough?

## Two places a signature can sit A SAML 2.0 response can carry a `<ds:Signature>` at two levels, and they are not the same statement: - **On the `<samlp:Response>`.** The reference names the response's `ID`, so the digest covers the response element and everything nested inside it — including the assertions, while they remain there. The statement is "the issuer of this response assembled exactly this message". - **On each `<saml:Assertion>`.** The reference names the assertion's `ID` and covers that assertion alone. The statement is "the issuer asserts exactly these claims about this subject", and it remains true wherever the assertion afterwards travels. Both are legal. A response may be signed, unsigned, or signed alongside signed assertions. ## What the profile requires, and why the binding decides it The rule is binding-specific, and the reasoning is worth being able to state: | Binding | Assertions in the response | Why | |---|---|---| | HTTP POST | **MUST** be signed | The document is relayed by the user's browser, an untrusted party that can modify what it posts on | | HTTP-Artifact | **MAY** be signed | The service provider fetched the message itself over a direct back-channel call to the identity provider, which authenticates the source at the transport level | So "we sign the response, that is the same thing" is wrong on the profile's own terms when HTTP POST is in use. This also disposes of the broader claim that "SAML assertions are always signed" — the specification is more precise than that, and the precision is exactly what an interviewer probes. ## What a response-level signature does and does not buy It buys real things. While the assertion is inside the signed response, a digest over the response covers it; inserting a fabricated assertion into that digested subtree changes the octets and breaks verification. For a receiver that verifies the response and consumes only from within the element it verified, the integrity property is genuine. What it does not buy: - **Portability.** Detach the assertion — pass it to another component, cache it, forward it, or place it in a different message — and nothing signed accompanies it. An assertion signed in its own right carries its proof with it, which is one reason exclusive canonicalisation exists. - **Independent evidence of authorship.** The proof is about the envelope. Where the responder and the issuer of the claims are different parties, an envelope signature says nothing about who authored those claims. - **Profile conformance under HTTP POST.** A receiver following the profile is entitled to reject a posted response whose assertions are unsigned, and strict implementations do. ## Where deployments actually sit Three configurations show up in production: 1. **Assertion signed only.** Meets the POST-binding rule. The `<samlp:Response>` envelope, including its `<samlp:Status>` and `InResponseTo`, is unprotected, so a receiver must not draw conclusions from unsigned envelope fields. 2. **Response signed only.** Common, and non-conformant under HTTP POST. It is also the configuration that surprises teams when a partner tightens its receiver and logins start failing with no change on their own side. 3. **Both signed.** Two signatures, each with its own single `<ds:Reference>` and its own transforms. The cost is a second signature operation per login and a marginally larger document. A service provider can also publish the expectation: `WantAssertionsSigned` on its `<SPSSODescriptor>` is the declaration that it requires signed assertions, and a partner that ignores it produces exactly the interoperability failure above. ## The question behind the question What an interviewer is really testing is whether the candidate separates "this message arrived intact" from "this claim was made by that issuer". Those are different properties with different lifetimes: the first expires the moment the message is unpacked, the second travels with the assertion. Every deployment argument about what to sign is an argument about which of the two you need — and under HTTP POST the profile has already decided that you need the second.