Skip to content

P0: authorize external human Auto-Dig lifecycle clients without collapsing gateway identity #50

Description

@lost-rob0t

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:

  1. 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.
  2. Whether the external-user session should be minted through a trusted local registration API, handshake authenticator, or another existing Quasar extension seam.
  3. How StarIntel scopes map to Quasar lifecycle capabilities without creating Bixby-specific capability names.
  4. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions