Repository navigation
Ward / IAM — principals, object access and revocation #24
Description
Outcome
An authenticated principal can access only its permitted operations and objects, with effective revocation.
Next planning checkpoint: Init. This is the earliest scope/review conversation, not an assignment or a promise to finish the whole outcome in that week. Selected work starts at #52.
Remaining acceptance
- Bind an enrolled Principal to one revocable credential adapter; derive a secret-free Sigil from trusted state.
- Enforce ownership on one Run/artifact query and recheck current authority at its effect or resume boundary.
- Verify two principals cannot read or act on each other's objects, including after revocation, queued work and restart.
Evidence and handoff
Start from current State of Work and its linked source/tests and owning ADRs. The linked original acceptance remains binding unless a named replacement outcome records its disposition. Detailed scope, negative cases and dated campaign evidence are preserved in preserved scope and evidence; historical evidence does not establish current qualification on its own. Any accepted requirement not selected for this profile needs an explicit route in #62 before this issue closes.
Choose one small implementation or verification slice when this outcome is admitted. Record the responsible contributor, exact profile/revision, observed result, failure/unknown boundary and next checkpoint. The founder reviews and approves all code for this campaign; merge and promotion follow CONTRIBUTING.
Activity
zenithruneblade commentedon Oct 12, 2026
Wind-down review (2026-10-12): ADR 38 gives the identity design, but current executable access is local Basic → fixed
magus:*Sigil. There is no general User/Principal/session store, OAuth/OIDC login, per-object tenancy or remote revocation yet. No IAM completion claim.Recommended next packet, subject to the owning design: LychD as an OIDC relying party against one separately operated provider; Ward retains local authorization. Use authorization-code + PKCE, exact
(issuer, subject)credential binding, explicit enrollment/linking, and a server-held revocable session. Prove one protected Session/Run chain (list/detail/history/SSE/consent/resume) with two users and revocation across queued work/restart. Keep unconverted remote routes unavailable. An OAuth button, tunnel or valid provider JWT cannot substitute for object authority.Primary-source research: Litestar Fullstack offers useful account/service organization examples; its auth defaults are not Ward's policy. RFC 9700 supports the code/PKCE direction and prohibits the password grant. OIDC subject stability is why email/display name must not be the identity key. No provider has been selected or deployed; becoming an OAuth authorization server is separate scope.
zenithruneblade commentedon Nov 6, 2026
Planning reset — 6 November 2026. The original acceptance below remains binding unless a named replacement outcome records its disposition. This is a preserved historical body, not a fresh capability/qualification claim.
Original issue scope and dated evidence before the planning reset
Establish a real identity and authorization boundary for one credential type and one owned resource.
Current source boundary — 3 November 2026: Ward / remote IAM is Partial. The local credential/fixed-Sigil boundary remains, alongside the inactive
host-opaque-candidate@1Ward foundation and its separately composed candidate-authority consumer. Dated bounded PostgreSQL evidence covers that authority/custody passage. The outbound peer profile separately distinguishes local operator authentication, workload signing identity and enrolled remote peer identity, with exact object/action permission and durable revocation. These slices do not deliver general remote human/device IAM: normal application activation, incoming Ward, remote sessions, delegated grants, tenant isolation and cross-process revocation remain Designed. The original checklist below remains the closure target; no item is checked from this source review.First working slice
Connections: Integrates with #8 and #23. #19 and #20 need explicit application authority before any remote use.
Later: Additional credential types, delegation chains, broader object coverage and remote ingress acceptance.
References: ADR 38 · ADR 09.
Contribution entry: Reuse the existing Ward Principal, credential and object/action owners; choose one missing application integration or general identity slice with denial tests.
Open decision: Pin the credential type, first protected resource and actual activation boundary against the current Ward contract; do not invent a second authority model.
Verification: Two-principal and revocation/restart tests. Shared contribution and touched-docs rules: #52.