What does your service provider store at login so that a later logout message naming a SessionIndex can find the right session?

## Two namespaces that have to be joined at login When a contractor's worker signs in to the permit system, two sessions come into existence. One belongs to the firm's identity provider — it authenticated the person and it keeps its own record. The other is yours: a server-side session record and a cookie in that worker's browser. The identity provider knows nothing about your record. When it later wants that sign-in ended, it names what it knows: the subject and a `SessionIndex`, which is its own handle for its own session. Your job, and the whole of this leaf's share of logout, is to have written down the join that turns that handle into your session ids. If you did not write it at login, there is nothing to look up later, and the message is unactionable however correct it is. ## What the row holds Against each local session you issue through a federated sign-in, record: - the **issuing counterparty**, as its `entityID` — the index is only meaningful within one issuer; - the **subject identifier exactly as received**, including its format and any qualifiers, because you have to match on what arrives, not on a normalised copy; - the **`SessionIndex`** from the assertion, if one was present; - your own **local session id**, and the time you wrote the row. Index it on issuer plus subject plus index, so the lookup on an inbound message is one read rather than a scan of live sessions. That index is the only performance decision here and it matters because the lookup happens on someone else's schedule. ## One human, several rows The relationship is not one to one in either direction, and a design that assumes it is will leave sessions alive. 1. One worker may hold **several of your sessions** — two browsers, a desktop and a tablet — created from **one** identity-provider session, so one index maps to several local ids. 2. The same worker may sign in again after the firm's identity provider has started a **new** session, producing a second index, so one subject maps to several indexes. 3. An assertion may carry **no** index at all, in which case you have a subject-scoped row and nothing finer. So the resolution rule is: if the inbound message names an index, end the sessions carrying that index for that issuer. If it names only a subject, end that subject's sessions for that issuer. Never widen beyond the issuer, because the same-looking identifier at another counterparty is a different person. ## Ending it means deleting your record The teardown is a write to your own session state, and it has to be visible to every replica immediately — otherwise a request already in flight to another instance continues on a session you believe is gone. What ends the session is the server-side record ceasing to be valid. Clearing the browser cookie is a courtesy: the browser that holds it may be closed, may be on a machine that is off, and in a back-channel teardown is not part of the exchange at all. A design that relies on the cookie being cleared has not ended anything. Write an audit entry as you go — which issuer, which index, how many local sessions were ended, and the time. When a firm's security team asks whether a departing worker's access really stopped, that entry is the answer. ## Idempotency is the requirement, not a nicety These messages arrive more than once. Retries, duplicate delivery and an operator clicking twice are all normal. Three cases have to be non-events: | Case | Correct behaviour | |---|---| | The same index arrives a second time | nothing further to do; report the same outcome as the first | | An index you have no row for | nothing to do; treat as done, and do not disclose whether the subject exists | | The session already expired on its own | nothing to do; treat as done | The common bug is treating *nothing found* as an error. It produces failures during perfectly normal retries, and it teaches the sender that something is wrong when nothing is. The implementation that gets this right is a delete-by-predicate that reports how many rows it affected and does not care whether that number was zero. ## What this leaf does not decide Ending **every** session a person holds everywhere, on a leaver event, is a different operation reached from a different trigger. So is the policy about what should happen when somebody leaves the firm. This piece is narrow on purpose: persist the join at login, resolve it on arrival, end those records, be idempotent, and leave an audit trail.