diff --git a/Codex-Project-Index.md b/Codex-Project-Index.md index 87a0270..00bc215 100644 --- a/Codex-Project-Index.md +++ b/Codex-Project-Index.md @@ -5,5 +5,4 @@ This page is generated from repository and product-directory project files. - [Repo-README](Repo-README) - `/mnt/DATA/git/govoplan-postbox/README.md` -- [Repo-docs-POSTBOX-BACKLOG](Repo-docs-POSTBOX-BACKLOG) - `/mnt/DATA/git/govoplan-postbox/docs/POSTBOX_BACKLOG.md` - [Repo-docs-POSTBOX-CONCEPT](Repo-docs-POSTBOX-CONCEPT) - `/mnt/DATA/git/govoplan-postbox/docs/POSTBOX_CONCEPT.md` diff --git a/Repo-docs-POSTBOX-CONCEPT.md b/Repo-docs-POSTBOX-CONCEPT.md index 0ed6c16..5b94c6a 100644 --- a/Repo-docs-POSTBOX-CONCEPT.md +++ b/Repo-docs-POSTBOX-CONCEPT.md @@ -1,4 +1,4 @@ - + > Mirrored from `/mnt/DATA/git/govoplan-postbox/docs/POSTBOX_CONCEPT.md`. > Origin: `repository`. @@ -13,6 +13,13 @@ GovOPlaN Postbox provides in-platform postboxes that are addressable containers 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 strategic target is an encrypted administrative postbox. The first +implementation may start with ordinary persisted messages, but the model must +not prevent later end-to-end encryption, role/function key epochs, signed +manifests, external-recipient tokens, or honest retraction semantics. The +cross-module target architecture is recorded in +`govoplan-core/docs/POSTBOX_E2EE_ARCHITECTURE.md`. + ## Role-Organization-Bound Access The special access pattern is a postbox 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. @@ -94,6 +101,11 @@ Optional consumers: - 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. +- Expiry, withdrawal, and retraction UI must distinguish future access control + from already fetched or decrypted plaintext. +- Message metadata should preserve room for ciphertext manifests, wrapped keys, + key epochs, recipient device references, and external capability tokens even + before full E2EE ships. ## First Implementation Shape @@ -108,3 +120,16 @@ The WebUI should start as an administration and inbox surface: - audit-visible administrative actions Campaign, files, portal, and mail behavior should arrive as optional integrations after the core postbox model is stable. + +## E2EE Readiness Checklist + +Before the data model is considered stable, verify that it can represent: + +- message or attachment ciphertext references +- signed manifest references +- recipient, role, or function key wrapping records +- key epoch and device-key references +- key-fetch/access audit events +- external recipient token state +- expiry and withdrawal state separate from deletion +- retention state that can operate without decrypting content