License Activation for Private Deployments

The goal is not absolute anti-cracking, but making piracy detectable, containable, attributable. Under the design premises (§0), threats converge to two tiers: Tier 1, copy without modification (clone the running system) → detectable; Tier 2, code change / forged internal trust → not defensible by software, needs hardware attestation / legal contracts.

Frequency floor: N independent clusters must each refresh ≥1×/validity to avoid fail-close → combined ≥N×, and you can't hide that behind a coordinator.

Because duplication detection doesn't depend on token changes but on the in-memory instance-id: the agent generates a random id in memory at startup, never persisted, sent on every refresh. A clone can't read the in-memory id → the clone generates a new id → one RT with multiple concurrent persistent ids = duplication. Cleaner than deployment_id (inherited by clones, identical to a migration); bypassing it needs patching the agent to pin the id = Tier 2.

Since detection is already provided by the instance-id, mutating the token (rotation) only adds a state machine / grace / bricking-on-lost-response, with no new coverage —— so the RT is static and refresh only extends the TTL. In essence the instance-id is a "lightweight unsigned PoP" that only detects, doesn't authenticate —— cleartext over TLS is enough.

Core invariant: one license = one live RT chain = one live consumer. Cloning and extraction both just "create a second consumer"; coverage is equivalent (same "multiple instance-id" signal) → achieve anti-dup and anti-extraction follows.

Large customers are bound by brand + contract + audit and basically don't touch it. The threat concentrates in small customers: over-deployment / whole-environment cloning = Tier 1, exactly this scheme's sweet spot. Hence detection-first, revoke only after confirmation —— small customers run rough ops (no HA / manual migration / snapshot restore), so don't silently stop service and hurt them.

The agent hosts refresh; most customers never touch the RT. The dominant piracy mode isn't extracting the RT, it's whole-environment cloning —— the RT is copied along with the Secret. And the in-memory instance-id catches exactly that: the clone can't read the in-memory id, the cloned agent generates a new id → one RT with two concurrent ids → duplication. Actually patching the agent to pin the id is Tier 2.

Two corrections: legit customers' friction is lower than feared (the agent hosts it robustly); the RT's accidental-leak surface is smaller than assumed (only inside the cluster).

The main reason isn't attribution —— it's keeping the durable credential off the outside links. Drop it and you'd bake the RT into the shipped package; once the package leaks on an outside link and is used alone (a thief deploys first / the legit party isn't live yet), the instance-id can't help (it only catches concurrency). The activation code makes the outside link carry only a one-time code: dead once the customer redeems it; if a thief redeems first, the customer's activation fails → instant exposure.

Attribution is a free second benefit: activation is a discrete node that splits a leak into pre-handoff (delivery chain) vs runtime (inside the customer). But discount it twice: an activation leak could be the customer's procurement forwarding it; runtime duplication could be an external attacker who breached the customer; and it only holds if you recorded the redeem context → a strong prior, not proof.

No —— "valid forever" overstates it. Static = the value doesn't change, but it's revocable: unsubscribe / account expiry / confirmed theft, the server refuses renewal, fail-close within one TTL. For duplication (concurrent reuse), the real threat, static RT + revoke + instance-id already covers it fully; the residual you worried about is a non-duplication corner (a thief using it alone, the account still paying, the legit party never coming online) —— neither reuse nor really plausible. To passively expire an old credential → go through re-activation.

The core benefit is stateless full-entitlement delivery. Each SLF is a self-contained, signed, time-bounded full snapshot. Hence: entitlement change/revoke/downscope is trivial (issue the next number, no delta protocol); the client is stateless about entitlement (holds only the current SLF + last_accepted_sequence, replaced wholesale); one signature is tamper-proof (no signing and ordering a stream of deltas); audit is free (each issuance is one record with the snapshot + sequence).

Versus long file + heartbeat: to support dynamic entitlement the heartbeat must carry updates → maintain a base + a stream of mutable deltas, reconcile both sides, sign and order each —— exactly the state SLF avoids; extending only the validity can't do dynamic adjustment.

So the RT degenerates to pure identity (no entitlement) = authN / authZ split = OAuth's refresh token (identity) + access token (signed claims). Three notes: ① state doesn't vanish, it moves to the server (source of truth), leaving the client minimal; ② "short" gives timely revoke/change, "full" gives statelessness —— a pair; ③ the cost = SLF TTL = the lower bound on revoke latency (an issued SLF can't be recalled, you just stop re-issuing —— symmetric with the heartbeat model). The layering dividend: duplication detection (RT + instance-id) lands cleanly in the authN layer, decoupled from entitlement.

Normal activation, see Ⅲ: one-time code → singleton/leader agent redeem → cloud validate (single-use / not expired / not revoked) → mint static RT + first SLF + record redeem context → void the code → agent stores the RT in the shared Secret, generates the in-memory instance-id, starts the refresh loop.

Redeem conflict = leak signal: re-redeeming a consumed code → clear error + recorded as a potential outside-link leak (a thief redeeming first makes the legit customer's activation fail → loud exposure).

Recovery / re-activation, two modes: recovery (RT lost; the old chain survives until the new code is redeemed, avoiding downtime) vs revocation (confirmed theft; kill the old chain immediately). Both revoke the old code first and converge to one live chain. Edges: RT lost / code expired → re-activation (accepts manual intervention, rare); the code TTL matches the deployment lead time + keeps a re-issue path.