coulomb/target-revenue
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Accept WP-0009-T01: rights tiers confirmed, option (a) chosen over recommendation

Browse source 
Maintainer (Bernd) accepted 2026-07-30: four rights tiers
(Viewer/Contributor/Operator/Admin) confirmed as proposed. Selected
option (a) - per-human sub-credentials at the Trust Service layer -
over this concept's own recommended option (b), meaning the Trust
Service's signed ledger records can attest to the specific human who
acted, not merely the binky tenant.

This adds a real, firm prerequisite the workplan didn't have before:
extending WP-0006's already-finished licensors/token auth model.
Restructured T02 (was: backend+audit) into T02 (WP-0006 auth
extension, new) + T03 (Control Plane backend, renumbered) + T04
(interactive UI, renumbered) to keep that scope visible as its own
task rather than folding it silently into backend work.
This commit is contained in:
tegwick 2026-07-30 13:06:36 +02:00
parent 757cbbc371
commit 50b25947f9
3 changed files with 72 additions and 38 deletions
Download patch file Download diff file Expand all files Collapse all files

42
specs/TargetRevenueControlPlaneConcept.md
View file

@ -40,8 +40,8 @@ script or CI pipeline acting *as* the Licensor, but not sufficient for
**multiple human users**, potentially with **different rights**, acting
*on behalf of* the same Licensor tenant (`binky`).
**Candidate rights tiers** (not yet decided, proposed for workplan T01 to
resolve):
**Rights tiers — adopted 2026-07-30** (`workplans/TREV-WP-0009-target-revenue-control-plane.md`
T01, maintainer-accepted, as proposed):
| Right | Can do |
|---|---|
@ -50,24 +50,26 @@ resolve):
| Operator | Everything Contributor can, plus: directly append Development Credit/Remission Credit entries, register new Phases, publish breach/compliance records |
| Admin | Everything Operator can, plus: manage which human users hold which right within the `binky` tenant |
**Design tension to resolve, not paper over:** WP-0006's Ledger append API
(`ledger.append_entry`) currently authenticates a single Licensor token,
not an individual human user — so "Operator Alice" and "Operator Bob"
both acting for `binky` are currently indistinguishable at the API layer
(both just look like "the `binky` token"). Either (a) the Control Plane
issues per-human-user sub-credentials that map to the same underlying
Licensor identity (requiring a schema/API change in WP-0006's auth
layer — a real, scoped follow-on task), or (b) the Control Plane holds
the one Licensor token server-side and layers its own human-user
authentication/authorization in front of it, recording *which human*
took an action in its own audit log distinct from the Trust Service's
own record (simpler, no WP-0006 changes required, but the Trust
Service's own signed records still only attest "the `binky` Licensor did
this," not "Alice, acting for `binky`, did this"). **Recommendation: start
with (b)** — it requires no changes to the already-finished, tested
WP-0006 auth model, and the Control Plane's own audit log (§5) can carry
the finer-grained human-attribution that the Trust Service's own
cryptographic signature does not need to.
**Design tension — resolved 2026-07-30, option (a) adopted, not (b):**
WP-0006's Ledger append API (`ledger.append_entry`) currently
authenticates a single Licensor token, not an individual human user — so
"Operator Alice" and "Operator Bob" both acting for `binky` are currently
indistinguishable at the API layer (both just look like "the `binky`
token"). The maintainer selected **(a): the Control Plane issues
per-human-user sub-credentials that map to the same underlying Licensor
identity**, over this document's own recommendation of (b) — meaning a
real, scoped auth-schema extension to WP-0006's already-finished
`licensors`/token model is now a genuine prerequisite for T02/T03, not a
hypothetical branch. The payoff: the Trust Service's own signed ledger
records can attest to the specific human who acted, "Alice, acting for
`binky`, did this," not merely "the `binky` Licensor did this" — a
stronger audit guarantee than (b) would have given, at the cost of
touching WP-0006's tested auth layer. See
`workplans/TREV-WP-0009-target-revenue-control-plane.md` T02 for the
resulting scope. (This document had recommended the simpler alternative
— the Control Plane holding one server-side token and layering its own
human-user audit log in front of it, with no WP-0006 changes required —
but the maintainer's choice of (a) is the adopted answer.)
## 3. Core interactive flow: creating a Development Credit entry