Capability or Authorization Revalidation¶
Use-time authorization re-check — instantiates Use-Time Referent Validation
Re-evaluates at the moment of use whether the authority presented still permits this actor to perform this action on this referent, rather than trusting a grant decided earlier.
A referent can still exist, be unchanged, and be the intended thing — and the actor may still have lost the right to touch it. Capability or Authorization Revalidation guards that dimension: at the moment of use it re-evaluates whether the authority presented — a token, role, capability, or grant — still permits this actor to perform this action on this referent, rather than trusting an authorization decided when the session or request began. Its defining focus is the authority facet of use-time validity, not existence or version: permissions can be revoked, downgraded, scoped away, or expired in the interval since they were granted, and this mechanism refuses to let a stale grant outlive the permission behind it. It re-derives the decision from live authority, records it, and can escalate the riskiest actions to a live human.
Example¶
A storage service issues a user a signed link to download report.pdf. Minutes later the user leaves the project and their access is revoked. When the download request arrives, the service does not stop at "is the link well-formed and unexpired?" — it re-checks, at request time, whether the bearer still holds read permission on that object under current policy. The answer is now no, so the download is denied, even though the link is valid and the file still exists. Authorization is evaluated at the moment of use, so a grant issued five minutes ago cannot outlive the permission it stood for.
How it works¶
- Re-consult live authority per use. For every use, re-evaluate the (subject, action, referent) triple against the current policy engine, ACL, or token-introspection endpoint — not a decision cached at session start.
- Re-derive, don't remember. Compute the allow/deny from live state so a revocation, role change, or scope reduction takes effect on the very next use.
- Record the decision. Log who was allowed or denied to do what, to which referent, and when — a linkage the action can be audited against later.
- Escalate the riskiest actions. For high-consequence uses, require a live human confirmation or step-up re-authentication before the authority is honored.
Tuning parameters¶
- Revalidation freshness — introspect on every call versus honor a short-lived cached token. Fresher catches a revocation sooner; caching cuts the per-use lookup but reopens the stale-grant gap.
- Decision granularity — a coarse role check versus fine per-object or per-field policy. Finer is safer but heavier on every use.
- Step-up threshold — which actions demand an extra human confirmation. Raising it adds friction but protects the highest-stakes uses.
- Audit depth — how much of each decision is recorded. More supports forensics and accountability at storage cost.
- Fail stance — deny-by-default versus allow-on-error when the authority source is unreachable. The safe default is deny.
When it helps, and when it misleads¶
Its strength is that authority is checked at every use, so a revocation or role change bites immediately rather than at the next login — the discipline of complete mediation, every access to every object checked against current authority.[n1] It is essential wherever the right to act can change faster than sessions turn over: shared documents, financial actions, admin operations, anything a departing employee or a downgraded role should instantly lose.
Its central failure mode is caching for performance: memoize the decision and you reintroduce the very stale-permission gap the mechanism exists to close. It guards authorization, not existence or integrity — a still-authorized actor can act on a referent that was concurrently deleted or changed, which is why it composes with, rather than replaces, the existence and version guards. The classic misuse is revalidating once at session start and trusting it for the session's life — precisely the pattern it is meant to replace. The discipline is to re-derive from live authority at each use and deny on doubt.
How it implements the components¶
audit_linkage_record— each authorization decision is recorded, linking actor, action, referent, outcome, and time, so a later audit can trace who was permitted to touch what.current_validity_predicate— the predicate here is is this authority still valid, now, for this action?, re-evaluated at use (the authority facet, distinct from Just-in-Time Existence Check's existence facet).human_confirmation_step— sensitive uses can require a live human step-up before authority is honored (here a proactive re-authentication gate, distinct from Safe Missing-Referent Fallback's escalation-on-failure use of the same step).
It re-checks the right to act, not the thing itself: whether the referent still exists is Just-in-Time Existence Check's question, whether it was deliberately revoked or tombstoned is Revocation or Tombstone Check's, and whether its version is unchanged is Compare-and-Swap or Version Guard's identity_and_sameness_test.
Related¶
- Instantiates: Use-Time Referent Validation — Capability or Authorization Revalidation supplies the use-time "may this actor still do this?" verdict.
- Sibling mechanisms: Revocation or Tombstone Check · Just-in-Time Existence Check · Compare-and-Swap or Version Guard · Atomic Check-and-Use Operation · Lease, Lock, or Reservation Token · Preflight Resource Probe · Safe Missing-Referent Fallback · Stale Reference Monitor · Transactional Precondition Guard
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Re-evaluates at the moment of use whether the authority presented still permits this actor to perform this action on this referent, rather than trusting a grant decided earlier, making its operative form a live operational control that automatically routes, enforces, adapts, or responds during execution.
Independent corroboration: The frozen evidence defines Capability or Authorization Revalidation as 'Re-evaluates at the moment of use whether the authority presented still permits this actor to perform this action on this referent, rather than trusting a grant decided earlier', so its operative form is Control, Automation & Runtime.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Security Studies & Intelligence Analysis
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Computer security established the reference-monitor requirement that access-control policy be enforced on every attempted subject-object operation, making stale or revoked authority fail at use time.
Related originating lineages:
- Computer Science & Software Engineering — Operating systems and distributed services implement complete mediation and current-state authorization checks at the point of use.
- Law & Governance — Governance defines revocation, expiry, delegation, and separation-of-duties rules that the authorization check enforces.
Review resolution: Both reviewers selected security. NIST's definition makes complete mediation—always invoking the validation mechanism—the decisive provenance evidence, and the Policy Machine documents policy-centered enforcement; computer science and governance remain implementation and policy contributors rather than independent origins.
Attribution caveat: Authorization policy is legally and organizationally governed, but revalidation at every invocation is specifically a security reference-monitor lineage.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
This mechanism and Revocation or Tombstone Check are easy to conflate but guard different things: revocation checks whether the referent has been killed, while this checks whether the actor's authority over a live referent still holds. They compose — a valid, un-revoked object can still be one the requester may no longer touch — and a complete use-time guard usually runs both.
[n1] Complete mediation — one of Saltzer and Schroeder's classic security design principles — requires that every access to every object be checked for current authority, with no reliance on a remembered earlier decision. Use-time authorization revalidation is the direct implementation of that principle. ↩