In a SAML metadata document, what do `validUntil` and `cacheDuration` each tell the party consuming it?

## Two attributes, two different questions A SAML metadata document is consumed as a cached copy. Both freshness attributes exist because the party reading the document is not the party maintaining it, and the reader has to decide on its own when its copy is too old to act on. | attribute | kind of value | question it answers | what it does **not** say | |---|---|---|---| | `validUntil` | an absolute instant, UTC | after when must this content not be used at all? | nothing about how often to refetch | | `cacheDuration` | a relative duration, e.g. `P7D`, `PT12H` | how long may a copy be held before refetching? | nothing about whether the content is still valid | They are independent, and a document commonly carries both. The root element of a metadata instance is required to carry at least one of them — a document with neither leaves the consumer with no stated basis for ever giving up its copy. ## `validUntil` is a hard stop, not a hint `validUntil` appears on the element it bounds, and it bounds that element **and its descendants**. Because it sits inside the document, the maintainer controls it and the consumer cannot extend it. Once the instant passes, the correct behaviour is to stop using the content, not to fall back to the last copy that parsed. That is severe on purpose, and it has a consequence people meet only once: - The keys a counterparty believes live in this document. - Expiry is **simultaneous** for everyone holding that copy. - So a `validUntil` that quietly passes does not slow anything down or degrade one login — it stops every login with that counterparty at the same moment, with nothing in the message exchange looking wrong. A useful habit is to treat `validUntil` as an operational deadline you renew on a schedule, not a security control you tighten. Setting it a month out and forgetting is a self-inflicted outage with a date on it. ## `cacheDuration` is a ceiling on staleness `cacheDuration` is written as an XML Schema duration — `PT12H`, `P1D`, `P7D` — and tells a consumer the maximum period it may go on using a copy before fetching again. Two things follow: 1. It is an upper bound, not a schedule. A consumer may refetch more often; it should not go longer. 2. It says nothing about validity. A copy whose `cacheDuration` has elapsed is not *invalid*, it is *due for refresh* — the content is still bounded by `validUntil`. ## Why the pair decides how fast you can move The reason this leaf matters in an interview is that these two attributes, and nothing else in the document, set the clock on every change the pair will ever make. Consider a regulator's reporting portal and several hundred licensed operators. The portal publishes `cacheDuration="P7D"`. It now needs to change the public key its counterparties hold: - Publishing the change is instantaneous. - **Arrival** is not. A counterparty that fetched yesterday is entitled to go on using yesterday's copy for the rest of the week. - So the earliest moment at which every counterparty can be assumed to hold the new content is a week away, no matter how urgent the reason. The trade-off runs both ways: - **Long `cacheDuration`** (days): few fetches, tolerant of an outage at the publication location, and a change that needs days to land. - **Short `cacheDuration`** (an hour): changes land fast, but every counterparty refetches constantly and your publication location becomes a dependency of their logins. - **`validUntil` far out**: fewer renewals, and a longer window in which nobody notices the document is unattended. - **`validUntil` near**: forces the relationship to be maintained, at the cost of an outage the day maintenance slips. ## The common misreadings - Treating `cacheDuration` as an expiry, and so believing a copy "went invalid" after twelve hours when the document was good for a year. - Treating `validUntil` as advisory and continuing on the last good copy — the one behaviour the attribute exists to forbid. - Reading either attribute as a statement about the embedded certificate's own lifetime. They bound the **document's** usability; a certificate's own dates are a separate matter, and the two routinely disagree. - Assuming a shortened `cacheDuration` binds immediately. It binds the copies fetched *after* it was published, which is why freshness policy always takes effect one generation late.