id: design: capability grants for providers (from #5686)

Summary

Follow-on design ticket from #5686 — its decomposition sketch names this as a separate design, and the parent's acceptance requires these tickets to be filed and linked. Filed in the 2026-11-04 gap pass (WS-F) so the design work exists and can be prioritised on its own merits; implementation timing is a separate decision, possibly months out.

What this design must settle

Least-privilege scoping, observation vs actuation classes, approval flows by sensitivity, and attenuation for provider grants.

Context from the parent

The parent design fixes the single capability-provider model — declaration, discovery, negotiation, least-privilege grants — instantiated by ESP32/MQTT, terminal, Bevy, smartphone, and web providers. The parent issue carries the surrounding decisions this ticket must not re-decide; where this ticket's answer would change a parent decision, record that explicitly rather than silently forking it.

Decision record expected

Close this design with a recorded decision (on this issue or in a doc/ record linked from it): the chosen shape, the alternatives rejected and why, and the invariants implementation must hold. If the design splits further, file the splits and link them here rather than growing this issue.

Relations

Parent: #5686. Programme: epic #2056. Filed by WS-F (2026-11-04 ID design gap & expansion pass).

CODE-1583

Field survey filed: #5931 (capability-provider research widening, per Drew's 2026-11-04 ruling) covers the current option space relevant to this issue in §6.4 — the capability-token field (UCAN 1.0, Biscuit 3.x, macaroons, IETF AAT draft): attenuate-only offline-verifiable delegation is a solved, multiply-implemented pattern; open question is encoding vs ID-native objects. It is an inventory, not a decision — the section ends with the open questions this design needs to answer.

Wave-2 cross-link from the worlds prior-art pass (#5955 program).

New evidence for the delegation-encoding question: Spritely's Brassica Chat prototype (Nov 2025) demonstrates the four-layer composition in production-adjacent form — (1) object capabilities for online access, (2) actors/async messaging over OCapN, (3) CRDTs for eventually-consistent offline messaging, (4) certificate capabilities (zcaps) for offline authorization via delegation chains — explicitly contrasting with ACL-based local-first apps (https://www.spritely.institute/news/composing-capability-security-and-conflict-free-replicated-data-types.html). The zcap layer is a third data point beside UCAN/Biscuit for attenuable, offline-verifiable delegation: chains of signed certificates rather than tokens. Full survey: workspace/scratch/worlds-capabilities-brief-2026-11-04/prior-art-research.md, Cluster 7.

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-s
Session / ID: task 10302
Found via: queue claim
Task: Triage of issue id: design: capability grants for providers (from #5686) #5900 (id: design: capability grants for providers, from design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686) — assigned to the opencode execution lane (session_id null at assignment); parked 20m after handoff checkpoint. The laptop claimant launches the bound opencode session, which drives task 10302 to its terminal state. Attempts 1/6.

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-i
Session / ID: task 10302
Found via: queue claim
Task: Triage issue id: design: capability grants for providers (from #5686) #5900 — assigned_lane=opencode, handed off to opencode claimant per §1b; parked 1800s for claimant launch
Expectation: claimant launches bound opencode session to triage at current main
Links: n/a

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-k
Session / ID: task 10302
Found via: queue claim
Task: Triage issue id: design: capability grants for providers (from #5686) #5900 — handed off to the opencode claimant per execution-lane assignment (assigned_lane=opencode); this lane does not work the task itself.
Expectation: The laptop claimant launches a bound opencode session for task 10302, which drives triage of issue id: design: capability grants for providers (from #5686) #5900 to a terminal state.
Links: task 10302 (queue repo-health-code-pilot)

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-s
Session / ID: task 10302
Task: Triage id: design: capability grants for providers (from #5686) #5900: id: design: capability grants for providers (from design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686). Claimed by lane code-s; execution-lane assignment returned opencode, so this task is handed off to the opencode claimant — no direct work by this lane. Fresh check on claim: issue id: design: capability grants for providers (from #5686) #5900 OPEN, no hard-stop labels.
Resume condition: claimant launches the bound opencode session and drives task 10302 to its terminal state.
Links: issue id: design: capability grants for providers (from #5686) #5900

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-v
Session / ID: task 10302
Found via: queue claim
Task: Triage of issue id: design: capability grants for providers (from #5686) #5900 (design: capability grants for providers) — execution lane assigned opencode; handed off to the opencode claimant, which launches the bound session.
Expectation: claimant session drives task 10302 to a terminal state under the queue worker id.
Links: issue id: design: capability grants for providers (from #5686) #5900

🤖 Agent note · picked up

Agent: queue worker, worker ID repo-worker-code, lane c29174f1-48e0-4b13-b4ff-9b73ab67e9ab
Task: queue task 10302 — triage id: design: capability grants for providers (from #5686) #5900
Next: verify current issue/parent/research state and current-main implementation or superseding design work; then record routing findings.
Links: id: design: capability grants for providers (from #5686) #5900

Queue triage — task 10302

Verdict: #5900 remains OPEN; the all-state PR search found no PR for it. Parent design #5686 and the capability-provider field survey #5931 are both open. The existing survey comment on this issue explicitly says it is an option inventory, not a design decision. Current main is 2aefba0.

Existing foundation: the ID capability design at doc/2026-10-09T09-59-07Z_design_attenuated_capabilities/ records scope attenuation, delegation, expiry/use limits and revocation; pkgs/id/crates/id-core/src/world_caps.rs contains the corresponding ledger machinery. That work does not settle provider-specific identity/scope, risk classes, or approval flows, so #5900 is not already done.

Triage scope and order:

Keep this ticket to provider grants: capability/provider/consumer binding, purpose and rate/volume bounds, expiry, issuance/approval by sensitivity, and the observation-versus-actuation distinction. Do not re-decide declaration, discovery, negotiation, or each target's transport; those are the parent and sibling tickets' scope.
Start from the parent design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686 authority/ceiling model and the existing ID grant/delegation machinery. Use id: research: capability-provider field survey — current options & variants per provider class + cross-cutting frameworks (from #5686) #5931 as evidence, then make an explicit choice between ID-native grant objects and a token encoding (including rejected alternatives); the survey itself does not choose.
Specify attenuation, revocation, expiry/use limits and provider lifecycle; coordinate offline/cached-grant behavior with id: design: offline & degraded operation for providers (from #5686) #5904 rather than duplicating its whole design.
Record invariants and alternatives in a linked doc/ decision record, then close this design ticket only when its acceptance criteria are met. Split only if the decision work identifies a genuinely independent design boundary.

Blockers: none to starting the design. The research input is already linked in the issue comments; its still-open status is not a dependency. No code changed in this triage.

🤖 Agent note · triaged

Agent: queue worker, worker ID repo-worker-code, lane c29174f1-48e0-4b13-b4ff-9b73ab67e9ab
Task: queue task 10302
Evidence: current issue/parent/research state and current-main design/code inventory summarized above.
Links: id: design: capability grants for providers (from #5686) #5900, design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686, id: research: capability-provider field survey — current options & variants per provider class + cross-cutting frameworks (from #5686) #5931

🤖 Agent note · picked up

Agent: queue worker (repo-worker-code), lane c29174f1-48e0-4b13-b4ff-9b73ab67e9ab
Session / ID: task 10302
Found via: queue claim; resuming the existing triage checkpoint
Task: Fresh revalidation confirms id: design: capability grants for providers (from #5686) #5900 is OPEN, no related PR is present, and the previous scoped triage comment already records the path and ordering.
Expectation: Verify that finding against current main and close task 10302 as triaged; no duplicate findings comment unless new evidence changes the route.
Links: task 10302 (repo-health-code-pilot), design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686, id: research: capability-provider field survey — current options & variants per provider class + cross-cutting frameworks (from #5686) #5931

🤖 Agent note · triaged / done

Agent: queue worker (repo-worker-code), lane c29174f1-48e0-4b13-b4ff-9b73ab67e9ab
Session / ID: task 10302
Task: Resumed from its existing triage checkpoint and revalidated at current main c26e0585add36770e90d7b24480b9bb5b3564c5e. id: design: capability grants for providers (from #5686) #5900 remains OPEN; design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686 and id: research: capability-provider field survey — current options & variants per provider class + cross-cutting frameworks (from #5686) #5931 remain OPEN; no related PR was found. The prior scoped findings and order in the triage comment remain valid.
Outcome: triaged; no code changes or tests were needed. id: design: capability grants for providers (from #5686) #5900 remains open for the design decision.
Links: task 10302 (repo-health-code-pilot), design(id): client-side capability providers — one provider model for ESP32/MQTT, terminal, Bevy, smartphone, and web #5686, id: research: capability-provider field survey — current options & variants per provider class + cross-cutting frameworks (from #5686) #5931

Navigation Menu

Repository navigation

id: design: capability grants for providers (from #5686) #5900

Summary

What this design must settle

Context from the parent

Decision record expected

Relations

Queue triage — task 10302

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

id: design: capability grants for providers (from #5686) #5900

Description

Summary

What this design must settle

Context from the parent

Decision record expected

Relations

Activity

developing-today commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

developing-today commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

Queue triage — task 10302

dezren39 commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions