concepts ยท permissions
Permissions should follow the graph, not the app
In the current reference implementation, a context is the permission boundary. It is a named graph inside a pod: a place where statements live and where read, write and manage authority can be granted.
Contexts are deliberately smaller than products. A calendar app can read a public event context. A private planning app can write to an internal context. An agent can see only the contexts its token grants.
same resource URI
|
+--> public context
| title, date, location
|
+--> private context
notes, drafts, internal statusThe current grant shape
The working model attaches grants to context IRIs. The permissions areread, write and manage. Public reads are handled as a public-read capability over contexts the pod exposes to the open web.
The important implementation detail is that context permissions are resolved server-side on each request. Access tokens stay slim. If a grant is revoked, the next request sees the reduced context set.
Downscope, not disclosure
Read surfaces can accept a context downscope. Unknown or unreadable contexts are silently excluded, so a caller cannot use errors to map private context topology.
The server returns the readable slice, not a diagnostic tour of what the caller failed to access.
Why contexts are useful
Contexts let the same resource carry different depth for different callers. A venue can publish an event publicly and keep booking notes private. A company can expose product knowledge to support tools while holding internal planning facts back.
This is also what makes graph retrieval safer. find, resource reads, SPARQL and MCP tools can all work over the same effective readable contexts instead of each surface inventing its own permissions.
Where ACP may fit
The authorization model is being reconsidered toward ACP-style and more fine-grained AuthZ. That should not be hidden. The website should not claim that context grants are the final word.
The stable idea is weaker and more important: permissions must be enforced by the pod, must survive different client surfaces, and must let data stay in the owner's space while apps come and go.