What does a SAML `<LogoutResponse>` whose second-level `<StatusCode>` is `PartialLogout` tell the initiator?

## Two levels of status, and only one of them is about the outcome Every SAML response message carries a `<samlp:Status>` element containing a `<samlp:StatusCode>` with a `Value` attribute holding a URI. The top level answers a narrow question: could the responder process this message at all? It takes one of a small set of values — `urn:oasis:names:tc:SAML:2.0:status:Success`, `urn:oasis:names:tc:SAML:2.0:status:Requester` when the fault lay with the sender, `urn:oasis:names:tc:SAML:2.0:status:Responder` when the responder itself failed, `urn:oasis:names:tc:SAML:2.0:status:VersionMismatch`. The interesting detail is that a `<samlp:StatusCode>` may *nest* another one. The inner code is the second level, and it qualifies the outcome. `urn:oasis:names:tc:SAML:2.0:status:PartialLogout` only ever appears there, under a top-level `Success`. ## What the code actually asserts A session authority that receives a `<LogoutRequest>` walks its list of session participants. When it cannot get every one of them to confirm, it must say so, and the second-level code is how. Read precisely, it asserts: - the authority processed the request and ended its own session; - it attempted propagation to the participants it knows about; - **at least one participant did not confirm** that it ended the session. Note what it does *not* assert. It does not say those participants are still logged in. A participant may have ended the session perfectly and then failed to get its `<LogoutResponse>` back — a browser that never returned from a front-channel hop is the classic case. Unconfirmed and still-live are different states, and the code reports the first. ## How the initiator should read each status | status on the `<LogoutResponse>` | meaning | what the initiator does | |---|---|---| | top-level `Success`, no nested code | every participant confirmed | end the local session and report a completed logout | | top-level `Success` with nested `PartialLogout` | propagation was incomplete | end the local session, qualify the message to the user, record the gap | | top-level `Requester` | the request itself was at fault | fix the message; the federated session is untouched | | top-level `Responder` | the responder could not process it | treat the exchange as failed; nothing was propagated | The two rows that get confused are the second and the fourth. A `Responder` status means nothing happened. A nested `PartialLogout` means most of it happened. Retrying makes some sense in the first case and little in the second, where a retry re-runs a propagation that already largely succeeded. ## What to put in front of the user This is where a partial logout does real damage, because the honest answer is uncomfortable. A user who is shown *You have been signed out of all applications* after a partial logout has been told something false by a system that knew it was false. Reasonable handling: 1. End the local application session unconditionally — that part is yours and it always works. 2. If the response carried a nested `PartialLogout`, say that sign-out could not be confirmed for every connected application, and that closing the browser is the reliable step. 3. Record which participants were unaccounted for, with the principal identifier and the session index, so an operator can answer the question later. 4. Do not loop. The profile places no retry obligation on anyone, and a client-side retry loop mostly generates traffic. ## Why it exists at all A protocol that could only say *success* or *failure* would force the authority into a lie either way: reporting failure after ending four sessions out of five, or reporting success after ending four out of five. The second-level code exists because the designers accepted that this exchange is best-effort and decided the honest outcome deserved a name on the wire. That is also why the code is worth asking about in an interview: a candidate who knows it exists usually also knows *why* logout half-works, and a candidate who has only read the happy path does not. In the e-discovery setting, this is the difference between an engagement-closure report that says *access ended* and one that says *access ended at the review tool and the document store; the transcript viewer did not confirm*. The second is the one counsel can act on.