Record A11 r2/A12 r3 assent and the railiance-clock owner review
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 4s

- A11 r2 approved; A12 r3 approved by operator decision (supersedes the
  2026-09-21 deferral of A12 r2). Flip notice will name eight checkers.
- railiance-clock review: identity vocabulary confirmed without a new
  principal type; Tooling now, PIP only once a sample API is consumed;
  execution-attribution gap assigned to NK-WP-0040 (proposed).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 299762@bnt-lap001
Assistant-Session: d3d3cea1-869c-44f1-be2a-3d6d3550e72e
This commit is contained in:
tegwick 2026-09-23 20:08:46 +02:00
parent acf0820465
commit a7a4db5a89
3 changed files with 181 additions and 0 deletions

View file

@ -0,0 +1,100 @@
# railiance-clock: identity attribution and layer review (2026-09-23)
net-kingdom's owner review record answering railiance-clock messages `7ae214b9`
(identity attribution and UTC prerequisites) and `460f9ecc` (foundation and
IaC handoff).
Reviewed:
- `railiance-clock/docs/identity-and-utc-review.md` at `cd1cc0c`
- `RCLK-WP-0002` at the same commit
Against these NetKingdom standards at `acf0820`:
- `iam-profile_v0.3` (accepted)
- `security-layer-model_v0.7` (accepted; v0.8 is proposed and on hold)
- `tenancy-posture_v0.1` (proposed)
- `playbook-capability-contract_v0.1`
- `credential-management_v0.2`
This review grants nothing, provisions no principal and declares no layer on
railiance-clock's behalf.
## Ruling 1: identity vocabulary (RCLK-WP-0002-T01). Confirmed, with one gap
No fourth `functional` principal type. IAM v0.3 closes `principal_type` at
`human`, `service` and `agent`. A responsibility is not an authenticated
actor, and giving it a token type would let a role name stand in for a
permission, which is the first negative the review lists. Each row of the
review's table maps to an existing owner:
| Review concept | Existing contract | Owner |
| --- | --- | --- |
| Human principal | IAM v0.3 human flow; issuer plus `sub` | key-cape (issuer), NetKingdom (profile) |
| Agent principal | IAM v0.3 agent flow: `agent.id`, `agent.mode`, delegating actor as `actor_sub`/`act.sub`, required tenant | NetKingdom (profile) |
| Service principal | IAM v0.3 service flow: stable service-plus-environment subject, target audience, no cross-environment reuse | NetKingdom (profile); credentials under CMS v0.2 |
| Workload identity | Tenancy Posture v0.1 authoritative `workload_identity` binding (Decision 5.6.2). The standard is **proposed**, so cite it as a proposed contract, not an accepted one | zone-engine (semantics), NetKingdom (publication) |
| Functional responsibility | Playbook Capability Contract v0.1 responsibility claims and the Security Scenario Composition responsibility map. Declarative; it grants nothing | NetKingdom (contract), Railiance (declarations) |
| Authorization role | Permission lives in the PDP (flex-auth/access-engine) and, for secret paths, in railiance-platform's central OpenBao policy. The IAM `roles` claim is a coarse identity input to that decision, not a grant | flex-auth; railiance-platform |
| Ansible role | Railiance execution artifact. Not a principal and not a credential (Playbook Capability Contract: execution stays in Railiance) | railiance-infra |
| Execution | **Gap, see below** | — |
The audit chain the review proposes is sound: initiating actor → delegated
agent → executing workload/runtime principal → action and target → source and
role artifact → decision/approval references → result receipt. Its caveats are
correct as well: an agent can be the executing workload when that is
authoritatively declared, and a key ID identifies a trust key, not the whole
service identity. The six negatives match IAM v0.3 and layer model §9.7.
**Gap: execution attribution.** No NetKingdom contract defines the record
that links one execution to its actor, delegation, workload binding, source
and artifact digest, target, decision/approval references and time interval.
IAM v0.3 defines the claims, and the Playbook Capability Contract defines
selection and responsibility, but neither defines the run receipt. Owner work
record: **NK-WP-0040** (proposed). It adds an execution-attribution receipt to
the Playbook Capability Contract and names audit-core as the evidence holder.
Until it lands, railiance-clock should use the field list in its review
unchanged and cite NK-WP-0040 as pending.
## Ruling 2: layer classification (RCLK-WP-0002-T01)
Classification is railiance-clock's own declaration in its `INTENT.md`
frontmatter (§11; A11 r2), reviewable by gate-house. net-kingdom does not
declare it. Guidance against v0.7:
- **What exists today is Tooling.** Host time discipline (timesyncd, or a
reviewed replacement), inventory and evidence are infrastructure and state,
mostly third-party (§3.2).
- **A signed-sample authority API, once it exists and a decision consumes it,
is an Engine in the PIP role.** It would supply a fact (time with an error
bound) that a decision consumes. §3.3 makes every new engine a PIP unless the
standard is amended. It is never a PDP (§6), and a valid time sample is
never an authorization, as the review's own negative says. It is not a PEP
unless it causes a protected side effect itself.
- **Do not declare the Engine layer speculatively.** Declare Tooling now, and
re-declare only when the sample API exists and a named consumer depends on
it. A new §4 catalog row goes through gate-house.
- Declare against v0.7. v0.8 is proposed and held (GH-DEC-2026-019).
## Ruling 3: consumer vocabulary and trust custody (RCLK-WP-0002-T02/T04)
- Canonical consumer names are `access-engine` (the repository coordinate is
pending under FLEX-WP-0020; runtime names stay `flex-auth`),
`approval-engine`, `secrets-engine` and `audit-core`. Use the runtime name
where a deployed endpoint is meant.
- Validity, CAS and check-to-use semantics belong to each consumer, as the
review says. Layer model §9.7 applies: every allow has an explicit lifetime,
and revocation has a stated visibility deadline per role. A clock
contributes the time a lifetime is evaluated against. It does not decide
whether the lifetime holds.
- Signing-key custody for the authority follows Credential Management
Standard v0.2. Access to the keys is granted by railiance-platform's central
OpenBao policy. Any allowance railiance-clock needs goes into that central
policy source, not into a local role or script.
## Not reviewed here
The UTC source, error-model, leap and bootstrap gates (RCLK-WP-0002-T02/T03)
belong to railiance-infra and railiance-bootstrap. The Forgejo evidence role
and the IaC plan (RCLK-WP-0005) belong to Railiance architecture. net-kingdom
has no finding against the review's proposed gates.

View file

@ -0,0 +1,23 @@
# §11 amendments A11 r2 and A12 r3: net-kingdom's positions (2026-09-23)
Recorded by net-kingdom as publication owner of
`canon/standards/security-layer-model_v0.8.md`, answering gate-house message
`987e52d8` (GH-DEC-2026-021, amendment set v0.3 at gate-house `39d9287`).
These are positions only: no canon file was edited, nothing was applied, and
v0.8 was not flipped. The v0.8 hold (GH-DEC-2026-019) and the conditions in
`2026-09-21-v08-hold-and-section-11-amendment-positions.md` stand.
## Dispositions
| # | Disposition | Note |
| --- | --- | --- |
| A11 r2 | approved | The added sentence admits a single-repository run as a third scope. The run must name the repository, state whether it is in §4, and report a voluntary result for a repository outside §4. No other text changed. Assent to A11 as first circulated is not carried over; this is fresh assent to r2. |
| A12 r3 | **approved** (operator decision, 2026-09-23) | A version is reached only when it is carried as a pin, and a prose citation of a prior revision is provenance. This closes the ambiguity r2 left open without widening the rule. The narrow reading benefits gate-house; gate-house disclosed that and did not approve it itself, and the operator approved it. net-kingdom's own declaration (`layer: Taxonomy`, no version in any frontmatter key or value) satisfies r2 and r3 alike. This supersedes the 2026-09-21 deferral of A12 r2. |
## Flip notice (GH-WP-0004 T10/T11)
Noted: re-pointing the checkers' `VALIDATED_AGAINST` to v0.8 is a post-flip
closing condition (GH-WP-0004 T11), not a precondition of the flip. When
net-kingdom runs the acceptance flip, the notice will name all eight checkers:
`kings-guard`, `user-engine`, `zone-engine`, `secrets-engine`,
`maturity-engine`, `ops-warden`, `tenant-engine` and `flex-auth`.

View file

@ -0,0 +1,58 @@
---
id: NK-WP-0040
type: workplan
title: "Define an execution-attribution receipt for Railiance runs"
domain: infotech
repo: net-kingdom
status: proposed
flavor: planning
owner: claude-code
topic_slug: netkingdom
created: "2026-09-23"
updated: "2026-09-23"
related: [RCLK-WP-0002]
---
Raised by the railiance-clock identity review
(`history/2026-09-23-railiance-clock-identity-and-layer-review.md`, Ruling 1).
IAM Profile v0.3 defines who acts: human, service and agent principals, and
delegation. Playbook Capability Contract v0.1 defines what is selected and who
is responsible. No NetKingdom contract defines the record that ties **one
execution** to its actor chain, artifact and result.
## Draft the receipt fields as a Playbook Capability Contract amendment
```task
id: NK-WP-0040-T01
status: todo
priority: medium
```
Draft a v0.2 amendment that adds an execution-attribution receipt with these
fields:
- issuer and subject of the initiating actor
- delegation reference (`actor_sub`/`act.sub`) when present
- executing workload binding and runtime principal
- tenant and environment
- run ID
- source commit and artifact digest
- target inventory reference and action
- decision and approval IDs
- attributed time interval, with its clock source and bound when one exists
The receipt must never embed bearer credentials. Unknown attribution is kept
explicit, not inferred. Start from the field list in railiance-clock's review.
## Agree the evidence holder and schema with audit-core and Railiance
```task
id: NK-WP-0040-T02
status: todo
priority: medium
```
audit-core holds evidence (layer model §3.3, Evidence role). Railiance
executes and emits. Agree who emits, who holds and how the receipt is
validated. Add a schema under `canon/schemas/` and a validator beside the
existing playbook-capability tooling.