In a SAML assertion, what does the `<Conditions>` `NotOnOrAfter` bound that `<SubjectConfirmationData>` `NotOnOrAfter` does not?

## Two windows, not one The most common misreading of a SAML assertion is that it has *an* expiry. It has at least two, on different elements, bounding different things, and a relying party has to satisfy both. At the co-operative's grain intake, the difference is easy to see. The haulier's identity provider signs a statement about the driver at 08:14. The browser must carry that document from the identity provider to the intake system's consuming endpoint — a matter of seconds. But the intake clerk may still be looking at the resulting screen ten minutes later. The first of those spans is what `<SubjectConfirmationData>` bounds; the second is nearer what `<Conditions>` bounds. ## What each one says - **`<Conditions>` `NotBefore` / `NotOnOrAfter`** — the window inside which this is a statement at all. Before `NotBefore` the identity provider has not yet vouched for anything; at or after `NotOnOrAfter` it no longer does. This is a property of the **statement**. - **`<SubjectConfirmationData>` `NotOnOrAfter`** — the last instant at which *this holder* may present *this copy* to confirm that they are the subject. This is a property of the **delivery**, and it belongs to the confirmation method, not to the statement's truth. Both are absolute instants in UTC, and both use the same exclusive convention: `NotOnOrAfter="2026-09-19T08:19:02Z"` means the last usable moment is strictly before 08:19:02, not up to and including it. `NotBefore` is inclusive — the named instant already counts. | Attribute | On which element | What it bounds | Typical span | |---|---|---|---| | `NotBefore` | `<Conditions>` | when the statement starts being one | issue time, or slightly before | | `NotOnOrAfter` | `<Conditions>` | when the statement stops being one | minutes, a deployment choice | | `NotOnOrAfter` | `<SubjectConfirmationData>` | how long this holder may deliver this copy | a few minutes at most | | `Recipient` | `<SubjectConfirmationData>` | the endpoint this copy was meant for | one absolute URL | ## The profile rules that go with them The core assertion grammar defines the elements; the Web Browser SSO profile adds the rules that matter in practice for a bearer subject confirmation: 1. The `<SubjectConfirmationData>` **must** carry a `Recipient` naming the endpoint the assertion was delivered to. 2. It **must** carry a `NotOnOrAfter`. 3. It **must not** carry a `NotBefore`. There is nothing to bound at the lower end: the holder cannot deliver a document that does not yet exist, and a lower bound on delivery only creates a window in which a correct message is rejected. 4. It **must** carry `InResponseTo` when the assertion answers an authentication request. What that value is matched against is a question about the flow, not about the assertion's structure; the attribute itself simply names the request this confirmation answers. ## Why a short delivery window is not enough on its own A reader sometimes concludes that if the delivery window is two minutes, the `<Conditions>` window hardly matters. It matters for a different reason: the `<Conditions>` window is the one that says how long the *content* stands. A statement that a driver authenticated is not made permanent by being delivered promptly, and a relying party that keeps the document and reads it again later is outside the window even though delivery was instant. The reverse mistake is worse. If a relying party checks only the `<Conditions>` window — commonly the longer of the two — then a copy of the document that leaked out of the browser hop remains presentable for the whole of that longer window. ## Clocks, and what the document cannot say Both windows are written as absolute UTC instants by the issuer and evaluated against the reader's own clock. Nothing in the assertion expresses a tolerance: there is no skew attribute, no relative lifetime, no "seconds from receipt". If the two parties' clocks disagree by more than the delivery window, a perfectly good assertion arrives already outside it — which is why the classic symptom of a skewed clock in this protocol is an intermittent login failure at one site and nowhere else, worst around the moment of issue. ## What to take away - Two windows, checked independently; failing either means the assertion cannot be used. - `NotOnOrAfter` excludes its own instant. - The narrow one bounds the **carrier**; the wide one bounds the **statement**. - Neither window says anything about how long the intake system's own session may last — that is the intake system's decision.