Internet-Draft SCSWP August 2026
Hebbar & Hiremani Expires 23 February 2027 [Page]
Workgroup:
secdispatch
Internet-Draft:
draft-hebbar-hiremani-scswp-01
Published:
Intended Status:
Experimental
Expires:
Authors:
S. Hebbar
Independent
S. Hiremani
Independent

Secure Collaborative State Workspace Protocol (SCSWP)

Abstract

This document specifies the Secure Collaborative State Workspace Protocol (SCSWP), a stateful, continuously authenticated protocol that enables multiple clients, operating from heterogeneous networks, to securely access and collaboratively manage a shared file workspace hosted on a central authoritative server.

SCSWP defines a complete protocol lifecycle encompassing client provisioning via a Key-Dissolving bootstrap mechanism, mutual X.509 certificate-based identity authentication, ephemeral Elliptic-Curve Diffie-Hellman (ECDH) key exchange producing a three-level cryptographic key hierarchy (K1, K2, K3), continuous Dynamic Network and Access (D/N/P/S) trust evaluation, per-client capability-based authorization, workspace-aware congestion control with a dynamic worker-pool scheduler, concurrent file-operation management via mutual exclusion locks and optimistic version control, idempotent operation execution, a hash-chained audit ledger, and session continuity and recovery through the Dynamic Network and Access Continuity (DNAC) mechanism.

The fundamental security principle of SCSWP is that client trust is not established permanently at login time. Instead, identity, device state, network context, session state, authorization state, resource state, and workspace state are evaluated continuously and cryptographically throughout the full lifetime of every connection.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 23 February 2027.

▲

Table of Contents

1. Introduction

Contemporary distributed systems increasingly require multiple clients, operating from geographically separated and organizationally distinct networks, to collaboratively access and modify shared files through a central authoritative server. Existing approaches address either the security plane (e.g., TLS-protected file servers) or the collaborative concurrency plane (e.g., distributed version control systems) independently. No single protocol addresses both planes together with continuous trust evaluation as a first-class protocol requirement.

The Secure Collaborative State Workspace Protocol (SCSWP) fills this gap by unifying the following capabilities into a single, coherent protocol:

  1. Client Provisioning: Centrally managed, server-authorized client creation using a Key-Dissolving bootstrap mechanism that controls protocol entry without replacing cryptographic authentication.

  2. Mutual Authentication: X.509 certificate-based identity validation in both directions, establishing that both the server and the client are who they claim to be before any key material is derived.

  3. Cryptographic Key Hierarchy: A three-level key hierarchy (K1, K2, K3) derived through HKDF [RFC5869] over ECDH [RFC8422] shared secrets, providing forward secrecy, purpose separation, and epoch-based key rotation.

  4. Continuous Trust Evaluation: A Dynamic Network and Access (D/N/P/S) trust model in which the client's Device context, Network context, Port context, and Socket/Session context are continuously authenticated and evaluated. Trust is not a binary post-login state; it is a continuously scored signal that drives rekeying, revalidation, and session suspension decisions.

  5. Per-Client Capability Authorization: Fine-grained, server-issued capability bits (READ, WRITE, APPEND, CREATE, DELETE, RENAME, LOCK, ADMIN) that govern which file operations each client may request within each workspace.

  6. Workspace-Aware Congestion Control: A two-layer congestion model combining transport-level flow control with an application-level priority-scheduled worker pool that prevents any single client from exhausting shared server resources.

  7. File Concurrency Management: Mutual exclusion locks, optimistic version control with configurable conflict policies (REJECT, RETRY, MERGE, REBASE, CONFLICT VERSION), and operation idempotency via deduplication identifiers.

  8. Hash-Chained Audit Ledger: Every significant operation produces an authenticated, hash-chained audit record incorporating the operation identifier, client and session identifiers, file identifier, previous and new versions, key epoch, trust state, and DNAC hash.

  9. DNAC Session Continuity: The Dynamic Network and Access Continuity mechanism provides cryptographic session recovery after disconnection. Upon reconnection, the client presents its last DNAC digest; the server validates the chain and, if valid, restores the session with a fresh K3 key epoch.

1.1. Scope

This document specifies:

  • The normative protocol message format and OpCode space.
  • The normative cryptographic procedures for K1, K2, and K3 derivation.
  • The normative DNAC construction and validation procedure.
  • The normative file-state record and concurrency control rules.
  • The normative audit record format and hash-chain construction.
  • Security requirements and threat analysis.
  • IANA registrations for the SCSWP OpCode registry and Capability Flags registry.

This document does NOT specify:

  • The internal server storage format for file data.
  • UI implementation details for client or server administration.
  • Deployment topology beyond the single-server model.
  • Post-quantum key encapsulation mechanisms (noted as future scope).

1.2. Design Principles

SCSWP is designed around the following core principles:

Continuous Authentication:
Authentication is not a one-time gate. The protocol continuously re-evaluates the D/N/P/S context and adjusts trust accordingly.
Defense in Depth:
Security is maintained at the identity plane (X.509, bootstrap), the trust plane (D/N/P/S), the security plane (K1/K2/K3 with epoch rotation), the authorization plane (capability ACL), and the concurrency plane (locks, versions, idempotency) simultaneously.
Cryptographic Separation:
Each key level serves exactly one purpose. K1 roots session identity. K2 encodes workspace authorization. K3 provides active session subkeys separated by purpose (authentication, control, payload).
Minimal Exposure:
Sensitive protocol information is always contained inside an AES-256-GCM authenticated encrypted envelope. The transport-visible portion carries only information required for routing.
Auditable State:
Every meaningful state transition produces an immutable, hash-chained audit record. The audit ledger serves as both a compliance artifact and an input to DNAC recovery.

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

The following terms are used throughout this document:

Server:
The SCSWP central authority. Maintains authoritative workspace state, issues client identities, performs continuous trust evaluation, and executes all file operations.
Client:
An SCSWP endpoint operating under a server-issued identity. Clients do not hold authoritative workspace state.
Bootstrap Token:
A server-generated, time-limited, single-use credential that controls protocol entry. Consumed on first use.
Key-Dissolving:
The property that a bootstrap token is irrevocably invalidated upon first successful use. Subsequent use of the same token MUST be rejected.
K1:
The session root key. Derived from ECDH shared secret via HKDF. Represents the identity plane of the session.
K2:
The workspace authorization key. Derived from K1 and the workspace authorization context via HKDF. Represents the authorization plane.
K3:
The active session key. Derived from K1, K2, a per-epoch nonce, and the epoch counter via HKDF. Expanded into three purpose-specific subkeys.
Epoch:
A monotonically increasing counter. Each K3 rotation increments the epoch. Old epoch keys MUST NOT be retained after rotation.
D/N/P/S:
The four dimensions of the dynamic trust context: Device, Network, Port, and Socket/Session.
Trust Score:
A floating-point value in [0, 100] representing the server's current confidence in the legitimacy of a client session.
DNAC:
Dynamic Network and Access Continuity. A cryptographic hash chain that accumulates the authenticated history of a session, used for session recovery after disconnection.
Workspace:
A named, server-managed directory to which one or more clients are authorized to perform file operations.
File-ID:
A globally unique identifier for a file within a workspace, formed as workspace_folder "/" filename.
Operation-ID:
A client-generated, globally unique identifier (UUID v4 [RFC4122]) assigned to each file operation request. Used to enforce idempotency.
ABNF:
Augmented Backus-Naur Form as defined in [RFC5234] and [RFC7405].

3. Protocol Overview and Architecture

SCSWP operates between a single authoritative Server and one or more Clients. The server manages workspace files, client identities, cryptographic material, and session state. Clients access workspace files exclusively through the server; no peer-to-peer file transfer occurs.

The protocol is organized into the following functional planes, processed in the order listed for every file operation:

Client Request
      |
      v
+-----------------------+
| IDENTITY PLANE        |  X.509 identity validation
+-----------------------+
      |
      v
+-----------------------+
| TRUST PLANE           |  D/N/P/S continuous evaluation
+-----------------------+
      |
      v
+-----------------------+
| SECURITY PLANE        |  K1 / K2 / K3 key hierarchy
+-----------------------+
      |
      v
+-----------------------+
| AUTHORIZATION PLANE   |  Capability / ACL check
+-----------------------+
      |
      v
+-----------------------+
| RESOURCE PLANE        |  Congestion + worker scheduling
+-----------------------+
      |
      v
+-----------------------+
| WORKSPACE PLANE       |  Lock / version / idempotency
+-----------------------+
      |
      v
+-----------------------+
| STORAGE PLANE         |  File I/O + version history
+-----------------------+
      |
      v
+-----------------------+
| AUDIT / STATE PLANE   |  Hash-chained audit + DNAC update
+-----------------------+
      |
      v
Client Response
Figure 1: SCSWP Processing Planes

3.1. Three-Plane Architecture

At the highest level of abstraction, SCSWP maintains three orthogonal security planes simultaneously:

IDENTITY PLANE:
Controls WHO the client is. Anchored by X.509 certificates and the Key-Dissolving bootstrap mechanism.
TRUST PLANE:
Controls HOW MUCH the server trusts the current connection context. Driven by D/N/P/S signals evaluated every T_TRUST seconds (RECOMMENDED: 5 seconds).
SECURITY PLANE:
Controls HOW communication is protected. Implemented through the K1/K2/K3 key hierarchy, AES-256-GCM envelope encryption, and HMAC-SHA-256 message authentication.

These planes are independent but interact: trust plane events (e.g., suspicious D/N/P/S change) trigger security plane actions (e.g., K3 epoch rotation).

3.2. Full Protocol Lifecycle

The complete SCSWP lifecycle is as follows:

State 1: UNREGISTERED
Client identity does not yet exist on the server.
State 2: PROVISIONED
Server creates a ClientIdentity record with a bootstrap_token and token_expires_at timestamp. Server issues a signed X.509 client certificate.
State 3: BOOTSTRAP
Client presents bootstrap_token in OP_PROVISION message. Token is validated and irrevocably consumed (Key-Dissolving).
State 4: X.509 AUTHENTICATION
Client and server perform mutual certificate validation. Client presents its ECDH ephemeral public key in OP_AUTH.
State 5: KDF -> K1
Both parties derive K1 from ECDH shared secret.
State 6: D/N/P/S TRUST EVALUATION (Layer-1 Complete)
Client begins sending continuous D/N/P/S context signals. Server establishes initial trust score.
State 7: WORKSPACE AUTHORIZATION -> KDF -> K2 -> KDF -> K3
Server resolves client capabilities. K2 and K3 (epoch 1) are derived.
State 8: ACTIVE SESSION
File operations are processed through all planes in order. Trust evaluation continues every T_TRUST seconds. Heartbeats sent every T_HEARTBEAT seconds.
Transition A:
Trust score drops below REKEY_THRESHOLD (80) -> K3 epoch rotation.
Transition B:
Trust score drops below SUSPEND_THRESHOLD (10) -> Session suspended.
Transition C:
Disconnect detected -> DNAC state persisted; all file locks released.
State 9: RECOVERY
Client reconnects and sends OP_DNAC_RECOVERY. If DNAC valid -> SESSION_RESTORED with new K3 epoch. If DNAC invalid -> return to State 3.

4. Client Provisioning and Bootstrap

4.1. Client Identity Registration

Before a client can connect to the server, an authorized administrator MUST register the client identity through the server's administration interface. Registration produces the following server-side records:

Client Identity Record:

client_id:
UUID v4 [RFC4122], server-generated.
common_name:
Human-readable client identifier.
workspace_folder:
The workspace this client is authorized for.
bootstrap_token:
Cryptographically random string, minimum 128 bits of entropy. MUST be generated using a CSPRNG conforming to [RFC4086].
token_expires_at:
UTC timestamp. RECOMMENDED maximum validity period: 24 hours. Servers MUST NOT issue tokens without an expiration timestamp.
is_active:
Boolean, initially FALSE. Set to TRUE on first successful OP_PROVISION exchange. A token with is_active=TRUE MUST be rejected on subsequent OP_PROVISION attempts.
cert_pem:
PEM-encoded X.509 certificate signed by the server CA.

Client Capability Record:

client_id:
References the Client Identity Record.
workspace_folder:
The workspace to which these capabilities apply.
capability_bits:
Integer bitmask. See Section 7.1.

4.2. Key-Dissolving Bootstrap Mechanism

The Key-Dissolving bootstrap mechanism controls protocol entry. A client MUST successfully complete the bootstrap phase before proceeding to identity authentication. The bootstrap credential itself does not authenticate the client cryptographically; it merely gates entry to the authentication phase.

The OP_PROVISION message carries:

  • The bootstrap_token.
  • The client's hostname (informational; not used for authentication).

Upon receipt of OP_PROVISION, the server MUST:

  1. Look up the bootstrap_token in the client identity store.
  2. Verify that a matching record exists with is_active=FALSE.
  3. Verify that token_expires_at is in the future.

  4. If all checks pass:

    1. Atomically set is_active=TRUE (Key-Dissolving step).
    2. Create a new SessionState record (session_id, initial trust score of 100.0).
    3. Load the Client Capability Record for this client.
    4. Respond with OP_ACK carrying client_id, cert_pem, and capability_bits.

  5. If any check fails:

    1. Respond with OP_ERROR carrying the appropriate error code.
    2. Increment a per-token failure counter. After three consecutive failures, the token MUST be permanently revoked.

Servers MUST use a constant-time string comparison when validating bootstrap tokens to prevent timing oracle attacks [RFC6151].

4.3. Bootstrap Token Expiration

Bootstrap tokens MUST carry an expiration timestamp. A server MUST reject any token whose token_expires_at timestamp is less than or equal to the current UTC time at the moment of validation.

The error code TOKEN_EXPIRED (0x02) MUST be returned in the OP_ERROR payload.

Re-issuance of a new token for the same client is a server administration action and is outside the scope of this protocol.

5. Mutual Authentication and Key Establishment

5.1. X.509 Certificate Authentication

SCSWP requires mutual X.509 [RFC5280] certificate authentication.

Server Certificate:

The server operates a Certificate Authority (CA) using an ECDSA key pair over curve P-384 (secp384r1) [RFC8422]. The CA issues a self-signed certificate that serves as the trust anchor for all client connections. The CA private key MUST be stored securely in volatile memory and regenerated on each server start, or persisted in a hardware security module.

The server CA certificate MUST include:

  • Subject and Issuer: CN=SCSWP-CA (or a site-specific name).
  • Validity: RECOMMENDED not to exceed 365 days.
  • Key Usage: keyCertSign, digitalSignature.
Client Certificate:

During client provisioning (Section 4.1), the server CA MUST issue a signed X.509 certificate to the client included in the OP_ACK response as cert_pem.

The client certificate MUST include:

  • Subject: CN=<common_name of the client>.
  • Issuer: The server CA distinguished name.
  • Validity: RECOMMENDED not to exceed 365 days.
  • SubjectAlternativeName: DNSName=<common_name>.
  • Key Usage: digitalSignature.
Authentication Exchange:
During OP_AUTH, the client presents its ECDH ephemeral public key. The server MUST verify the certificate was signed by the server CA before proceeding with key derivation. Clients MUST store and present cert_pem for any subsequent re-authentication.

5.2. ECDH Key Exchange

After successful certificate validation, the client and server perform an ephemeral Elliptic-Curve Diffie-Hellman (ECDH) key exchange [RFC8422].

Key Generation:
Both the client and the server MUST generate a fresh ephemeral ECDH key pair for each session. All ECDH operations MUST use curve P-384 (secp384r1). Support for P-256 is OPTIONAL and NOT RECOMMENDED for new deployments.
Exchange:
The client sends its ephemeral public key (PEM-encoded) in the OP_AUTH request. The server responds with its public key in the OP_ACK response. The raw ECDH shared secret MUST NOT be used directly as a cryptographic key. It MUST be passed through HKDF as described in Section 5.3.

5.3. K1 — Session Root Key Derivation

K1 is the session root key, derived as follows:

IKM = ECDH(client_private_key, server_public_key)
    = ECDH(server_private_key, client_public_key)

K1 = HKDF-SHA256(
         IKM  = IKM,
         salt = nil,
         info = "SCSWP_K1:" || session_id,
         L    = 32 octets
     )

Where:

  • HKDF-SHA256 is defined in [RFC5869] using HMAC-SHA-256 [RFC2104].
  • session_id is the UUID v4 session identifier assigned during OP_PROVISION.
  • The info string MUST be encoded as UTF-8 [RFC3629].
  • L=32 octets yields a 256-bit key.

K1 MUST be retained in volatile memory only. K1 MUST NOT be written to persistent storage, transmitted over the network, or included in any log output. K1 is used solely as input to K2 derivation (Section 7.2) and MUST NOT be used directly as an encryption or MAC key.

6. Trust Plane — Dynamic D/N/P/S Evaluation

6.1. D/N/P/S Context Structure

The D/N/P/S context is a structured representation of the client's current operating environment across four dimensions:

D — Device:
A stable identifier for the client device, SHOULD be the server-provisioned client_id or a hardware-bound identifier.
N — Network:
The client's current network-layer source address as observed at the server. NAT mappings and mobile network handoffs cause legitimate address changes; the trust penalty for network changes is therefore lower than the penalty for device changes.
P — Port:
The client's staging port. Informational in the current epoch; future versions MAY use it for per-port isolation policy.
S — Socket/Session:
Session-layer context including session_id, current key epoch, and DNAC chain tip.

The D/N/P/S context MUST be encoded as a JSON object [RFC8259] with the following normative fields:

{
  "device_id":  <string>,
  "network_ip": <string>,
  "port":       <uint16>,
  "session_id": <string>,
  "epoch":      <uint32>,
  "dnac":       <string>
}

ABNF for the JSON object:

dnps-object = "{" SP
              %s"\"device_id\""  ":" SP json-string "," SP
              %s"\"network_ip\"" ":" SP json-string "," SP
              %s"\"port\""       ":" SP json-uint   "," SP
              %s"\"session_id\"" ":" SP json-string "," SP
              %s"\"epoch\""      ":" SP json-uint   "," SP
              %s"\"dnac\""       ":" SP json-string
              SP "}"

6.2. Continuous Trust Evaluation

The client MUST send an OP_TRUST_EVAL message to the server at regular intervals. The RECOMMENDED interval is T_TRUST = 5 seconds. The OP_TRUST_EVAL message carries:

  • The current D/N/P/S context object (Section 6.1).

  • An HMAC-SHA-256 [RFC2104] signature:

    sig = HMAC-SHA256(key  = K3.auth_key,
                  data = canonical_JSON(dnps_object))

    where canonical_JSON is a deterministic UTF-8 encoding with keys lexicographically sorted and no insignificant whitespace.

  • The current epoch number.

The server MUST verify the HMAC signature before accepting the D/N/P/S context. An invalid signature MUST result in OP_ERROR code SIGNATURE_INVALID (0x0B) and an incremental trust penalty.

6.3. Trust Scoring and Policy Actions

The server maintains a Trust Score T in [0, 100] for each active session. The initial Trust Score on session establishment is 100.0.

Trust Penalties:

Table 1
Signal Penalty (ΔT)
Network address change -15.0
Device identifier change -60.0
Operation rate > R_MAX in W_RATE -5.0 per evaluation
HMAC signature invalid -25.0
Authentication failure -25.0

where R_MAX = 20 operations and W_RATE = 10 seconds.

Trust Healing: If no anomalies are detected, the Trust Score SHOULD be increased by H_TRUST (RECOMMENDED: 0.5) up to the maximum of 100.0.

Policy Actions Triggered by Trust Score:

T < REKEY_THRESHOLD (RECOMMENDED: 80.0):
The server MUST initiate a K3 epoch rotation (Section 7.3). The server MUST include rekey=true and the new epoch_nonce_b64 in the OP_TRUST_EVAL ACK response.
T <= SUSPEND_THRESHOLD (RECOMMENDED: 10.0):
The server MUST set the session is_suspended flag. All subsequent file operation requests MUST be rejected with OP_ERROR code SESSION_SUSPENDED (0x09). The session MUST be recorded in the audit ledger with result "SUSPENDED".
T <= 0:
The server MUST terminate the connection immediately. All file locks held by this session MUST be released.

The Trust Score MUST be included in every audit record produced during the session (Section 12.1).

7. Authorization Plane and Workspace Key Derivation

7.1. Per-Client Capability Model

SCSWP uses a capability-based authorization model. Each client is issued a set of capabilities that govern which operations it may perform within its assigned workspace. The capability set is represented as an integer bitmask:

Table 2
Bit Name Value Description
0 READ 1 Download and retrieve file content.
1 WRITE 2 Upload and overwrite file content.
2 APPEND 4 Append data to an existing file.
3 CREATE 8 Create new files within the workspace.
4 DELETE 16 Delete files from the workspace.
5 RENAME 32 Rename files within the workspace.
6 LOCK 64 Acquire and release file locks.
7 ADMIN 128 All of the above plus server-level operations.

A client with ADMIN capability MUST be treated as having all other capabilities regardless of individual bit states.

If a client requests an operation for which it lacks the corresponding capability bit, the server MUST reject the request with OP_ERROR code PERMISSION_DENIED (0x08) and record the attempt in the audit ledger.

Predefined Capability Presets:

Table 3
Preset Bits Set Effective Value
READ_ONLY READ 1
READ_WRITE READ|WRITE|CREATE|LOCK 75
FULL All bits set 255

7.2. K2 — Workspace Authorization Key Derivation

K2 encodes the cryptographic binding between the session root (K1) and the workspace authorization context. K2 is derived independently by both the client and the server without transmission:

K2 = HKDF-SHA256(
         IKM  = K1,
         salt = nil,
         info = "SCSWP_K2:" || workspace_folder || ":" || session_id,
         L    = 32 octets
     )

K2 MUST NOT be transmitted. It MUST be retained in volatile memory only. K2 is used solely as input to K3 derivation (Section 7.3). A client MUST NOT attempt to access a different workspace using the same K2 value.

7.3. K3 — Active Session Key Derivation and Epoch System

K3 is the active session key, expanded from a 96-octet HKDF output into three 32-octet purpose-specific subkeys:

K3_material = HKDF-SHA256(
                 IKM  = K1 || K2,
                 salt = epoch_nonce,
                 info = "SCSWP_K3:epoch:" || epoch,
                 L    = 96 octets
             )

K3.auth_key    = K3_material[0:32]    ; HMAC-SHA-256 over D/N/P/S
K3.ctrl_key    = K3_material[32:64]   ; AES-256-GCM for control msgs
K3.payload_key = K3_material[64:96]   ; AES-256-GCM for file payloads

Where epoch_nonce is a 16-octet CSPRNG value generated freshly for each epoch by the server; epoch is the ASCII decimal epoch counter (starting at 1).

A new epoch MUST be initiated when any of the following occur:

  1. The Trust Score T falls below REKEY_THRESHOLD.
  2. The server receives an explicit OP_REKEY request from the client.
  3. Session recovery via DNAC (Section 11.3) completes.
  4. The epoch counter reaches EPOCH_MAX (RECOMMENDED: 2^32 - 1), requiring full re-authentication.

Upon epoch rotation, the previous epoch's K3 material MUST be securely erased from memory. The new epoch and epoch_nonce_b64 MUST be communicated in the OP_ACK or OP_TRUST_EVAL ACK.

8. Secure Transport and Message Envelope

8.1. Transport Layer

SCSWP messages MUST be carried over a reliable, ordered, full-duplex transport. RECOMMENDED transport: WebSocket [RFC6455] over TLS 1.3 [RFC8446]. The WebSocket connection MUST be established to the server's protocol endpoint, conventionally at path "/protocol".

Future deployments MAY use QUIC [RFC9000] as the transport layer. If TLS is not available at the transport layer, implementations MUST rely on the SCSWP application-layer AES-256-GCM envelope (Section 8.3) to provide confidentiality and integrity. TLS is STRONGLY RECOMMENDED regardless.

8.2. Protocol Message Format

All SCSWP messages are encoded as JSON objects [RFC8259]. The normative wire format is:

{
  "opcode":     <uint8>,
  "session_id": <string | null>,
  "epoch":      <uint32>,
  "payload":    <object>
}

ABNF for the message envelope:

scswp-message = "{" SP
                %s"\"opcode\""     ":" SP uint8  "," SP
                %s"\"session_id\"" ":" SP (json-string / "null") "," SP
                %s"\"epoch\""      ":" SP uint32 "," SP
                %s"\"payload\""    ":" SP json-object
                SP "}"

uint8  = 1*3DIGIT
uint32 = 1*10DIGIT

Unknown opcode values MUST result in an OP_ERROR response with error code UNKNOWN_OPCODE (0x0D). The total message length SHOULD NOT exceed 67108864 octets (64 MiB).

8.3. Secure Envelope

File payload data included in OP_FILE_OP WRITE and READ responses MUST be protected using AES-256-GCM [NIST.SP.800-38D].

Encryption:
  nonce    := CSPRNG(12 octets)
  ct || tag := AES-256-GCM-Encrypt(
                   key=K3.payload_key, nonce=nonce, aad=nil, pt=data)
  envelope := nonce || ct || tag
  data_b64 := BASE64URL(envelope)   ; RFC 4648 Section 5

Decryption:
  envelope := BASE64URL-DECODE(data_b64)
  nonce    := envelope[0:12]
  pt       := AES-256-GCM-Decrypt(
                   key=K3.payload_key, nonce=nonce, aad=nil,
                   ct=envelope[12:])

AES-256-GCM authentication tag length MUST be 128 bits (16 octets). If tag verification fails, the receiver MUST discard the message, increment a failure counter, apply a trust penalty (Section 6.3), and NOT process the decrypted data. Control messages SHOULD use K3.ctrl_key for envelope protection.

8.4. OpCode Registry

The following opcodes are defined in this specification:

Table 4
Value Name Direction Description
0x01 OP_PROVISION C->S Bootstrap / Key-Dissolving
0x02 OP_AUTH C->S ECDH identity authentication
0x03 OP_TRUST_EVAL C->S D/N/P/S context signal
0x04 OP_WORKSPACE_AUTH C->S Workspace authorization ack
0x05 OP_FILE_OP C->S File operation (LIST/READ/WRITE)
0x06 OP_LOCK C->S Acquire file write lock
0x07 OP_UNLOCK C->S Release file write lock
0x08 OP_DNAC_RECOVERY C->S Session recovery via DNAC
0x09 OP_REKEY C->S Explicit K3 epoch rotation request
0x0A OP_HEARTBEAT C->S Keep-alive
0x0B OP_ACK S->C Generic success response
0x0C OP_ERROR S->C Error response
0x0D OP_NACK S->C Negative acknowledgement

OP_FILE_OP Sub-Operations (carried in payload "op" field): LIST, READ, WRITE, APPEND. See Section 15.1 for IANA registration of these opcodes.

9. Congestion Control and Resource Management

9.1. Application-Level Flow Control

SCSWP implements a two-layer congestion control model. Layer 1 is handled by the transport (TLS/WebSocket or QUIC). Layer 2 implements workspace-aware scheduling and backpressure above the transport layer.

The server MUST maintain per-client resource metrics: outstanding_ops, resource_debt, op_rate, and queue_depth.

If outstanding_ops >= MAX_OPS_PER_CLIENT (RECOMMENDED: 10), the server MUST reject the incoming operation with OP_ERROR code SERVER_BUSY (0x0A) and a RECOMMENDED retry_ms value of 500. The client MUST honor retry_ms before retransmitting.

9.2. Dynamic Worker-Pool Scheduler

The server MUST maintain a shared pool of N_WORKERS asynchronous workers (RECOMMENDED: N_WORKERS = 8). Each queued operation is assigned a priority score:

score = resource_debt(session_id)
        + op_weight(op_type)
        - wait_boost(wait_time)

op_weight:  READ=0  SYNC=5  APPEND=8  WRITE=10
wait_boost: min(wait_time_seconds * 2, 50)

Workers MUST be dispatched in ascending score order (lowest score = highest priority), RECOMMENDED to be implemented as a binary min-heap. When an operation completes, DEBT_INCREMENT (RECOMMENDED: 5.0) is added to resource_debt. On each scheduler cycle, resource_debt is multiplied by DEBT_DECAY (RECOMMENDED: 0.9).

9.3. Per-Client Resource Debt

Resource debt enforces scheduler fairness but MUST NOT affect authorization. A client's right to perform an operation is determined entirely by its capability bits (Section 7.1) and its trust score (Section 6.3). Resource debt determines only WHEN an authorized operation executes, not WHETHER it is permitted.

10. Workspace Plane — File Concurrency and Version Control

10.1. File State Record

The server MUST maintain a File State Record for every file operated on within a workspace, containing at minimum:

Table 5
Field Type Description
file_id string workspace_folder "/" filename
file_name string The base file name.
version uint32 Monotonically increasing. Starts at 1; incremented by 1 on each successful WRITE or APPEND.
lock_state enum UNLOCKED | WRITE_LOCK
locked_by string session_id of the lock holder, or NULL.
updated_at datetime UTC timestamp of last modification.

The server MUST retain the complete version history of each file as a sequence of records: file_id, version, data, written_by, written_at, size_bytes.

10.2. Mutual Exclusion Locking

SCSWP uses server-side exclusive write locks to prevent concurrent WRITE or APPEND operations from producing an undefined result.

Lock Acquisition (OP_LOCK):

A client MUST send OP_LOCK before issuing a WRITE or APPEND operation. The server MUST verify LOCK capability, atomically check lock_state, and respond with OP_ACK {status: "LOCKED"} if UNLOCKED, or OP_ERROR {error: "FILE_LOCKED"} if WRITE_LOCK is held by another session.

Lock Release (OP_UNLOCK):
After completing WRITE or APPEND, the client MUST send OP_UNLOCK. The server MUST verify locked_by == requesting session_id; releases by non-owners MUST be rejected.
Automatic Lock Release on Disconnect:
When a client connection terminates for any reason, the server MUST release all file locks held by that session atomically. Lock release on disconnect MUST be recorded in the audit ledger.
Advisory vs. Mandatory Locking:
SCSWP implements mandatory server-side locking. A WRITE request received for a file held by another session MUST be rejected with OP_ERROR code FILE_LOCKED (0x05), regardless of any client-side flag.

10.3. Optimistic Version Control and Conflict Policies

A client MAY include an expected_version field in OP_FILE_OP WRITE or APPEND payloads. If the server's current version differs, a conflict is detected.

The client MUST include a conflict_policy field. If absent, the server MUST apply REJECT. Defined policies:

REJECT:
Server MUST NOT apply the write. Responds with OP_ERROR VERSION_CONFLICT. Client MUST re-fetch before retrying.
RETRY:
Server MUST NOT apply the write. Responds with OP_ERROR RETRY_REQUIRED. Client SHOULD re-fetch and re-submit.
MERGE:
Server MUST apply the write, recording it as a merge in the audit ledger. Implementations SHOULD perform three-way text merge for text/plain or application/json. Binary files MUST use the WRITE payload as authoritative.
REBASE:
Semantically equivalent to MERGE in this version. Future versions MAY define distinct behavior.
CONFLICT VERSION:
Server MUST NOT apply the write. Instead, it creates a new snapshot version record for the client's payload alongside the server's current version. Both versions exist until an authorized administrator resolves the conflict.

10.4. Operation Idempotency

Each file-modifying operation (WRITE, APPEND) MUST carry a client-generated operation_id (UUID v4 [RFC4122]). The server MUST maintain an idempotency record keyed on operation_id. If a record exists, the server MUST return the previously computed result without re-executing the operation, including idempotent: true in the OP_ACK payload. The idempotency record SHOULD be retained for a minimum of 24 hours.

11. DNAC — Dynamic Network and Access Continuity

11.1. DNAC State Digest Construction

The DNAC hash chain accumulates a cryptographic summary of the session's authenticated state. Each link is defined as:

DNAC_N = SHA-256(
             prev_dnac    ||
             session_id   ||
             operation_id ||
             state_digest ||
             timestamp
         )

Where prev_dnac is the hex-encoded SHA-256 of the previous link, or the ASCII string "GENESIS" for the first link. All fields are concatenated with the "|" separator before hashing. The DNAC chain MUST be initialized with DNAC_0 = "GENESIS".

11.2. DNAC Chain Evolution

The DNAC chain advances after every significant protocol event:

Table 6
Event state_digest
Successful bootstrap "BOOTSTRAP"
Successful authentication "AUTH_OK"
Successful WRITE v{N} "<file_id>:v<version>"
Successful READ "READ:<file_id>"
Trust evaluation "TRUST:<score>"

The server MUST persist the DNAC chain tip (DNAC_N) and preceding link (DNAC_{N-1}) to stable storage upon session termination to enable recovery.

11.3. Session Recovery via DNAC

When a client reconnects after disconnection, it MUST attempt DNAC-based session recovery before initiating full re-authentication.

  1. Client sends OP_DNAC_RECOVERY:

    { "client_id": "<client_id>", "last_dnac": "<DNAC_N_hex>" }
  2. Server looks up the most recently persisted DNAC tip for client_id.

  3. If last_dnac matches the persisted DNAC tip:

    1. The server MUST NOT reuse the previous session's K3 keys.
    2. The server MUST generate a fresh epoch_nonce and rotate K3 to a new epoch.

    3. The server responds:

      OP_ACK {
  "status": "SESSION_RESTORED",
  "session_id": "<id>",
  "epoch": <new_epoch>,
  "epoch_nonce_b64": "<base64url_nonce>"
}

  4. If last_dnac does NOT match, the server responds:

    OP_ERROR { "error": "DNAC_MISMATCH_REAUTHENTICATE" }

    The client MUST perform full re-authentication starting from OP_PROVISION.

12. Audit and State Ledger

12.1. Audit Record Structure

Every significant protocol event MUST produce an audit record containing:

Table 7
Field Type Description
operation_id string UUID v4; unique audit record identifier.
client_id string UUID v4; identifies the client.
session_id string UUID v4; identifies the session.
file_id string "<workspace>/<filename>", or NULL.
operation_type string Event name (see below).
timestamp datetime UTC timestamp of record creation.
result string "SUCCESS", "FAILED", "SUSPENDED", "DISCONNECTED", or error code.
trust_score float Trust Score T at record creation time.
key_epoch uint32 Current K3 epoch at record creation time.
prev_version uint32 File version before operation, or NULL.
new_version uint32 File version after operation, or NULL.
prev_hash string Hex SHA-256 of the previous audit record.
record_hash string Hex SHA-256 of this record's chain link.
dnac string DNAC chain tip at record creation time.

Operation type values: BOOTSTRAP, AUTH, TRUST_EVAL, WORKSPACE_AUTH, LIST, READ, WRITE, APPEND, LOCK, UNLOCK, REKEY, DNAC_RECOVERY, HEARTBEAT, DISCONNECT.

12.2. Hash-Chained Ledger

Audit records MUST be chained to form a tamper-evident ledger:

prev_hash   = record_hash of the preceding record ("GENESIS" for first).

record_hash = SHA-256(prev_hash || operation_id || result)
              (fields concatenated with "|" separator; output hex-encoded)

An auditor verifying the ledger MUST start from the record with prev_hash = "GENESIS" and verify each record_hash in sequence. A mismatch indicates tampering at that record. The audit ledger SHOULD be exportable in CSV [RFC4180] format.

13. Reference Implementation

A reference implementation of the SCSWP protocol, including both the authoritative server and a compatible client, is available as an open-source Python package.

The source code and packaging details can be found at the following URL: https://github.com/sripad2020/Secure-Collaborative-State-Workspace-Protocol

The published package is available on PyPI: https://pypi.org/project/scswp/

The reference implementation includes the min-heap priority scheduler, ECDH-based key hierarchy, DNAC hash-chain construction, and SQLite-backed audit ledger as specified in this document.

14. Security Considerations

14.1. Cryptographic Algorithm Security

  • Elliptic Curve: P-384. Provides 192 bits of security strength [RFC8422], exceeding the NIST 128-bit minimum [NIST.SP.800-57]. P-256 MUST NOT be used where long-term security is required.
  • Key Derivation: HKDF-SHA256 [RFC5869]. The info field MUST include a purpose-specific prefix.
  • Symmetric Encryption: AES-256-GCM [NIST.SP.800-38D]. GCM nonce MUST be 96 bits (12 octets) generated from a CSPRNG per encryption call. Nonce reuse is a catastrophic failure. K3 MUST be rotated before 2^32 encryptions.
  • Message Authentication: HMAC-SHA-256 [RFC2104] using K3.auth_key.
  • Digest: SHA-256 [FIPS.PUB.180-4].

14.2. Key Material Handling

K1, K2, K3, and their subkeys MUST be stored exclusively in volatile memory. Implementations MUST NOT write key material to disk, log it in diagnostic output, transmit K1 or K2 in any protocol message, or retain previous-epoch K3 material after key rotation. On session termination, all key material MUST be securely erased.

14.3. Bootstrap Token Security

Tokens MUST contain a minimum of 128 bits of entropy [RFC4086]. Validation MUST use constant-time string comparison [RFC6151]. Tokens MUST expire within a server-configured window (RECOMMENDED maximum: 24 hours). Tokens are single-use. After three consecutive failed validation attempts, the token MUST be permanently revoked.

14.4. Trust Score Manipulation

All OP_TRUST_EVAL messages are HMAC-signed with K3.auth_key; invalid HMACs MUST be rejected and penalized. The server MUST treat the absence of OP_TRUST_EVAL for more than T_TRUST_TIMEOUT seconds (RECOMMENDED: 15 seconds) as suspicious and apply a trust penalty. Replayed messages from a previous epoch carry an outdated epoch value and MUST be rejected.

14.5. File Lock Security

Clients without LOCK capability MUST NOT be able to acquire or release locks. Servers SHOULD implement a maximum lock duration (RECOMMENDED: 300 seconds) after which the lock is forcibly released and a trust penalty applied.

14.6. Audit Ledger Integrity

The audit store SHOULD be append-only. Periodic ledger hash checkpoints SHOULD be published to an external, immutable log. The DNAC chain and the audit chain are independent; an attacker must tamper with both to conceal an operation.

14.7. Version Conflict Policies and Data Integrity

Deployments where data integrity is paramount SHOULD restrict all clients to the REJECT conflict policy. The CONFLICT VERSION policy is the safest option for multi-client scenarios as it preserves all versions pending administrator resolution.

14.8. Session Suspension and Denial of Service

Network change penalties are intentionally lower than device change penalties to accommodate mobile clients. Administrators SHOULD be able to manually restore a suspended session after out-of-band verification.

14.9. Post-Quantum Cryptography Considerations

SCSWP's K1 derivation relies on the security of ECDH over P-384, which could be broken by a cryptographically relevant quantum computer [SHOR1994]. Future versions SHOULD incorporate a hybrid key establishment mechanism combining ECDH with a PQ-KEM [NIST.PQC.FIPS.203]:

IKM_hybrid = ECDH_secret || PQ-KEM_secret

This IKM_hybrid replaces the ECDH_secret input to HKDF in K1 derivation. The rest of the key hierarchy (K2, K3) is unchanged.

14.10. Privacy Considerations

D/N/P/S signals MUST never be transmitted without K3.auth_key HMAC protection. D/N/P/S data MUST NOT appear in the audit ledger in cleartext. Administrators MUST be informed that D/N/P/S data constitutes personal data under applicable privacy regulations.

15. IANA Considerations

15.1. SCSWP OpCode Registry

IANA is requested to create a new registry titled "SCSWP OpCode Registry" under the "Secure Collaborative State Workspace Protocol (SCSWP)" registry group. Registration Policy: Specification Required [RFC8126].

Table 8
Value Name Reference
0x01 OP_PROVISION Section 4.2
0x02 OP_AUTH Section 5.2
0x03 OP_TRUST_EVAL Section 6.2
0x04 OP_WORKSPACE_AUTH Section 7.1
0x05 OP_FILE_OP Section 10
0x06 OP_LOCK Section 10.2
0x07 OP_UNLOCK Section 10.2
0x08 OP_DNAC_RECOVERY Section 11.3
0x09 OP_REKEY Section 7.3
0x0A OP_HEARTBEAT Section 3.2
0x0B OP_ACK Section 8.4
0x0C OP_ERROR Section 8.4
0x0D OP_NACK Section 8.4
0x0E OP_CHUNK Reserved; future use
0x0F OP_SYNC Reserved; future use
0x10-0xEF Unassigned
0xF0-0xFF Private Use

15.2. SCSWP Capability Flags Registry

IANA is requested to create a new registry titled "SCSWP Capability Flags Registry" under the "SCSWP" registry group. Registration Policy: Specification Required [RFC8126].

Table 9
Bit Name Value Reference
0 READ 1 Section 7.1
1 WRITE 2 Section 7.1
2 APPEND 4 Section 7.1
3 CREATE 8 Section 7.1
4 DELETE 16 Section 7.1
5 RENAME 32 Section 7.1
6 LOCK 64 Section 7.1
7 ADMIN 128 Section 7.1
8-31 Unassigned

15.3. SCSWP Conflict Policy Registry

IANA is requested to create a new registry titled "SCSWP Conflict Policy Registry" under the "SCSWP" registry group. Registration Policy: Specification Required [RFC8126].

Table 10
Name Reference
REJECT Section 10.3
RETRY Section 10.3
MERGE Section 10.3
REBASE Section 10.3
CONFLICT_VERSION Section 10.3

15.4. SCSWP Error Code Registry

IANA is requested to create a new registry titled "SCSWP Error Code Registry" under the "SCSWP" registry group. Registration Policy: Specification Required [RFC8126].

Table 11
Code Name Description
0x01 INVALID_BOOTSTRAP_TOKEN Token not found or already used.
0x02 TOKEN_EXPIRED Token validity period elapsed.
0x03 AUTH_FAILED ECDH or certificate verification failed.
0x04 NO_SESSION session_id not found.
0x05 FILE_LOCKED File held by another session.
0x06 VERSION_CONFLICT expected_version mismatch.
0x07 RETRY_REQUIRED Client should re-fetch and retry.
0x08 PERMISSION_DENIED Client lacks required capability.
0x09 SESSION_SUSPENDED Trust score at or below threshold.
0x0A SERVER_BUSY outstanding_ops limit reached.
0x0B SIGNATURE_INVALID HMAC verification failed.
0x0C DNAC_MISMATCH DNAC recovery hash mismatch.
0x0D UNKNOWN_OPCODE Received opcode not recognized.
0x0E FILE_NOT_FOUND Requested file does not exist.
0x0F WORKSPACE_NOT_FOUND Workspace folder does not exist.

16. References

16.1. Normative References

[RFC2104]
Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, , <https://www.rfc-editor.org/info/rfc2104>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629]
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, , <https://www.rfc-editor.org/info/rfc3629>.
[RFC4086]
Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, , <https://www.rfc-editor.org/info/rfc4086>.
[RFC4122]
Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, , <https://www.rfc-editor.org/info/rfc4122>.
[RFC4648]
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, , <https://www.rfc-editor.org/info/rfc4648>.
[RFC5234]
Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, , <https://www.rfc-editor.org/info/rfc5234>.
[RFC5280]
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 5280, , <https://www.rfc-editor.org/info/rfc5280>.
[RFC5869]
Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, , <https://www.rfc-editor.org/info/rfc5869>.
[RFC5952]
Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, , <https://www.rfc-editor.org/info/rfc5952>.
[RFC7405]
Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, , <https://www.rfc-editor.org/info/rfc7405>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, , <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, , <https://www.rfc-editor.org/info/rfc8259>.
[RFC8422]
Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "ECC Cipher Suites for TLS Versions 1.2 and Earlier", RFC 8422, , <https://www.rfc-editor.org/info/rfc8422>.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, , <https://www.rfc-editor.org/info/rfc8446>.
[NIST.SP.800-38D]
Dworkin, M., "Recommendation for Block Cipher Modes of Operation: GCM and GMAC", NIST Special Publication 800-38D, , <https://doi.org/10.6028/NIST.SP.800-38D>.
[FIPS.PUB.180-4]
NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4, , <https://doi.org/10.6028/NIST.FIPS.180-4>.

16.2. Informative References

[RFC4180]
Shafranovich, Y., "Common Format and MIME Type for CSV Files", RFC 4180, , <https://www.rfc-editor.org/info/rfc4180>.
[RFC6151]
Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and HMAC-MD5", RFC 6151, , <https://www.rfc-editor.org/info/rfc6151>.
[RFC6455]
Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, , <https://www.rfc-editor.org/info/rfc6455>.
[RFC9000]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, , <https://www.rfc-editor.org/info/rfc9000>.
[NIST.SP.800-57]
Barker, E., "Recommendation for Key Management: Part 1 - General", NIST Special Publication 800-57 Part 1 Rev. 5, , <https://doi.org/10.6028/NIST.SP.800-57pt1r5>.
[NIST.PQC.FIPS.203]
NIST, "Module-Lattice-Based Key-Encapsulation Mechanism Standard", FIPS 203, , <https://doi.org/10.6028/NIST.FIPS.203>.
[SHOR1994]
Shor, P.W., "Algorithms for Quantum Computation: Discrete Logarithms and Factoring", Proceedings of the 35th Annual Symposium on Foundations of Computer Science, pp. 124-134, .

Appendix A. Protocol State Machine 

+-------------+  OP_PROVISION (valid token)  +-------------+
| UNREGISTERED|----------------------------->| BOOTSTRAP   |
+-------------+                              +------+------+
                                                    |
                                     OP_AUTH (ECDH) |
                                                    v
                                           +--------+--------+
                                           | AUTHENTICATING  |
                                           +--------+--------+
                                                    |
                                       K1 derived   |
                                                    v
                                           +--------+--------+
                                           |   K1 READY      |
                                           +--------+--------+
                                                    |
                                   K2, K3 derived   |
                                                    v
                                           +--------+--------+
                    +--------------------->|     ACTIVE      |<----+
                    |                      +--+---+---+------+     |
                    |                         |   |   |            |
                    | trust < REKEY_THRESHOLD |   |   |            |
                    |  +----------------------+   |   |            |
                    |  v                          |   |            |
                    | +-----------+  trust<=SUSP  |   | disconnect |
                    | |  REKEYING |  +------------+   |            |
                    | | (new K3)  |  |                |            |
                    | +-----+-----+  v                v            |
                    |       |  +----------+  +----------------+    |
                    +-------+  | SUSPENDED|  |  DISCONNECTED  |    |
                               +----------+  +-------+--------+    |
                                                     |             |
                                        DNAC valid   |             |
                                         +-----------+             |
                                         |   DNAC invalid          |
                                         v                         |
                                +--------+--------+                |
                                |    RECOVERED    +----------------+
                                | (new K3 epoch)  |
                                +-----------------+
Figure 2: SCSWP Session State Machine

Appendix B. Cryptographic Algorithm Rationale

B.1. Choice of P-384

P-384 provides 192 bits of security, significantly exceeding the NIST 128-bit minimum [NIST.SP.800-57]. The workspace domain model involves persistent client identities and long-lived shared workspaces, making the higher security margin appropriate. P-384 is performant on modern hardware and supported natively in all major cryptographic libraries.

B.2. Choice of HKDF-SHA256 for K1/K2/K3

HKDF [RFC5869] provides domain separation through the info parameter; the "SCSWP_K1:", "SCSWP_K2:", and "SCSWP_K3:" prefixes ensure key material derived for different purposes cannot be confused. It also supports arbitrary output lengths, enabling a single HKDF call for K3 to produce all three subkeys simultaneously.

B.3. Choice of AES-256-GCM

AES-256-GCM provides authenticated encryption (confidentiality and integrity in a single pass), is hardware-accelerated via AES-NI on all major CPU architectures, and is the standard cipher suite in TLS 1.3 [RFC8446].

B.4. Key Separation and Purpose Binding

The three K3 subkeys enforce cryptographic purpose separation. auth_key is used exclusively for HMAC-SHA-256 over D/N/P/S signals and MUST NOT be used for encryption. ctrl_key is used for AES-256-GCM encryption of control messages and MUST NOT be used for file payload encryption. payload_key is used for AES-256-GCM encryption of file content and MUST NOT be used for control messages. This separation ensures that a compromise of one subkey does not affect the security of the others.

Appendix C. Example Message Flows

C.1. Initial Connection Flow 

Client                                          Server
------                                          ------
OP_PROVISION {bootstrap_token, hostname} ------>
                                          [Validate token]
                                          [Set is_active=TRUE]
                                          [Create session]
                                          [Load ACL]
      <----- OP_ACK {client_id, cert_pem, capabilities, session_id}

OP_AUTH {public_key_pem} -------------------->
                                          [ECDH exchange]
                                          [Derive K1, K2, K3]
      <--- OP_ACK {server_public_key, epoch=1, epoch_nonce_b64}

OP_TRUST_EVAL {dnps, sig, epoch=1} ---------->
                                          [Verify HMAC-sig]
                                          [Evaluate D/N/P/S]
      <------ OP_ACK {trust_score=100.0, rekey=false, epoch=1}
Figure 3: Initial Connection Message Flow

C.2. File Write Flow (with Lock and Conflict Detection) 

Client                                          Server
------                                          ------
OP_LOCK {folder, filename} ------------------>
                                          [Check ACL: LOCK cap]
      <----------- OP_ACK {status="LOCKED", file_id}

OP_FILE_OP {op="WRITE", data_b64,
            expected_version=5,
            conflict_policy="REJECT",
            operation_id} ----------------->
                                          [ACL: WRITE cap check]
                                          [Idempotency check]
                                          [Version: server=5, OK]
                                          [Worker pool dispatch]
                                          [AES-256-GCM decrypt]
                                          [Write to disk + audit]
                                          [Advance DNAC]
      <---- OP_ACK {op="WRITE", filename, version=6}

OP_UNLOCK {folder, filename} -------------->
      <--------- OP_ACK {status="UNLOCKED"}
Figure 4: File Write Message Flow

C.3. DNAC Session Recovery Flow 

Client                                          Server
------                                          ------
[reconnect after disconnect]
OP_DNAC_RECOVERY {client_id, last_dnac} ------>
                                          [Look up DNAC tip]
                                          [Compare hashes]
                                          [Rotate K3 to epoch N+1]
      <--- OP_ACK {status="SESSION_RESTORED",
                   epoch=N+1, epoch_nonce_b64}

[Client derives new K3; session resumes]
Figure 5: DNAC Session Recovery Message Flow

C.4. Trust Score Rekey Flow 

Client                                          Server
------                                          ------
OP_TRUST_EVAL {dnps={network_ip changed},
               sig, epoch=3} --------------->
                                          [Apply -15 network penalty]
                                          [trust=85 -> below 80: YES]
                                          [Rotate K3 to epoch 4]
      <--- OP_ACK {trust_score=85, rekey=true,
                   epoch=4, epoch_nonce_b64="..."}

[Client derives K3 for epoch 4; all subsequent
 messages use epoch=4 and new K3 subkeys]
Figure 6: Trust Score Rekey Message Flow

Authors' Addresses

Sripad Hebbar
Independent
Sharan Hiremani
Independent