feat: integrate durable authorization audit and runtime composition
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0e747-8f27-7242-8df8-8bc44f88c929
This commit is contained in:
parent
3e386147fd
commit
c9b6916dac
14 changed files with 767 additions and 16 deletions
|
|
@ -47,8 +47,9 @@ A host composes `create_app(access_controller=AccessController(...))` with:
|
|||
set. The token is reread on every call and is separate from the end-user token.
|
||||
Remote `/v1/keys` responses never establish their own trust. Current/previous keys
|
||||
can coexist in the mounted trust file; removing a key takes effect next call.
|
||||
- `Audit.append`: an **owner implementation still owed** that returns only after
|
||||
durable acceptance. Every allow must reach this sink before handler execution;
|
||||
- `AuditCoreSink`: implemented against the owner
|
||||
[eight-field ingestion contract](../../audit-core/docs/event-envelope.md), returning
|
||||
only after an operational-custody probe and explicit durable acceptance. Every allow must reach this sink before handler execution;
|
||||
a failed sink blocks reads as well as writes. Authorization receipts say
|
||||
`authorized`, not “operation completed.” Domain commit/outcome audit remains a
|
||||
separate requirement; this source seam does not claim transactional audit.
|
||||
|
|
@ -58,7 +59,10 @@ A host composes `create_app(access_controller=AccessController(...))` with:
|
|||
Do not implement these missing adapters as a constant allow, in-memory audit sink,
|
||||
or an assertion copied from token claims. Tests use synthetic owners explicitly.
|
||||
The current CLI deliberately provides no fixture adapter or production bypass.
|
||||
A deployment composition factory and dependency health probes remain T02–T04 work.
|
||||
An explicit `SecuritySettings`/owner-facts composition now owns the HTTP client
|
||||
and closes it with the runtime. Audit custody is probed per append. Real owner-facts
|
||||
admission and additional owner dependency probes remain T02–T04 work; see the
|
||||
[owner integration review](owner-access-integration.md).
|
||||
|
||||
For this candidate all Hub resources are explicitly **platform-owned**. Other
|
||||
target tenants are refused. Root requires AAL2/3, active account and tenants,
|
||||
|
|
@ -124,8 +128,8 @@ browser PKCE sessions/logout and real MCP root login remain open.
|
|||
2. T02: immutable root binding, registered audience/redirects, PKCE/MFA/recovery,
|
||||
admitted live facts adapters, attended login/logout and revocation receipts.
|
||||
3. T03: dedicated Hub policy and fact provenance review; authenticated deployment,
|
||||
credential/key custody, durable audit implementation and native rotation probes.
|
||||
4. T04–T05: composed deployable runtime, dependency health probes, all client/extension
|
||||
credential/key custody, real Audit Core sender admission and native rotation probes.
|
||||
4. T04–T05: deploy the admitted composition, complete dependency health probes and all client/extension
|
||||
migrations, domain outcome audit, legacy lane rollback and full root journeys.
|
||||
5. T06–T08: every platform/Railiance receipt, separate public-enable approval and
|
||||
later role/delegation/tenant isolation. No milestone is closed by local fixtures.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue