docs(postbox): define function-bound encrypted vault semantics
This commit is contained in:
13
README.md
13
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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user