When a step-up challenge succeeds, what does an application's own session record store to mark that elevation, and how does it fall away?
answer
- the server writes it down
- not a flag the client sends
- scoped to an operation, not a session
- granted-at instant, plus covered operation
- spent on use, or aged out
basics
~20 sA server-side elevation record hung off the session: which operation it covers, the instant the challenge passed, which challenge attempt satisfied it, and its state. It is never client-asserted, and it falls away by being spent on that operation or by ageing out.
solid answer
~50 sThe server writes an **elevation record** attached to the session record it already keeps. It holds the session it belongs to, the operation or class of operations it covers, the instant the challenge passed, a reference to the challenge attempt that was satisfied, and a state of granted or spent. A bare boolean is the usual mistake: it can say a session once stepped up, but not which write is covered or whether the authority is still live. The elevation falls away two ways — it is marked spent in the same transaction that commits the covered operation, or it ages out at its own short lifetime if it is never used. Crucially it is a server-side fact: a client may ask for an elevation and may use one, but a header or hidden field claiming re-authentication happened is a request, not evidence.
code
json · 10 lines{
"elevation_id": "3f1c9a7e-2b44-4d10-9c31-7ad0f2e55b81",
"session_id": "s_9c2e41b0",
"covers_operation": "callsign.transfer",
"covers_subject": "callsign:GX4TQM",
"granted_at": "2026-09-19T11:04:18Z",
"expires_at": "2026-09-19T11:09:18Z",
"satisfied_attempt": "att_71d40c",
"state": "granted"
}go deeper
Recall that the server, not the browser, writes down that a fresh challenge passed, and that the note says which operation it covers and when it was granted. A client cannot simply claim it re-authenticated.
Explain the record's whole lifecycle: what it is bound to, why a boolean is not enough, why the window is measured from the challenge instant, and why it is marked spent in the same transaction that commits the covered write.
Show the failure you are buying off. Say what happens when consumption is not transactional with the write, what an elevation keyed by account rather than session lets a parallel session do, and how you would reconstruct an authorised transfer from the records months later.
Frame the trade: scoping elevations tightly to single operations costs prompts and support calls, while widening the scope converts one challenge into standing authority. Say which of the two failures your service can actually survive, and set the granularity from that.
## The one sentence this record exists for A step-up elevation is a fact the **server** wrote down about itself: at a known instant, this session presented a fresh challenge and passed it. On an amateur-radio licensing portal, transferring a callsign from one holder to another is the operation that must not ride a session which authenticated an hour ago, so the portal demands a fresh challenge at the moment of transfer. Whatever that challenge is, it ends with one question for the server author: *what do I write down, so that the next few seconds of this session can be treated differently from the rest of it?* The answer is a small record hanging off the session record the server already keeps. Every property of it follows from a single rule: a client may **ask** for an elevation and may **use** one, but it may never **assert** one. A header, a query parameter or a hidden field saying that re-authentication happened is a request, not evidence, and a gate that believes it has no gate at all. ## The fields the record actually needs - **The session it belongs to.** An elevation detached from its session is meaningless; keyed only by account, it lets a second, unelevated session of the same holder ride an elevation it never earned. - **The covered operation, or class of operations.** Callsign transfer, or holder-identity changes — not merely *elevated*. Without this the portal cannot answer the only question the gate ever asks: is *this* write covered? - **The instant the challenge passed.** The window is measured from here. Not from sign-in, not from the last request the session made. - **A reference to the challenge attempt that was satisfied.** One field saying which pending attempt this elevation came out of, so the transfer is reconstructible afterwards and so the same attempt cannot mint two elevations. - **A state**, granted or spent, changed under the same transaction as the write it authorises. | Marker shape | What it can answer | What it cannot | |---|---|---| | A boolean on the session | has this session ever stepped up? | which operation, when, or whether the authority is still live | | A timestamp and nothing else | how long ago did a challenge pass? | which operation it was granted for, or whether it was already used | | Scoped, timestamped, spendable | is this particular write covered right now? | nothing the gate needs | ## Measured against the operation, not against the session The interesting half of *how long does it count* here is not the number of minutes. It is what the clock is attached to. Attach the window to the session and one challenge quietly licenses every privileged write until it lapses: a holder who stepped up to transfer one callsign has, without ever being asked, also authorised the next transfer and the one after that. Attach it to the operation and a second transfer submitted eight minutes later is a **separate question** — the first elevation was granted for the first transfer, spent on it, and says nothing whatever about the second. That is why the record carries a scope and a state and not merely a time. The window still exists, but its job is narrow: it bounds the gap between the challenge passing and the covered write committing. It is an outer bound on one operation, not a licence period. ## How an elevation falls away There are two ways, and a design needs both: 1. **It is spent.** The gate reads it, the operation commits, and the same transaction marks it consumed. If consumption is not in the same transaction as the write, a retried or duplicated submission finds the elevation still granted and runs the operation again under authority that was already used. 2. **It ages out.** A granted elevation that is never used expires at its own short lifetime — short enough that a holder who walks away from the keyboard does not leave live authority lying in the store waiting for whoever sits down next. ## What this record is not It is **not a permission**. The elevation says a fresh challenge passed; whether this holder may transfer this callsign at all is an ordinary authorisation decision about ownership and role, and both checks must pass independently. Collapsing them produces the ugliest failure in this area: an operation that anyone able to pass a challenge may perform, because passing the challenge was read as being allowed. It is also not something the gate may infer. Reading *the session exists and the holder is signed in* as elevation is the same defect wearing a friendlier face — the server loses the ability to tell a write authorised seconds ago from one authorised at breakfast, which was the entire point of writing the record down. ## What a missing field costs, in order of damage - **No scope:** one challenge, unbounded privileged writes. - **No state:** the same elevation replayed by a duplicated submission. - **No granted-at instant:** nothing ages out, and the store accumulates live authority. - **No attempt reference:** the transfer cannot be reconstructed afterwards, and one attempt can mint two elevations.
- A second callsign transfer is submitted eight minutes after the first one committed. Does the earlier elevation cover it?No. The elevation named the first transfer and was marked spent in the transaction that committed it, so the gate finds nothing granted for the second and demands a fresh challenge. If it did cover it, the window would be attached to the session rather than to the operation, and one challenge would silently authorise every later transfer until the clock ran out.
- Why must the elevation live in the server's own record rather than in a value the browser carries back with the privileged request?Because its holder controls anything the browser carries. A marker that travels client-side can be kept, re-presented after it should have been spent, or swapped for another the same holder legitimately obtained. Signing it makes tampering detectable but does not stop replay or substitution. Only a server-side record can be atomically consumed, and consumption is what limits an elevation to the one operation it was granted for.
- What should the record hold so that, months later, someone can reconstruct which ceremony authorised a particular callsign transfer?A reference from the elevation to the challenge attempt that satisfied it, and from the committed transfer back to the elevation. That chain answers which attempt passed, when, in which session, and for which callsign. Without it an audit can show that a transfer happened and that some challenge passed nearby, but cannot tie the two together — and cannot rule out an elevation minted for a different operation.
saying these in an interview costs you the question
- Trusting a client-supplied header or hidden field claiming the challenge was passed.
- Storing a bare boolean, with no record of which operation it covers.
- Treating one elevation as licence for every privileged write that follows.
- Leaving the elevation granted after the covered operation has committed.
- Measuring the elevation window from sign-in rather than from the challenge.
- Reading a granted elevation as permission, and skipping the ordinary authorisation check.