/ 01The step-up ladder
| Action | Step-up required? |
|---|---|
| Login | MFA at IdP — no platform step-up |
| Browse, view L1–L4 | — |
| View L5 / L6 within session (standing access) | — |
| First view of Restricted / Privileged in session | Yes |
| Approve any access request | Yes |
| Reclassify in any direction | Yes |
| Bulk export | Yes |
| Bulk reclassification | Yes + supervisor |
| Create / modify ethical wall | Yes + second approver |
| Generate regulator export bundle | Yes |
| Toggle auto-grant kill switch | Yes (tenant admin) |
| L0 interaction (rare role) | Yes, every time |
/ 02The ACR claim
Step-up state is carried in a JWT claim — the standard OIDC acr (Authentication Context Class Reference) value. After a successful step-up the JWT is reissued with the elevated acr, valid for a configurable window (default 15 minutes).
Rego policies inspect input.requester.step_up_acr when deciding whether to permit a sensitive action. Without it, the action is denied with reason step_up_required.
/ 03Hash-bound step-up
A step-up token alone is not enough. For document-level actions (L6 fetch, reclassify, export), the step-up flow requires a resource hash in the challenge payload. The IdP issues an ACR bound to that specific document.
Effect: an attacker who steals a step-up token cannot replay it against a different document. The token authorises one action against one resource, and only for the window it is valid.
{
"action": "document.fetch.l6",
"resource_hash": "sha256:71d4...",
"valid_until": "2026-04-25T13:30:00Z",
"requester": "usr_...",
"acr": "urn:parelion:acr:step-up:webauthn"
}
/ 04Audit events
Every step-up emits at least one event. The event class is access; the type varies:
| Event | When |
|---|---|
StepUpRequired | Action attempted without sufficient ACR |
StepUpChallengeIssued | Server-issued challenge sent to client |
StepUpGranted | Client returned a valid response; ACR upgraded |
StepUpDenied | Client failed or cancelled |
L6FetchAuthorised | Step-up successful; document fetch proceeds |
The L6-fetch event is written before bytes leave the home DMS. If the home DMS denies the fetch (its own permission check), a corresponding L6FetchDeniedAtSource event is appended.
/ 05Break-glass
Break-glass is a documented bypass for emergencies — life-safety, regulator demand, court order. The bypass is:
- Available only to the named tenant admin pair (two-person rule)
- Time-bounded — defaults to 60 minutes, hard cap at 4 hours
- Logged as a single high-visibility event (
BreakGlassActivated) with required free-text reason - Notifies group compliance, the DPO, and the customer's external auditor on activation
Break-glass bypasses step-up but does not bypass ethical walls. Walls are absolute.