Identity Model

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 Identity Model — the protocol-level mechanisms for identifying, authenticating, and authorizing participants in the Faberio platform.

The identity model covers two participant types, both using cryptographic key pairs:

• Nodes — infrastructure participants that host the Runtime and replicate data; a node may run on a participant's personal device (smartphone, tablet, laptop, personal computer) or on an always-on server operated by a user or independent operator
• Users — human or application participants registered within an information space

Nodes and users authenticate independently using Ed25519 signatures. Public keys for both participant types are stored in the information space and used for verification. A user MAY operate from multiple devices simultaneously — each registered as a user device with its own local replica.

This specification complements the Object Identifier specification. UUIDv7 identifies objects in the database. The identity model defines how participants authenticate and exercise access rights at the protocol level.

---

1. Scope

This specification defines:

• node cryptographic identity
• user cryptographic identity within an information space
• groups — named collections of users for access policy assignment
• information space public key registry
• user device registration and multi-device enrollment
• authentication at the protocol level
• data access control integration (see Data Access Control)

This specification does not define:

• object identifiers (see Object Identifier)
• application-level role systems
• certificate authority infrastructure
• private key recovery mechanisms
• specific transport or serialization implementations

---

2. Motivation

Distributed systems cannot rely on centralized identity providers. Every participant must be able to prove its identity and exercise access rights without a central authority.

Faberio addresses this with symmetric cryptographic identity for both participant types:

Participant / entity	Scope	Database object	Protocol identity
Node	Infrastructure	UUIDv7 node record	Ed25519 key pair
User	Information space	UUIDv7 user record	Ed25519 key pair
Group	Information space	UUIDv7 group record	None — referenced by access policies only

Nodes authenticate using cryptographic proofs for node-level background replication and peer communication. Users authenticate using cryptographic proofs for local operations and user-level background replication. Public keys for both are registered in the information space and replicated across participating nodes.

The user device — typically the user's phone, laptop, or a dedicated server — stores the user's private key and local replica. Multiple devices MAY be active simultaneously. Identity is established by the user's key pair registered in the information space — not by any single device.

---

3. Identity Architecture

Both nodes and users prove identity through signatures verified against public keys stored in the information space. Each user device holds the user's private key and performs signing after local unlock.

---

4. Node Identity

4.1 Overview

Every Faberio node possesses a globally unique cryptographic identity. Faberio identifies nodes using asymmetric cryptography rather than IP addresses, hostnames, or centralized identity providers.

Node identity enables:

• peer authentication
• encrypted communication
• digital signatures
• trust establishment
• secure service discovery (see Node Discovery)
• node-level background replication

4.2 Key Pair

Every node MUST possess exactly one active key pair consisting of:

Component	Description
Private key	Secret key used for signing and decryption. MUST never leave the node.
Public key	Public key used for verification and encryption. Stored in the node record.

Implementations MUST use Ed25519 as the signing algorithm.

The private key MUST be stored in a secure location accessible only to the Runtime. Implementations MUST NOT transmit private keys over the network.

4.3 Node ID

The Node ID is a stable identifier derived from the node's public key.

Implementations MUST derive the Node ID as follows:

1. Serialize the public key in its canonical binary form
2. Compute SHA-256 of the serialized public key
3. Encode the first 16 bytes of the digest as a lowercase hexadecimal string (32 characters)

The Node ID is used in protocol messages, discovery records, and authentication handshakes. It is independent of the node's UUIDv7 database record identifier.

4.4 Node Record

Each node is stored as a database object with a UUIDv7 identifier.

Field	Description
id	UUIDv7 object identifier
display_name	Human-readable name of the node
node_id	Cryptographic Node ID derived from public key
public_key	Ed25519 public key

The UUIDv7 id is the primary key for storage and replication. The node_id is the protocol-level identifier used for authentication and communication.

4.5 Key Rotation

Nodes MUST support key rotation without changing the node's UUIDv7 record.

When a key pair is rotated:

1. A new key pair is generated
2. The new public key replaces the previous value in the node record
3. The Node ID changes to reflect the new public key
4. The UUIDv7 record identifier remains unchanged

Implementations SHOULD provide a transition period during which the previous public key is still accepted for verification.

4.6 Node Authentication

A node proves its identity by signing protocol messages with its private key.

Receiving nodes MUST verify signatures using the sender's public key from the node record before processing authenticated messages.

Node authentication is required for:

• node-level background replication (see Messaging and RPC)
• messaging between nodes
• peer discovery and connectivity handshakes

---

5. User Identity

5.1 Overview

A user is a participant that interacts with applications within an information space. Like nodes, users possess cryptographic key pairs at the platform level.

User identity is scoped to an information space. A physical person participating in three information spaces has three separate user records — each with its own key pair, UUIDv7 identifier, and approval status. Information spaces remain independent trust boundaries.

Users do not authenticate through a managing node. They prove identity by signing with their private key; the Runtime verifies signatures against the user's public key registered in the information space.

5.2 User Record

Each user is stored as a database object within an information space.

Field	Description
id	UUIDv7 object identifier
information_space_id	UUIDv7 of the information space this user belongs to
display_name	Human-readable name of the user
user_id	Cryptographic User ID derived from public key
public_key	Ed25519 public key — primary user identity
status	pending, approved, or rejected (see Data Access Control)
requested_at	Time the user requested participation (Unix milliseconds)
approved_by	UUIDv7 of the approving administrator user (nullable)
approved_at	Time of approval (Unix milliseconds, nullable)

The public_key is the user's protocol identity within the information space. The UUIDv7 id is the primary key for storage, replication, and access policy references.

Which nodes the user operates from is defined by user device records (see section 5.4) — not by the user record itself.

User records replicate across participating nodes through node-level background synchronization. Private keys MUST NOT be stored in user records or replicated.

5.3 User ID

The User ID is derived from the user's public key using the same algorithm as the Node ID (see section 4.3).

The User ID is used in protocol messages and authentication contexts. It is independent of the user's UUIDv7 database record identifier.

5.4 User Devices

A user MAY operate from multiple nodes simultaneously — for example, a phone and a laptop. Each node is registered as a user device.

A user device record links a user to an authorized node:

Field	Description
id	UUIDv7 object identifier
user_id	UUIDv7 of the user record
information_space_id	UUIDv7 of the information space
node_id	UUIDv7 of the node (device) authorized for this user
status	active or revoked
enrolled_at	Time the device was authorized (Unix milliseconds)
enrolled_by_device_id	UUIDv7 of the user device that authorized enrollment (nullable — null for the first device)

Each active user device:

• stores the user's private key in a secure location on that node
• hosts an independent local replica synchronized through user-level background replication
• signs operations locally after the user unlocks the private key on that device
• operates concurrently with other active devices — changes converge through replication

There is no single home node limit. A user MAY have any number of active devices, subject to application policy.

5.4.1 First Device Enrollment

When a user registers, the first device:

1. generates the user's Ed25519 key pair
2. creates the user record with public_key and status: pending
3. creates a user device record linking the user to the current node with status: active
4. stores the private key locally

5.4.2 Additional Device Enrollment

To add a second (or subsequent) device while continuing to use existing devices:

1. the user authenticates on an existing active device
2. the existing device generates an enrollment authorization — signed by the user's private key, containing the new node's identity
3. the new device receives the authorization through a secure channel (QR code, one-time link, physical proximity — application-specific)
4. the new device creates a user device record with status: active and enrolled_by_device_id referencing the authorizing device
5. the private key is transferred to the new device through the secure enrollment channel — encrypted, never stored in replicated records

The new device begins user-level background replication independently. Both devices operate simultaneously.

5.4.3 Device Revocation

When a device is lost or decommissioned:

1. the user revokes the device from any remaining active device
2. the user device record is updated to status: revoked
3. the Runtime on revoked devices MUST reject further operations for that user
4. the user SHOULD rotate their key pair if the private key may have been compromised

User device records replicate across the information space through node-level background synchronization.

5.5 User Key Pair

Every user MUST possess exactly one active key pair per information space:

Component	Description
Private key	Stored on each active user device. MUST never be transmitted except during encrypted device enrollment.
Public key	Stored in the user record within the information space. Replicated to all participating nodes.

The same private key MAY exist on multiple active devices. All devices sign with the same key; the Runtime verifies against the single registered public_key.

Implementations MUST use Ed25519 as the signing algorithm.

When a user participates in multiple information spaces, each user record has a separate key pair. Keys MUST NOT be shared across information space boundaries.

5.6 User Authentication

A user proves identity by signing messages with their private key on an active user device. The Runtime verifies signatures using the user's public_key from the information space user record.

Authentication flow:

1. the user unlocks their private key on the current device (application-specific)
2. the Runtime verifies the current node has an active user device record for this user
3. the Runtime signs the operation or session context with the user's private key
4. the Runtime verifies the signature against the registered public key
5. the Runtime checks status: approved before granting access to shared data

User authentication is required for:

• local database and file storage operations
• user-level background replication sessions
• any operation where the Runtime acts on behalf of a specific user

5.7 User Key Rotation

Users MUST support key rotation without changing the user's UUIDv7 record.

When a key pair is rotated:

1. a new key pair is generated on an active user device
2. the new public key replaces the previous value in the user record
3. the User ID changes to reflect the new public key
4. the UUIDv7 record identifier remains unchanged
5. the new private key MUST be re-provisioned to all active user devices through the enrollment process

Key rotation MUST require approval from an administrator or verification through a defined recovery process defined by the application.

5.8 Groups

A group is a named collection of users within an information space. Operators use groups to assign access policies to multiple users at once. Groups are not cryptographic participants — they have no key pair and do not authenticate independently.

5.8.1 Group Record

Each group is stored as a database object within an information space.

Field	Description
id	UUIDv7 object identifier — used as subject_id when subject_type is group in access policies
information_space_id	UUIDv7 of the information space this group belongs to
display_name	Human-readable group name
description	Optional operator description
enabled	Whether the group is active for policy resolution (true or false)

Group records replicate across participating nodes through node-level background synchronization. Implementations MUST NOT store user private keys or node private keys in group records.

5.8.2 Group Membership

Membership links users to groups through separate group membership records:

Field	Description
id	UUIDv7 object identifier
information_space_id	UUIDv7 of the information space
group_id	UUIDv7 of the group record
user_id	UUIDv7 of the user record
added_at	Time membership was granted (Unix milliseconds)
added_by	UUIDv7 of the administrator user who added the member (nullable)

A user MAY belong to multiple groups within the same information space. A group MAY contain any number of users with status: approved in that space.

When resolving access for an authenticated user, the Runtime MUST collect policies where:

• subject_type is user and subject_id matches the user's UUIDv7 identifier, or
• subject_type is group, subject_id matches a group the user belongs to, and that group has enabled: true

Disabled groups (enabled: false) MUST NOT contribute policies during evaluation.

5.8.3 Group Management

Operators with sufficient privileges MAY:

1. create, rename, or disable groups
2. add or remove group members by creating or deleting membership records
3. attach access policies to a group (subject_type: group, subject_id = group UUIDv7)

User approval status is evaluated per user, not per group. A user with status: pending or rejected MUST NOT receive access through group membership until status: approved, even if the group carries allow policies.

The reference MVP MAY implement direct user policies only; group records remain part of the protocol model for operators who prefer role-based assignment.

---

6. Information Space Public Key Registry

Each information space maintains a public key registry — the collection of node and user records with their public keys within that space.

Record type	Public key purpose
Node record	Verify node-level background replication and peer authentication
User record	Verify user authentication and user-level background replication
User device record	Authorize a specific node to operate on behalf of the user
Group record	No public key — resolves group-scoped access policies (see section 5.8)
Group membership record	Links users to groups for policy resolution

When the Runtime receives a signed message, it:

1. identifies the participant type (node or user)
2. resolves the public key from the information space registry
3. verifies the Ed25519 signature
4. applies access control based on the authenticated participant

The public key registry replicates across trusted nodes through node-level background synchronization. Trust in a public key is established through:

• Nodes — administrator approval of information space membership (see Node Discovery)
• Users — administrator approval (status: approved) and access policies (see Data Access Control)

---

7. Data Access Control

Access rights are evaluated using the authenticated user's UUIDv7 identifier and their public key within the information space. The Data Access Control specification defines how policies grant read and write access to database collections, columns, rows, and files.

7.1 Principle

When a user requests access to data, the Runtime evaluates the request using:

1. the authenticated user's UUIDv7 identifier and verified signature
2. the user's status in the information space
3. the access policies defined in the Data Access Control specification

7.2 Access Evaluation

7.3 Policy Enforcement

Access control policies are defined within the information space and enforced locally on every node. Policy structure, scope levels, and evaluation rules are defined in the Data Access Control specification.

7.4 Background Replication Authorization

All inter-node data synchronization is performed as background replication by the Runtime. Applications do not initiate cross-node data operations — users read and write the local replica on their current device.

Background replication operates in one of two authorization contexts:

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

See the Data Access Control specification for replication authorization contexts and policy filtering rules.

---

8. Relationship to Object Identifiers

Faberio uses two identification layers that MUST NOT be conflated:

Layer	Applies to	Identifier	Used for
Object identifier	All database objects	UUIDv7	Storage, replication, referencing
Identity model	Nodes and users	Key pair (Node ID / User ID)	Authentication, signatures

Examples:

Entity	UUIDv7 (object)	Identity model (protocol)
Node	0195a3f0-7f78-7894-abcd-ef0123456789	Node ID a3f8c2e17b4d9a0e5f1c8b2d6e4a7f90
User	0195a3f0-809a-7895-bcde-f01234567890	User ID b4e9d3f28c5e0b1f6g2d9c3e7f5b8a01
Group	0195a3f0-8150-7897-dabc-000000000005	Access policy subject (subject_type: group)
Data record	0195a3f0-812c-7896-cdef-012345678901	Access policy (via user or group UUIDv7)

---

9. Security Requirements

Implementations MUST:

• generate key pairs using a cryptographically secure random number generator
• protect private keys from unauthorized access on user devices and infrastructure nodes
• verify Ed25519 signatures on all authenticated protocol messages
• reject messages with invalid or missing signatures
• resolve public keys from the information space registry before verification
• enforce access control before granting access to replicated data
• associate every data access request with a cryptographically authenticated user context
• store user private keys only on active user devices — never in replicated records
• verify the current node has an active user device record before user authentication

Implementations MUST NOT:

• transmit private keys over the network
• replicate user private keys across nodes
• accept identity claims without public key signature verification
• bypass access control evaluation for replicated data
• share user key pairs across information space boundaries
• grant shared data access to users with pending or rejected status

---

10. Examples

10.1 Node Registration

1. Runtime generates Ed25519 key pair
2. Node ID derived from public key
3. UUIDv7 assigned to node record
4. Node record stored:

   id:           0195a3f0-7f78-7894-abcd-ef0123456789
   display_name: Home Server
   node_id:      a3f8c2e17b4d9a0e5f1c8b2d6e4a7f90
   public_key:   3a7f...e2b1

10.2 User Registration (First Device)

1. User generates Ed25519 key pair on phone (first device)
2. User ID derived from public key
3. UUIDv7 assigned to user record
4. User record stored in information space:

   id:                   0195a3f0-809a-7895-bcde-f01234567890
   information_space_id: 0195a3f0-8000-7890-abcd-000000000001
   display_name:         Alice
   user_id:              b4e9d3f28c5e0b1f6g2d9c3e7f5b8a01
   public_key:           7c2d...4f8a
   status:               pending

5. User device record created:

   user_id:              0195a3f0-809a-7895-bcde-f01234567890
   node_id:              0195a3f0-7f78-7894-abcd-ef0123456789  (phone)
   status:               active
   enrolled_by_device_id: null

10.3 Second Device Enrollment

1. Alice authenticates on phone
2. Phone generates enrollment authorization (signed by Alice's private key)
3. Alice scans QR code on laptop with authorization
4. Laptop creates user device record:

   user_id:              0195a3f0-809a-7895-bcde-f01234567890
   node_id:              0195a3f0-8200-7892-cdef-000000000003  (laptop)
   status:               active
   enrolled_by_device_id: 0195a3f0-8300-7893-def0-000000000004  (phone device)

5. Private key provisioned to laptop via encrypted enrollment channel
6. Both phone and laptop run user-level background replication independently

10.4 Administrator Approval

Administrator updates user record:

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

Access policies granted for user 0195a3f0-809a-7895-bcde-f01234567890

10.5 Authenticated Data Access

User:              0195a3f0-809a-7895-bcde-f01234567890
User public key:   7c2d...4f8a (from information space registry)
Current device:    0195a3f0-8200-7892-cdef-000000000003  (laptop)
Data record:       0195a3f0-812c-7896-cdef-012345678901

1. User unlocks private key on laptop
2. Runtime verifies laptop has active user device record
3. Runtime signs operation with user private key
4. Runtime verifies signature against registered public key
5. Runtime checks status: approved
6. Runtime evaluates access policy → access granted

10.6 Group Policy Assignment

1. Operator creates group record:

   id:                   0195a3f0-8150-7897-dabc-000000000005
   information_space_id: 0195a3f0-8000-7890-abcd-000000000001
   display_name:         Support Team
   enabled:              true

2. Operator adds Alice to the group (membership record):

   group_id:  0195a3f0-8150-7897-dabc-000000000005
   user_id:   0195a3f0-809a-7895-bcde-f01234567890

3. Access policy targets the group:

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

4. When Alice (approved user) requests tickets, Runtime resolves policies
   for her user id AND for group 0195a3f0-8150-7897-dabc-000000000005

See Data Access Control — Group Read Grant for evaluation outcomes.

---

11. References

• Object Identifier
• Data Access Control
• Node Discovery
• RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA)
• RFC 9562 — Universally Unique Identifiers (UUIDs)