Consumer: lost-rob0t/starintel-bixby#7
Related lifecycle owner: #41
Gateway consumer: starintel-labs/starintel-infra#72
Canonical OAuth owner: lost-rob0t/starintel-server#111
Post-merge discovery
Quasar #43 merged the durable autodig.status, autodig.run.get, autodig.run.list, autodig.run.start, autodig.run.pause, autodig.run.resume, and autodig.run.stop handlers onto current main.
However the WebSocket authorization boundary still has no session profile suitable for an external human client:
+default-capabilities+ does not include any autodig.* lifecycle commands;
register-autodig-worker-session intentionally grants only status/get/list plus worker claim/heartbeat/complete/fail and explicitly excludes start/pause/resume/stop;
- therefore a Bixby gateway adapter cannot truthfully expose the merged public lifecycle through current authenticated WebSocket sessions; it would fail
security.forbidden.
Goal
Add the smallest canonical Quasar authorization/delegation seam that lets a trusted external service such as starintel-bixby-gateway act for an authenticated StarIntel human principal without turning the gateway service identity into the user identity.
The design must consume StarIntel's existing OAuth/human-principal authority from starintel-server#111; Quasar must not invent a second OAuth token format, user DB, or scope model.
Required authority properties
- preserve three identities distinctly: StarIntel human principal, gateway service identity, Quasar runtime/session identity;
- lifecycle access must be derived from canonical StarIntel user scopes/capabilities, not caller-supplied fields;
- support least-privilege read lifecycle authority separately from lifecycle control authority;
- workspace/run access must remain fail-closed across users; possession of
runId alone never grants access;
- no bearer/access token in query strings, command payload journals, events, logs, or public protocol results;
- no static capsule-wide or gateway-wide session may silently grant every Bixby user shared lifecycle authority;
- the scheduled worker session remains separate and must not gain user control commands;
system.capabilities must truthfully expose only the commands granted to the authenticated/delegated user session.
ADADR design questions
Research/analyze before production code:
- Whether Quasar should accept an injected/authenticated principal assertion from a trusted StarIntel adapter, or consume a generic StarIntel token-introspection/principal projection if such a canonical boundary exists.
- Whether the external-user session should be minted through a trusted local registration API, handshake authenticator, or another existing Quasar extension seam.
- How StarIntel scopes map to Quasar lifecycle capabilities without creating Bixby-specific capability names.
- How per-principal ownership/access is represented for runs so two users in one workspace cannot inspect/control each other's runs accidentally.
TDD/security gate
Tests first must prove:
- standard browser/default sessions still do not gain Auto-Dig control implicitly;
- worker sessions still cannot start/pause/resume/stop;
- external human read-only authority can status/get/list but cannot mutate;
- external human control authority can start/pause/resume/stop only with canonical delegated authorization;
- cross-user run get/control fails closed even in the same workspace;
- missing/invalid/expired/revoked upstream user authority fails closed;
- service identity cannot substitute itself for the human principal;
- capability discovery matches the granted lifecycle surface;
- no credential or raw auth context appears in protocol results/audit events.
Non-goals
- no Bixby-specific protocol in Quasar;
- no gateway-local lifecycle DB;
- no browser/Playwright automation for runtime authority;
- no direct CouchDB/RabbitMQ control path;
- no weakening the existing worker fencing/lease semantics.
Exit
An external gateway can translate its frozen client contract into canonical quasar.control.v1 lifecycle commands while Quasar still observes/enforces the real delegated human authority and per-user run isolation.
Consumer:
lost-rob0t/starintel-bixby#7Related lifecycle owner: #41
Gateway consumer:
starintel-labs/starintel-infra#72Canonical OAuth owner:
lost-rob0t/starintel-server#111Post-merge discovery
Quasar #43 merged the durable
autodig.status,autodig.run.get,autodig.run.list,autodig.run.start,autodig.run.pause,autodig.run.resume, andautodig.run.stophandlers onto currentmain.However the WebSocket authorization boundary still has no session profile suitable for an external human client:
+default-capabilities+does not include anyautodig.*lifecycle commands;register-autodig-worker-sessionintentionally grants only status/get/list plus worker claim/heartbeat/complete/fail and explicitly excludes start/pause/resume/stop;security.forbidden.Goal
Add the smallest canonical Quasar authorization/delegation seam that lets a trusted external service such as
starintel-bixby-gatewayact for an authenticated StarIntel human principal without turning the gateway service identity into the user identity.The design must consume StarIntel's existing OAuth/human-principal authority from
starintel-server#111; Quasar must not invent a second OAuth token format, user DB, or scope model.Required authority properties
runIdalone never grants access;system.capabilitiesmust truthfully expose only the commands granted to the authenticated/delegated user session.ADADR design questions
Research/analyze before production code:
TDD/security gate
Tests first must prove:
Non-goals
Exit
An external gateway can translate its frozen client contract into canonical
quasar.control.v1lifecycle commands while Quasar still observes/enforces the real delegated human authority and per-user run isolation.