See the surface a real owner approves
Grant scope, fields, retention, and refusal evidence are all visible without reading the spec first.
Click through a fictional tax-prep app asking a fictional owner for three pay statements. Approve the grant, see only the granted fields come back, then revoke and watch the next read get refused. The transcript on the right shows the API-shaped JSON for each step.
Decides what to share, can revoke at any time.
Import the last three pay statements so you can finish your tax return without re-keying numbers.
Stand-in payroll connector used only inside this sandbox. No real Acme Corporation, employer, or paycheck data is involved.
Press Stage the request to begin. You'll play the fictional owner, Sam, deciding what Quill Tax can read from a simulated payroll connector.
Net and gross pay totals from the last three pay periods, plus the issuing employer name.
No grant yet, so no records to project. PDPP refuses unscoped reads by construction, not by convention.
Each panel reveals as you advance the walkthrough. Shapes are representative of PDPP, not byte-for-byte from a live reference run. See /docs for normative semantics.
Grant scope, fields, retention, and refusal evidence are all visible without reading the spec first.
Each step exposes a representative request/response so you can compare your own draft to the protocol.
Approve a grant, revoke it, and watch the simulated resource server refuse the next read.
Keeping artifact boundaries crisp is part of the protocol's contract with reviewers.
Operator views run against a real local or self-hosted reference instance with owner auth. They are intentionally out of scope here.
See the surface map->When the sandbox and the docs disagree, trust the docs. The sandbox is pedagogy, not a conformance suite.
Read the docs->Vana does not host a canonical PDPP owner instance. To run one, fork the repo and use the Docker compose stack.
Self-host instructions->