Permit

Protocol v1 · Ed25519 · Apache-2.0

Sign once.
Authorize anywhere.

Permit gives independent software a small, open format for product rights that work offline and stay manageable online.

Get started Read Protocol v1
Offline-verifiable Online-manageable Framework-neutral
SIGNED CREDENTIAL

permit/v1

✓ verified
type
entitlement
subject
org:studio-42
product
pro.desktop
edition
team
seats
12 named
use
perpetual
Ed25519 0a:30:14:14:d3:67…
public trustactive
exact payload1,110 bytes

THE MISSING PRODUCT LAYER

Payments are not permissions.

A payment event proves that money moved. An account proves identity. Neither gives an installed app a durable, portable answer to “what may this user run right now?”

Permit turns that answer into a signed artifact. The application verifies it locally with public keys it already trusts. A future management service may issue or refresh credentials, but authorization never depends on that service being reachable.

01

Exact bytes, no ambiguity

Ed25519 signs the decoded payload bytes exactly. Verifiers never parse and re-serialize JSON before checking the signature.

02

Rights outlive connectivity

Long-lived entitlements stand on their own. Products add short-lived activation leases only when their policy needs online control.

03

Policy without platform lock-in

Permit sits beside Rivet, Glaze, native apps, or any other runtime. The application framework never owns commercial policy.

ONE VOCABULARY, DISTINCT WINDOWS

Model the product you actually sell.

Use rights, update eligibility, and access to newly published features are independent facts.

Model Use Updates New features
Perpetual purchase Forever Open or bounded Open or bounded
Perpetual + maintenance Forever Maintenance window Open or bounded
Perpetual + feature window Forever Open or bounded Feature window
Subscription Until term end By policy By policy
Trial Until trial end By policy By policy

Teams, named seats, devices, concurrent seats, bundles, editions, add-ons, and scalar capabilities remain separate claims — no overloaded “license count.”

SMALL CORE, EXPLICIT LAYERS

Verify first. Interpret second.

1

Envelope

Decode the payload and signature. Reject unknown protocol versions and algorithms.

2

Trust

Resolve key_id through next, active, retired, or revoked trust-store state.

3

Signature

Verify Ed25519 over the exact payload bytes before claims are used.

4

Policy

Evaluate product, version, time windows, grants, installation, and optional lease.

ENTITLEMENTDurable commercial right
product · edition · grants · seats
ACTIVATIONOptional installation lease
installation_id · expires_at · grace
TRIALIndependent evaluation right
subject · limits · use_expires_at

KEY ROTATION WITHOUT A FLAG DAY

Ship tomorrow's trust before you need it.

nextstaged in clients
activesigning now
retiredhistorical cutoff
revokedrejected immediately

RACKET REFERENCE IMPLEMENTATION

From zero to verified.

Install the package, generate a key pair, sign a payload, then verify it with only the public trust store.

Browse source and test vectors →
permit — shell
$ raco pkg install --auto \
  --name permit https://github.com/turinglambdaai/permit.git

$ raco permit keygen \
  --private private-key.der \
  --public public-key.der \
  --trust-store trust-store.json \
  --key-id license-2026 \
  --issuer com.example

$ raco permit verify \
  --trust-store trust-store.json \
  --credential entitlement.permit.json

✓ verified entitlement

A DELIBERATE BOUNDARY

A protocol, not a billing company.

Permit v0.1 does not implement payments, accounts, pricing, tax, email, dashboards, hosted metering, or a license server. Future management systems may issue Permit credentials through this boundary; they do not belong in the verification core.