Implement bounded Forgejo credential mutations #29

New issue

Closed

opened 2026-09-03 16:38:26 +00:00 by larandar · 0 comments

larandar commented

2026-09-03 16:38:26 +00:00

Owner

Proposal

Implement the narrow Forgejo mutation adapter that ratified OpenSpec 61 v0.1.4 requires: Vedanta causes Forgejo to mint and exactly delete one bounded queen-account token per lease.

Delivery class

agent-unit — add src/forgejo.rs and capture-double tests. A live least-scope proof against a deployed Forgejo remains a separate operator-gated record.

Design

Kanidm and Forgejo are independent issuers: distinct APIs, distinct permission models, distinct failure modes, distinct acceptance doubles. #8 owns the Kanidm half; this leaf owns the Forgejo half, and the Session still returns one interface-compatibility verdict over both.

Mint requires explicit expiry and returns value, token ID, expiry, and subject once. Deletion targets one exact token ID; it succeeds externally for an unknown or already-deleted token while the audit trail retains the observed-before distinction. Forgejo denial is final and never triggers broader authority or an authority-widening retry.

Tasks

Implement bounded queen-account token mint with typed result metadata.
Implement exact token-ID deletion, retaining the observed-before distinction.
Prove least scope — the adapter holds no capability beyond per-lease mint and delete.
Prove unrelated-subject denial and no authority-widening retry against capture doubles.

Specification Delta

Requirement: one lease mints and deletes exactly one bounded Forgejo token

Scenario: a lease is issued and later revoked

GIVEN an authorized lease naming a queen account
WHEN issue and then revocation run
THEN exactly one bounded token is minted
AND revocation deletes that exact token ID and no other

Scenario: the adapter is asked to exceed its scope

GIVEN an authenticated Forgejo adapter
WHEN any operation outside per-lease token mint and delete is attempted
THEN it is refused, and no retry widens the granted authority

Owner ruling (2026-09-03)

#20 Q1 ratified: the Forgejo native adapter becomes a separate Session #20 leaf rather than a broadening of #8. The structural gap named in #8's grooming record and carried by #20 Q1 is closed by this record.

OpenSpec

OpenSpec 20

Structural parent

Vedanta#20

## Proposal Implement the narrow Forgejo mutation adapter that ratified [OpenSpec 61 v0.1.4](https://jo.et0.pw/Ting/Ting/wiki/OpenSpec-61-forge-identity-lifecycle-contract) requires: Vedanta causes Forgejo to mint and exactly delete one bounded queen-account token per lease. ## Delivery class `agent-unit` — add `src/forgejo.rs` and capture-double tests. A live least-scope proof against a deployed Forgejo remains a separate operator-gated record. ## Design Kanidm and Forgejo are independent issuers: distinct APIs, distinct permission models, distinct failure modes, distinct acceptance doubles. #8 owns the Kanidm half; this leaf owns the Forgejo half, and the Session still returns one interface-compatibility verdict over both. Mint requires explicit expiry and returns value, token ID, expiry, and subject once. Deletion targets one exact token ID; it succeeds externally for an unknown or already-deleted token while the audit trail retains the observed-before distinction. Forgejo denial is final and never triggers broader authority or an authority-widening retry. ## Tasks - [ ] Implement bounded queen-account token mint with typed result metadata. - [ ] Implement exact token-ID deletion, retaining the observed-before distinction. - [ ] Prove least scope — the adapter holds no capability beyond per-lease mint and delete. - [ ] Prove unrelated-subject denial and no authority-widening retry against capture doubles. ## Specification Delta ### Requirement: one lease mints and deletes exactly one bounded Forgejo token #### Scenario: a lease is issued and later revoked - **GIVEN** an authorized lease naming a queen account - **WHEN** issue and then revocation run - **THEN** exactly one bounded token is minted - **AND** revocation deletes that exact token ID and no other #### Scenario: the adapter is asked to exceed its scope - **GIVEN** an authenticated Forgejo adapter - **WHEN** any operation outside per-lease token mint and delete is attempted - **THEN** it is refused, and no retry widens the granted authority ## Owner ruling (2026-09-03) [#20](https://jo.et0.pw/Ting/Vedanta/issues/20) Q1 ratified: the Forgejo native adapter becomes a separate Session #20 leaf rather than a broadening of #8. The structural gap named in #8's grooming record and carried by #20 Q1 is closed by this record. ## OpenSpec [OpenSpec 20](https://jo.et0.pw/Ting/Vedanta/wiki/OpenSpec-20-openbao-forge-identity-lifecycle) ## Structural parent [Vedanta#20](https://jo.et0.pw/Ting/Vedanta/issues/20)

larandar added the

Kind/Feature

Kind/Security

labels

2026-09-03 16:38:33 +00:00

larandar added a new dependency

2026-09-03 16:38:33 +00:00

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

larandar referenced this issue

2026-09-03 16:38:45 +00:00

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

larandar referenced this issue