coulomb/security-canon
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Assess Mode of Authority canon and re-order SECURITY-WP-0001

Browse source 
Review of spec/ModeOfAuthorityCanon-v0.1.md, recorded as a timestamped
assessment in history/. Two findings change the plan.

SecurityCanon is not only a recipient of extracted InfoTechCanon material. The
Mode of Authority draft is a native contribution and is plausibly the organizing
spine of the canon, so the vocabulary has to be settled before artifacts are
migrated into it rather than after.

Mode of Authority and CARING independently invented overlapping dimensions.
Scope, Subject, Activation/Condition and Capability/Operations collide by name
while differing in meaning, and CARING's Operator role reads as a synonym for
the OPERATE auth mode without being one. Merging naively would produce a canon
that misleads.

Workplan adapted: T02 becomes a three-way reconciliation with a required
dimension-collision table, T04 must declare Mode of Authority as an export, T05
now waits on the vocabulary being settled, and two tasks are added — T06 to
promote the draft into a checkable Tier-1 artifact with its orientation
surfaces, T07 to resolve the collision as a recorded decision.

The assessment leaves five questions to the owner, including whether CARING
migrates at all and whether Mode of Authority is security terminology or
general information-systems terminology.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AUkN13CAqtXWPXuEiEtmJj

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 36656@bnt-lap001
Assistant-Session: 66d6eece-d245-43ca-85e8-68a1b5970a67
This commit is contained in:
tegwick 2026-09-20 21:01:32 +02:00
parent 95267b137d
commit c8e941f5ab
2 changed files with 355 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

281
history/260920-mode-of-authority-and-canon-structure.md Normal file
View file

@ -0,0 +1,281 @@
---
id: SECURITY-ASSESSMENT-260920
type: assessment
title: "Mode of Authority Canon review and the structure of SecurityCanon"
repo: security-canon
author: claude
created: "2026-09-20T20:59:23+0200"
reviewed_artifact: spec/ModeOfAuthorityCanon-v0.1.md
status: for-review
---
# Mode of Authority review and the structure of SecurityCanon
Assessment written 2026-09-20 20:59 (Europe/Berlin) against
`spec/ModeOfAuthorityCanon-v0.1.md` at commit `1ac4f56`, InfoTechCanon at
`e1f98da`, and [INTENT.md](../INTENT.md) as bootstrapped the same day.
This is a recommendation for review, not a decision. It answers one question:
**how should SecurityCanon be structured so that it gives good orientation and
clean terminology?**
---
## 1. What the Mode of Authority Canon actually is
MoA v0.1 is a 1 346-line research draft that introduces one concept — the
**Mode of Authority** (short: **Auth Mode**) — and defends it carefully:
> A semantic classification of the intended relationship between an actor and a
> system scope, describing the nature and purpose of the authority being exercised.
Seven canonical modes: `USE`, `OBSERVE`, `OPERATE`, `ADMINISTER`, `GOVERN`,
`CONSTRUCT`, `SOVEREIGN`. Around them sit supporting dimensions — Scope,
Authority Realm, Actor/Subject, Delegation and Impersonation, Activation,
Authority Provenance, Principal Type, Environment, Evidence Boundary — plus a
compact notation (`MODE @ SCOPE` with modifiers), a ten-question design
heuristic, a stated research hypothesis, and seven open questions.
### Assessment of quality
The draft is **strong, and stronger than its "Research Draft" status suggests**.
Three things stand out:
1. **It is disciplined about what it is not.** Section 27 explicitly refuses
`AUDIT`, `SUPPORT`, `DEVELOPER`, `OWNER`, `BREAK_GLASS`, `SUPERADMIN`, `ROOT`
as modes and shows each as a composition. Principle A2 refuses the privilege
ladder (`USE < ADMINISTER < SOVEREIGN`). Section 14 refuses `root` as a mode.
A vocabulary that states its non-members is a vocabulary that can be checked.
2. **Its central distinction is real and load-bearing.** The `read + USE` vs
`read + OBSERVE` example (§8) shows the access-operation axis and the
authority-relationship axis are genuinely orthogonal. Most access models
collapse them, which is why `admin` means nothing portable.
3. **A3 and A5 are the valuable, unusual claims.** Auditability as a property
of the *Evidence Boundary* rather than of the mode, and sovereignty as
scope-relative with no universal root, are both positions that pay off
directly in federated and multi-tenant reasoning.
### Weaknesses to carry into review
- **No machine-readable form.** Everything is prose and fenced pseudo-notation.
There is no frontmatter, no artifact id, no schema, no `owned_concepts`. It is
not yet a canon artifact in the InfoTechCanon sense; it is a paper.
- **Q2 is not a minor open question.** "Is CONSTRUCT always distinct from
GOVERN?" — policy-as-code makes these overlap, and SecurityCanon's own
consumers run governance as code. This needs a position, not a placeholder.
- **Q3 (substrate authority) is under-served by the current model.** Hypervisor
over VM, host root over container, cloud provider over tenant: A5 says these
dominate without being universally sovereign, but there is no dimension that
records *which* realm dominates which. `AuthorityProvenance = SUBSTRATE` names
the fact without modeling the relation.
- **Purpose and Time appear in the Access Situation tuple (§4) and then vanish.**
Neither gets a section. InfoTechCanon already owns a PURPOSES/Purpose
extension, so Purpose is an import waiting to happen, not a gap to fill here.
- **`spec/` is the wrong home for it.** Under the InfoTechCanon Repository
Layout Standard, `spec/` is implementation guidance and guardrails
(PRD, technical spec); `research/` is "results of explorations in the problem
and solution space", `yymmdd-` prefixed. A self-declared research draft
proposing a vocabulary belongs in `research/` until it is promoted into the
canon proper. (Note: the file was swept into the bootstrap commit `1ac4f56`
by `git add -A`; it was not deliberately placed there by that commit.)
---
## 2. The finding that should change the plan
SECURITY-WP-0001 was written on the assumption that SecurityCanon is a
**recipient**: a destination for IT-security material extracted from
InfoTechCanon. MoA v0.1 shows that assumption is incomplete.
> SecurityCanon has a **native contribution** of its own, and that contribution
> is plausibly the organizing spine of the whole canon rather than one more
> artifact in it.
Auth Mode is not a peer of "the security model" and "the DevSecOps model". It is
the axis along which those, and CARING, and the access-control model, can be
read coherently. If the extraction proceeds first and the spine is fitted
afterwards, the imported artifacts will have already re-established their own
InfoTechCanon-shaped structure and the spine will not fit.
**Recommendation: settle the spine before the migration, not after.**
---
## 3. The terminology collision that must be resolved first
This is the sharpest finding in the review. MoA and InfoTechCanon's CARING
standard **independently invented overlapping vocabularies**, and several terms
collide by name while differing in meaning. Merging them naively would produce a
canon that is actively misleading.
### Three axes, currently conflated
| Axis | Question it answers | Where it lives today |
| --- | --- | --- |
| **Auth Mode** | In what *relationship* to the system is authority exercised? | MoA §6–13 |
| **Canonical Role** | What *lifecycle responsibility posture* does a subject hold toward the product? | CARING §11: Creator, Builder, Verifier, Maintainer, Integrator, Operator, Manager, Coach, Doer |
| **Plane** | Which *surface* of the system is touched? | CARING §22: Intent, Build, Runtime, Execution, Configuration, Data, Identity, Policy, Secret, Audit, Commercial, Community |
These are three genuinely different questions. The problem is that their value
sets rhyme:
| Looks like a duplicate | Actually |
| --- | --- |
| CARING role `Operator` vs MoA `OPERATE` | Different axes. A Maintainer can exercise `OPERATE`; an Operator can exercise `OBSERVE`. Same word, different question. |
| CARING `Build Plane` vs MoA `CONSTRUCT` | Near-synonymous in practice — the plane names the surface, the mode names the authority over it. Strongest merge candidate. |
| CARING `Policy Plane` vs MoA `GOVERN` | Plane is where policy lives; GOVERN is authority over authority. Related, not equal. |
| CARING `Audit Plane` vs MoA `Evidence Boundary` | Genuinely different: one is a surface, the other is a trust question ("can the observed alter the evidence?"). MoA's is the more useful concept. |
| CARING `Condition` vs MoA `Activation` | Substantially the same idea. MoA's enumeration (`STANDING`, `JIT`, `APPROVED`, `INCIDENT`, `BREAK_GLASS`, `RECOVERY`) is the better-developed one. |
| CARING `Capability` vs MoA `AccessOperations` | Overlapping. CARING's is richer. |
| CARING `Scope` vs MoA `Scope` | Same concept, two definitions. Must become one. |
| CARING `Subject` vs MoA `Actor`/`Subject` | MoA refines: it splits the acting entity from the authority context. CARING has only the one. MoA's split is the better model and should win. |
### What MoA adds that CARING does not have
`Authority Realm`, `Authority Provenance`, `Evidence Boundary`, `Environment`,
the Actor/Subject split, and scope-relative sovereignty. These are the real
contribution and none of them are redundant.
### What CARING has that MoA does not
Descriptive/prescriptive duality, the Native Role Warning, declared vs effective
access with an analysis requirement, exposure modes and exposure events,
lifecycle state, restriction, organization relation, a descriptor artifact, and a
worked Kubernetes RBAC benchmark. CARING is far more operationally developed.
**Neither subsumes the other.** The correct outcome is one dimension set with one
definition per concept, not two standards that each redefine Scope and Subject.
This is the single most important decision the canon has to make, and it should
be recorded as a decision because it binds both canons.
---
## 4. Recommended structure
### 4.1 Layer the canon in three tiers
Orientation fails when everything sits in one flat list. Three tiers, each
answering a different reader question:
```text
Tier 1 VOCABULARY What are the words? ← Mode of Authority
Tier 2 MODELS How do the words compose? ← access control, security,
DevSecOps
Tier 3 STANDARDS What must a system do? ← CARING, benchmarks, profiles
```
Auth Mode belongs in Tier 1 and nothing in Tier 1 may import from Tier 2 or 3.
CARING sits in Tier 3 and imports its dimensions from Tier 1 rather than
defining them. This is the structural move that resolves §3: the collision
disappears once there is exactly one place a dimension may be defined.
### 4.2 Proposed directory layout
Conforming to the InfoTechCanon Repository Layout Standard (`full` level) and
mirroring InfoTechCanon's own `infospace/` convention:
```text
INTENT.md SCOPE.md README.md AGENTS.md
infospace/
vocabulary/
mode-of-authority/ ← promoted from the research draft
SecurityCanonModeOfAuthority.md
auth-modes.yaml ← the seven modes, machine-readable
dimensions.yaml ← scope, activation, provenance,
evidence-boundary, principal-type,
environment
models/
access-control/ ← migrated from InfoTechCanon
security/ ← migrated
devsecops/ ← migrated
standards/
caring/ ← migrated; dimensions re-pointed to vocabulary/
benchmarks/kubernetes-rbac/
mappings/ ← to NIST, ISO 27001, K8s RBAC, cloud IAM
profiles/ ← worked examples
interfaces/
federation.yaml ← the canon-federation card (WP-0001-T04)
research/
260920-mode-of-authority-v0.1.md ← the draft, kept as provenance
spec/ docs/ workplans/ history/ demand/
```
`research/` keeps the v0.1 draft verbatim as provenance; `infospace/vocabulary/`
holds the promoted canon artifact. That separation lets the draft stay
readable as an argument while the canon artifact becomes checkable.
### 4.3 Orientation surface
Four things a reader or agent needs, none of which exist yet:
1. **A one-page vocabulary card** — the seven modes, the dimension list, and the
`MODE @ SCOPE` notation, on one screen. MoA §28's summary table is already
most of this.
2. **The design heuristic as the entry point.** MoA §29's ten questions are the
best orientation device in the draft and are currently buried at the end.
They should be the front door of the canon, not its appendix.
3. **A disambiguation page.** "You said *operator* — did you mean the CARING
canonical role or the `OPERATE` auth mode?" Given §3, this is not optional.
4. **Machine-readable indexes**, following InfoTechCanon's `infospace/agent/`
pattern, so agents retrieve terminology instead of guessing it.
### 4.4 Naming
Rename the artifact to `SecurityCanonModeOfAuthority` on promotion, matching the
`InfoTechCanon*` / `CommerceCanon*` convention. Keep **Auth Mode** as the short
term — it is good, and `MoA` should be avoided in prose.
Reserve a namespace now (`sec-authority:` for the vocabulary, `sec-caring:` for
the migrated standard). CARING currently owns `itc-caring:`, and that namespace
must be rewritten on migration, not aliased.
---
## 5. Recommended changes to SECURITY-WP-0001
| Task | Current | Recommended |
| --- | --- | --- |
| T02 disposition review | Two-way: what moves from InfoTechCanon | **Three-way**: reconcile MoA vocabulary, the ITC access-control model, and CARING. Add the dimension-collision table as required output. |
| T03 reference survey | Unchanged | Unchanged. |
| T04 federation card | Unchanged in intent | Must declare Auth Mode as a SecurityCanon **export**, not only ITC imports. |
| T05 migration handoff | Waits on T02+T03 | Also waits on the vocabulary promotion below. |
| — | — | **New: promote MoA v0.1 into a canon artifact** — frontmatter, id, `owned_concepts`, schema, machine-readable mode/dimension files, move draft to `research/`. |
| — | — | **New: resolve the dimension collision as a recorded decision** — it binds both canons, so it is a decision, not a task note. |
| — | — | **New: answer Q2 (CONSTRUCT vs GOVERN) and Q3 (substrate authority)** before the vocabulary is declared stable. |
The ordering changes: **vocabulary promotion and collision resolution come
before migration.** T05's migration workplan should be drafted against a settled
spine.
---
## 6. Open questions for the owner
These need your decision; I have not assumed answers.
1. **Does CARING migrate to SecurityCanon, or stay in InfoTechCanon and import
the vocabulary?** It imports eleven InfoTechCanon models — moving it is
expensive, and it may be the artifact that most belongs where the shared
roots are. This is the biggest single unresolved boundary question.
2. **Is Auth Mode security terminology or general information-systems
terminology?** A case exists that it belongs in InfoTechCanon, with
SecurityCanon consuming it — it describes authority in all systems, not only
security-relevant ones. I lean to it living here, because its payoff is
security reasoning, but the argument is not one-sided.
3. **Does the Actor/Subject split replace CARING's Subject dimension**, with
CARING rewritten accordingly? That is an upstream change to a
release-candidate standard.
4. **Is the identity model security terminology or a shared root?** Carried
forward unchanged from SCOPE.md; MoA's Principal Type dimension makes it
sharper but does not settle it.
5. **Does SecurityCanon need a service surface** (validation, indexes) or does
it reuse InfoTechCanon's Python service? The machine-readable files proposed
in §4.2 are only worth generating if something checks them.
---
## 7. Recommendation in one line
Promote Mode of Authority into a proper Tier-1 vocabulary artifact and resolve
its collision with CARING's dimensions **first**; let that settled vocabulary
determine what migrates and how, rather than migrating into an unsettled spine.

79
workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md
View file

@ -22,7 +22,17 @@ disposition that the migration itself will follow.
Scope is bootstrap and planning. The migration of artifacts is deliberately not
in this workplan: it depends on the disposition review in T02 and gets its own
workplan once the boundary is settled. See [INTENT.md](../INTENT.md) for the
layer claim and [INTENT.md](../INTENT.md) for the success gates.
layer claim and the success gates.
**Revised 2026-09-20** after reviewing `spec/ModeOfAuthorityCanon-v0.1.md`. The
[Mode of Authority assessment](../history/260920-mode-of-authority-and-canon-structure.md)
found that SecurityCanon is not only a recipient of extracted material: the Mode
of Authority draft is a native contribution and is plausibly the organizing spine
of the canon. It also found that Mode of Authority and CARING independently
invented overlapping dimensions — Scope, Subject, Activation/Condition,
Capability/Operations — that collide by name while differing in meaning.
Consequently the vocabulary is settled *before* the migration, not after: T06 and
T07 are new and precede T05.
## Establish repository governance and registration
@ -54,6 +64,15 @@ rationale and the resulting import declarations. Candidates are the security,
access control, and DevSecOps models, the CARING access governance standard, and
its Kubernetes RBAC benchmark.
The review is **three-way**, not two-way: it reconciles the Mode of Authority
vocabulary, the InfoTechCanon access-control model, and CARING. Required output
includes the dimension-collision table — one row per overlapping concept, naming
the single surviving definition and its owning tier. Assessment section 3 holds
the first draft of that table.
Answer explicitly whether CARING migrates at all. It imports eleven InfoTechCanon
models, so staying put and importing the vocabulary is a live option.
Resolve the open boundary questions rather than assuming them: whether the
identity model is security terminology or a shared root; how the small-saas
profile's policy, control, evidence, and incident artifacts split; and which
@ -86,7 +105,8 @@ state_hub_task_id: "a844ccdc-f75d-53b6-858e-c92f30aad7ce"
Publish SecurityCanon's interface card with actual imports, available exports,
source authority, maturity, and peer references, following the pattern
CommerceCanon and InterfaceCanon established. Add reciprocal navigation with
CommerceCanon and InterfaceCanon established. The card must declare Mode of
Authority as a SecurityCanon **export**, not only InfoTechCanon imports. Add reciprocal navigation with
InfoTechCanon and pass the canon-federation validator. Coordinate with
prj-canon-federation rather than amending federation governance here.
@ -99,9 +119,58 @@ priority: medium
state_hub_task_id: "387bfae1-c7a1-5826-856e-f5364121f849"
```
With the disposition (T02) and reference survey (T03) reviewed, draft the
migration workplan — slice order, provenance handling, and the per-slice
validation gate for both canons. Waits on T02 and T03.
With the disposition (T02), reference survey (T03), vocabulary promotion (T06)
and dimension decision (T07) settled, draft the migration workplan — slice order,
provenance handling, and the per-slice validation gate for both canons.
Migrating into an unsettled spine is the failure this ordering prevents.
## Promote Mode of Authority into a canon artifact
```task
id: SECURITY-WP-0001-T06
status: todo
priority: high
```
Turn the v0.1 research draft into a checkable Tier-1 vocabulary artifact:
frontmatter with artifact id, namespace and `owned_concepts`; machine-readable
files for the seven auth modes and the supporting dimensions; and the three
orientation surfaces the assessment names — the one-page vocabulary card, the
ten-question design heuristic promoted to the front door, and the
role/plane/mode disambiguation page.
Move the draft verbatim to `research/260920-mode-of-authority-v0.1.md` as
provenance. It currently sits in `spec/`, which the Repository Layout Standard
reserves for implementation guidance; a self-declared research draft belongs in
`research/` until promoted.
Close the two open questions that block stability: Q2, whether CONSTRUCT is
always distinct from GOVERN under policy-as-code, and Q3, how substrate
authority is represented. Purpose and Time appear in the Access Situation tuple
without sections; resolve Purpose as an import from InfoTechCanon's PURPOSES
extension rather than defining it here.
## Decide the dimension collision
```task
id: SECURITY-WP-0001-T07
status: todo
priority: high
```
Record a decision — not a task note — resolving each overlapping dimension to
one definition in one tier, because the outcome binds both canons. At minimum:
Scope, Subject versus the Actor/Subject split, Activation versus CARING
Condition, Capability versus AccessOperations, Build Plane versus CONSTRUCT,
Audit Plane versus Evidence Boundary, and the `Operator` role versus the
`OPERATE` mode.
Also decide the prior question the assessment raises: whether Mode of Authority
is security terminology owned here, or general information-systems terminology
that belongs in InfoTechCanon with SecurityCanon consuming it.
Reserve namespaces as part of the decision. CARING currently owns `itc-caring:`,
which must be rewritten rather than aliased if it migrates.
## Out of scope