In SAML metadata, what do `WantAuthnRequestsSigned`, `AuthnRequestsSigned` and `WantAssertionsSigned` declare — and what are they not?

## Three attributes, and which role each lives on | attribute | role descriptor | meaning | when omitted | |---|---|---|---| | `WantAuthnRequestsSigned` | `<IDPSSODescriptor>` | I want the requests I receive to be signed | optional; no requirement stated | | `AuthnRequestsSigned` | `<SPSSODescriptor>` | I sign the requests I send | assumed false | | `WantAssertionsSigned` | `<SPSSODescriptor>` | I want the assertions delivered to me signed | assumed false | All three are optional booleans. The two on the service-provider role are **assumed false when omitted**, which is worth stating explicitly: silence is a statement, and it says *no*. ## The grammar is the mnemonic The naming is consistent and candidates still reverse it under pressure: - A **`Want…`** prefix describes an expectation of the **other** party. It is a request made of whoever reads the document. - A bare attribute — `AuthnRequestsSigned` — describes the publisher's **own** behaviour. It is a promise, not a request. So a document that carries `WantAuthnRequestsSigned` is an identity-provider role asking to be sent signed requests; a document that carries `AuthnRequestsSigned` is a service-provider role announcing that it signs them. Between one pair both may be present, in the two different documents, and that is the healthy case: an expectation on one side matched by a promise on the other. ## What they are not: declarations, not controls This is the whole point of the question, and it separates people who have operated a relationship from people who have read the schema. 1. **A metadata attribute cannot make a counterparty do anything.** Publishing `WantAuthnRequestsSigned="true"` does not cause requests to arrive signed. It causes a human or a configuration process on the other side to arrange it — or not. 2. **Publishing an expectation is not enforcing it.** A party that publishes `WantAssertionsSigned="true"` and treats its own published document as the check has no check at all. The document is an announcement; the refusal has to happen where content is actually evaluated. 3. **Silence is meaningful.** Because the service-provider role's pair is assumed false when omitted, a counterparty reading your document learns that you do not sign your requests and do not require signed assertions. That may be exactly what you did not mean to say. ## The failure this produces, and how it looks In the worked setting, the regulator's portal publishes `WantAssertionsSigned="true"` and treats the matter as settled. Several hundred licensed operators read that document once, at integration time. Then: - Most configure signing, because their side reads the attribute during onboarding. - One does not — perhaps the relationship was configured before the attribute was added, perhaps the reading was manual and missed. - Content arrives from that operator without a signature, and if the portal only ever published the expectation rather than acting on it, that content is accepted. The symptom is the absence of a symptom. Nothing errors, nothing logs a mismatch, and the weakest relationship in the estate is indistinguishable from the strongest until somebody diffs the documents. The second failure is the mirror image and produces a loud break instead of a silent one: the identity-provider role publishes `WantAuthnRequestsSigned="true"`, a counterparty that omitted `AuthnRequestsSigned` sends unsigned requests, and every attempt is refused. Here the metadata contains the whole diagnosis — one side's expectation, the other side's silence — and reading both documents side by side is faster than reading any log. ## Reading a pair of documents as a policy statement A useful review habit is to lay the two documents next to each other and check that each expectation has a matching promise: - Does their `WantAuthnRequestsSigned` have your `AuthnRequestsSigned` opposite it? - Does your `WantAssertionsSigned` correspond to something the counterparty actually does? - Where an attribute is absent, has somebody decided that, or has it simply never been set? That review is cheap, it is the only place the pair's signing policy is written down in a machine-readable form, and it is the artefact an auditor can be handed. What it cannot be is the enforcement point — which bytes are covered by a signature, and how that is checked, is a separate subject from what the document says the parties expect.