From a7a4db5a89d775a88ccdc00a4b2d69cecbf1931b Mon Sep 17 00:00:00 2001 From: tegwick Date: Wed, 23 Sep 2026 20:08:46 +0200 Subject: [PATCH] Record A11 r2/A12 r3 assent and the railiance-clock owner review - 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 Assistant: claude-code Assistant-Model: opus Assistant-Process: 299762@bnt-lap001 Assistant-Session: d3d3cea1-869c-44f1-be2a-3d6d3550e72e --- ...iliance-clock-identity-and-layer-review.md | 100 ++++++++++++++++++ ...ion-11-amendments-a11r2-a12r3-positions.md | 23 ++++ ...K-WP-0040-execution-attribution-receipt.md | 58 ++++++++++ 3 files changed, 181 insertions(+) create mode 100644 history/2026-09-23-railiance-clock-identity-and-layer-review.md create mode 100644 history/2026-09-23-section-11-amendments-a11r2-a12r3-positions.md create mode 100644 workplans/NK-WP-0040-execution-attribution-receipt.md diff --git a/history/2026-09-23-railiance-clock-identity-and-layer-review.md b/history/2026-09-23-railiance-clock-identity-and-layer-review.md new file mode 100644 index 0000000..b35d992 --- /dev/null +++ b/history/2026-09-23-railiance-clock-identity-and-layer-review.md @@ -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. diff --git a/history/2026-09-23-section-11-amendments-a11r2-a12r3-positions.md b/history/2026-09-23-section-11-amendments-a11r2-a12r3-positions.md new file mode 100644 index 0000000..76c4e6c --- /dev/null +++ b/history/2026-09-23-section-11-amendments-a11r2-a12r3-positions.md @@ -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`. diff --git a/workplans/NK-WP-0040-execution-attribution-receipt.md b/workplans/NK-WP-0040-execution-attribution-receipt.md new file mode 100644 index 0000000..ffe21b9 --- /dev/null +++ b/workplans/NK-WP-0040-execution-attribution-receipt.md @@ -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.