Context
The hosted verdict API (score.attach.dev) currently authenticates with a single shared Bearer token (ATTACH_OPEN_SCORE_API_TOKEN). That is acceptable for the current standalone / small-trusted-set usage (Guard "Mode B", see attach-guard/docs/SETUP_MODES.md), but it does not scale to many managed users: whoever holds the token has full access, there's no per-caller identity, no per-user revocation, and no per-user metering.
This issue tracks the design for moving beyond one shared token. Not urgent — single token is fine for now; capturing the plan so Mode A (managed setup via Attach Platform) can scale later.
Goals (later)
- AuthN — per-user/per-org identity. Replace the single shared secret with credentials that identify the caller.
- Metering / quota. Per-identity request accounting and limits (today rate limiting is per-IP only).
- Revocation. Revoke one user/org without rotating everyone's access.
- Attribution. Know who is calling for usage/debugging.
- (Optional, later) AuthZ / RBAC. Only if distinct actions or tiers emerge (privileged ops, plan-gated policy profiles, org admin controls). Not needed for the current single read-only
/v0/verdict surface.
Candidate approaches
- Platform-signed JWTs (preferred direction). Attach Platform issues short-lived JWTs carrying
sub (user), org, scope/plan, exp. The score service verifies the signature locally (no per-request DB lookup); revocation via short expiry + refresh. scope is where future RBAC plugs in.
- Shared keystore / opaque tokens. Service validates opaque tokens against a store (DB/Redis). Simpler to reason about; adds a lookup + state to the service.
Service-side changes implied
internal/packageverdict/server.go: auth middleware accepts validated identities instead of a single constant-time compare.- Per-identity metering layer (quota counters keyed by
sub/org).
- Likely a join with
attach-platform for issuance + revocation.
Out of scope (for now)
- Implementation. Single shared token stays as-is until this is scheduled.
Context
The hosted verdict API (
score.attach.dev) currently authenticates with a single shared Bearer token (ATTACH_OPEN_SCORE_API_TOKEN). That is acceptable for the current standalone / small-trusted-set usage (Guard "Mode B", seeattach-guard/docs/SETUP_MODES.md), but it does not scale to many managed users: whoever holds the token has full access, there's no per-caller identity, no per-user revocation, and no per-user metering.This issue tracks the design for moving beyond one shared token. Not urgent — single token is fine for now; capturing the plan so Mode A (managed setup via Attach Platform) can scale later.
Goals (later)
/v0/verdictsurface.Candidate approaches
sub(user),org,scope/plan,exp. The score service verifies the signature locally (no per-request DB lookup); revocation via short expiry + refresh.scopeis where future RBAC plugs in.Service-side changes implied
internal/packageverdict/server.go: auth middleware accepts validated identities instead of a single constant-time compare.sub/org).attach-platformfor issuance + revocation.Out of scope (for now)