diff --git a/history/260920-mode-of-authority-and-canon-structure.md b/history/260920-mode-of-authority-and-canon-structure.md new file mode 100644 index 0000000..2f7626e --- /dev/null +++ b/history/260920-mode-of-authority-and-canon-structure.md @@ -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. diff --git a/workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md b/workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md index 4058b0b..a2e7c76 100644 --- a/workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md +++ b/workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md @@ -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