--- 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.