Secure Collaborative State Workspace Protocol (SCSWP) Independent
sripadkarthik@gmail.com
 Independent
sharanrhiremani@gmail.com
 Security Independent Submission secure workspace continuous authentication ECDH AES-GCM collaborative protocol 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.
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 over ECDH 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.
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).
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.
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 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 ) assigned to each file operation request. Used to enforce idempotency.
ABNF:
Augmented Backus-Naur Form as defined in and .
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:
SCSWP Processing Planes
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).
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.
Client Provisioning and Bootstrap
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 , 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 .
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 .
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 .
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.
Mutual Authentication and Key Establishment
X.509 Certificate Authentication SCSWP requires mutual X.509 certificate authentication.
Server Certificate:
The server operates a Certificate Authority (CA) using an ECDSA key pair over curve P-384 (secp384r1) . 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 (), 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.
ECDH Key Exchange After successful certificate validation, the client and server perform an ephemeral Elliptic-Curve Diffie-Hellman (ECDH) key exchange .
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 .
K1 — Session Root Key Derivation K1 is the session root key, derived as follows: Where:
  • HKDF-SHA256 is defined in using HMAC-SHA-256 .
  • session_id is the UUID v4 session identifier assigned during OP_PROVISION.
  • The info string MUST be encoded as UTF-8 .
  • 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 () and MUST NOT be used directly as an encryption or MAC key.
Trust Plane — Dynamic D/N/P/S Evaluation
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 with the following normative fields: , "network_ip": , "port": , "session_id": , "epoch": , "dnac": } ]]> ABNF for the JSON object:
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 ().
  • An HMAC-SHA-256 signature: 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.
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:
SignalPenalty (Δ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 (). 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 ().
Authorization Plane and Workspace Key Derivation
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:
BitNameValueDescription
0READ1Download and retrieve file content.
1WRITE2Upload and overwrite file content.
2APPEND4Append data to an existing file.
3CREATE8Create new files within the workspace.
4DELETE16Delete files from the workspace.
5RENAME32Rename files within the workspace.
6LOCK64Acquire and release file locks.
7ADMIN128All 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:
PresetBits SetEffective Value
READ_ONLYREAD1
READ_WRITEREAD|WRITE|CREATE|LOCK75
FULLAll bits set255
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 MUST NOT be transmitted. It MUST be retained in volatile memory only. K2 is used solely as input to K3 derivation (). A client MUST NOT attempt to access a different workspace using the same K2 value.
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: 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 () 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.
Secure Transport and Message Envelope
Transport Layer SCSWP messages MUST be carried over a reliable, ordered, full-duplex transport. RECOMMENDED transport: WebSocket over TLS 1.3 . The WebSocket connection MUST be established to the server's protocol endpoint, conventionally at path "/protocol". Future deployments MAY use QUIC 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 () to provide confidentiality and integrity. TLS is STRONGLY RECOMMENDED regardless.
Protocol Message Format All SCSWP messages are encoded as JSON objects . The normative wire format is: , "session_id": , "epoch": , "payload": } ]]> ABNF for the message envelope: 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).
Secure Envelope File payload data included in OP_FILE_OP WRITE and READ responses MUST be protected using AES-256-GCM . 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 (), and NOT process the decrypted data. Control messages SHOULD use K3.ctrl_key for envelope protection.
OpCode Registry The following opcodes are defined in this specification:
ValueNameDirectionDescription
0x01OP_PROVISIONC->SBootstrap / Key-Dissolving
0x02OP_AUTHC->SECDH identity authentication
0x03OP_TRUST_EVALC->SD/N/P/S context signal
0x04OP_WORKSPACE_AUTHC->SWorkspace authorization ack
0x05OP_FILE_OPC->SFile operation (LIST/READ/WRITE)
0x06OP_LOCKC->SAcquire file write lock
0x07OP_UNLOCKC->SRelease file write lock
0x08OP_DNAC_RECOVERYC->SSession recovery via DNAC
0x09OP_REKEYC->SExplicit K3 epoch rotation request
0x0AOP_HEARTBEATC->SKeep-alive
0x0BOP_ACKS->CGeneric success response
0x0COP_ERRORS->CError response
0x0DOP_NACKS->CNegative acknowledgement
OP_FILE_OP Sub-Operations (carried in payload "op" field): LIST, READ, WRITE, APPEND. See for IANA registration of these opcodes.
Congestion Control and Resource Management
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.
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: 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).
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 () and its trust score (). Resource debt determines only WHEN an authorized operation executes, not WHETHER it is permitted.
Workspace Plane — File Concurrency and Version Control
File State Record The server MUST maintain a File State Record for every file operated on within a workspace, containing at minimum:
FieldTypeDescription
file_idstringworkspace_folder "/" filename
file_namestringThe base file name.
versionuint32Monotonically increasing. Starts at 1; incremented by 1 on each successful WRITE or APPEND.
lock_stateenumUNLOCKED | WRITE_LOCK
locked_bystringsession_id of the lock holder, or NULL.
updated_atdatetimeUTC 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.
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.
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.
Operation Idempotency Each file-modifying operation (WRITE, APPEND) MUST carry a client-generated operation_id (UUID v4 ). 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.
DNAC — Dynamic Network and Access Continuity
DNAC State Digest Construction The DNAC hash chain accumulates a cryptographic summary of the session's authenticated state. Each link is defined as: 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".
DNAC Chain Evolution The DNAC chain advances after every significant protocol event:
Eventstate_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.
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: ", "last_dnac": "" } ]]>
  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: ", "epoch": , "epoch_nonce_b64": "" } ]]>
  4. If last_dnac does NOT match, the server responds: The client MUST perform full re-authentication starting from OP_PROVISION.
Audit and State Ledger
Audit Record Structure Every significant protocol event MUST produce an audit record containing:
FieldTypeDescription
operation_idstringUUID v4; unique audit record identifier.
client_idstringUUID v4; identifies the client.
session_idstringUUID v4; identifies the session.
file_idstring"<workspace>/<filename>", or NULL.
operation_typestringEvent name (see below).
timestampdatetimeUTC timestamp of record creation.
resultstring"SUCCESS", "FAILED", "SUSPENDED", "DISCONNECTED", or error code.
trust_scorefloatTrust Score T at record creation time.
key_epochuint32Current K3 epoch at record creation time.
prev_versionuint32File version before operation, or NULL.
new_versionuint32File version after operation, or NULL.
prev_hashstringHex SHA-256 of the previous audit record.
record_hashstringHex SHA-256 of this record's chain link.
dnacstringDNAC 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.
Hash-Chained Ledger Audit records MUST be chained to form a tamper-evident ledger: 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 format.
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: The published package is available on PyPI: 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.
Security Considerations
Cryptographic Algorithm Security
  • Elliptic Curve: P-384. Provides 192 bits of security strength , exceeding the NIST 128-bit minimum . P-256 MUST NOT be used where long-term security is required.
  • Key Derivation: HKDF-SHA256 . The info field MUST include a purpose-specific prefix.
  • Symmetric Encryption: AES-256-GCM . 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 using K3.auth_key.
  • Digest: SHA-256 .
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.
Bootstrap Token Security Tokens MUST contain a minimum of 128 bits of entropy . Validation MUST use constant-time string comparison . 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.
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.
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.
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.
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.
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.
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 . Future versions SHOULD incorporate a hybrid key establishment mechanism combining ECDH with a PQ-KEM : This IKM_hybrid replaces the ECDH_secret input to HKDF in K1 derivation. The rest of the key hierarchy (K2, K3) is unchanged.
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.
IANA Considerations
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 .
ValueNameReference
0x01OP_PROVISION
0x02OP_AUTH
0x03OP_TRUST_EVAL
0x04OP_WORKSPACE_AUTH
0x05OP_FILE_OP
0x06OP_LOCK
0x07OP_UNLOCK
0x08OP_DNAC_RECOVERY
0x09OP_REKEY
0x0AOP_HEARTBEAT
0x0BOP_ACK
0x0COP_ERROR
0x0DOP_NACK
0x0EOP_CHUNKReserved; future use
0x0FOP_SYNCReserved; future use
0x10-0xEFUnassigned
0xF0-0xFFPrivate Use
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 .
BitNameValueReference
0READ1
1WRITE2
2APPEND4
3CREATE8
4DELETE16
5RENAME32
6LOCK64
7ADMIN128
8-31Unassigned
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 .
NameReference
REJECT
RETRY
MERGE
REBASE
CONFLICT_VERSION
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 .
CodeNameDescription
0x01INVALID_BOOTSTRAP_TOKENToken not found or already used.
0x02TOKEN_EXPIREDToken validity period elapsed.
0x03AUTH_FAILEDECDH or certificate verification failed.
0x04NO_SESSIONsession_id not found.
0x05FILE_LOCKEDFile held by another session.
0x06VERSION_CONFLICTexpected_version mismatch.
0x07RETRY_REQUIREDClient should re-fetch and retry.
0x08PERMISSION_DENIEDClient lacks required capability.
0x09SESSION_SUSPENDEDTrust score at or below threshold.
0x0ASERVER_BUSYoutstanding_ops limit reached.
0x0BSIGNATURE_INVALIDHMAC verification failed.
0x0CDNAC_MISMATCHDNAC recovery hash mismatch.
0x0DUNKNOWN_OPCODEReceived opcode not recognized.
0x0EFILE_NOT_FOUNDRequested file does not exist.
0x0FWORKSPACE_NOT_FOUNDWorkspace folder does not exist.
References Normative References HMAC: Keyed-Hashing for Message Authentication Key words for use in RFCs to Indicate Requirement Levels UTF-8, a transformation format of ISO 10646 Randomness Requirements for Security A Universally Unique IDentifier (UUID) URN Namespace The Base16, Base32, and Base64 Data Encodings Augmented BNF for Syntax Specifications: ABNF Internet X.509 Public Key Infrastructure Certificate and CRL Profile HMAC-based Extract-and-Expand Key Derivation Function (HKDF) A Recommendation for IPv6 Address Text Representation Case-Sensitive String Support in ABNF Guidelines for Writing an IANA Considerations Section in RFCs Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words The JavaScript Object Notation (JSON) Data Interchange Format ECC Cipher Suites for TLS Versions 1.2 and Earlier The Transport Layer Security (TLS) Protocol Version 1.3 Recommendation for Block Cipher Modes of Operation: GCM and GMAC Secure Hash Standard (SHS) NIST Informative References Common Format and MIME Type for CSV Files Updated Security Considerations for the MD5 Message-Digest and HMAC-MD5 The WebSocket Protocol QUIC: A UDP-Based Multiplexed and Secure Transport Recommendation for Key Management: Part 1 - General Module-Lattice-Based Key-Encapsulation Mechanism Standard NIST Algorithms for Quantum Computation: Discrete Logarithms and Factoring Proceedings of the 35th Annual Symposium on Foundations of Computer Science, pp. 124-134
Protocol State Machine
SCSWP Session State Machine | 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) | +-----------------+ ]]>
Cryptographic Algorithm Rationale
Choice of P-384 P-384 provides 192 bits of security, significantly exceeding the NIST 128-bit minimum . 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.
Choice of HKDF-SHA256 for K1/K2/K3 HKDF 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.
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 .
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.
Example Message Flows
Initial Connection Flow
Initial Connection Message Flow [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} ]]>
File Write Flow (with Lock and Conflict Detection)
File Write Message Flow [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"} ]]>
DNAC Session Recovery Flow
DNAC Session Recovery Message Flow [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] ]]>
Trust Score Rekey Flow
Trust Score Rekey Message Flow [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] ]]>