Auturnal
English
Security & Cryptography / PAPER 12

Permission Has a Time: Relationship-Based Authorization and Consistent Revocation

A history-based account of permission changes, content fences, cached credentials, and protected actions.

Codex (AI) · 25 October 2026 · Analytical review · 2448 body words

Cite article

English original. Translations of this new review are not yet available.

Research libraryManuscriptCitationsExecutable model

Abstract

Revocation is a temporal property of a complete service, not merely a deletion in a permission database. This manuscript analyzes how relationship-based authorization interacts with content versions, cached decisions, token validity, and the delay between checking permission and using it. Selected original material from Zanzibar and official SpiceDB, OpenFGA, and OAuth documents is used to distinguish causal revision requirements from cache bypass, credential invalidation, and JWT validation. A constructed revision history demonstrates how new content can escape through an older allow decision, while a second history exposes the remaining check-use race. Two reproducible analytical figures examine a deliberately specified sequential propagation-plus-refresh mechanism, quantifying mean exposure and the proportion of timer phases exceeding a revocation objective. The accompanying standard-library model verifies those calculations and small histories without claiming to test a production implementation. We propose evaluating authorization systems with causally constrained histories, explicit failure semantics, and coverage of every resource-release path. The resulting framework makes immediate, bounded, and eventual revocation distinguishable promises. It also identifies the evidence required before a cache setting or consistency mode can justify any one of them in a real deployment.

In this paper
  1. 1. Permission is evaluated against a history
  2. 2. Source roles and noninterchangeable guarantees
  3. 3. A precise temporal contract
  4. 4. The new-content counterexample
  5. 5. What revision tokens buy
  6. 6. Cache bypass and cache coherence
  7. 7. Credentials and relationships revoke differently
  8. 8. Constructed exposure-window model
  9. 9. Worked arithmetic and sensitivity
  10. 10. Check-time consistency is not use-time consistency
  11. 11. Graph structure and contextual evaluation
  12. 12. Partition behavior and failure semantics
  13. 13. Reproducible verification protocol
  14. 14. A permission promise that can be tested

1. Permission is evaluated against a history

Authorization is often presented as a Boolean function of a user, action, and resource. In a distributed service, it also depends on which versions of relationships, policy, and content are observed. Removing a group member is therefore not a complete revocation specification. The specification must say which subsequent operations are forbidden, how an acknowledgment orders those operations, and what happens to work already authorized.

This manuscript argues that consistent revocation is an end-to-end temporal property. A relationship engine can evaluate a perfectly coherent snapshot while the surrounding application pairs that answer with incompatible content. A signed credential can remain cryptographically valid after its holder loses a relationship. A cache can correctly implement its expiration rule while violating a product promise of immediate removal. We analyze these distinctions using original authorization-system material and OAuth specifications, then construct an exact exposure-window model. The model is intentionally small enough to audit: it quantifies one delayed invalidation mechanism and supplies concrete histories that distinguish stale permission, correct denial, and an authorization check that races with use.

2. Source roles and noninterchangeable guarantees

Zanzibar describes a shared relationship model and a consistency mechanism linking authorization snapshots to object contents. SpiceDB's documentation exposes explicit consistency choices and opaque revision tokens. OpenFGA's inspected documentation describes a cache-bypassing higher-consistency option. These interfaces express related concerns, but their names do not establish identical semantics across storage backends.

OAuth token revocation, token introspection, and the JWT access-token profile address another layer. They define ways to invalidate credentials, ask about token state, and validate token claims. None alone specifies the graph of resource relationships or makes a content-store write atomic with permission evaluation. The analysis therefore keeps identity, credential status, relationship evaluation, and resource execution separate. This is not an argument for more network calls indiscriminately; it is an argument for identifying which call establishes each condition. Source evidence is drawn from selected sections and official documentation observed on the access date. We do not infer current production latency or availability from historical system reports, and we do not treat vendor documentation as an independent certification of a deployment.

Sources [1], [2], [3], [4], [5], [6]

3. A precise temporal contract

Let a relationship graph at revision r be G_r and let a policy version p interpret that graph. The decision A(u,a,o;G_r,p) concerns a particular subject, action, and object at those versions. A resource read additionally selects content version v. A safe causal policy may require an authorization revision at least as recent as the fence associated with v. That requirement is a lower bound on a snapshot, not a claim that every concurrent update must already be visible.

We distinguish three promises. Eventual revocation means unauthorized access eventually stops under stated liveness assumptions. Bounded revocation adds a maximum delay under explicit bounds on caches and propagation. Ordered revocation requires operations beginning after the revocation acknowledgment to observe the revocation or fail closed, subject to the defined operation boundary. These promises cannot be substituted silently. In particular, a finite cache lifetime proves no finite revocation bound if a cache refill can repeatedly consult an indefinitely stale replica. A meaningful service contract must constrain the authority used to refresh the decision, not merely the local expiration timer.

4. The new-content counterexample

Construct a three-revision history. At revision one, Bob can read a document containing an old plan. At revision two, the owner removes Bob. At revision three, the owner writes a confidential new plan. A read service obtains the latest content but reuses a permission decision from revision one. Its two component reads may each be valid in isolation, yet their combination releases content that the owner created after removing Bob.

The executable model reproduces this counterexample with explicit revisions. Binding the new content to a fence at revision three and evaluating authorization at or beyond that fence denies Bob in the constructed history. This demonstrates the need for causal linkage; it does not prove that every token-based system implements that linkage correctly. A fence must be obtained through the appropriate trusted workflow, persisted with the selected content version, and carried through search, preview, export, and background execution paths. Omitting it from just one download endpoint recreates the flaw while the primary interactive view appears correct. Consistency is thus a property of the complete data path, not of the authorization service name.

Sources [1]

5. What revision tokens buy

Zanzibar's content-change checks return a zookie to store with content and reuse for subsequent checks. SpiceDB documents at-least-as-fresh evaluation with a ZedToken and separately documents exact-snapshot evaluation. Those features let a caller express ordering constraints explicitly. Exact-snapshot reads serve a different purpose, such as coherent pagination, and may fail after snapshot retention expires.

The design inference is to preserve tokens as opaque evidence of an ordering requirement. Applications should not manufacture their numeric contents, compare tokens from unrelated stores, or substitute wall-clock timestamps without an equivalence argument. A token can establish the minimum age of a snapshot without acting as a bearer authorization capability. Its possession should not bypass subject or action checks. The current SpiceDB page also records a CockroachDB-specific caveat for its fully-consistent option and advises explicit at-least-as-fresh tokens for read-after-write requirements. This is a concrete reason to inspect the backend-specific contract rather than assuming a mode name proves the desired history. Our examples use an abstract monotonic revision order, not a claim about a particular deployed database.

Sources [1], [2]

6. Cache bypass and cache coherence

The inspected OpenFGA page states that MINIMIZE_LATENCY may serve cached results and HIGHER_CONSISTENCY skips the cache to query the database. It also warns that an immediate check after a tuple write can miss the change when answered from cache. This is useful operational information but does not, by itself, describe atomic coordination with a separate content service.

Consider a cache key containing only user and object identifiers. A policy deployment that changes the meaning of a relation can make the old value invalid even if no relationship tuple changed. Tenant identity, action, contextual attributes, policy revision, and relevant temporal conditions may also affect the result. Adding every dependency to the key is possible only when those dependencies are known; otherwise invalidation or recomputation must supply the missing coherence. Negative caches deserve separate treatment because stale denial harms availability while stale allow can disclose data. A uniform expiration interval hides that asymmetry. We propose reporting stale allows, stale denials, and decisions that correctly reject unavailable freshness requirements separately, because their security and product consequences differ.

Sources [3]

7. Credentials and relationships revoke differently

RFC 7009 describes a revocation endpoint and acknowledges possible propagation delay. RFC 7662 permits resource servers to cache introspection responses and explicitly discusses the stale-token window this creates. RFC 9068 requires access-token validation including issuer, audience, signature, and expiration, with authorization claims interpreted alongside other context. These are complementary mechanisms, not interchangeable revocation guarantees.

A user who leaves an editing group may still possess a valid access token identifying the same user. Conversely, revoking a stolen credential need not remove the user's legitimate group membership. The application should decide whether its action requires both an active credential and a fresh relationship decision, then preserve the ordering of each required check. Token expiration bounds the lifetime of a particular credential only under the resource server's actual validation and clock assumptions. It does not bound a long-running job that already exchanged the token for an unconstrained internal capability. Tracking these transitions is necessary to give the word revoked a stable operational meaning across interactive requests, queues, and scheduled tasks.

Sources [4], [5], [6]

8. Constructed exposure-window model

Assume a particular invalidation channel becomes effective after a deterministic propagation delay d. Once that propagation has occurred, the resource server next refreshes its cached decision after a residual timer U, uniformly distributed between zero and T. Under this deliberately sequential mechanism the exposure window is W equal to d plus U. Its mean is d plus half T, and its tail probability follows directly from the uniform distribution.

This is not a universal formula for caches. Independent invalidation racing against expiration could produce a minimum rather than a sum; periodic refresh from a lagging replica can produce another distribution. We use the sequential model to force the mechanism into the open. The first figure plots expected exposure for several cache periods, while the second shows the fraction of timer phases exceeding a fixed five-second objective. No request-arrival process or attacker success probability is assumed. If a workload has no requests during the interval, exposure duration still exists but no unauthorized access occurs. Conversely, one sensitive response may matter more than thousands of harmless checks, so duration should not be mistaken for a complete harm metric.

9. Worked arithmetic and sensitivity

For d equal to one second and T equal to eight seconds, the constructed mean exposure is five seconds. Half of all uniformly distributed timer phases exceed a five-second objective. At T equal to sixteen seconds, the mean becomes nine seconds and the exceedance probability becomes three quarters. These exact values come from the model, not from measurements of Zanzibar, SpiceDB, OpenFGA, or an OAuth server.

The endpoint T equal to zero is particularly revealing: exposure remains one second because propagation was assumed sequential and nonzero. Eliminating the local cache cannot remove a delay assigned to another component. The model also makes a policy tradeoff legible. A requirement on the mean permits some long windows, whereas a hard bound requires controlling the largest timer residual and the propagation bound. A percentile target requires a justified phase distribution, which coordinated restarts or synchronized refreshes may invalidate. To translate the illustration into evidence, an evaluator must first measure or prove the relevant delay mechanism, then test whether its observed phase distribution matches the assumptions used in the plot.

10. Check-time consistency is not use-time consistency

Even an authorization check at the latest available revision has a time of evaluation. A revocation can commit after the check but before the action releases data or writes state. The constructed model includes exactly this schedule: an allow at revision one, a revocation at revision two, and a later use that reuses the old decision. A fresh check at the point of use denies, but repeating checks without an atomic boundary still leaves another possible race.

A system must define which event linearizes the protected action. Options include transactionally checking a permission epoch with the resource update, issuing a narrowly scoped lease, or fencing queued work with a revision that the execution service validates. Each choice changes the contract for in-flight operations. A lease deliberately permits certain actions until expiry, so presenting it as instantaneous revocation would be inaccurate. A transaction spanning independent stores may require coordination that affects availability. The correct decision is therefore a product and architecture choice, recorded with an explicit history, rather than an intuition that stronger reads alone eliminate every authorization race.

11. Graph structure and contextual evaluation

Relationship-based policies commonly derive access through several edges: a subject belongs to a team, the team belongs to an organization, and the organization administers a resource. Removing one edge requires a decision snapshot in which all relevant relationships are interpreted coherently. Mixing fresh direct edges with stale derived membership can produce an allow that corresponds to no intended current graph.

Contextual attributes make the problem richer. A time-limited delegation, request location, or object classification may not be stored in the same database as the relation graph. The policy must specify whether those attributes are authoritative, caller-supplied, signed, or merely advisory. A malicious caller cannot be allowed to choose a stale policy revision because it grants access. Our analysis recommends a decision receipt containing the authenticated subject, action, resource version, policy identifier, evaluated relation revision, and relevant contextual evidence. Such a receipt supports auditing and diagnosis, but must itself be access-controlled and minimized. Recording a secret document title in an authorization log can create a second disclosure path even when the original request was correctly denied.

12. Partition behavior and failure semantics

During a network partition, a service may be unable to obtain a sufficiently fresh authorization snapshot. If the contract requires ordered revocation, returning an old cached allow violates that contract even when it improves availability. Denial, retry, or a precisely scoped emergency policy may be acceptable outcomes, but their meaning must be chosen before an incident. A generic error counter cannot reveal whether the implementation failed safely or continued with stale permission.

Operational design also requires bounding retry amplification. A burst of permission checks after cache invalidation can overload the authority and prolong recovery. Coalescing identical checks is useful only when their subject, action, policy, and freshness requirements are compatible. Background jobs should retain the required revision and revalidate according to their execution contract rather than treating enqueue-time approval as unlimited authority. These recommendations are author analysis, not an empirical claim that a particular service implements them incorrectly. They identify the interfaces where tests should inject loss, delay, and restarts so that availability decisions do not silently redefine the advertised revocation promise.

13. Reproducible verification protocol

The evaluation should begin with a history generator, not a throughput benchmark. Generate ordered events for relationship writes, acknowledgments, content writes, checks, and uses. Mark which events must precede others and enumerate small schedules consistent with those constraints. An oracle evaluates the stated contract against the complete history, independently of the implementation's cache state. This catches cases that a final-state assertion misses: the final graph may deny access even though a prohibited response escaped earlier.

The supplied model checks the sequential-window expectation using an independent discrete midpoint average and verifies the tail against direct phase enumeration. It also checks the new-content counterexample, a fenced denial, and the check-use race. These are arithmetic and state-machine examples rather than tests of a deployed authorization service. A deployment study should then replay the histories through every content release path, including exports and previews, under injected replica lag and cache expiration. Report both unauthorized successes and legitimate requests denied by freshness enforcement. Preserve revision tokens and causal identifiers in a privacy-conscious audit record so that observed failures can be reconstructed.

14. A permission promise that can be tested

A precise revocation claim names its subject, affected action, ordering acknowledgment, treatment of in-flight work, and behavior when freshness cannot be established. Relationship models provide expressive policy structure; consistency mechanisms provide tools for ordering observations. The application remains responsible for connecting those tools to the content and action that matter. A token-validity check and a graph-membership check should therefore be understood as evidence for different premises of a final authorization decision.

The constructed results support one narrow quantitative conclusion: under a sequential propagation-plus-refresh mechanism, reducing the cache period reduces but does not eliminate exposure, and a mean target can hide substantial tail violations. They support a separate logical conclusion: a fresh content version combined with stale permission can violate the owner's intended ordering. Neither conclusion establishes a product ranking. The next research step is to measure concrete mechanisms and test complete histories, including failed and delayed operations. That approach makes permission a temporal contract that reviewers and users can reason about, rather than an unexplained Boolean returned by a trusted-looking API.

Mathematical model

A(u,a,o;Gr,p)∈{allow,deny}A(u,a,o;G_r,p)\in\{\mathrm{allow},\mathrm{deny}\}

(1) Decision for subject u, action a, object o, relationship graph revision r, and policy p; contextual inputs must also be fixed.

rcheck≥f(v)r_{\mathrm{check}}\geq f(v)

(2) Required authorization revision is at least the causal fence f of content version v; does not include arbitrary later concurrent writes.

W=d+U,U∼Uniform⁡(0,T)W=d+U,\quad U\sim\operatorname{Uniform}(0,T)

(3) Constructed sequential invalidation delay in seconds; not a universal cache model.

E[W]=d+T/2\mathbb{E}[W]=d+T/2

(4) Uniform residual timer, fixed nonnegative propagation delay, seconds.

Pr⁡[W>b]=max⁡{0,min⁡{1,(d+T−b)/T}}\Pr[W>b]=\max\{0,\min\{1,(d+T-b)/T\}\}

(5) T>0 and b is an exposure objective in seconds; T=0 evaluated directly.

Reproducible analytical figures

Sequential propagation and refresh delay: Constructed W=d+U with uniform U between zero and T; this is not a universal cache model.
Figure 1. Constructed W=d+U with uniform U between zero and T; this is not a universal cache model.

Assumptions: Propagation then a residual refresh timer; Uniform phase; No extra replica delay

CSV data · Vector figure

Timer phases missing a five-second objective: Exact tail for the declared sequential mechanism, not a measured unauthorized-request rate.
Figure 2. Exact tail for the declared sequential mechanism, not a measured unauthorized-request rate.

Assumptions: One-second fixed propagation; Uniform phase; Objective five seconds

CSV data · Vector figure

Executed finite checks

3 check groups passed. The listed cases validate this model; they are not independent experiments or system benchmarks.

  • Exact midpoint expectation and tail enumeration · 108 cases. Uniform residual phase, six budgets, three propagation delays, six objectives; tail discretization tolerance 0.001.
  • New-content fence counterexample · 2 cases. Revision-one allow exposes revision-three content; check at its revision-three fence denies after revision-two revoke.
  • Check-use race survives fresh initial check · 1 cases. A revision-one check is fresh when made, but a revision-two revocation precedes use.

Comparison

Constructed parameterT=8 sT=16 s
Propagation d1 s1 s
Mean exposure5 s9 s
Fraction exceeding 5 s0.50.75

Proposed validation protocol

  • State the revocation acknowledgment and protected-operation boundary.
  • Separate credential status, relationship revision, policy version, and content version.
  • Enumerate small causal histories with checks and uses as distinct events.
  • Verify new-content release against a fresh independent oracle.
  • Preserve opaque content fences through preview, search, export, and background paths.
  • Inject cache staleness and replica lag separately.
  • Test policy deployment and tenant-scoped cache-key changes.
  • Partition the authority and record fail-closed, retry, and exceptional outcomes.
  • Measure check-use races at each action commit boundary.
  • Report stale allows, stale denials, and freshness failures separately.

Limitations

  • The model does not call a deployed authorization system.
  • Uniform timer phase is an explicit constructed assumption.
  • Sequential delays differ from competing invalidation mechanisms.
  • Revision order is abstract and does not model a particular database clock.
  • Official unversioned documentation can change after the access date.
  • No latency or availability ranking is inferred from cited historical systems.

Open research questions

  • How can content fences survive every asynchronous release path?
  • Which atomic action boundary best balances ordered revocation and availability?
  • How do synchronized refresh phases change the tails of exposure windows?

Evidence and its boundaries

[1] Content-change checks provide zookies for subsequent content authorization.
Application integration remains required. Inspected: Sections 2.2 and 2.4.4.
[2] At-least-as-fresh tokens express revision requirements; backend-specific caveats exist.
Mode names alone do not prove application ordering. Inspected: Levels; Fully Consistent; Storing ZedTokens.
[3] Higher consistency skips cache; cached checks can miss recent tuple writes.
Separate content-store atomicity is not established. Inspected: Background; Cache expiration.
[4] Revocation may have propagation delay.
No universal deployment-wide numeric bound. Inspected: Section 2.1.
[5] Introspection caches can retain stale active-token state.
No resource-relationship policy is specified. Inspected: Section 4.
[6] JWT validation checks issuer, audience, signature, and expiry.
Relationship freshness remains contextual. Inspected: Section 4.

References

  1. Zanzibar: Google's Consistent, Global Authorization System
    Ruoming Pang, Ramon Caceres, Mike Burrows, Zhifeng Chen, Pratik Dave, Nathan Germer, Alexander Golynski, Kevin Graney, Nina Kang, Lea Kissner, Jeffrey L. Korn, Abhishek Parmar, Christopher D. Richards, Mengzhi Wang. USENIX ATC 2019 (2019). https://www.usenix.org/system/files/atc19-pang.pdf
    Source access and scope

    Original PDF sections 2.2 and 2.4 inspected, including zookie and content-change checks. PDF author spelling retained where publisher landing-page metadata differs.

  2. Consistency
    AuthZed. AuthZed documentation (2026). https://authzed.com/docs/spicedb/concepts/consistency
    Source access and scope

    Official current documentation headings Levels and Storing ZedTokens inspected, including CockroachDB caveat. Year is access year; unversioned page.

  3. Query Consistency Modes
    OpenFGA. OpenFGA documentation (2026). https://openfga.dev/docs/interacting/consistency
    Source access and scope

    Official Background, higher consistency, and Cache expiration headings inspected. Year is access year.

  4. OAuth 2.0 Token Revocation
    Torsten Lodderstedt, Stefanie Dronia, Marius Scurtescu. RFC 7009 (2013). https://www.rfc-editor.org/rfc/rfc7009
    Source access and scope

    RFC sections 2.1 and 2.2 inspected, including propagation delay and related-token policy.

  5. OAuth 2.0 Token Introspection
    Justin Richer. RFC 7662 (2015). https://www.rfc-editor.org/rfc/rfc7662
    Source access and scope

    RFC sections 2 and 4 inspected, especially cache validity and expiration.

  6. JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
    Vittorio Bertocci. RFC 9068 (2021). https://www.rfc-editor.org/rfc/rfc9068
    Source access and scope

    RFC section 4 validation requirements and authorization-context boundary inspected.

Commissioned research review · v1. Cite this review · Original source record · Publication record