How can access keys rotate automatically without a key database?

Both the index-tier and asset-tier keys are computed on demand as an HMAC of a secret salt and the current rotation-period identifier. Because the derivation is a pure function of the salt and the period, the server never needs to store which keys have been issued - it simply recomputes the current period's keys whenever it needs to check a presented key, and last period's keys stop matching automatically once the period changes.

What is the difference between the index-tier and asset-tier keys?

The index-tier key grants access to the document manifest - a listing of titles and metadata. The asset-tier key, derived independently from the same salt using a different domain string, grants access to individual document content. An attacker holding only the index-tier key can enumerate titles but cannot read any document, which is a deliberate defense-in-depth property.

What happens to the system after a full server restart?

Nothing needs to be recovered. Because no key state is persisted, the system resumes operation immediately after a restart, deriving the current period's keys again from the still-provisioned salt. The next scheduled rotation occurs on time regardless of any restarts that happened in between.

Stateless Deterministic Document Key Rotation

Executive Summary

NDA-gated document distribution - due-diligence data rooms, investor documentation, technical specifications shared under confidentiality - needs temporary, revocable access that rotates on a schedule without requiring a persistent token database to manage. JIL Sovereign's document access control system solves this with a genuinely stateless design: every access key is a deterministic function of one secret salt and the current calendar period, recomputed on demand rather than looked up.

A document server holds a single secret salt value, never disclosed to any requester. For each rotation period (an ISO calendar week in the preferred embodiment), the server derives two access keys via HMAC: an index-tier key gating the document manifest, and a separate asset-tier key gating individual document content. The current period's key pair is published to a static, out-of-band-configured recipient list via authenticated email at the start of each period. The server persists no record of which keys have been issued, and no key ever needs to be explicitly revoked - it simply stops matching the moment the rotation period changes.

Core Innovation: Two distinct access tiers, each independently HMAC-derived from one secret salt and a rotation-period identifier, with zero persistent key state - rotation, revocation, and zero-downtime restart all fall out of the derivation being a pure function rather than a database lookup.

Problem Statement

Every mainstream access-control primitive assumes state somewhere. JSON Web Tokens carry an expiration claim, but revoking a token before expiry requires server-side state - a blocklist or a token database. OAuth2 refresh tokens require exactly the same thing: a token store and a revocation endpoint. Time-based one-time passwords (TOTP, RFC 6238) rotate automatically without server-side state, but they are a single-tier authentication primitive, not designed to gate content of two different sensitivities within the same corpus. None of the three, individually or combined, was designed for the specific case of NDA-gated document distribution to a small, static, out-of-band-configured recipient list.

HMAC-based key derivation (HKDF, RFC 5869) is a well-understood primitive on its own, and centralized key-rotation services such as AWS KMS handle automatic rotation - but both require a stateful key-management layer behind them. The combination this claim covers - genuinely stateless two-tier gating derived from one salt, specifically shaped for document-sensitivity separation rather than user authentication or API authorization - does not appear in prior art.

Persistent key records held by the server

Independent access tiers derived from one salt

Weekly

Default rotation cadence (ISO calendar week)

Why Existing Approaches Fall Short

JSON Web Tokens: revocation before expiry requires server-side state; no native multi-tier content gating.
OAuth2 refresh tokens: require a token database and a revocation endpoint; stateful by design.
TOTP / HOTP: stateless rotation but single-tier; not built to separate manifest access from content access.
AWS KMS rotation schedules: centralized, stateful key management; not a deterministic zero-database scheme.

Technical Architecture

Key Derivation

For rotation period t, the server computes:

index_tier_key(t) = HMAC-SHA-256(salt, "INDEX:" || t)
asset_tier_key(t) = HMAC-SHA-256(salt, "ASSET:" || t)

where salt is a high-entropy secret held only in server configuration, and t is formatted as an ISO calendar-week identifier (e.g., 2026-W29) in the preferred embodiment, rotating every Monday 00:00 UTC. The derivation is a pure function: identical salt and t always produce identical keys, and no lookup table is involved.

System Components

Component	Function
Secret salt store	Holds the high-entropy salt, provisioned via environment variable or secrets manager; never disclosed to any requester.
Key derivation module	Implements the HMAC formulas above; deterministic and stateless.
Key publication module	Delivers each period's key pair to a static, out-of-band recipient list via authenticated email at the start of the period.
Index-tier gating module	Serves the document manifest only if the presented key matches the current period's index-tier key.
Asset-tier gating module	Serves individual document content only if the presented key matches the current period's asset-tier key.

Stateless Properties

The server persists no database of issued or presented keys. Rotation of valid keys happens automatically at every period boundary purely because the deterministic derivation produces a different key for a different t - there is no explicit revocation step. A complete server restart requires no state-recovery step: the current period's keys are simply re-derived from the still-provisioned salt. A supplementary, independently-stateful magic-link path can coexist for cases needing one-time-token access, without altering the primary stateless mechanism.

Privacy Property

The server does not log which keys were presented or by whom - standard access logs may record URL paths and IP addresses per ordinary web-server logging, but key values themselves are never written to logs, preserving requester privacy even from the operator's own infrastructure.

Prior Art Differentiation

Approach	Stateless rotation	Multi-tier content gating	Zero-downtime restart	Built for NDA-gated corpora
JSON Web Tokens	No (revocation needs state)	No	Yes	No
OAuth2 refresh tokens	No	No	No	No
TOTP / HOTP	Yes	No (single-tier)	Yes	No
AWS KMS rotation	No	N/A	No	No
JIL Sovereign	Yes	Yes, two tiers	Yes	Yes

Individually, HMAC derivation and calendar-interval rotation are well-known primitives; what is novel is combining stateless two-tier content-sensitivity gating with zero server-side key state, specifically shaped for out-of-band-configured recipient lists rather than general user authentication.

Patent Claim

Independent Claim 30: A computer-implemented method for access-controlling a corpus of digital documents served by a document server, comprising: maintaining at the document server a secret salt value not disclosed to any requester; for each rotation period of a predetermined calendar interval, deterministically deriving a pair of access keys comprising an index-tier key computed as an HMAC of the secret salt and a concatenation of a first domain string and the rotation period, and an asset-tier key computed as an HMAC of the secret salt and a concatenation of a distinct second domain string and the rotation period; publishing the current-period key pair to a static, out-of-band-configured list of authorized recipients via a secondary secure channel at the start of each rotation period; serving a document manifest in response to an index-tier request only if the presented key matches the derived index-tier key; and serving an individual document in response to an asset-tier request only if the presented key matches the derived asset-tier key; wherein the document server maintains no persistent state regarding issued keys, and rotation of valid keys occurs automatically at each rotation-period boundary without operator intervention.