From c8e941f5abbdc56b900614b6883d1fcb3851dd7b Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 20 Sep 2026 21:01:32 +0200 Subject: [PATCH] Assess Mode of Authority canon and re-order SECURITY-WP-0001 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 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 --- ...0-mode-of-authority-and-canon-structure.md | 281 ++++++++++++++++++ ...Y-WP-0001-bootstrap-and-extraction-plan.md | 79 ++++- 2 files changed, 355 insertions(+), 5 deletions(-) create mode 100644 history/260920-mode-of-authority-and-canon-structure.md 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