Skip to content

feat(store): admit SubjectService token principal (enum half) (RIG-2863) - #911

Open
rigel-mintaka wants to merge 2 commits into
mainfrom
compass-server/rig-2863-subject-service-enum
Open

feat(store): admit SubjectService token principal (enum half) (RIG-2863)#911
rigel-mintaka wants to merge 2 commits into
mainfrom
compass-server/rig-2863-subject-service-enum

Conversation

@rigel-mintaka

Copy link
Copy Markdown
Contributor

Add a third token-subject principal class, SubjectService = 2, for
first-party supervised compute tiers (the LLM gateway, a future MCP
gateway) that authenticate back to the Server. This is the enum half
of the frozen SubjectService addendum — the urgent, dependency-free
slice, since the enum number and the tokens.subject_kind CHECK are
painful to change once a non-disposable database has applied v1.

  • T1: SubjectService SubjectKind = 2 (append-only; 0/1 unchanged),
    seal comment retargeted to name three kinds and cite this record,
    and the Subject/Subject.ID docs widened off the two-kind
    enumeration onto the third id space (types.go).
  • T2: widen the tokens.subject_kind CHECK to IN (0, 1, 2) in
    0001_init.sql (edited in place per the pre-GA disposable-DB
    posture) plus its header comment; sqlc regenerates byte-identically
    (no internal/store/db drift).
  • T3: track the gosec G115 waiver's constrained-set text (0/1
    0/1/2) in tokens.go.
  • T5: the 3-kind cross-door pgtest matrix in auth/token_test.go (a
    service token resolves only at want=SubjectService, ErrWrongKind
    at every other door and for account/Runner tokens at the service
    door) plus two store round-trips proving the CHECK admits 2 and
    stays a closed set at exactly {0, 1, 2} (an out-of-range kind fails
    23514, which falls through to the bare wrap — no new sentinel).

The service-door mount (T4), token issuance, and tenant posture are
explicitly out of scope: they land with the RIG-2863 service surface
(RIG-1715 T2), gated on the secretspec v0.20 bump (RIG-3320).

Spec-impact: none (executes the frozen record; no ledger/design edit).
Refs RIG-2863

Co-authored-by: Matt Wilkinson matt@rigel.build

Add a third token-subject principal class, `SubjectService = 2`, for
first-party supervised compute tiers (the LLM gateway, a future MCP
gateway) that authenticate back to the Server. This is the enum half
of the frozen SubjectService addendum — the urgent, dependency-free
slice, since the enum number and the `tokens.subject_kind` CHECK are
painful to change once a non-disposable database has applied v1.

- T1: `SubjectService SubjectKind = 2` (append-only; 0/1 unchanged),
  seal comment retargeted to name three kinds and cite this record,
  and the `Subject`/`Subject.ID` docs widened off the two-kind
  enumeration onto the third id space (`types.go`).
- T2: widen the `tokens.subject_kind` CHECK to `IN (0, 1, 2)` in
  `0001_init.sql` (edited in place per the pre-GA disposable-DB
  posture) plus its header comment; sqlc regenerates byte-identically
  (no `internal/store/db` drift).
- T3: track the gosec G115 waiver's constrained-set text (`0/1` →
  `0/1/2`) in `tokens.go`.
- T5: the 3-kind cross-door pgtest matrix in `auth/token_test.go` (a
  service token resolves only at `want=SubjectService`, ErrWrongKind
  at every other door and for account/Runner tokens at the service
  door) plus two store round-trips proving the CHECK admits 2 and
  stays a closed set at exactly {0, 1, 2} (an out-of-range kind fails
  23514, which falls through to the bare wrap — no new sentinel).

The service-door mount (T4), token issuance, and tenant posture are
explicitly out of scope: they land with the RIG-2863 service surface
(RIG-1715 T2), gated on the secretspec v0.20 bump (RIG-3320).

Spec-impact: none (executes the frozen record; no ledger/design edit).
Refs RIG-2863

Co-authored-by: Matt Wilkinson <matt@rigel.build>
@linear-code

linear-code Bot commented Sep 6, 2026

Copy link
Copy Markdown

RIG-2863

@trunk-io

trunk-io Bot commented Sep 6, 2026

Copy link
Copy Markdown

Merging to main in this repository is managed by Trunk.

  • To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

@github-actions

github-actions Bot commented Sep 6, 2026

Copy link
Copy Markdown

Compass engineering docs preview: https://compass-server-rig-2863-subj-4s8u.compass-eng-docs.pages.dev

Deployed from compass-server/rig-2863-subject-service-enum at 10c5fa7.

…rix (RIG-2863)

Review R1 follow-up on the SubjectService enum half.

- **Migration comment (medium):** the T2 header-comment edit had grown the
  `tokens` block from 4 lines to 5, shifting every line below `0001_init.sql:373`
  by +1 and silently invalidating 8 line-pinned citations in three frozen design
  records (at-rest-encryption, dogfood-e2e-steer-deliver-seam,
  mention-offline-redelivery). Rewrapped the comment back to 4 lines with the full
  semantics intact, reverting the shift and leaving all 8 citations correct with
  zero edits to the frozen records (per docs/designs/CONTRIBUTING.md §5 this is a
  link-integrity concern; the count-preserving rewrap avoids touching the records
  at all).
- **Cross-door matrix (low):** added the runner positive diagonal
  (`runner token wanted as runner resolves`) to `TestServiceTokenCrossDoorMatrix`,
  closing the 3x3 — a resolvable token of each kind now succeeds at its own door,
  pinning the `want` comparison against all three values rather than only the two
  rejection axes.

No runtime behavior change. gofmt/build/vet clean; sqlc-drift byte-identical;
sql-migration-gate green; store + auth pgtests pass (matrix runs all 6 subtests).

Refs RIG-2863
Spec-impact: none
Ledger-impact: none
Co-authored-by: Matt Wilkinson <matt@rigel.build>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant