Session: OpenBao-owned Forge identity leases and private Vedanta effect #20

Closed
opened 2026-08-29 17:05:03 +00:00 by larandar · 2 comments
Owner

Proposal

Deliver the OpenBao lease backend and private Vedanta effector as one atomic interface-compatibility review.

Session review boundary

One PR carries independently committed leaves, but the reviewer gives one verdict on the public lease contract, private command ABI, mutation adapters, and lost-response semantics together. Leaf count does not size the Session.

Design

OpenBao owns authorization, state, and delivery. Vedanta authenticates only OpenBao, validates the deployed projection, persists every operation before mutation, and uses narrow native adapters. No status path contains a secret.

Owner ruling (2026-09-03), Q1: the two native issuers get one leaf each. #8 owns the Kanidm mutation adapter; #29 owns the Forgejo one. Kanidm and Forgejo have independent APIs, permission models, failure modes, and acceptance doubles, so broadening #8 across both would fuse two unlike proofs into one record. The Session boundary is unchanged: one interface-compatibility verdict still covers every leaf.

Tasks

  • #8 — bounded Kanidm credential mutations.
  • #29 — bounded Forgejo credential mutations.
  • #22 — private command authentication and validation.
  • #21 — durable operation journal and non-secret status/ack.
  • #23 — uncertain-delivery reconciliation and orphan invalidation.
  • #12 — authorize and issue initial leases.
  • #24 — read, rotate, and revoke lease transitions.

Specification Delta

Requirement: one reviewed boundary owns the complete lifecycle handshake

Scenario: the Session PR is accepted

  • GIVEN compatible OpenBao and Vedanta implementations
  • WHEN the reviewer accepts the PR
  • THEN issue, rotation, revocation, replay, and lost delivery share one tested contract
  • AND workloads still cannot reach Vedanta

OpenSpec

OpenSpec 20

Structural parent

Ting/Ting#60

## Proposal Deliver the OpenBao lease backend and private Vedanta effector as one atomic interface-compatibility review. ## Session review boundary One PR carries independently committed leaves, but the reviewer gives one verdict on the public lease contract, private command ABI, mutation adapters, and lost-response semantics together. Leaf count does not size the Session. ## Design OpenBao owns authorization, state, and delivery. Vedanta authenticates only OpenBao, validates the deployed projection, persists every operation before mutation, and uses narrow native adapters. No status path contains a secret. **Owner ruling (2026-09-03), Q1:** the two native issuers get one leaf each. #8 owns the Kanidm mutation adapter; #29 owns the Forgejo one. Kanidm and Forgejo have independent APIs, permission models, failure modes, and acceptance doubles, so broadening #8 across both would fuse two unlike proofs into one record. The Session boundary is unchanged: one interface-compatibility verdict still covers every leaf. ## Tasks - [ ] #8 — bounded Kanidm credential mutations. - [ ] #29 — bounded Forgejo credential mutations. - [ ] #22 — private command authentication and validation. - [ ] #21 — durable operation journal and non-secret status/ack. - [ ] #23 — uncertain-delivery reconciliation and orphan invalidation. - [ ] #12 — authorize and issue initial leases. - [ ] #24 — read, rotate, and revoke lease transitions. ## Specification Delta ### Requirement: one reviewed boundary owns the complete lifecycle handshake #### Scenario: the Session PR is accepted - **GIVEN** compatible OpenBao and Vedanta implementations - **WHEN** the reviewer accepts the PR - **THEN** issue, rotation, revocation, replay, and lost delivery share one tested contract - **AND** workloads still cannot reach Vedanta ## OpenSpec [OpenSpec 20](https://jo.et0.pw/Ting/Vedanta/wiki/OpenSpec-20-openbao-forge-identity-lifecycle) ## Structural parent [Ting/Ting#60](https://jo.et0.pw/Ting/Ting/issues/60)
Author
Owner

Grooming state: Grilled — Q1 ratified; the leaf set is complete.
Evidence: Ratified OpenSpec 61 v0.1.4 requires Vedanta to cause Forgejo to mint and exactly delete one bounded queen-account token per lease. OpenSpec 20 and Session #20 listed six leaves — #8 the Kanidm mutation adapter, #12 the OpenBao backend, #22 command validation, #21 journal/status, #23 reconciliation, #24 lease transitions — and none owned the Forgejo API adapter, its least-scope proof, exact token-ID deletion, or capture-double negatives.

Frontier

empty — grilled 2026-09-03.

Q1 — missing native adapter. Ratified (Larandar, 2026-09-03): a separate Forgejo-adapter leaf, not a broadening of #8. Kanidm and Forgejo have independent APIs, permissions, failure modes, and acceptance doubles, while the Session still gives one interface-compatibility verdict. Delivered as #29; the ruling is recorded in this record's Design, the leaf is in Tasks, and the native edge #20#29 is installed.

Standing state

PR #27 (merged 2026-09-02) delivered the original six leaves. The Session now waits on #29 alone. Its merge also failed to close #8, #23, and #24 despite the Closes keywords — tracker hygiene, carried separately, not a delivery gap.

Related evidence: Ting OpenSpec 61, Vedanta OpenSpec 20, #8, #12, #21–#24, #29, PR #27.

<!-- larandar:groom:v1 --> **Grooming state:** Grilled — Q1 ratified; the leaf set is complete. **Evidence:** Ratified [OpenSpec 61 v0.1.4](https://jo.et0.pw/Ting/Ting/wiki/OpenSpec-61-forge-identity-lifecycle-contract) requires Vedanta to cause Forgejo to mint and exactly delete one bounded queen-account token per lease. [OpenSpec 20](https://jo.et0.pw/Ting/Vedanta/wiki/OpenSpec-20-openbao-forge-identity-lifecycle) and Session #20 listed six leaves — #8 the Kanidm mutation adapter, #12 the OpenBao backend, #22 command validation, #21 journal/status, #23 reconciliation, #24 lease transitions — and none owned the Forgejo API adapter, its least-scope proof, exact token-ID deletion, or capture-double negatives. ### Frontier empty — grilled 2026-09-03. **Q1 — missing native adapter. Ratified (Larandar, 2026-09-03):** a separate Forgejo-adapter leaf, not a broadening of #8. Kanidm and Forgejo have independent APIs, permissions, failure modes, and acceptance doubles, while the Session still gives one interface-compatibility verdict. Delivered as #29; the ruling is recorded in this record's Design, the leaf is in Tasks, and the native edge #20 → #29 is installed. ### Standing state [PR #27](https://jo.et0.pw/Ting/Vedanta/pulls/27) (merged 2026-09-02) delivered the original six leaves. The Session now waits on #29 alone. Its merge also failed to close #8, #23, and #24 despite the `Closes` keywords — tracker hygiene, carried separately, not a delivery gap. **Related evidence:** Ting OpenSpec 61, Vedanta OpenSpec 20, #8, #12, #21–#24, #29, PR #27.
Author
Owner

Complete. All seven leaves closed: #8, #12, #21, #22, #23, #24, and #29.

Six landed in PR #27 (merged 2026-09-02) as the one interface-compatibility review this record specified. #29 — the Forgejo adapter added by the Q1 ruling of 2026-09-03 — landed separately in PR #42 at 4673e20, because it was ruled into existence after that PR had merged.

Q1's structural gap is closed. The two native issuers now have one adapter each — src/kanidm.rs and src/forgejo.rs — and building the second confirmed the ruling's premise rather than merely following it: Forgejo has no token expiry field at all, where Kanidm's mint refuses without an explicit one. Broadening #8 across both would have forced one record to carry two incompatible notions of what makes a credential bounded.

What closing this record claims, and what it does not. The lease contract, private command ABI, both mutation adapters and the lost-response semantics are written and tested against capture doubles — 113 lib tests. Nothing here has authenticated to a live Kanidm or a live Forgejo. sa-vedanta does not exist, so the narrow-delegation proof (flake-ops#123) and the Forge least-scope proof both remain outstanding operator-gated work behind flake-ops#98.

**Complete.** All seven leaves closed: [#8](https://jo.et0.pw/Ting/Vedanta/issues/8), [#12](https://jo.et0.pw/Ting/Vedanta/issues/12), [#21](https://jo.et0.pw/Ting/Vedanta/issues/21), [#22](https://jo.et0.pw/Ting/Vedanta/issues/22), [#23](https://jo.et0.pw/Ting/Vedanta/issues/23), [#24](https://jo.et0.pw/Ting/Vedanta/issues/24), and [#29](https://jo.et0.pw/Ting/Vedanta/issues/29). Six landed in [PR #27](https://jo.et0.pw/Ting/Vedanta/pulls/27) (merged 2026-09-02) as the one interface-compatibility review this record specified. #29 — the Forgejo adapter added by the Q1 ruling of 2026-09-03 — landed separately in [PR #42](https://jo.et0.pw/Ting/Vedanta/pulls/42) at `4673e20`, because it was ruled into existence after that PR had merged. **Q1's structural gap is closed.** The two native issuers now have one adapter each — `src/kanidm.rs` and `src/forgejo.rs` — and building the second confirmed the ruling's premise rather than merely following it: Forgejo has **no token expiry field at all**, where Kanidm's mint refuses without an explicit one. Broadening #8 across both would have forced one record to carry two incompatible notions of what makes a credential bounded. **What closing this record claims, and what it does not.** The lease contract, private command ABI, both mutation adapters and the lost-response semantics are written and tested against capture doubles — 113 lib tests. Nothing here has authenticated to a live Kanidm or a live Forgejo. `sa-vedanta` does not exist, so the narrow-delegation proof ([flake-ops#123](https://jo.et0.pw/lar.ad/flake-ops/issues/123)) and the Forge least-scope proof both remain outstanding operator-gated work behind [flake-ops#98](https://jo.et0.pw/lar.ad/flake-ops/issues/98).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
Ting/Vedanta#20
No description provided.