Data Access Control

Draft specification

Maturity: Draft — not yet validated by a reference implementation. Subject to change during Runtime development.

See Protocol Specifications for reading order and the full specification index.

Abstract

This specification defines the Faberio Data Access Control model — the platform capability for authorizing user access to data in the Distributed Database and Distributed File Storage.

Access is granted at multiple granularity levels: tables (collections), columns, and rows for database data; path prefixes and individual files for file storage. Each grant specifies read or write permission and MAY include a condition that limits access to data matching a predicate.

All inter-node data synchronization is performed as background replication by the Runtime. Replication operates in one of two authorization contexts: node-level (the entire information space) or user-level (only data the user is authorized to access). Applications do not initiate cross-node data operations — users read and write the local replica only.

Users registered in an information space do not automatically gain access to shared data. User records include an approval status, and access is granted only after an administrator approves the user and explicit access policies are in place. See the Identity Model for user cryptographic identity within an information space.

The Runtime evaluates access policies on every node before allowing database or file storage operations. For operations that transmit data to another node or external client, authorization MUST occur on the source side — the Runtime that serves or sends the data — not only on the requesting client Runtime. See section 9.5.

1. Scope

This specification defines:

access policy model and structure
permission types (read, write)
database access scopes (collection, column, row)
file storage access scopes (path prefix, file, metadata field)
condition expressions for conditional access
policy evaluation algorithm
relationship to user cryptographic identity and user devices
user registration and administrator approval
information space scoping
local enforcement on replicated data
source-side authorization for outbound data transmission

This specification does not define:

user and node authentication (see Identity Model)
application authorization for information spaces (see Node Discovery)
database or file storage APIs (see Distributed Database, Distributed File Storage)
administrator user interface and workflow tooling

2. Motivation

Replicated data is shared across independently operated nodes, but not every user should see or modify all data within an information space. Applications need fine-grained control over who can read and write specific tables, columns, rows, and files.

Faberio provides data access control as a platform service. Operators define policies that the Runtime enforces on every database and file storage operation — regardless of whether the application uses the SDK, HTTP API, or native access mode.

Authorization MUST NOT rely on the requesting client alone. The source Runtime — the node that holds the data being read, replicated, or returned over the HTTP API — MUST evaluate policies before data leaves that node. Receiving-side checks MAY provide defense in depth but do not replace source-side enforcement.

By separating access policy definition from application code, Faberio ensures consistent enforcement across all replicas and integration modes.

3. Concepts

3.1 Access Policy

An access policy is a set of rules that define which users MAY read or write which data resources within an information space.

Policies are stored as database records and replicated across participating nodes. Each node enforces policies locally at operation time.

3.2 Subject

A subject is the user or group to whom access is granted. The subject_id field in a policy record is a UUIDv7 identifier:

when subject_type is user, subject_id MUST be the user's UUIDv7 record identifier
when subject_type is group, subject_id MUST be the group's UUIDv7 record identifier

See the Identity Model — Groups for group and membership record schemas.

3.3 Resource

A resource is a data target within the distributed database or file storage. Resources are addressed at different granularity levels depending on the service.

3.4 Permission

A permission grants a subject the right to perform an operation on a resource:

Permission	Database	File storage
read	Query and retrieve records or column values	Read file content and metadata
write	Create, update, and delete records or column values	Store, update, and delete files

Write permission encompasses all mutating operations. Implementations MUST NOT grant partial write permissions (e.g. update without delete) at the platform level — such distinctions are an application concern.

3.5 Condition

A condition is an optional predicate that further restricts a permission to data matching a specific criteria. Conditions apply primarily to row-level database access and file-level storage access.

When a permission includes a condition, the Runtime grants access only if the target data satisfies the predicate.

3.6 Scope Levels

Access control operates at multiple scope levels. More specific scopes take precedence over broader scopes during evaluation.

Database scopes:

Scope	Resource pattern	Description
Collection	`database.collection.{name}`	Entire table (collection)
Column	`database.collection.{name}.column.{field}`	Specific field within records
Row	`database.collection.{name}.row`	Individual records matching a condition

File storage scopes:

Scope	Resource pattern	Description
Path prefix	`storage.path.{prefix}`	All files under a logical path prefix
Metadata field	`storage.metadata.{field}`	Specific metadata field (e.g. `mime_type`)
File	`storage.file`	Individual files matching a condition

3.7 Replication Authorization Context

Background replication between nodes operates in one of two authorization contexts. The context determines how much data the Runtime synchronizes between peers.

Context	Identity	Replication scope
Node-level	Node cryptographic identity	All records and files in the information space
User-level	User cryptographic identity (UUIDv7 + public key)	Only records and files the user is authorized to access

Node-level background replication applies when the Runtime synchronizes the full information space between trusted peers — for example, between server nodes or when a node maintains a complete replica of the space.

User-level background replication applies when the Runtime synchronizes data on behalf of a specific user — for example, on a user device that should hold only the subset of data that user is authorized to access. The Runtime evaluates access policies for that user and limits synchronization to authorized objects and files only.

Applications MUST NOT initiate cross-node data operations. Users read and write the local replica on their current device; the Runtime propagates changes to and from remote nodes through background replication only.

3.8 Source-Side Authorization

Source-side authorization is policy evaluation performed by the Runtime that originates or serves data before that data is returned to an application, sent in a replication payload, or exposed through the HTTP API.

The source node is the Runtime instance whose local replica contains the records or files being accessed or transmitted. For HTTP API and external clients, the source node is the host Runtime serving the request. For background replication, the source node is the peer sending the replication payload in that exchange direction.

Source-side authorization is mandatory. A requesting or receiving Runtime MUST NOT be treated as sufficient proof of authorization for data it did not originate.

3.9 User Registration Status

Each user record within an information space includes a status field that tracks administrator approval. Users registered with a public key do not automatically receive shared data access — they MUST be approved by an administrator. See section 11.

4. Relationship to Identity Model

Data access control builds on the Identity Model. Every access evaluation requires a cryptographically authenticated user context:

the user's UUIDv7 identifier and verified Ed25519 signature
the user's status in the information space
the access policies associated with the user or their groups

Access policies are defined within the information space and enforced locally on every node that holds a replica.

See the Identity Model for user cryptographic identity and multi-device registration.

5. Policy Model

5.1 Policy Record

Access policies are stored as database records within an information space.

Field	Type	Description
`id`	UUIDv7	Policy identifier
`information_space_id`	UUIDv7	Information space this policy applies to
`subject_type`	string	`user` or `group`
`subject_id`	UUIDv7	User or group identifier
`resource`	string	Resource pattern (see section 3.6)
`permission`	string	`read` or `write`
`condition`	string	Optional predicate expression (see section 6)
`effect`	string	`allow` or `deny`
`priority`	integer	Evaluation priority (higher value = evaluated first)
`enabled`	boolean	Whether the policy is active

5.2 Policy Rules

Implementations MUST enforce the following rules:

policies are scoped to a single information space
a user MUST have an authenticated context before policy evaluation
default effect is deny — access is granted only when an explicit allow policy matches
deny policies with equal or higher priority override allow policies
disabled policies MUST NOT be evaluated

5.3 Policy Inheritance

Policies do not inherit implicitly across scope levels. A collection-level read grant does not automatically grant column-level or row-level access unless the policy resource pattern covers those scopes.

However, broader grants apply to all operations within the scope:

Grant	Covers
`database.collection.orders` read	All records and all columns in `orders`
`database.collection.orders.column.total` read	Only the `total` column in `orders` records
`database.collection.orders.row` read + condition	Only records in `orders` matching the condition

6. Condition Expressions

6.1 Overview

Conditions restrict permissions to data that satisfies a predicate. They are required for row-level database access and file-level storage access. Conditions MAY also be used at collection or path prefix scope to limit broad grants.

6.2 Expression Language

Conditions are expressed as comparison and logical expressions evaluated against the operation context.

Available context variables:

Variable	Description
`user.id`	Authenticated user's UUIDv7 identifier
`user.user_id`	Authenticated user's cryptographic User ID
`user.device_node_id`	Current user device's node UUIDv7 identifier
`record.{field}`	Field value from the target database record
`file.path`	Logical path of the target file
`file.metadata.{field}`	Metadata field of the target file
`file.id`	UUIDv7 identifier of the target file

Supported operators:

Operator	Description
`==`, `!=`	Equality and inequality
`>`, `<`, `>=`, `<=`	Numeric and timestamp comparison
`in`	Membership in a list
`and`, `or`, `not`	Logical combination
`startsWith`, `endsWith`, `contains`	String matching

6.3 Examples

record.owner_id == user.id

record.department == "sales" and record.status != "archived"

file.path startsWith "/shared/" and file.metadata.owner_id == user.id

6.4 Evaluation Timing

Operation	When condition is evaluated
read	After retrieving candidate records or files — non-matching results are filtered out
write	Before applying the mutation — operation is rejected if the target does not match

For query operations, the Runtime SHOULD push applicable conditions to the storage engine when possible to avoid retrieving data the user is not authorized to access.

7. Database Access Control

7.1 Collection-Level Access

Collection-level policies control access to an entire table (collection).

resource:   database.collection.orders
permission: read
effect:     allow

Grants read access to all records and all columns in the orders collection.

resource:   database.collection.orders
permission: write
effect:     allow
condition:  record.department == "sales"

Grants write access only to records in orders where department equals "sales".

7.2 Column-Level Access

Column-level policies restrict access to specific fields within a collection.

resource:   database.collection.employees.column.salary
permission: read
effect:     allow
condition:  user.id == record.manager_id

Grants read access to the salary column only when the authenticated user is the record's manager.

When a user has collection-level read access but column-level deny (or no grant) for specific fields, the Runtime MUST omit or mask those columns in the response.

7.3 Row-Level Access

Row-level policies control access to individual records based on a condition.

resource:   database.collection.orders.row
permission: read
effect:     allow
condition:  record.customer_id == user.id

Grants read access only to orders records where customer_id matches the authenticated user.

resource:   database.collection.orders.row
permission: write
effect:     allow
condition:  record.owner_id == user.id and record.status == "draft"

Grants write access only to the user's own draft orders.

7.4 Query Filtering

For query operations, the Runtime MUST apply all applicable row-level and column-level policies:

resolve policies for the authenticated user and target collection
combine row-level conditions into a filter
execute the query with the combined filter
mask or omit columns not covered by column-level grants

Users MUST NOT receive records or column values they are not authorized to access, even if the query would otherwise return them.

7.5 Native Database Access

When applications use native database access, the Runtime MUST enforce the same access policies. Native queries are subject to row-level and column-level filtering equivalent to the standard API.

8. File Storage Access Control

8.1 Path Prefix Access

Path prefix policies control access to files under a logical path.

resource:   storage.path./documents/
permission: read
effect:     allow

Grants read access to all files under /documents/.

resource:   storage.path./team/sales/
permission: write
effect:     allow
condition:  file.metadata.owner_id == user.id

Grants write access to files under /team/sales/ only when the user owns the file.

8.2 Metadata Field Access

Metadata field policies restrict access to specific file metadata.

resource:   storage.metadata.owner_id
permission: read
effect:     allow

Grants read access to the owner_id metadata field on all files the user can otherwise access.

When a user lacks metadata field read access, the Runtime MUST omit that field from metadata responses.

8.3 File-Level Access

File-level policies control access to individual files based on a condition.

resource:   storage.file
permission: read
effect:     allow
condition:  file.metadata.shared == true or file.metadata.owner_id == user.id

Grants read access to files that are either shared or owned by the authenticated user.

resource:   storage.file
permission: write
effect:     allow
condition:  file.metadata.owner_id == user.id

Grants write access only to files owned by the authenticated user.

8.4 List Filtering

For list operations, the Runtime MUST apply file-level conditions and path prefix policies. Users MUST NOT see file objects in list results they are not authorized to access.

8.5 Native Filesystem Access

When applications use native filesystem access, the Runtime MUST enforce the same access policies. Filesystem operations are mapped to file objects and evaluated against path prefix and file-level policies before granting access to the underlying directory.

9. Policy Evaluation

9.1 Evaluation Order

The Runtime evaluates policies in the following order:

Application information space authorization — verify the application is authorized for the target information space (see Node Discovery)
User authentication — verify Ed25519 signature against the public key registry and establish authenticated user context (see Identity Model)
User approval status — verify the user has approved status in the information space (see section 11)
Policy resolution — collect all enabled policies for the user, groups the user belongs to (see Identity Model — Groups), and the target information space
Priority sorting — sort policies by priority descending
Scope matching — match policies to the requested resource and operation
Condition evaluation — evaluate conditions against the operation context
Effect resolution — apply allow or deny based on the highest-priority matching policy

9.2 Default Deny

If no matching allow policy is found, access MUST be denied. Implementations MUST NOT grant access by default.

9.3 Deny Overrides

An explicit deny policy with equal or higher priority than a matching allow policy MUST take precedence.

Example:

Priority	Resource	Permission	Effect
100	`database.collection.orders`	read	allow
200	`database.collection.orders.row`	read	deny, condition: `record.status == "classified"`

The user can read orders except classified records.

9.4 Column Masking

When a user has collection-level read access but lacks column-level read access for specific fields:

the Runtime MUST omit or null those fields in read responses
the Runtime MUST reject write operations that modify protected columns

9.5 Source-Side Authorization

Access control MUST be enforced on the source side for every operation that exposes data outside the Runtime process boundary on that node — including reads served to applications, HTTP API responses, and outbound replication payloads.

Operation path	Source node	Requirement
SDK / native access (local)	The Runtime hosting the application	Evaluate policies before read/write against the local replica
HTTP API (external client)	The Runtime serving the HTTP request	Evaluate policies on the server Runtime before constructing the response; client-side checks on the caller are not sufficient
Background replication (outbound)	The peer sending records or files in that exchange	Evaluate policies (and user-level filters, if applicable) before including objects in the replication payload
Background replication (inbound)	The receiving Runtime	MAY re-validate membership and policies; MUST NOT skip source-side checks on the sending peer

Rules:

Implementations MUST evaluate access policies on the source node before transmitting data to another node or external client.
Implementations MUST NOT assume that a replication request, sync session, or HTTP call is authorized because the requesting Runtime already performed a local check.
For user-level replication, the sending peer MUST filter records, columns, and files using the replication session's user context and access policies before transmission.
For node-level replication between approved peers, the sending node MUST still enforce application information space authorization and MUST NOT expose data from information spaces the receiving application or session is not authorized to access (see Node Discovery).
Local reads after replication are enforced on the receiving node as well; source-side and local enforcement are complementary, not alternatives.

A hostile or compromised client Runtime MUST NOT be able to obtain unauthorized data solely by issuing replication or HTTP requests. The source Runtime is the trust boundary for what may leave the node.

10. Information Space Scoping

Access policies are scoped to an information space via information_space_id. Policies in one information space MUST NOT affect data in another.

Before evaluating data access policies, the Runtime MUST verify:

the application is authorized for the target information space (see Node Discovery)
the user has approved status in the information space (see section 11)
the access policies belong to the same information space as the target data

11. User Registration and Administrator Approval

11.1 Node Trust vs User Authorization

Trust at the node level and authorization at the user level are separate concerns.

Level	What is trusted	Effect
Node	A node is approved for an information space (see Node Discovery)	The node participates in discovery and node-level background replication
User	A user is registered with a public key and approved in an information space (this section)	The user MAY authenticate and access shared data according to access policies

Node approval and user approval are independent. A user MAY register from a device whose node is still pending — neither gate implies the other.

Users MUST obtain administrator approval (status: approved) before the Runtime grants access to shared resources — regardless of whether their device node is approved for the information space.

11.2 User Record as Space Registration

User participation in an information space is represented by a user record with a registered public key. See the Identity Model for the complete user record structure.

Key fields for access control:

Field	Description
`id`	UUIDv7 user identifier — used as policy subject
`information_space_id`	Information space this user belongs to
`public_key`	Ed25519 public key — protocol identity, stored in the space registry
`user_id`	Cryptographic User ID derived from public key
`status`	`pending`, `approved`, or `rejected`
`approved_by`	UUIDv7 of the approving administrator (nullable)
`approved_at`	Time of approval (nullable)

Each user record belongs to exactly one information space. A person participating in multiple spaces has separate user records — each with its own key pair — in each space.

User records replicate across trusted nodes through node-level background synchronization. Private keys MUST NOT be included in user records.

11.3 Registration Lifecycle

Status	Description
`pending`	Public key registered; user cannot access shared data
`approved`	Administrator approved; access policies MAY grant data access
`rejected`	Request denied; access MUST NOT be granted

When a user registers in an information space, the application MUST create a user record with status: pending and the user's public_key.

Device authorization is tracked separately through user device records (see Identity Model). Each active device hosts its own local replica and runs user-level background replication independently.

Until status is approved, the Runtime MUST deny access to shared data — even if the device node is a trusted member of the space.

11.4 Administrator Approval

Administrator is not a platform-level role. Applications define which users MAY approve registration requests by granting them write access to user records and access policy records within the information space.

Approval is a two-step process:

Update user status — change status from pending to approved, set approved_by and approved_at
Grant access policies — create explicit allow policies for the user or assign the user to a group with applicable policies

Step 2 MAY be performed automatically when the user is approved — for example, by assigning a default role group.

Implementations MUST NOT grant shared data access to users with pending or rejected status, regardless of other policies.

11.5 Status Evaluation

Before evaluating access policies for an operation within an information space, the Runtime MUST:

verify the current node has an active user device record for the user (see Identity Model)
verify the user's Ed25519 signature against the registered public_key
verify the user record has status: approved for the target information space

If no user record exists, or status is pending or rejected, access MUST be denied.

11.6 Relationship to Access Policies

User approval status and access policies serve complementary roles:

Mechanism	Purpose
Status (`approved`)	Gate — user's public key is trusted in the information space
Access policies	Grant — user is permitted to read or write specific resources

A user with approved status but no matching allow policies MUST still be denied access (default deny).

A user with matching allow policies but pending or rejected status MUST be denied access — approval status takes precedence over policy grants.

The Runtime MUST enforce approval status independently of policy conditions.

11.7 User Record Replication

User records — including public keys and approval status — replicate across trusted nodes through node-level background replication. An administrator on any node with sufficient authorization MAY approve pending users; the approval propagates to all participating nodes.

Users authenticate locally on an active user device using their private key. The Runtime verifies the device is authorized and resolves the public key from the local replica of the information space registry.

11.8 Administrator Authorization

Applications define administrator capabilities through access policies. A typical configuration grants administrators:

Resource	Permission	Purpose
`database.collection.node_memberships`	write	Approve or reject node membership requests
`database.collection.users`	write	Approve or reject user registration, update public keys
`database.collection.access_policies`	write	Grant access policies to approved users

The initial administrator for an information space is established during space creation — typically by registering an approved user with write access on node membership, user, and policy collections.

12. Background Replication Authorization

All inter-node data synchronization is background replication initiated by the Runtime. Applications and users do not perform cross-node data operations — they read and write the local replica only. The Runtime propagates changes asynchronously according to the configured replication authorization context.

12.1 Authorization Contexts

Background replication operates in one of two contexts:

Level	Identity	Use case
Node-level	Node cryptographic identity	Full information space synchronization between trusted peers
User-level	User cryptographic identity	User-scoped background synchronization

12.2 Node-Level Background Replication

In node-level replication, nodes authenticate using their cryptographic identities. The Runtime treats the remote node as a trusted peer within the information space.

Both the local node and the remote node MUST have status: approved membership for the information space before node-level replication proceeds. See Node Discovery — Administrator Approval.

Node-level replication synchronizes all records and files belonging to the information space — subject to application information space configuration (see Node Discovery).

Node-level replication is used for:

background synchronization between server nodes
full information space convergence within a trusted network
replication engine synchronization via Messaging and RPC
replicating membership records, access policies, and other platform data

12.3 User-Level Background Replication

In user-level replication, the Runtime includes a user context in the background replication session — the user's UUIDv7 identifier, User ID, and public key reference.

The Runtime evaluates access policies for that user and synchronizes only the database records and files the user is authorized to access. Records and files that fail policy evaluation MUST NOT be replicated.

User-level replication is used for:

user devices that hold a local subset of shared data
background synchronization scoped to a specific user's access rights
minimizing replicated data on mobile and personal devices

User-level replication applies row-level conditions, column-level grants, path prefix policies, and file-level conditions when determining which objects to synchronize.

12.4 Replication Scope

Authorization context	Objects replicated
Node-level	All records and files in the information space
User-level	Only records and files matching the user's access policies

Implementations MUST:

perform all inter-node data synchronization as background replication
include the authorization context (node-level or user-level) in replication sessions
evaluate access policies on the sending peer before including records or files in outbound replication payloads
filter replication payloads by user access policies when user-level replication is used
NOT replicate records or files the user is not authorized to read under user-level replication
NOT expose cross-node data operation APIs to applications

Each replica enforces access control locally on every user operation and on every outbound transmission. Background replication brings data to the local replica; the source node decides what may be sent; the receiving node enforces what the user MAY read or write once data is local.

12.5 Replication Mode Selection

The node operator configures which replication mode applies:

Deployment	Typical mode	Rationale
Server / always-on node	Node-level	Maintains a complete replica of the information space
User device (phone, laptop)	User-level	Replicates only data the user is authorized to access

A single node MAY run both modes simultaneously — node-level replication for platform data and user-level replication sessions for each registered user on the device.

12.6 Future: Partial and Lazy Synchronization

Flexible full synchronization (lazy loading, paginated snapshots, metadata-first replication) is planned for future protocol versions. See Distributed Database — section 9.4 and Distributed File Storage — section 9.4.

Authorization rules apply unchanged:

every snapshot page and on-demand fetch MUST be authorized on the source node (section 9.5)
user-level replication MUST NOT fetch or send deferred payloads the user is not authorized to read
metadata-first replication MUST NOT expose column values or file content in headers that the subject is not allowed to read under column-level or file-level policies

Partial local replicas are not a bypass for access control — they reduce bandwidth and storage, not trust boundaries.

13. Security Requirements

Implementations MUST:

evaluate access policies before every database and file storage operation
evaluate access policies on the source node before HTTP API responses and outbound replication payloads (section 9.5)
associate every operation with an authenticated user context
enforce default deny when no matching allow policy exists
apply row-level conditions to query and list operations
mask or omit unauthorized columns and metadata fields
scope all policies to a single information space
replicate access policy records across participating nodes
enforce policies identically across SDK, HTTP API, and native access modes
verify user Ed25519 signatures against the information space public key registry
verify user approval status before granting access to shared data
replicate user records (public keys and status) across participating nodes
deny access to users with pending or rejected status regardless of access policies
filter replication payloads by user access policies when user-level background replication is used
perform inter-node data synchronization exclusively as background replication
distinguish node-level and user-level authorization context in replication sessions

Implementations MUST NOT:

grant shared data access without verified user signature
grant shared data access to users without approved status
grant access without policy evaluation
rely on the requesting client Runtime as the sole authorization boundary for data served over HTTP API or replication
transmit records, files, or column values in replication or API responses without source-side policy evaluation
bypass access control for replicated data on receiving nodes
expose cross-node data operation APIs to applications
replicate records or files the user is not authorized to access under user-level replication
expose records, columns, or files that fail condition evaluation
allow applications to modify access policy records without authorization
apply policies across information space boundaries

14. Examples

14.1 Collection Read Grant

Policy:
  subject_type: user
  subject_id:   0195a3f0-809a-7895-bcde-f01234567890
  resource:     database.collection.products
  permission:   read
  effect:       allow

Request:
  user:       0195a3f0-809a-7895-bcde-f01234567890
  operation:  query({ collection: "products" })

Result: All products returned

14.2 Group Read Grant

Group record (see Identity Model — Groups):
  id:           0195a3f0-8150-7897-dabc-000000000005
  display_name: Support Team
  enabled:      true

Group membership:
  group_id: 0195a3f0-8150-7897-dabc-000000000005
  user_id:  0195a3f0-809a-7895-bcde-f01234567890   (Alice, status: approved)

Policy:
  subject_type: group
  subject_id:   0195a3f0-8150-7897-dabc-000000000005
  resource:     database.collection.tickets
  permission:   read
  effect:       allow

Request (Alice, signed, status: approved):
  user:       0195a3f0-809a-7895-bcde-f01234567890
  operation:  query({ collection: "tickets" })

Result: Allowed — policy resolved via group membership

Request (Bob, signed, status: approved, not in group):
  user:       0195a3f0-8200-7892-cdef-000000000003
  operation:  query({ collection: "tickets" })

Result: Denied — no matching user or group policy

Request (Alice, signed, status: pending — still in group):
  user:       0195a3f0-809a-7895-bcde-f01234567890
  operation:  query({ collection: "tickets" })

Result: Denied — user approval status checked before group policies apply

14.3 Row-Level Read Filter

Policy:
  subject_type: user
  subject_id:   0195a3f0-809a-7895-bcde-f01234567890
  resource:     database.collection.orders.row
  permission:   read
  effect:       allow
  condition:    record.customer_id == user.id

Request:
  user:       0195a3f0-809a-7895-bcde-f01234567890
  operation:  query({ collection: "orders" })

Result: Only orders where customer_id matches the user

14.4 Column-Level Masking

Policy (allow):
  resource:   database.collection.employees
  permission: read
  effect:     allow

Policy (allow):
  resource:   database.collection.employees.column.name
  permission: read
  effect:     allow

Policy (allow):
  resource:   database.collection.employees.column.department
  permission: read
  effect:     allow

(No grant for column "salary")

Request:
  operation:  query({ collection: "employees" })

Result: Records returned with name and department only; salary omitted

14.5 Conditional Write

Policy:
  resource:     database.collection.orders.row
  permission:   write
  effect:       allow
  condition:    record.owner_id == user.id and record.status == "draft"

Request:
  user:       0195a3f0-809a-7895-bcde-f01234567890
  operation:  update({ id: "...", data: { status: "submitted" } })
  record:     { owner_id: "0195a3f0-809a-7895-bcde-f01234567890", status: "draft" }

Result: Allowed

Request:
  record:     { owner_id: "0195a3f0-809a-7895-bcde-f01234567890", status: "submitted" }

Result: Denied — status is not "draft"

14.6 File Path Access

Policy:
  resource:   storage.path./shared/documents/
  permission: read
  effect:     allow

Request:
  operation:  read({ path: "/shared/documents/report.pdf" })

Result: Allowed

Request:
  operation:  read({ path: "/private/documents/report.pdf" })

Result: Denied — path not covered

14.7 Deny Override

Policy (priority 100):
  resource:   database.collection.reports
  permission: read
  effect:     allow

Policy (priority 200):
  resource:   database.collection.reports.row
  permission: read
  effect:     deny
  condition:  record.classification == "confidential"

Request:
  operation:  query({ collection: "reports" })

Result: All reports except those with classification "confidential"

14.8 User-Level Background Replication

Replication mode: user-level (background)
User:             0195a3f0-809a-7895-bcde-f01234567890

Policy:
  resource:   database.collection.orders.row
  permission: read
  effect:     allow
  condition:  record.customer_id == user.id

Remote node holds 100 order records. User is authorized for 12 records.

Background replication session:
  mode: user-level
  user: 0195a3f0-809a-7895-bcde-f01234567890

Result: Runtime replicates only the 12 authorized order records to the local replica.
         User reads orders through the local database API — no cross-node request.

14.9 Administrator Approval

User registers in Project Alpha:

User record:
  id:                   0195a3f0-809a-7895-bcde-f01234567890
  information_space_id: 0195a3f0-8000-7890-abcd-000000000001
  public_key:           7c2d...4f8a
  status:               pending

User device (phone):
  node_id:              0195a3f0-7f78-7894-abcd-ef0123456789
  status:               active

Request (signed with user private key):
  user:       0195a3f0-809a-7895-bcde-f01234567890
  operation:  query({ collection: "orders" })

Result: Denied — status not approved

Administrator approves:
  status:      approved
  approved_by: 0195a3f0-8100-7891-bcde-000000000010
  approved_at: 1718000000000

Policy granted:
  subject_id: 0195a3f0-809a-7895-bcde-f01234567890
  resource:   database.collection.orders.row
  permission: read
  effect:     allow
  condition:  record.customer_id == user.id

Request (same user, signed):

Result: Allowed — signature verified, status approved, policy matches

Abstract​

1. Scope​

2. Motivation​

3. Concepts​

3.1 Access Policy​

3.2 Subject​

3.3 Resource​

3.4 Permission​

3.5 Condition​

3.6 Scope Levels​

3.7 Replication Authorization Context​

3.8 Source-Side Authorization​

3.9 User Registration Status​

4. Relationship to Identity Model​

5. Policy Model​

5.1 Policy Record​

5.2 Policy Rules​

5.3 Policy Inheritance​

6. Condition Expressions​

6.1 Overview​

6.2 Expression Language​

6.3 Examples​

6.4 Evaluation Timing​

7. Database Access Control​

7.1 Collection-Level Access​

7.2 Column-Level Access​

7.3 Row-Level Access​

7.4 Query Filtering​

7.5 Native Database Access​

8. File Storage Access Control​

8.1 Path Prefix Access​

8.2 Metadata Field Access​

8.3 File-Level Access​

8.4 List Filtering​

8.5 Native Filesystem Access​

9. Policy Evaluation​

9.1 Evaluation Order​

9.2 Default Deny​

9.3 Deny Overrides​

9.4 Column Masking​

9.5 Source-Side Authorization​

10. Information Space Scoping​

11. User Registration and Administrator Approval​

11.1 Node Trust vs User Authorization​

11.2 User Record as Space Registration​

11.3 Registration Lifecycle​

11.4 Administrator Approval​

11.5 Status Evaluation​

11.6 Relationship to Access Policies​

11.7 User Record Replication​

11.8 Administrator Authorization​

12. Background Replication Authorization​

12.1 Authorization Contexts​

12.2 Node-Level Background Replication​

12.3 User-Level Background Replication​

12.4 Replication Scope​

12.5 Replication Mode Selection​

12.6 Future: Partial and Lazy Synchronization​

13. Security Requirements​

14. Examples​

14.1 Collection Read Grant​

14.2 Group Read Grant​

14.3 Row-Level Read Filter​

14.4 Column-Level Masking​

14.5 Conditional Write​

14.6 File Path Access​

14.7 Deny Override​

14.8 User-Level Background Replication​

14.9 Administrator Approval​

15. References​