Pillar 02
Authorization
Policy-based access control enforced at the control plane. What any session can see or do is determined by roles, resource ownership, and cooperative membership status — not by arbitrary tier restrictions.
Design philosophy
Authorization in a cooperative is different from authorization in a SaaS product. There is no "free tier" versus "pro tier." Every member has the same fundamental rights. What varies is responsibility: some members coordinate resources, some govern the collective, some are new and still onboarding.
The authorization model reflects this. Permissions are derived from roles and resource ownership, not from a payment tier.
Roles
Member
Any authenticated person who has joined the cooperative. Members can use all platform services, participate in governance proposals, and view the collective treasury. There is no "read-only" member.
Coordinator
A member elected or appointed to coordinate a specific resource, project, or working group. Coordinators can create sub-spaces, invite new members to their resource, and initiate workflows on behalf of the resource.
Council
Governing council members who have been granted elevated platform authority by collective vote. Council members can approve large treasury actions, modify platform-wide policies, and manage coordinator assignments.
Node operator
Members who operate physical infrastructure nodes. They have access to infrastructure management dashboards and can view system health metrics for the nodes they operate.
Resource ownership
Every object in the system (a file, a chat room, a project, a treasury account) has an owning entity: either a specific member, a working group, or the collective. Ownership determines who can read, modify, share, or delete the resource.
Ownership can be transferred between members or reassigned to the collective. If a member leaves the cooperative, their individually-owned resources are transferred to a governance-controlled escrow account pending collective decision.
Membership status
Authorization also depends on membership status:
- Active — full access to all cooperative services
- Provisional — onboarding period; limited to read-only participation in governance
- Suspended — temporarily restricted pending a governance review; can view but not act
- Alumni — former member; can access archived data but not active spaces
Control plane enforcement
Every API request passes through the Control Plane API, which evaluates the session's role, the resource's ownership policy, and the member's current status before allowing the action. This is not middleware — it is a dedicated policy evaluation step on every request.
Policy documents are stored in Ceramic (a decentralized data stream) so that policy changes are auditable and tamper-evident. The Control Plane reads the current policy document and applies it. Historical policy states are always recoverable.
Federation and cross-node authorization
When a member from one shard visits another shard's space, their identity is verified via the federated Auth Edge, and a cross-shard session is issued with the minimum permissions granted by both nodes' policies. Neither node needs to share a database — the session token carries the cross-node claims.