railiance-clock/docs/identity-and-utc-review.md

Identity and host UTC contract review

Status: identity vocabulary confirmed by NetKingdom on 2026-09-23; UTC policy and remaining owner gates are still open in RCLK-WP-0002-T01/T02/T03. See the September 28 disposition for the pinned owner review, Tooling declaration and existing NK-WP-0040 receipt-schema gap. This review authorizes no principal provisioning, policy grant or production use.

Source baseline

Reviewed NetKingdom commit 8dc5050aa380f1864d8ffbf80bd07c131f7df895:

• canon/standards/iam-profile_v0.3.md: accepted; principal types human, service and agent, issuer-scoped subjects and delegated actor attribution.
• canon/standards/security-layer-model_v0.7.md: accepted baseline.
• canon/standards/security-layer-model_v0.8.md: proposed successor, not automatically adopted by this review.
• canon/standards/tenancy-posture_v0.1.md: proposed; useful explicit workload identity/binding model, with adoption status to be confirmed by its owner.

S1 ownership is established by railiance-master ADR-0004 and railiance-infra's reef source map. The live host receipt is evidence/2026-09-14-railiance01-clock-inventory.json.

Identity vocabulary and proposed execution attribution

The user's human/agentic/functional distinction should build on existing principal types. Do not add a fourth functional token principal type merely to represent an operational responsibility. The following concepts need separate references:

Concept	Clock deployment example	Meaning
Human principal	Operator requesting or approving a deployment	Accountable actor, issuer plus subject
Agent principal	Agent preparing or initiating the change	Own identity plus delegation when applicable
Service principal	Runner or authority service runtime credential	Machine identity scoped to environment/audience
Workload identity	Independently governed deployment runner or clock service	Stable execution unit bound to runtime principals
Functional responsibility	Host time operator, clock sample provider	Responsibility/capability; does not itself grant access
Authorization role	Reviewed permission to converge host time configuration	Policy assignment with scope and lifecycle
Ansible role	Versioned host time role in railiance-infra	Reusable code artifact; not a credential or principal
Execution	One invocation against a reviewed inventory	Run ID linking actor, executor, artifact and result

Proposed audit chain: initiating actor → delegated agent (when present) → executing workload/runtime principal → action and target → exact source and Ansible role artifact → native decision/approval references → result receipt. An agent can itself be an executing workload when authoritatively declared; do not invent a service hop for every execution. Neither a role filename nor a repository name establishes the authenticated executor or its permissions.

A run receipt should reference issuer/subject, tenant, environment, delegation reference, workload binding, run ID, source commit/artifact digest, target inventory reference, action, applicable decision/approval IDs and attributed time interval. Use existing owner schemas and custody rules; never embed bearer credentials. A signing key ID identifies a trust key, not the complete service identity. Bind it to the intended authority and environment through the reviewed trust lifecycle.

Review negatives: role name mistaken for permission; agent using human subject; missing delegation; cross-tenant or environment credential reuse; runtime principal without matching workload binding; valid time sample mistaken for authorization. Reject ambiguous identity at the relevant enforcement owner; retain unknown attribution explicitly in diagnostic evidence.

Host UTC findings and proposed policy gates

The live host reports timesyncd enabled, UTC and synchronized, with distro fallback ntp.ubuntu.com. This is sufficient inventory evidence, not a reviewed UTC bound.

Systemd v255 documentation says timesyncd implements SNTP and can step large clock offsets. It describes boot initialization separately from synchronization; time-set.target alone does not wait for reference synchronization. The application also needs continuing quality checks after any startup synchronization gate. Source.

Configured NTP servers are tried in turn. Per-link sources also participate, and fallback servers apply only when other source information is absent. Consequently, a longer configured server list does not provide simultaneous independent-source agreement. RootDistanceMaxSec is a source-selection threshold, not an independently established bound on this application's UTC estimate. Source. These versioned upstream documents guide review; the installed package/version and vendor changes still need recording before the role is implemented.

Proposed policy requirements for the owner review:

1. Retain the existing daemon during inventory. Before calling it an adequate authority baseline, decide how the health adapter establishes a conservative error bound under stated upstream, network and host trust assumptions. If it cannot, expose diagnostic health only and return unusable authority time. Evaluate a reviewed daemon replacement if necessary; never run two disciplines.
2. Record approved source operators, endpoints, leap convention, source-selection behavior and treatment of DHCP/per-link/runtime overrides. Endpoint count is not evidence of operator or reference independence. No new endpoints are selected by this review.
3. Propose unsmeared UTC as the starting convention, subject to infrastructure and consumer assent. Define wire behavior through a leap explicitly: until that behavior is reviewed and tested, protected use is unavailable across an announced or detected leap/continuity ambiguity. Do not guess a safe exclusion duration.
4. Require a versioned error model, maximum observation age and tested host drift assumptions. Missing measurements or stale health produce unusable state. A signed quality flag, stratum, last offset or sample dispersion alone cannot stand in for that model. Disable protected offline holdover initially.
5. Source loss, reboot, step and unexpected source/leap change invalidate authority continuity as specified. Bootstrap verifies reference synchronization and the application quality gate; ongoing monitoring detects later degradation.

Owner review requests and acceptance

Owner	Concrete review requested	Completion evidence
NetKingdom / gate-house	Confirm identity vocabulary, binding/delegation model, and clock Tooling versus Engine/PIP boundary	Versioned ruling; no speculative layer declaration
railiance-infra	Confirm effective source/version inventory and propose daemon/health model against these gates	Source policy and measurement plan in RAIL-HO-WP-0013
railiance-bootstrap	Confirm time initialization versus usable-reference ordering and handoff	Owner automation references and failed-quality startup test
Clock/security consumers	Review leap handling, unknown bounds and identity/time separation	Accepted contract references and C05/C09/C14/C16 negatives

Track identity review in RCLK-WP-0002-T01, trust/leap review in T02, and the measured error model in T03. Broader IAM schema changes belong to NetKingdom's owner work records; this document proposes a cross-owner review, not a parallel IAM system.