# 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.