net-kingdom/history/2026-09-23-railiance-clock-identity-and-layer-review.md

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.