swactor/DATASTORE_AUTH.md

# Swactor Datastore Auth Specification

**Version:** 0.1.0 (MVP)
**Status:** Draft
**Companion to:** `DATASTORE_PROTOCOL.md`

## 1. Overview

This document specifies the authorization layer for the Swactor Datastore. It defines how access is controlled for external clients connecting to a datastore node.

### Principles

- **Cryptographic identity** — keys, not passwords. Every participant is identified by an ed25519 public key (`NodeId`).
- **Binary access** — a client is either authorized or not. No permission tiers for MVP.
- **Owner-only administration** — only the datastore owner can grant or revoke access.
- **Transport-layer authentication** — iroh's QUIC handshake cryptographically proves a peer's `NodeId`. This spec builds authorization on top of that.

### Non-Goals (MVP)

- Per-path permission scoping.
- Permission tiers (read-only, read-write, admin).
- Capability tokens or time-limited delegated access.
- Multi-level delegation chains.

## 2. Trust Boundaries

```
┌─────────────────────────────────────────────┐
│             Cluster (SWIM mesh)              │
│                                              │
│  Node A ◄──────────────► Node B             │
│           implicitly trusted                 │
│           (no auth checks)                   │
└──────────────────┬──────────────────────────┘
                   │
                   │  auth boundary
                   │
        ┌──────────▼──────────┐
        │   External Clients  │
        │                     │
        │  CLI tool           │
        │  Browser user       │
        └─────────────────────┘
```

- **Cluster-internal** (node-to-node via SWIM): implicitly trusted. Nodes that are members of the SWIM cluster communicate freely — no per-request auth checks.
- **External clients** (CLI, browser): must be authorized. Every external request is checked against the Access Control List before being dispatched to the actor system.

## 3. Identity Model

The auth layer reuses the existing ed25519 identity model from the distribution layer:

- Every client (CLI tool, browser user, node) has an ed25519 keypair.
- Identity is the 32-byte public key, represented as `NodeId`.
- The same `NodeId` type from `distribution::types` is used throughout.

There is no separate "user" concept — a keypair *is* an identity.

## 4. Access Control List

### 4.1 Structure

```
AccessControlList {
    owner:           NodeId,              // The datastore owner's public key
    authorized_keys: Set<NodeId>,         // Explicitly authorized client keys
}
```

- The **owner** always has full access (implicit; never needs to be in `authorized_keys`).
- An empty `authorized_keys` set means only the owner can access the datastore.

### 4.2 Persistence

The ACL is persisted as a JSON file alongside the datastore's `storage_path`:

```
{storage_path}/
├── chunks/
├── manifests/
└── acl.json              # AccessControlList
```

### 4.3 Mutations

| Operation | Signature | Who |
|-----------|-----------|-----|
| Grant access | `grant(key: NodeId)` | Owner only |
| Revoke access | `revoke(key: NodeId)` | Owner only |

- `grant` adds a `NodeId` to `authorized_keys`. Idempotent — granting an already-authorized key is a no-op.
- `revoke` removes a `NodeId` from `authorized_keys`. Idempotent — revoking a non-existent key is a no-op.
- Revoking the owner is a no-op (the owner's implicit access cannot be removed).
- Both operations persist the updated ACL to disk immediately.

## 5. Auth Path 1 — Direct iroh Connection

For clients that connect directly to the datastore node over iroh (QUIC):

```
Client (ed25519 keypair)              Datastore Node
        │                                    │
        │──── iroh QUIC handshake ──────────>│
        │     (proves client's NodeId)       │
        │                                    │
        │                              check NodeId
        │                              against ACL
        │                                    │
        │<─── accept / reject ──────────────│
        │                                    │
        │     (if accepted, all ops on       │
        │      this connection are allowed)  │
```

1. The iroh QUIC handshake cryptographically proves the peer's `NodeId` (ed25519 public key).
2. On connection establishment, the node checks the peer's `NodeId` against the ACL.
3. If authorized → connection accepted. All operations on that connection are allowed with no per-message overhead.
4. If not authorized → connection rejected immediately.

This is the preferred auth path — zero overhead after the initial handshake.

## 6. Auth Path 2 — Signed Requests (Browser Relay)

For browser users who cannot establish direct iroh connections (e.g., because the browser communicates via a website backend that relays requests):

### 6.1 Threat Model

The website backend acts as an **untrusted relay**. It forwards requests between the browser and the datastore node but never sees private keys. The relay cannot forge, modify, or replay requests.

### 6.2 Signed Envelope

Each request is wrapped in a signed envelope:

```
SignedRequest {
    payload:    SignedRequestPayload,    // The request details
    public_key: NodeId,                 // Client's public key
    signature:  Signature,              // ed25519 signature over serialized payload
}

SignedRequestPayload {
    action:    DatastoreAction,         // What the client wants to do
    timestamp: u64,                     // Unix timestamp (seconds)
    nonce:     [u8; 16],                // 16 random bytes
}

DatastoreAction = enum {
    Put { name, content_hash, size_bytes, tags },
    Get { content_hash },
    Delete { content_hash },
    List { name_filter },
}
```

### 6.3 Verification Steps

The datastore node verifies a signed request in strict order:

1. **Signature validity** — verify the ed25519 signature over the canonical serialization of `SignedRequestPayload` using the provided `public_key`.
2. **Timestamp freshness** — reject if `|now - payload.timestamp| > 300` seconds.
3. **Nonce uniqueness** — reject if `payload.nonce` has been seen before within the time window.
4. **ACL check** — reject if `public_key` is not in the ACL.

If any step fails, the request is denied with the corresponding `DeniedReason`.

### 6.4 Put Payload Note

`DatastoreAction::Put` references a `content_hash` rather than embedding raw file data. The bulk data is uploaded separately, and its integrity is guaranteed by blake3 content addressing. The signed envelope authorizes the *operation*, not the data transfer.

## 7. Replay Protection

### 7.1 Timestamp Window

- Requests must have a `timestamp` within ±300 seconds of the node's wall clock.
- This bounds the maximum clock drift between client and server.
- Requests outside this window are rejected with `DeniedReason::RequestExpired`.

### 7.2 Nonce

- Each request includes a 16-byte random nonce.
- The node maintains a set of recently seen nonces.
- Duplicate nonces within the time window are rejected with `DeniedReason::ReplayDetected`.

### 7.3 Nonce Garbage Collection

- Nonces are stored alongside their timestamps.
- When a nonce's timestamp falls outside the ±300 second window, it is eligible for GC.
- GC runs periodically (piggy-backed on request processing or a background sweep).

## 8. Enforcement Point

Auth is enforced at the **edge** of the actor system — between external clients and the internal actors:

```
External Client
      │
      ▼
┌─────────────┐
│  Auth Gate   │◄── ACL check happens here
└──────┬──────┘
       │
       ▼
┌──────────────┐    ┌─────────────────┐    ┌────────────────┐
│ MetadataActor│◄──►│ BlobStoreActor  │    │ TransferActor  │
│              │    │                 │    │                │
│  (auth-      │    │  (auth-         │    │  (auth-        │
│   unaware)   │    │   unaware)      │    │   unaware)     │
└──────────────┘    └─────────────────┘    └────────────────┘
```

### 8.1 Direct iroh Connections

- Auth check at connection acceptance time.
- Once accepted, the connection is fully trusted for all operations.
- No per-message overhead.

### 8.2 Signed Requests (Browser Relay)

- A `GatewayActor` receives signed request envelopes.
- The GatewayActor verifies the envelope (signature, timestamp, nonce, ACL).
- If valid, the GatewayActor dispatches the inner action to the `MetadataActor`.
- If invalid, the GatewayActor returns the denial reason to the relay.

### 8.3 Internal Actors

`MetadataActor`, `BlobStoreActor`, and `TransferActor` remain **auth-unaware**. They process messages from any source within the actor system. The auth boundary is strictly external.

## 9. Key Management

### 9.1 Key Generation

- Uses `ed25519_dalek` keypairs (same as node identity).
- CLI: `swactor-store auth keygen` generates a new keypair and prints both the secret key (for the client to store) and the public key (to share with the owner).
- Browser: keypair generated client-side using WebCrypto Ed25519 or wasm-compiled ed25519. The private key never leaves the browser.

### 9.2 Grant Flow

```
1. Client generates an ed25519 keypair.
2. Client shares their public key with the datastore owner (out-of-band).
3. Owner runs: swactor-store auth grant <pubkey>
4. Client can now access the datastore.
```

The out-of-band exchange is intentional — it keeps the trust model simple. The owner explicitly decides who gets access.

### 9.3 Revocation

```
1. Owner runs: swactor-store auth revoke <pubkey>
2. Client's access is immediately revoked.
3. Existing direct iroh connections from that client remain open until disconnected.
4. Signed requests from the revoked key are rejected immediately.
```

Note: revoking a key does not forcibly disconnect an active iroh session. The revocation takes effect on the next connection attempt. For immediate disconnection, the owner should also restart the node or implement connection tracking (future extension).

## 10. CLI Extensions

The following subcommands are added under `swactor-store auth`:

```
swactor-store auth keygen
    Generate a new ed25519 keypair.
    Prints the public key (hex) and secret key (hex) to stdout.

swactor-store auth grant <pubkey>
    Add a public key to the ACL's authorized_keys set.
    Requires running on the owner's node.

swactor-store auth revoke <pubkey>
    Remove a public key from the ACL's authorized_keys set.
    Requires running on the owner's node.

swactor-store auth list
    Show all authorized keys (including the owner).

swactor-store auth whoami
    Show this node's public key (NodeId).
```

## 11. Integration with Datastore Protocol

Each protocol flow from `DATASTORE_PROTOCOL.md` §6 has a clear auth integration point:

| Protocol Flow | Auth Path 1 (Direct) | Auth Path 2 (Signed Request) |
|---------------|----------------------|------------------------------|
| §6.1 PUT | Connection-level ACL check | `SignedRequest { action: Put { name, content_hash, size_bytes, tags }, .. }` |
| §6.2 GET (Local) | Connection-level ACL check | `SignedRequest { action: Get { content_hash }, .. }` |
| §6.3 GET (Remote) | Connection-level ACL check | `SignedRequest { action: Get { content_hash }, .. }` → node handles remote fetch internally |
| §6.4 DELETE | Connection-level ACL check | `SignedRequest { action: Delete { content_hash }, .. }` |
| §6.5 LIST (Local) | Connection-level ACL check | `SignedRequest { action: List { name_filter }, .. }` |
| §6.6 LIST (Swarm-Wide) | Connection-level ACL check | `SignedRequest { action: List { name_filter }, .. }` → node handles fan-out internally |

In all cases, auth is enforced *before* the request reaches the actor system. Internal inter-node communication (DHT replication, chunk transfers between cluster members) is not subject to auth checks.

## 12. Future Extensions

These are explicitly **out of scope** for MVP but inform the design:

- **Per-path permission scoping** — restrict a key to specific path prefixes (e.g., read-only access to `photos/`).
- **Permission tiers** — read-only, read-write, admin roles.
- **Capability tokens** — time-limited, scope-limited bearer tokens for delegated access without sharing long-lived keys.
- **Multi-level delegation** — allow authorized users to grant limited access to others.
- **Connection tracking** — forcibly disconnect revoked keys from active iroh sessions.