PermDock

Roadmap

What PermDock 0.1.0 contains, what is planned, what the project deliberately does not do, how versions are numbered, and the open design questions.

This page is the single place for what exists, what is planned and what is still undecided. A page for something not built yet carries a Status: planned or Status: tracking line under its frontmatter; every other page describes code in the package. Design rationale lives in the Why section of the page that owns each decision.

Current scope

permdock@0.1.0 is on npm. It is one package: core, every adapter, the permdock CLI (permdock/cli, permdock/unplugin, permdock/next/plugin) and the test runners (permdock/testing).

  • Core. definePermissions, resource and typed permission references, with renamed for former keys; definePolicy, role, allow, deny and portable conditions with an in-memory evaluator; time-bound grants (validFrom, validUntil) and policy delegations for agents; the two-principal subject (principal, actor, delegation) with tenancy, memberships, scoped, custom and global custom roles; createPermDock with can, decide, explain, assert, filter, simulate, snapshot and on; field-level grants, quota grants through LimitStore, approvals with quorum, stages and escalation through ApprovalStore, decision events through DecisionSink, and connections that end on a RevocationFeed. See concepts.
  • Adoption. An app with its own permission keys, SQL helpers, tokens and stored custom roles moves over in steps that each leave it working: rls generate --helpers-only --shims, rls migrate, renamed aliases, and doctor PD055 and PD056 to measure what still uses an old key. See existing apps.
  • Adapters. UI adapters for React, React Native, Vue, Svelte and Solid; Next.js with Cache Components; server adapters for Hono, Express, Fastify, Elysia, Nest, Node, tRPC, oRPC and the Fetch kernel; your own CLI through permdock/terminal; agent adapters for MCP, the AI SDK, the Claude Agent SDK, Eve, OpenAI Agents, WebMCP and A2A; where compilers for Drizzle, Prisma and Kysely; providers for JWT and OIDC, Supabase, Better Auth, Clerk and Convex; AuthZEN as a PDP and as a PEP (permdock/pdp); approvals, SSF and CAEP, SCIM, OpenAPI, OpenTelemetry and the optional permdock/cloud client. See adapters.
  • Supabase. permdock/supabase/middleware as a @supabase/middleware 1.0 entry next to @supabase/server 1.9, with named secret keys as service principals and bridges in place of the deprecated framework adapters; supabaseRls policies for Realtime channels and Storage buckets; the { subject: { session: { live: true } } } condition over auth.sessions; rls verify --advisors over Splinter, doctor PD062 and PD063 for legacy claim settings and statements supautils rejects; pg_jsonschema checks through rls.jsonSchema and supabase.hook.validate; and capability-matrix ids in the manifest's requires, with supabaseClaimVectors in permdock/testing. See Supabase.
  • Standards. AuthZEN 1.0, Standard Schema, RFC 9457 Problem Details, JOSE and OpenID Connect, the FAPI 2.0 resource-server profile, RFC 9068 and SCIM claims, OAuth scopes and RAR, MCP authorization, OpenAPI 3.2 with the pinned 3.3 Security Profiles draft, Overlay 1.1 with the pinned 1.2 draft, Arazzo, Postgres RLS, Web Bot Auth and A2A. See standards.
  • CLI. collect, catalog, diff, usage, doctor, skills, openapi emit | import, arazzo check, rls generate | import | verify | migrate, supabase hook generate | inspect and cloud push, plus the collect-only createPermDockPlugin and createPermDockUnplugin build hooks. See CLI.
  • Testing and docs. Policy matrix tests, conformance runners for every extension interface, client parity, HTTP adapter and ORM parity scenario runners, the shared SaaS domain, the permdock, permdock-wire, permdock-audit and topic Agent Skills, llms.txt, and the public docs MCP server at /mcp.

Planned

  • Cloud integrations. The connector catalog for trusted issuers, CAEP transmitters, OTLP, OCSF, CloudEvents webhooks and compliance platforms, each over a standard wire format or an existing PermDock interface (Cloud integrations).
  • External AuthZEN certification. testAuthZen runs PermDock's Todo vectors and the official interop vectors in the repository; deploying the interop PDP and filing the submission are the external steps on the AuthZEN checklist.
  • Supabase MCP recipe. A recipe that filters @supabase/server/mcp's generated tools through permdock/mcp, once PR #146 ships in a release; nothing is built against the alpha (watch list).
  • Compiled pg_jsonschema checks. rls.jsonSchema moves to jsonb_matches_compiled_schema once pg_jsonschema's compiled schema type (PR #98, merged after v0.3.4) reaches a Supabase Postgres release.
  • Claim-mapping ports. subjectFromSupabase ports for the Swift, Python and Dart SDKs that read supabaseClaimVectors, once the capability matrix's conformance schema (PR #30) lands.
  • OpenAPI registrations. The permdock namespace pull request against the OpenAPI Namespace Registry and a decision on IANA registration of the application/permdock-*+jwt media types; both are external steps on the checklist on OpenAPI registries.

Specifications PermDock follows without code, including GNAP, carry a build, name or track posture on the standards watch list.

Non-goals

  • Requiring a network call to decide. PermDock is a PDP you embed; PermDock Cloud is optional, and every hosted capability (approvals, decision log, snapshot distribution) has an in-process default behind the same interface. permdock/pdp is the only opt-in exception.
  • A policy DSL; policies are TypeScript data.
  • Replacing authentication or issuing tokens.
  • Zanzibar-scale relation graphs; bridge to OpenFGA or SpiceDB through a provider or a RelationSource. Object hierarchies (folders in folders, sub-teams, reporting lines) are relation grants that walk a parent chain to a bounded depth (relationships); resource roles follow declared, typed parent chains (tenancy).
  • Tenant, team, invitation, membership or custom-role storage and management APIs. PermDock reads memberships and custom roles through MembershipSource and RoleSource; the auth provider or the application owns the tables and the invitation flow.
  • UI components beyond <Protected> and the Next.js <PermissionBoundary> error boundary: no tenant-switcher dropdown, role badge or approval dialog. Hooks return data; the design system renders it (UI).
  • CommonJS output or Node versions older than the ESM-only baseline.
  • Copying permix, CASL or Kilpi APIs.
  • Wrapping tools that already read PermDock's output. Spec producers, SDK generators, docs UIs, auth providers with JWKS, agent frameworks without a hook of their own, audit sinks and flag SDKs are reached through wire formats and recipes, never a per-vendor package entry.
  • Angular. There is no permdock/angular; Angular apps consume the AuthZEN decision endpoint and the plain JSON snapshot format (wire formats), and a community adapter can follow the Vue shape.

Versioning

  • Releases follow semver from 0.1.0, published under the latest npm dist-tag. Every wire format is at v1: snapshot v: 1, approval request v: 1, catalog-v1.json with version: 1, and x-permdock-catalog.v: 1.
  • A breaking change to a wire format bumps that format's major (v: 2) and the package major; a breaking change to a public identifier or a default is a major release with a migration note on each affected adapter page. Before 1.0.0, the package major is the minor: 0.1.x to 0.2.0.
  • Any change to a public identifier, wire format or default behaviour starts as an RFC-lite issue and ends as an update to the owning page's Why section.
  • Adapters, the CLI and the test runners version with core; there is no independent versioning because there is only one package.
  • Pinned draft revisions (OpenAPI 3.3 Security Profiles, Overlay 1.2, WebMCP, Web Bot Auth) are bumped with a changeset and recorded in x-permdock-catalog.drafts; see the watch list.

Open questions

This is the single list of open design questions for the whole docs site. Pages do not carry their own; a question is removed from here when its decision is written into the owning page's Why section.

None at the moment. Every question raised before 0.1.0 is decided in the Why section of the page that owns it.

Last updated on

On this page