security-canon/history/260920-mode-of-authority-and-canon-structure.md

id	type	title	repo	author	created	reviewed_artifact	status
SECURITY-ASSESSMENT-260920	assessment	Mode of Authority Canon review and the structure of SecurityCanon	security-canon	claude	2026-09-20T20:59:23+0200	spec/ModeOfAuthorityCanon-v0.1.md	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 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:

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:

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.