secdispatch S. Hebbar Internet-Draft S. Hiremani Intended status: Experimental Independent Expires: 23 February 2027 22 August 2026 Secure Collaborative State Workspace Protocol (SCSWP) draft-hebbar-hiremani-scswp-01 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/. Hebbar & Hiremani Expires 23 February 2027 [Page 1] Internet-Draft SCSWP August 2026 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. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Design Principles . . . . . . . . . . . . . . . . . . . . 6 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6 3. Protocol Overview and Architecture . . . . . . . . . . . . . 8 3.1. Three-Plane Architecture . . . . . . . . . . . . . . . . 10 3.2. Full Protocol Lifecycle . . . . . . . . . . . . . . . . . 10 4. Client Provisioning and Bootstrap . . . . . . . . . . . . . . 11 4.1. Client Identity Registration . . . . . . . . . . . . . . 11 4.2. Key-Dissolving Bootstrap Mechanism . . . . . . . . . . . 12 4.3. Bootstrap Token Expiration . . . . . . . . . . . . . . . 13 5. Mutual Authentication and Key Establishment . . . . . . . . . 13 5.1. X.509 Certificate Authentication . . . . . . . . . . . . 13 5.2. ECDH Key Exchange . . . . . . . . . . . . . . . . . . . . 14 5.3. K1 — Session Root Key Derivation . . . . . . . . . . . . 14 6. Trust Plane — Dynamic D/N/P/S Evaluation . . . . . . . . . . 15 6.1. D/N/P/S Context Structure . . . . . . . . . . . . . . . . 15 6.2. Continuous Trust Evaluation . . . . . . . . . . . . . . . 16 6.3. Trust Scoring and Policy Actions . . . . . . . . . . . . 16 7. Authorization Plane and Workspace Key Derivation . . . . . . 17 7.1. Per-Client Capability Model . . . . . . . . . . . . . . . 18 7.2. K2 — Workspace Authorization Key Derivation . . . . . . . 19 7.3. K3 — Active Session Key Derivation and Epoch System . . . 19 8. Secure Transport and Message Envelope . . . . . . . . . . . . 20 8.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 20 Hebbar & Hiremani Expires 23 February 2027 [Page 2] Internet-Draft SCSWP August 2026 8.2. Protocol Message Format . . . . . . . . . . . . . . . . . 20 8.3. Secure Envelope . . . . . . . . . . . . . . . . . . . . . 21 8.4. OpCode Registry . . . . . . . . . . . . . . . . . . . . . 21 9. Congestion Control and Resource Management . . . . . . . . . 23 9.1. Application-Level Flow Control . . . . . . . . . . . . . 23 9.2. Dynamic Worker-Pool Scheduler . . . . . . . . . . . . . . 23 9.3. Per-Client Resource Debt . . . . . . . . . . . . . . . . 23 10. Workspace Plane — File Concurrency and Version Control . . . 23 10.1. File State Record . . . . . . . . . . . . . . . . . . . 24 10.2. Mutual Exclusion Locking . . . . . . . . . . . . . . . . 24 10.3. Optimistic Version Control and Conflict Policies . . . . 25 10.4. Operation Idempotency . . . . . . . . . . . . . . . . . 25 11. DNAC — Dynamic Network and Access Continuity . . . . . . . . 26 11.1. DNAC State Digest Construction . . . . . . . . . . . . . 26 11.2. DNAC Chain Evolution . . . . . . . . . . . . . . . . . . 26 11.3. Session Recovery via DNAC . . . . . . . . . . . . . . . 26 12. Audit and State Ledger . . . . . . . . . . . . . . . . . . . 27 12.1. Audit Record Structure . . . . . . . . . . . . . . . . . 27 12.2. Hash-Chained Ledger . . . . . . . . . . . . . . . . . . 29 13. Reference Implementation . . . . . . . . . . . . . . . . . . 29 14. Security Considerations . . . . . . . . . . . . . . . . . . . 29 14.1. Cryptographic Algorithm Security . . . . . . . . . . . . 29 14.2. Key Material Handling . . . . . . . . . . . . . . . . . 30 14.3. Bootstrap Token Security . . . . . . . . . . . . . . . . 30 14.4. Trust Score Manipulation . . . . . . . . . . . . . . . . 30 14.5. File Lock Security . . . . . . . . . . . . . . . . . . . 30 14.6. Audit Ledger Integrity . . . . . . . . . . . . . . . . . 30 14.7. Version Conflict Policies and Data Integrity . . . . . . 31 14.8. Session Suspension and Denial of Service . . . . . . . . 31 14.9. Post-Quantum Cryptography Considerations . . . . . . . . 31 14.10. Privacy Considerations . . . . . . . . . . . . . . . . . 31 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 15.1. SCSWP OpCode Registry . . . . . . . . . . . . . . . . . 31 15.2. SCSWP Capability Flags Registry . . . . . . . . . . . . 32 15.3. SCSWP Conflict Policy Registry . . . . . . . . . . . . . 33 15.4. SCSWP Error Code Registry . . . . . . . . . . . . . . . 34 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 16.1. Normative References . . . . . . . . . . . . . . . . . . 35 16.2. Informative References . . . . . . . . . . . . . . . . . 36 Appendix A. Protocol State Machine . . . . . . . . . . . . . . . 37 Appendix B. Cryptographic Algorithm Rationale . . . . . . . . . 38 B.1. Choice of P-384 . . . . . . . . . . . . . . . . . . . . . 39 B.2. Choice of HKDF-SHA256 for K1/K2/K3 . . . . . . . . . . . 39 B.3. Choice of AES-256-GCM . . . . . . . . . . . . . . . . . . 39 B.4. Key Separation and Purpose Binding . . . . . . . . . . . 39 Appendix C. Example Message Flows . . . . . . . . . . . . . . . 39 C.1. Initial Connection Flow . . . . . . . . . . . . . . . . . 39 C.2. File Write Flow (with Lock and Conflict Detection) . . . 40 Hebbar & Hiremani Expires 23 February 2027 [Page 3] Internet-Draft SCSWP August 2026 C.3. DNAC Session Recovery Flow . . . . . . . . . . . . . . . 41 C.4. Trust Score Rekey Flow . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 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: a. *Client Provisioning:* Centrally managed, server-authorized client creation using a Key-Dissolving bootstrap mechanism that controls protocol entry without replacing cryptographic authentication. b. *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. c. *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. d. *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. e. *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. Hebbar & Hiremani Expires 23 February 2027 [Page 4] Internet-Draft SCSWP August 2026 f. *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. g. *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. h. *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. i. *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. Hebbar & Hiremani Expires 23 February 2027 [Page 5] Internet-Draft SCSWP August 2026 * 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. Hebbar & Hiremani Expires 23 February 2027 [Page 6] Internet-Draft SCSWP August 2026 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]. Hebbar & Hiremani Expires 23 February 2027 [Page 7] Internet-Draft SCSWP August 2026 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: Hebbar & Hiremani Expires 23 February 2027 [Page 8] Internet-Draft SCSWP August 2026 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 Hebbar & Hiremani Expires 23 February 2027 [Page 9] Internet-Draft SCSWP August 2026 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. Hebbar & Hiremani Expires 23 February 2027 [Page 10] Internet-Draft SCSWP August 2026 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. Hebbar & Hiremani Expires 23 February 2027 [Page 11] Internet-Draft SCSWP August 2026 *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: a. Atomically set is_active=TRUE (Key-Dissolving step). b. Create a new SessionState record (session_id, initial trust score of 100.0). c. Load the Client Capability Record for this client. d. Respond with OP_ACK carrying client_id, cert_pem, and capability_bits. 5. If any check fails: a. Respond with OP_ERROR carrying the appropriate error code. Hebbar & Hiremani Expires 23 February 2027 [Page 12] Internet-Draft SCSWP August 2026 b. 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=. * Issuer: The server CA distinguished name. Hebbar & Hiremani Expires 23 February 2027 [Page 13] Internet-Draft SCSWP August 2026 * Validity: RECOMMENDED not to exceed 365 days. * SubjectAlternativeName: DNSName=. * 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]. Hebbar & Hiremani Expires 23 February 2027 [Page 14] Internet-Draft SCSWP August 2026 * 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": , "network_ip": , "port": , "session_id": , "epoch": , "dnac": } ABNF for the JSON object: Hebbar & Hiremani Expires 23 February 2027 [Page 15] Internet-Draft SCSWP August 2026 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:* Hebbar & Hiremani Expires 23 February 2027 [Page 16] Internet-Draft SCSWP August 2026 +==================================+=====================+ | 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 | +----------------------------------+---------------------+ Table 1 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 Hebbar & Hiremani Expires 23 February 2027 [Page 17] Internet-Draft SCSWP August 2026 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: +=====+========+=======+========================================+ | 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. | +-----+--------+-------+----------------------------------------+ Table 2 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:* Hebbar & Hiremani Expires 23 February 2027 [Page 18] Internet-Draft SCSWP August 2026 +============+========================+=================+ | Preset | Bits Set | Effective Value | +============+========================+=================+ | READ_ONLY | READ | 1 | +------------+------------------------+-----------------+ | READ_WRITE | READ|WRITE|CREATE|LOCK | 75 | +------------+------------------------+-----------------+ | FULL | All bits set | 255 | +------------+------------------------+-----------------+ Table 3 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 Hebbar & Hiremani Expires 23 February 2027 [Page 19] Internet-Draft SCSWP August 2026 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: a. The Trust Score T falls below REKEY_THRESHOLD. b. The server receives an explicit OP_REKEY request from the client. c. Session recovery via DNAC (Section 11.3) completes. d. 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": , "session_id": , "epoch": , "payload": } ABNF for the message envelope: Hebbar & Hiremani Expires 23 February 2027 [Page 20] Internet-Draft SCSWP August 2026 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: Hebbar & Hiremani Expires 23 February 2027 [Page 21] Internet-Draft SCSWP August 2026 +=======+===================+===========+===================+ | 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 | +-------+-------------------+-----------+-------------------+ Table 4 OP_FILE_OP Sub-Operations (carried in payload "op" field): LIST, READ, WRITE, APPEND. See Section 15.1 for IANA registration of these opcodes. Hebbar & Hiremani Expires 23 February 2027 [Page 22] Internet-Draft SCSWP August 2026 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 Hebbar & Hiremani Expires 23 February 2027 [Page 23] Internet-Draft SCSWP August 2026 10.1. File State Record The server MUST maintain a File State Record for every file operated on within a workspace, containing at minimum: +============+==========+==================================+ | 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. | +------------+----------+----------------------------------+ Table 5 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 Hebbar & Hiremani Expires 23 February 2027 [Page 24] Internet-Draft SCSWP August 2026 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. Hebbar & Hiremani Expires 23 February 2027 [Page 25] Internet-Draft SCSWP August 2026 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: +===========================+========================+ | Event | state_digest | +===========================+========================+ | Successful bootstrap | "BOOTSTRAP" | +---------------------------+------------------------+ | Successful authentication | "AUTH_OK" | +---------------------------+------------------------+ | Successful WRITE v{N} | ":v" | +---------------------------+------------------------+ | Successful READ | "READ:" | +---------------------------+------------------------+ | Trust evaluation | "TRUST:" | +---------------------------+------------------------+ Table 6 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. Hebbar & Hiremani Expires 23 February 2027 [Page 26] Internet-Draft SCSWP August 2026 1. Client sends OP_DNAC_RECOVERY: { "client_id": "", "last_dnac": "" } 2. Server looks up the most recently persisted DNAC tip for client_id. 3. If last_dnac matches the persisted DNAC tip: a. The server MUST NOT reuse the previous session's K3 keys. b. The server MUST generate a fresh epoch_nonce and rotate K3 to a new epoch. c. The server responds: OP_ACK { "status": "SESSION_RESTORED", "session_id": "", "epoch": , "epoch_nonce_b64": "" } 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: Hebbar & Hiremani Expires 23 February 2027 [Page 27] Internet-Draft SCSWP August 2026 +================+==========+===================================+ | 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 | "/", 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. | +----------------+----------+-----------------------------------+ Table 7 Operation type values: BOOTSTRAP, AUTH, TRUST_EVAL, WORKSPACE_AUTH, LIST, READ, WRITE, APPEND, LOCK, UNLOCK, REKEY, DNAC_RECOVERY, HEARTBEAT, DISCONNECT. Hebbar & Hiremani Expires 23 February 2027 [Page 28] Internet-Draft SCSWP August 2026 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. Hebbar & Hiremani Expires 23 February 2027 [Page 29] Internet-Draft SCSWP August 2026 * *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. Hebbar & Hiremani Expires 23 February 2027 [Page 30] Internet-Draft SCSWP August 2026 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]. Hebbar & Hiremani Expires 23 February 2027 [Page 31] Internet-Draft SCSWP August 2026 +===========+===================+======================+ | 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 | | +-----------+-------------------+----------------------+ Table 8 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]. Hebbar & Hiremani Expires 23 February 2027 [Page 32] Internet-Draft SCSWP August 2026 +======+============+=======+=============+ | 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 | | | +------+------------+-------+-------------+ Table 9 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]. +==================+==============+ | Name | Reference | +==================+==============+ | REJECT | Section 10.3 | +------------------+--------------+ | RETRY | Section 10.3 | +------------------+--------------+ | MERGE | Section 10.3 | +------------------+--------------+ | REBASE | Section 10.3 | +------------------+--------------+ | CONFLICT_VERSION | Section 10.3 | +------------------+--------------+ Table 10 Hebbar & Hiremani Expires 23 February 2027 [Page 33] Internet-Draft SCSWP August 2026 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]. +======+=========================+==================================+ | 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. | +------+-------------------------+----------------------------------+ Hebbar & Hiremani Expires 23 February 2027 [Page 34] Internet-Draft SCSWP August 2026 | 0x0E | FILE_NOT_FOUND | Requested file does | | | | not exist. | +------+-------------------------+----------------------------------+ | 0x0F | WORKSPACE_NOT_FOUND | Workspace folder | | | | does not exist. | +------+-------------------------+----------------------------------+ Table 11 16. References 16.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005, . [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, . [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, May 2008, . Hebbar & Hiremani Expires 23 February 2027 [Page 35] Internet-Draft SCSWP August 2026 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010, . [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, December 2014, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, . [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "ECC Cipher Suites for TLS Versions 1.2 and Earlier", RFC 8422, August 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018, . [NIST.SP.800-38D] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: GCM and GMAC", NIST Special Publication 800-38D, November 2007, . [FIPS.PUB.180-4] NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015, . 16.2. Informative References [RFC4180] Shafranovich, Y., "Common Format and MIME Type for CSV Files", RFC 4180, October 2005, . Hebbar & Hiremani Expires 23 February 2027 [Page 36] Internet-Draft SCSWP August 2026 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and HMAC-MD5", RFC 6151, March 2011, . [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021, . [NIST.SP.800-57] Barker, E., "Recommendation for Key Management: Part 1 - General", NIST Special Publication 800-57 Part 1 Rev. 5, May 2020, . [NIST.PQC.FIPS.203] NIST, "Module-Lattice-Based Key-Encapsulation Mechanism Standard", FIPS 203, August 2024, . [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, 1994. Appendix A. Protocol State Machine Hebbar & Hiremani Expires 23 February 2027 [Page 37] Internet-Draft SCSWP August 2026 +-------------+ 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 Hebbar & Hiremani Expires 23 February 2027 [Page 38] Internet-Draft SCSWP August 2026 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 Hebbar & Hiremani Expires 23 February 2027 [Page 39] Internet-Draft SCSWP August 2026 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 Hebbar & Hiremani Expires 23 February 2027 [Page 40] Internet-Draft SCSWP August 2026 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 Email: sripadkarthik@gmail.com Sharan Hiremani Independent Email: sharanrhiremani@gmail.com Hebbar & Hiremani Expires 23 February 2027 [Page 41]