Status. Proposed design only. Nothing in this vault is DG client approval. No application, service or test has been executed; every scenario is Not executed. Fees and dates are open.
Authentication and authorization
Purpose
The order in which a request earns access.
Source notes
API-and-Request-Pipeline, Permissions-and-Confidentiality, Step-02-Identity-Membership-Roles, Step-03-Policy-Pipeline-and-Isolation-Harness.
Current state
Proposed.
Contract
- Authenticate: valid session. Provider is Blocked by Q09; use the
IdentityProviderport (Integration-Ports). - Resolve membership: exactly one active membership. Balanced allows one company per user (Q01). A client-supplied company or actor id is never trusted.
- Authorise the record: role, assignment, ownership and, for private engagements, participation. Roles and limits are in Permissions-and-Confidentiality; the role matrix details are Blocked by Q02.
- Validate version and transition, then commit mutation and event together.
Denial behaviour
Unauthorised and non-existent private objects produce an indistinguishable denial (T27). The exact shape is Blocked by Q08. Revocation blocks future access, not copies already legitimately seen (T25); the in-flight boundary is Blocked by Q07.
DG administrators
Membership approval and revocation with MFA (Step-09-DG-Membership-Tool-and-Metadata). No private message content by default; any support access needs a new decision (Q08).
Invariants
Deny by default. Re-check access when a message is queued, before delivery, and when a link is opened. An email link is not an access grant.
Scenarios
T01, T02, T25, T26, T27, T28, T37.
Change history
| Date | Change |
|---|---|
| 2026-10-20 | Created (bootstrap Phase 2) |