Permits (SignedPermit)

✅ Verified

Against Axowl.Auth/EndPoints/PermitEndpoints.cs + Axowl.Auth/Program.cs (origin/main) — 2026-08-26.

Now live

This route was documented on 2026-06-22 but was not registered until 2026-08-26 — calls returned 404. It is registered now. Three issues were fixed in the same change: the revocation check never matched (key built twice, two different ways), the route’s {slug} was never compared against the permit’s organization, and the idempotency cache was keyed only by the caller-supplied key.

A SignedPermit is a cryptographically signed authorization for a specific action. The Brain & Permit principle: Axowl issues the permit; your plugin/app performs the action and verifies the permit. Base path: /api/org/{slug}/permits (authenticated).

Method · Route	Purpose	Source
POST /issue	Issue a SignedPermit for the caller’s ConnectedId + requested scope	PermitEndpoints.cs:33

Whose permit is it?

The permit is always issued for the caller’s own ConnectedId in the organization named by {slug} — there is no way to request a permit on behalf of another badge. A person who belongs to several organizations holds a separate badge in each; the one in the route’s organization is the one that counts.

Request body

Field	Type	Notes
requestedScope	string, required	Scope key from the permission scopes catalog.
ttlSeconds	int, optional (default 30)	Clamped to 1–300.
idempotencyKey	string, optional	Replays the same permit within its TTL. Scoped to your badge and scope — your key cannot collide with another caller’s.
context	object, optional	Free-form, embedded in the permit as a context claim.

Issuance checks (in order)

POST /issue runs these before signing:

1. Organization — resolve {slug}; the caller must be a member (enforced upstream by tenant resolution).
2. Badge — resolve the caller’s ConnectedId in that organization.
3. Active — is the ConnectedId active?
4. Revocation — is the ConnectedId on the revocation list?
5. Scope — does the member hold the requested scope (HashSet.Contains, wildcards allowed)?
6. Seal tier — derived from the org’s SecurityMode.
7. Sign — issue the permit, RS256-signed with the org’s signing key.

Failure shapes: 400 no organization context · 404 no badge for the caller in that organization · 403 badge inactive, revoked, or missing the scope · 500 the org has no signing key (Settings → Keys).

The permit is verifiable by your side against the org’s published JWKS — no shared secret. Permits draw their authority from the same sealed RBAC snapshot as everything else — see Roles & permissions and Permission scopes.