2.8 KiB
| title | description | layout |
|---|---|---|
| Permissions and capabilities | How permissions work in NextGraph, based on cryptographic capabilities | ../../../layouts/MainLayout.astro |
As explained already in the Nuri chapter, all permissions are handled in NextGraph with cryptographic capabilities.
When the user shares a link to a document or to a branch, this link (Nuri) contains all the capabilities needed in order to open and read this document, and optionally, to modify it.
Those capabilities are composed of :
- the RepoID of the document
- a read capability on the branch.
- If it is the root branch, then access to the whole document and all its branches will be granted.
- If it is a transactional branch (Header, Main, a block, a fork, etc...) then only this specific branch will be accessible.
- the overlay ID. see the Network chapter about overlays.
- the locator which is a list of brokers that can be contacted in order to join the overlay and access the topics. Read more on topics in the sync protocol chapter.
If the user receives write access to the repo, then the capability will contain also the ReadCap of the inner overlay. This inner overlay is were al the updates are happening, and the ReadCap is needed in order to enter this overlay.
The editor will also need to have their UserId added to the internal list of editors within the repo, and they will also need to receive the BranchWriteCapSecret that is needed in order to publish in the topic's pub/sub.
All of this is done transparently and the only thing needed is to go to "Permissions" in the Document menu, and then share the generated Nuri to the new editor.
An API will also be provided for permission manipulation.
Adding permissions can be done offline (as long as the new user can synchronize), and is an asynchronous operation.
But removing permissions is a synchronous operation that requires a SyncSignature (signed by the quorum).
more on that soon...
Authorization & Capability Delegation
Apps developed with our SDK are treated as untrusted by the Verifier, and will therefor need to provide all the capabilities for the Documents they intend to read or write.
As apps are considered as viewers and editors, an App instance always runs with an associated document, where the data generated by the app can be saved.
If the app needs access to other documents of the User, the capabilities can be saved by the app in the current document that the app instance has been associated with.
The Verifier, which has access to that associated document, will automatically use those capabilities for any API access made by the app. The programmer can also attach some additional capabilities to every API call.
more on that feature once it will be implemented...