The forkable PDPP implementation, not the protocol authority.
This surface explains the runnable code in this repository: the authorization server, resource server, local composition, dashboard, reference clients, tests, and deployment posture. For normative protocol behavior, use the protocol docs.
Purpose and non-goals
The reference exists to make PDPP concrete enough to fork, test, and criticize.
Executable proof
Prove grant issuance, owner self-export, resource queries, native provider identity, polyfill connector identity, and reference-only diagnostics with runnable code and tests.
Not canonical SaaS
Do not read this website as a hosted multi-tenant PDPP service or as a promise that every implementation must copy these dashboard, trace, or storage choices.
Surface map
Each route family has a different job, authority, and data posture.
PDPP docs
Normative protocol semantics, extension docs, grant shapes, query behavior, and intentionally deferred scope.
Forkable implementation
Current code, tests, dashboards, example clients, and operator diagnostics for one implementation of PDPP.
Operator dashboard
A stateful control plane for a running local or self-hosted instance. It is not a public hosted demo.
Sandbox
Interactive mock-backed walkthrough of one PDPP scenario end to end: request, consent, scoped read, revocation, refusal. No credentials, no live data.
Architecture
Clients stage access requests
PAR and protected registration shape the current reference client-connect path.
Owners approve bounded grants
Consent creates durable grants with streams, fields, retention, and source identity.
Resource reads enforce grants
The resource server projects records to the granted fields and supports owner self-export separately.
Operators inspect the instance
Dashboard pages and _ref routes expose traces, runs, records, deployment diagnostics, and timelines for this implementation.
Trust boundaries
- The protocol docs define PDPP semantics; the reference implementation demonstrates one executable interpretation.
- Reference-only headers, traces, timelines, and deployment diagnostics are operator aids, not protocol negotiation.
- The dashboard reads live instance state and should be protected with owner auth when exposed beyond local development.
- The public website does not imply that Vana operates a canonical live PDPP owner dashboard for real data.
Review paths
These links keep artifact boundaries explicit: protocol docs are normative, coverage is public evidence, sandbox is mock-only, and live operation remains local or self-hosted.
Public coverage matrix->
Falsifiable status rows for protocol flows, retrieval extensions, collection profiles, reference diagnostics, sandbox, and deferred scope.
Interactive mock walkthrough->
Click through one full PDPP scenario in your browser: a fictional client requests scoped pay statements, the owner approves, the resource server returns only granted fields, and revocation refuses the next read. Inspectable JSON for each step.
GitHub source->
Browse the monorepo, issues, tests, Docker files, and reference package.
Root README->
Repo overview, dev commands, Docker image posture, and top-level project map.
Reference README->
Local stack, direct AS/RS mode, Docker Compose, owner auth, and generated artifacts.
Architecture docs->
Protocol-facing architecture notes. Treat repo package topology as reference behavior unless specified by docs.
OpenSpec change history->
Project planning and active changes. Useful for review context, but not protocol authority.
Self-hosted operator instructions->
Start a composed browser origin, protect the dashboard, and inspect a running instance locally.
Reference topology->
Existing reference notes remain available, labeled as current implementation behavior rather than protocol truth.
End-to-end flows->
Concrete request, consent, owner self-export, and query examples from the current reference.