From 5d141a0eaaaf7059807745bc61de509d3e15d01e Mon Sep 17 00:00:00 2001 From: Albrecht Degering Date: Tue, 21 Jul 2026 20:49:20 +0200 Subject: [PATCH] docs(postbox): define function-bound encrypted vault semantics --- README.md | 13 +++++++-- docs/POSTBOX_CONCEPT.md | 59 ++++++++++++++++++++++++++++++++++++++--- 2 files changed, 67 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 13e2924..872c424 100644 --- a/README.md +++ b/README.md @@ -22,9 +22,18 @@ Core owns auth, tenants, RBAC evaluation, database/session primitives, module di ## Role-bound postboxes -A role-bound postbox is linked to an organizational unit and one or more roles. A person can access that postbox while their identity has an effective matching role in that organizational unit. Access is not tied to a login mailbox, personal email address, or static user assignment. +A function-bound postbox is linked to an organizational unit and one or more +institutional functions. It can exist with zero, one, or several current +incumbents. A person can access it only while their identity has an effective +assignment or time-bounded delegation in that organizational context. Access +is not tied to a login mailbox, personal email address, or static user +assignment. -When the role assignment changes, postbox access changes with it. The postbox keeps durable message and evidence history, while authorization remains derived from current platform role state. +When the assignment changes, postbox access and encrypted key grants change +with it. The postbox keeps durable content and evidence history through +vacancy, hand-over, and delegation; multiple incumbents receive independently +auditable access. Revocation prevents future platform key access but cannot +erase plaintext already fetched or exported. ## Module integration diff --git a/docs/POSTBOX_CONCEPT.md b/docs/POSTBOX_CONCEPT.md index 6c13a95..60f8fa7 100644 --- a/docs/POSTBOX_CONCEPT.md +++ b/docs/POSTBOX_CONCEPT.md @@ -4,7 +4,13 @@ GovOPlaN Postbox provides in-platform postboxes that are addressable containers for messages, files, workflow evidence, and operational handoff. They can be used internally, exposed through portals, and connected to campaign workflows. -The key distinction from a mailbox is ownership. A mailbox is usually bound to a login, user credential, or external mail account. A GovOPlaN postbox is bound to platform context: organization, role, process, portal, campaign, or service responsibility. +The key distinction from a mailbox is ownership. A mailbox is usually bound to +a login, user credential, or external mail account. A GovOPlaN postbox is a +durable communication and content-access container bound to institutional +context: primarily a function in an organizational unit, and where explicitly +needed a role, process, portal, campaign, or service responsibility. It may look +like an inbox for a message task or like a vault for content shared with the +current holders of that responsibility; neither form is owned by one account. The strategic target is an encrypted administrative postbox. The first implementation may start with ordinary persisted messages, but the model must @@ -31,6 +37,13 @@ role for `District Office North` can see the postbox. When the function, delegation, or role mapping is removed or expires, access disappears without moving messages or reassigning a mailbox. +The postbox exists independently of its holders. It remains addressable while +the function is vacant and may accept durable deliveries according to policy; +the UI must then show that no current human holder can open or act on the +content. Assigning one or several incumbents grants access in their explicit +function context. It does not transfer ownership of the container or rewrite +its history. + This makes postboxes useful for responsibilities that outlive individuals: - intake desks @@ -39,6 +52,24 @@ This makes postboxes useful for responsibilities that outlive individuals: - portal message inboxes for organizational responsibilities - file or evidence drops linked to a role in an organization +### Incumbency, hand-over, and delegation + +- Zero, one, or several people may hold a function at the same time. +- A postbox can remain vacant without being deleted, redirected to a personal + account, or losing content. +- A new assignment can grant access to the function's permitted history through + a current key epoch. Which historical epochs a new incumbent receives is an + explicit postbox policy, not an accidental consequence of account creation. +- A delegation is a time-bounded access grant in the represented function + context. Expiry removes future platform key access and action authority; it + cannot destroy plaintext or exports already obtained. +- Hand-over and revocation rotate the function/postbox key epoch. Per-content + data keys should normally be rewrapped; policy may require content + re-encryption for a stronger rotation event. +- Stored content is not silently substituted or overwritten. A correction, + replacement, or new version is a new linked object with provenance while the + previous signed/ciphertext manifest remains governed by retention policy. + ## Authorization Model Postbox authorization should be derived from access-owned identity and role data through core/access contracts. The postbox module stores postbox bindings and postbox-specific permissions, but it should not duplicate membership, group, or role resolution. @@ -106,8 +137,14 @@ Optional consumers: ## Operational Rules -- Current role state controls current access. -- Historical message records remain durable even when no current person holds the role. +- Current function assignment and delegation state controls current access. +- Historical message records remain durable even when no current person holds + the function; vacancy is a visible attention/access state, not a missing + postbox. +- Multiple incumbents receive independent device-bound key grants and remain + distinguishable in access and action evidence. +- Delegation start, expiry, withdrawal, key grant, and key-epoch rotation are + separate auditable events. - Administration of bindings should require explicit postbox administration permission plus access/RBAC authority for the target organization. - Sensitive access decisions and binding changes should emit audit events. - Retention rules should be postbox-owned but able to reference campaign, file, and portal provenance. @@ -194,3 +231,19 @@ Before the data model is considered stable, verify that it can represent: - external recipient token state - expiry and withdrawal state separate from deletion - retention state that can operate without decrypting content + +## E2EE decisions still to settle before implementation + +The product direction above is selected, but the first trusted profile still +needs bounded decisions on: + +- whether a new incumbent receives all retained history, history from a + policy-defined date, or only content delivered during the assignment; +- organizational recovery/escrow and the authority required when every holder + loses all registered device keys; +- whether ordinary rotation only rewraps per-content keys or also re-encrypts + ciphertext, and which events require the stronger path; +- assurance and quorum requirements for delegation, hand-over, emergency + access, export, and destructive retention; and +- how attention/escalation works during a vacancy without granting plaintext + access to an unrelated personal account.