From 383e75f6b21358e858c9566d5bf3dd6f98150c14 Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 20 Sep 2026 21:34:45 +0200 Subject: [PATCH] Re-scope SecurityCanon to architecture-layer vocabulary (SEC-ADR-001) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Owner decision of 2026-09-20 answering four of the five open questions from the Mode of Authority assessment, recorded as SEC-DEC-0001 with the reasoning in docs/adr-001-securitycanon-boundary.md. CARING stays in InfoTechCanon: it is implementation-layer and imports eleven InfoTechCanon models, and SecurityCanon should help rather than hinder keeping InfoTechCanon practical. Identity stays a shared root, since pulling it in would collapse too much into security and it reaches into personhood; a dedicated identity or personhood canon is deferred, not rejected. Mode of Authority is architecture where CARING is implementation — different layers of abstraction, neither subsuming the other, but they must not use the same word for different things. No service surface is duplicated: integration is uniform across commerce-canon, interface-canon and security-canon through the canon-federation interface card, and InfoTechCanon's service stays the only one. Content migration is therefore no longer a goal. T02 narrows from a disposition review to concept placement, T03 becomes a non-collision survey, and T05, the migration workplan handoff, is cancelled. T06 gains the three-way mapping table and T07 becomes the terminology separation decision. The remaining open question is analysed in docs/260920-actor-subject-implications.md. InfoTechCanon's access-control model already owns Actor and Subject and binds them as "Subject is the access-control view of an actor", while Mode of Authority uses the same two words for two distinct parties; and CARING already carries the split for non-human subjects. The note recommends renaming Mode of Authority's second party to Authority Context rather than changing a release-candidate standard. 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 --- .repo-manager/index.json | 124 +++++++++++++ INTENT.md | 108 ++++++++---- README.md | 24 ++- SCOPE.md | 62 ++++--- decisions/decisions.md | 13 ++ docs/260920-actor-subject-implications.md | 163 ++++++++++++++++++ docs/adr-001-securitycanon-boundary.md | 132 ++++++++++++++ ...URITY-WP-0001-bootstrap-and-vocabulary.md} | 101 ++++++----- 8 files changed, 621 insertions(+), 106 deletions(-) create mode 100644 .repo-manager/index.json create mode 100644 decisions/decisions.md create mode 100644 docs/260920-actor-subject-implications.md create mode 100644 docs/adr-001-securitycanon-boundary.md rename workplans/{SECURITY-WP-0001-bootstrap-and-extraction-plan.md => SECURITY-WP-0001-bootstrap-and-vocabulary.md} (54%) diff --git a/.repo-manager/index.json b/.repo-manager/index.json new file mode 100644 index 0000000..7ccb026 --- /dev/null +++ b/.repo-manager/index.json @@ -0,0 +1,124 @@ +{ + "schema": "repo_manager.index.v1", + "slug": "security-canon", + "repo_root": "/home/worsch/security-canon", + "head_sha": "8251f8022d460924a5273eff6ba2fbc181532a25", + "observed_at": "2026-09-20T19:34:32.162255Z", + "source_fingerprint": "015164818408dfe0982f7abd9be81a04bbf641d2941b9d68a80390e78b8de932", + "source_files": [ + ".repo-classification.yaml", + "INTENT.md", + "decisions/decisions.md", + "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md" + ], + "work_records": [ + { + "kind": "workplan", + "id": "SECURITY-WP-0001", + "status": "active", + "title": "Bootstrap security-canon and establish the Mode of Authority vocabulary", + "source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md", + "uuid": "72c0e8f7-c904-59bd-9a7f-55d6de8ac715", + "parent_id": null, + "extra": {} + }, + { + "kind": "task", + "id": "SECURITY-WP-0001-T01", + "status": "done", + "title": "Establish repository governance and registration", + "source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md", + "uuid": "9eabbe55-3529-5821-a248-d05c57a3556f", + "parent_id": "SECURITY-WP-0001", + "extra": {} + }, + { + "kind": "task", + "id": "SECURITY-WP-0001-T02", + "status": "todo", + "title": "Boundary and terminology review", + "source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md", + "uuid": "8b9e4cd0-9905-5ae8-9a23-8957110d72e4", + "parent_id": "SECURITY-WP-0001", + "extra": {} + }, + { + "kind": "task", + "id": "SECURITY-WP-0001-T03", + "status": "todo", + "title": "Reference-impact survey", + "source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md", + "uuid": "dd8bc579-6a89-5b77-bfd8-3acdb4a4f472", + "parent_id": "SECURITY-WP-0001", + "extra": {} + }, + { + "kind": "task", + "id": "SECURITY-WP-0001-T04", + "status": "todo", + "title": "Federation interface card and reciprocal navigation", + "source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md", + "uuid": "a844ccdc-f75d-53b6-858e-c92f30aad7ce", + "parent_id": "SECURITY-WP-0001", + "extra": {} + }, + { + "kind": "task", + "id": "SECURITY-WP-0001-T05", + "status": "cancel", + "title": "Migration workplan handoff \u2014 cancelled", + "source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md", + "uuid": "387bfae1-c7a1-5826-856e-f5364121f849", + "parent_id": "SECURITY-WP-0001", + "extra": {} + }, + { + "kind": "task", + "id": "SECURITY-WP-0001-T06", + "status": "todo", + "title": "Promote Mode of Authority into a canon artifact", + "source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md", + "uuid": "de5fc42c-2e18-5f03-b86c-a5ad45a9bb0a", + "parent_id": "SECURITY-WP-0001", + "extra": {} + }, + { + "kind": "task", + "id": "SECURITY-WP-0001-T07", + "status": "todo", + "title": "Decide the terminology separation", + "source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md", + "uuid": "4a0d3df9-d8a2-51c4-a4bc-72488d866068", + "parent_id": "SECURITY-WP-0001", + "extra": {} + }, + { + "kind": "decision", + "id": "SEC-DEC-0001", + "status": "accepted", + "title": "SecurityCanon boundary: CARING stays in InfoTechCanon; Auth Mode is architecture-layer vocabulary", + "source_path": "decisions/decisions.md", + "uuid": null, + "parent_id": null, + "extra": { + "record": { + "id": "SEC-DEC-0001", + "kind": "decision", + "title": "SecurityCanon boundary: CARING stays in InfoTechCanon; Auth Mode is architecture-layer vocabulary", + "status": "accepted", + "created": "2026-09-20T19:30:50.120170Z", + "updated": "2026-09-20T19:30:50.120170Z" + } + } + } + ], + "events": [ + { + "type": "repo.reconciled", + "workplan_count": 1, + "task_count": 7, + "source": "repo-manager", + "emitted_at": "2026-09-20T19:34:32.162320Z" + } + ] +} diff --git a/INTENT.md b/INTENT.md index 8d8a6f4..2d28707 100644 --- a/INTENT.md +++ b/INTENT.md @@ -9,14 +9,17 @@ and avoid redefining concepts another canon already owns. ## Origin and demand The initial demand is the repository owner's 2026-09-20 request to refine -InfoTechCanon by moving its IT-security material into a dedicated canon. -InfoTechCanon has accumulated security content — a security model, an access -control model, a DevSecOps model, the CARING access governance standard, and the -CARING Kubernetes RBAC benchmark — that is orthogonal to its taxonomy-layer role -and better served by a canon with its own review cadence and consumers. +InfoTechCanon by giving its IT-security material a dedicated home. -Extraction is a migration, not a rewrite. Source artifacts keep their provenance, -and InfoTechCanon retains the shared roots that security terminology imports. +Reviewing the Mode of Authority draft changed what that means. SecurityCanon's +first contribution is **architecture-layer security vocabulary of its own**, not +a transfer of InfoTechCanon's content. Per [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md), +content migration is neither urgent nor a goal in itself: + +> SecurityCanon should help, not hinder, keeping InfoTechCanon practical. + +An artifact moves only when moving it makes both canons more practical, and the +burden of proof is on the move. Anything that does move keeps its provenance. ## Layer and boundary @@ -37,7 +40,11 @@ depends: - **whitehat-security** owns adversarial evidence and findings practice. - **InfoTechCanon** remains the authority for the shared roots — artifact, ownership, relationship, mapping, assimilation, profile, pattern, conformance, - provenance, and interface mechanisms — that this canon imports. + provenance, and interface mechanisms — that this canon imports. It also keeps + **CARING**, the access-control model, and the **identity** model: CARING because + it is implementation-layer and imports eleven InfoTechCanon models, identity + because it is a shared root reaching into personhood rather than a security + concern. A dedicated identity or personhood canon is deferred, not rejected. - Consumers own their own adoption evidence and importing profiles. A generic security semantic contract belongs here; a security obligation imposed @@ -62,6 +69,13 @@ network-shaped rather than purely hierarchical, pattern-oriented rather than mer taxonomic, externally mappable without being externally constrained, and orthogonal without becoming isolated. +It adds one stance of its own: **architecture, not implementation.** SecurityCanon +describes the relationships in which authority is exercised, before and +independently of the mechanisms that enforce them. CARING occupies the +implementation layer in InfoTechCanon. The two are different layers of +abstraction, and neither subsumes the other — but they must not use the same word +for different things. + External standards influence SecurityCanon through mappings and assimilation. They do not define its internal semantics directly. @@ -69,11 +83,16 @@ They do not define its internal semantics directly. 1. Every canonical security concept has a clear owner. 2. Concepts are imported from their owning canon, never redefined. -3. Mappings to external bodies of knowledge are explicit, versioned, scoped, and justified. -4. Migrated artifacts preserve provenance and their InfoTechCanon history. -5. Profiles constrain standards for concrete implementation contexts. -6. Artifacts are useful to both humans and agents. -7. Evolution preserves provenance, compatibility information, and rationale. +3. Direct terminology overlap with InfoTechCanon is avoided: where a concept is + shared it is defined once upstream and imported; where concepts genuinely + differ, the names must visibly differ. +4. Mappings to external bodies of knowledge are explicit, versioned, scoped, and justified. +5. Migrated artifacts preserve provenance and their InfoTechCanon history. +6. Profiles constrain standards for concrete implementation contexts. +7. Artifacts are useful to both humans and agents. +8. Evolution preserves provenance, compatibility information, and rationale. +9. Integration with InfoTechCanon is uniform with the other domain canons, and + the service surface is never duplicated. ## Non-goals @@ -82,30 +101,44 @@ OWASP, or MITRE ATT&CK. It does not define one mandatory security model every system must fully implement, operate consumer systems, enforce policy, issue credentials, or provide production authorization or detection services. +It also ships **no service surface of its own** — no CLI, HTTP API, or validation +service. InfoTechCanon's service is the single place canons are inspected and +validated, and SecurityCanon ties into it through the same canon-federation +interface card mechanism that CommerceCanon and InterfaceCanon use. A check that +does not exist yet is a change to InfoTechCanon's service, not a second service +here. + ## Direction of travel -The repository should initially establish the canon skeleton and federation -interface, then receive the security material extracted from InfoTechCanon with -its provenance intact, then publish mappings and at least one worked profile. +The repository should first promote the Mode of Authority draft into a checkable +architecture-layer vocabulary with its orientation surfaces, publish its +federation interface card declaring that vocabulary as an export, and publish the +mapping that relates it to InfoTechCanon's access-control model and CARING. + +Only then, and only where it demonstrably helps both canons, does content move. Stable promotion requires reviewed mappings and concrete consumer evidence. ## Outcome -InfoTechCanon's IT-security material lives in SecurityCanon as a coherent, -independently reviewable canon: security terminology, the CARING access -governance standard and its Kubernetes RBAC benchmark, published with declared -imports from InfoTechCanon, a federation interface card, and preserved -provenance — while InfoTechCanon retains only the shared roots those artifacts -import and carries no dangling references. +SecurityCanon is a coherent architecture-layer security vocabulary that +InfoTechCanon references: Mode of Authority published as a checkable artifact +with declared imports, a federation interface card declaring it as an export, +orientation surfaces that let a reader or agent find the right term, and a +mapping that relates it cleanly to InfoTechCanon's access-control model and +CARING — with InfoTechCanon left more practical than before, not less. ## Invariants -- InfoTechCanon remains valid at every step: `make check` passes and its - validation reports zero errors before and after each migration slice. -- Migrated artifacts keep their provenance and their InfoTechCanon history; - extraction is a move with recorded lineage, not a rewrite. +- InfoTechCanon remains valid and remains practical: `make check` passes and its + validation reports zero errors, and no change here makes working in + InfoTechCanon harder. +- Any migrated artifact keeps its provenance and its InfoTechCanon history; + a move is a move with recorded lineage, never a rewrite. - Concepts are imported from their owning canon, never redefined on both sides. - No concept is left unowned, and no concept is claimed by two canons. +- No word means one thing here and a different thing in InfoTechCanon. +- Integration stays uniform with CommerceCanon and InterfaceCanon; no service + surface is duplicated. - The State Hub stays a read model: workplan files here are authoritative and are registered by `fix-consistency`, never by hand. @@ -113,19 +146,20 @@ import and carries no dangling references. 1. Repository registered in the State Hub with a topic, classification, and federation interface card; reciprocal navigation with InfoTechCanon passes - the canon-federation validator. -2. A reviewed disposition record naming, for every security artifact in - InfoTechCanon, whether it moves, stays, or splits — with rationale. -3. Migration complete: the artifacts dispositioned as `move` are present here - with provenance, and absent from InfoTechCanon. -4. Both canons validate clean after migration, with no unresolved cross-canon - references in either direction. + the canon-federation validator, by the same mechanism the other canons use. +2. Mode of Authority promoted into a checkable artifact with machine-readable + modes and dimensions, and its open questions on CONSTRUCT-versus-GOVERN and + substrate authority answered. +3. A published mapping relating the vocabulary to InfoTechCanon's access-control + model and CARING, with no term colliding across the two canons. +4. Orientation surfaces present: the vocabulary card, the design heuristic as + the entry point, and the role/plane/mode disambiguation page. 5. At least one worked profile or benchmark demonstrates the canon is usable by a consumer, and its scope statement is reviewed against intent. ## Project retirement -Archive this repository only if the extraction is abandoned and the material -returns to InfoTechCanon. On success this repository does not retire — it -becomes a standing canon and its project flavor is reconsidered, as -CommerceCanon and InterfaceCanon were. +Archive this repository only if the vocabulary is abandoned or absorbed +upstream. On success this repository does not retire — it becomes a standing +canon and its project flavor is reconsidered, as CommerceCanon and +InterfaceCanon were. diff --git a/README.md b/README.md index 7e4d604..277f6e4 100644 --- a/README.md +++ b/README.md @@ -5,9 +5,15 @@ Orthogonal vocabulary and canonical model for security-related concepts. SecurityCanon extends InfoTechCanon with a focused security domain model, in the same architectural role that [CommerceCanon](../commerce-canon) holds for commercial terminology and [InterfaceCanon](../interface-canon) for interface -terminology. Its initial content is the IT-security material extracted from -InfoTechCanon: the security, access control, and DevSecOps models, the CARING -access governance standard, and the CARING Kubernetes RBAC benchmark. +terminology. + +Its subject is **architecture, not implementation**: the relationships in which +authority is exercised, described before and independently of the mechanisms +that enforce them. Its first contribution is the **Mode of Authority** vocabulary +— seven auth modes (`USE`, `OBSERVE`, `OPERATE`, `ADMINISTER`, `GOVERN`, +`CONSTRUCT`, `SOVEREIGN`) read relative to a scope. CARING and the access-control +and identity models stay in InfoTechCanon, at the implementation layer and as +shared roots; see [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md). | | | | --- | --- | @@ -15,12 +21,20 @@ access governance standard, and the CARING Kubernetes RBAC benchmark. | **Domain** | infotech | | **Workplan prefix** | `SECURITY-WP-` | | **Upstream canon** | [InfoTechCanon](../info-tech-canon) | +| **Service surface** | none — reuses InfoTechCanon's | Start with [INTENT.md](INTENT.md) and [SCOPE.md](SCOPE.md). Agent instructions are in [AGENTS.md](AGENTS.md); active work is in [workplans/](workplans/). +| Document | What it holds | +| --- | --- | +| [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md) | the boundary decision — what stays upstream, and why | +| [Mode of Authority assessment](history/260920-mode-of-authority-and-canon-structure.md) | review of the v0.1 draft and the proposed canon structure | +| [Actor/Subject implications](docs/260920-actor-subject-implications.md) | the one open terminology question, analysed | + ## Status -Bootstrap. The repository is registered and governed, but holds no migrated -canon content yet. See [SECURITY-WP-0001](workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md). +Bootstrap. The repository is registered and governed. Its only content is the +Mode of Authority v0.1 research draft, not yet promoted into a canon artifact. +See [SECURITY-WP-0001](workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md). diff --git a/SCOPE.md b/SCOPE.md index f3755de..50903d6 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -1,12 +1,15 @@ # SCOPE -Reviewed: 2026-09-20 (Europe/Berlin). +Reviewed: 2026-09-20 (Europe/Berlin), after [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md). ## Current repository scope -Bootstrap. The repository carries governance files — INTENT, GOAL, SCOPE, -AGENTS, repo classification — and one active workplan. It holds no canon -content and no service code yet. +Bootstrap. The repository carries governance files — INTENT, SCOPE, AGENTS, +repo classification — the [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md) +boundary decision, the Mode of Authority review in `history/`, and one active +workplan. The only content is the Mode of Authority v0.1 research draft, not yet +promoted into a canon artifact. There is no service code, and by decision there +will be none. ## Ownership and boundaries @@ -16,6 +19,11 @@ shared roots from InfoTechCanon and does not redefine them. Out of scope, with the owner named: +- the CARING access governance standard and its Kubernetes RBAC benchmark, + the access-control model, and the identity model — **InfoTechCanon**, by + SEC-ADR-001 D1 and D3 +- any CLI, HTTP API, or validation service — **InfoTechCanon's service surface**, + by SEC-ADR-001 D4; integration is via the canon-federation interface card - security architecture and standards of record for the estate — NetKingdom - authorization decisions — flex-auth - login, OIDC, MFA — key-cape / Keycloak @@ -26,27 +34,39 @@ Out of scope, with the owner named: ## Planned scope -The extraction candidates in InfoTechCanon, pending the disposition review in -`SECURITY-WP-0001-T02`: +The near-term deliverable is the architecture-layer vocabulary, not a migration. -| Source path in info-tech-canon | Kind | +| Deliverable | Task | | --- | --- | -| `infospace/models/security/` | model | -| `infospace/models/access-control/` | model | -| `infospace/models/devsecops/` | model | -| `infospace/standards/caring/` | standard | -| `infospace/standards/caring/benchmarks/kubernetes-rbac/` | benchmark | +| Mode of Authority promoted to a checkable Tier-1 artifact | `SECURITY-WP-0001-T06` | +| Terminology separation from CARING and the access-control model | `SECURITY-WP-0001-T07` | +| Federation interface card declaring Auth Mode as an export | `SECURITY-WP-0001-T04` | +| Orientation surfaces: vocabulary card, design heuristic, disambiguation page | `SECURITY-WP-0001-T06` | -Open boundary questions the disposition review must answer, not assume: +InfoTechCanon artifacts this canon **references rather than absorbs**: -- whether `infospace/models/identity/` is security terminology or a shared root - that stays in InfoTechCanon; -- how the small-saas profile's security artifacts (policy, control, evidence, - incident) split between the two canons; -- which InfoTechCanon concepts become declared imports rather than moves. +| Path in info-tech-canon | Relationship | +| --- | --- | +| `infospace/standards/caring/` | implementation layer; imports the vocabulary | +| `infospace/models/access-control/` | owns Subject, Principal, IdentityReference | +| `infospace/models/identity/` | shared root; stays upstream | +| `infospace/models/security/` | boundary under review in `SECURITY-WP-0001-T02` | +| `infospace/models/devsecops/` | boundary under review in `SECURITY-WP-0001-T02` | + +Open questions, carried and not assumed: + +- whether the security and DevSecOps models are better placed here or upstream — + the only remaining migration candidates, and neither is urgent; +- how the small-saas profile's security artifacts relate to this canon; +- the Actor/Subject naming question, analysed in + [the implications note](docs/260920-actor-subject-implications.md) and decided + under `SECURITY-WP-0001-T07`. ## Exclusions and evolution -No service surface, CLI, HTTP API, or validation tooling is in scope until the -canon content exists and a demand for them is recorded. Whether SecurityCanon -reuses InfoTechCanon's Python service or ships its own is deferred. +No service surface is in scope, now or later: SEC-ADR-001 D4 settles that +SecurityCanon reuses InfoTechCanon's service rather than shipping its own. A +check that does not exist is a change request against InfoTechCanon. + +A dedicated identity or personhood canon may eventually be right. It is deferred +and belongs to no current workplan. diff --git a/decisions/decisions.md b/decisions/decisions.md new file mode 100644 index 0000000..b9b6dc4 --- /dev/null +++ b/decisions/decisions.md @@ -0,0 +1,13 @@ +# Decision records + +## SEC-DEC-0001 — SecurityCanon boundary: CARING stays in InfoTechCanon; Auth Mode is architecture-layer vocabulary + +```yaml +id: SEC-DEC-0001 +kind: decision +title: 'SecurityCanon boundary: CARING stays in InfoTechCanon; Auth Mode is architecture-layer + vocabulary' +status: accepted +created: '2026-09-20T19:30:50.120170Z' +updated: '2026-09-20T19:30:50.120170Z' +``` diff --git a/docs/260920-actor-subject-implications.md b/docs/260920-actor-subject-implications.md new file mode 100644 index 0000000..1e3c7b6 --- /dev/null +++ b/docs/260920-actor-subject-implications.md @@ -0,0 +1,163 @@ +--- +id: SEC-NOTE-260920 +type: analysis +title: "Implications of the Actor/Subject split for CARING and the access-control model" +repo: security-canon +status: for-discussion +created: "2026-09-20" +relates_to: SEC-ADR-001 +carried_by: SECURITY-WP-0001-T07 +--- + +# Implications of the Actor/Subject split + +Question 3 of the [Mode of Authority assessment](../history/260920-mode-of-authority-and-canon-structure.md), +left open by [SEC-ADR-001](adr-001-securitycanon-boundary.md) for review and +discussion. This note does not decide it. + +## 1. What MoA proposes + +MoA §19–20 splits the acting entity from the authority context: + +```text +actor = support-agent ← the entity performing the action +subject = customer-123 ← whose authority context is being used +relation = IMPERSONATED ← or DELEGATED +``` + +The claim is that `actor = subject` is the normal case but not the universal +one, and that delegation, impersonation, service accounts, token exchange and +agentic automation all depend on being able to say so. + +The claim is correct. The problem is entirely one of naming. + +## 2. The finding that reframes the question + +**The split already exists downstream — twice — under different names.** + +### InfoTechCanon access-control model §11.2 + +```text +Subject is the access-control view of an actor. +Actor semantics are owned by the Organization Model. +``` + +So InfoTechCanon already owns both words, and binds them in a **specific +relationship**: Subject is a *view of* Actor. Actor is owned by the Organization +Model, not by access control at all. + +MoA uses the same two words for a **different relationship**: Actor and Subject +are two distinct parties, one acting on behalf of the other. + +This is not an overlap that can be papered over. Under SEC-ADR-001 D2 — related +concepts at different layers must not share a word for different things — this is +the clearest violation in the entire vocabulary, and it is MoA's to fix, because +InfoTechCanon owns the terms and owned them first. + +### CARING §32 + +For non-human subjects, CARING already distinguishes: + +```text +Principal +Effective actor +Delegator +Tool or agent +Policy ceiling +Execution context +Audit identity +``` + +with an explicit agent access formula: + +```text +Effective Agent Access = + Delegated Human/System Authority + ∩ Agent Capability Ceiling + ∩ Scope Boundary + ∩ Exposure Policy +``` + +and it classifies execution paths as Direct, Delegated, Mediated and Induced +(§33), with an `ImpersonationBlocked` restriction (§29). + +**CARING therefore does not lack the distinction.** It has a richer one than MoA +— Delegator, audit identity, capability ceiling, induced paths — but it is scoped +to non-human subjects and expressed as a formula rather than as a general +dimension. + +### Consequence + +The original framing — "does MoA's split replace CARING's single Subject +dimension?" — rests on a false premise. CARING's Subject dimension is not single; +§32 and §33 already carry the split. The real questions are narrower: + +1. What does MoA call its two parties, given InfoTechCanon owns *Actor* and + *Subject* with a different meaning? +2. Should CARING's §32 vocabulary be generalised beyond non-human subjects? + +## 3. Options for question 1 — naming + +| Option | Description | Assessment | +| --- | --- | --- | +| **A. MoA adopts the downstream names** | Use CARING's `Principal` / `Effective actor` / `Delegator`. | Rejected. Imports implementation vocabulary into the architecture layer, which inverts the layering SEC-ADR-001 D2 establishes. | +| **B. MoA renames its second term** | Keep `Actor`; rename MoA's `Subject` to something unambiguous — `Authority Context`, `Mandate Source`, or `On-Behalf-Of Party`. | **Recommended.** Smallest change, no upstream churn, and it removes the collision at its source. `Actor` survives because MoA's use is compatible with the Organization Model's ownership of actor semantics. | +| **C. Change InfoTechCanon** | Redefine Subject upstream so both readings align. | Rejected. Edits a release-candidate standard and eleven dependent models to accommodate a draft. Contradicts D1's "help, not hinder". | +| **D. Document and live with it** | Keep both meanings, add a disambiguation page. | Rejected as a primary answer. A disambiguation page is needed regardless, but it is not a substitute for not having the collision. | + +Under option B, the MoA notation becomes: + +```text +support-agent: + USE @ tenant/acme + authority_context = customer-42 + relation = IMPERSONATED +``` + +`Authority Context` is preferred over the alternatives because it names what the +field actually holds — the authority being drawn on — rather than a party, which +keeps it true when the on-behalf-of target is a role or a mandate rather than a +person. + +## 4. Options for question 2 — generalising CARING §32 + +The split matters for human-on-human cases too: a support agent impersonating a +customer involves no non-human subject, yet needs exactly the same treatment. + +| Option | Description | Assessment | +| --- | --- | --- | +| **A. Leave CARING unchanged** | Non-human scoping stands; SecurityCanon maps into it. | Viable. Zero upstream cost. Leaves a real gap for human impersonation. | +| **B. Generalise the §32 role set** | Drop "for non-human subjects"; the roles apply to any subject. | **Recommended, if and when InfoTechCanon wants it.** Additive, non-breaking, and the formula already generalises unchanged. | +| **C. Add a full dimension** | Promote actor/authority-context to a twelfth CARING dimension. | Premature. §32 and §33 cover the cases; a new dimension would duplicate them. | + +Option B is an InfoTechCanon change, not a SecurityCanon one. Per SEC-ADR-001 it +should be raised as a demand signal against InfoTechCanon and accepted on its own +merits, not bundled into SecurityCanon's vocabulary work. **Nothing in +SecurityCanon blocks on it.** + +## 5. What SecurityCanon does regardless of the outcome + +Independent of both questions, the vocabulary promotion (`SECURITY-WP-0001-T06`) +must publish a mapping table at the boundary, because three vocabularies describe +these entities today and readers will meet all three: + +| MoA (architecture) | ITC access control | CARING (implementation) | +| --- | --- | --- | +| Actor | Subject / Principal | Principal, Effective actor | +| Authority Context *(proposed)* | — | Delegator | +| relation = DELEGATED | — | Delegated Access (§33.2) | +| relation = IMPERSONATED | — | Customer impersonation; `ImpersonationBlocked` | +| — | — | Audit identity, capability ceiling | + +The blank cells are informative: MoA has no notion of a capability ceiling, and +InfoTechCanon's access-control model has no on-behalf-of relation at all. Neither +gap is urgent, and neither is a reason to move content between canons. + +## 6. Recommendation + +Adopt **3B** — rename MoA's second party to `Authority Context` — and treat +**4B** as a separate, optional demand signal against InfoTechCanon. Publish the +mapping table in §5 as part of the vocabulary promotion either way. + +This keeps the collision out of the canon without touching a release-candidate +standard, which is what SEC-ADR-001 D1 and D2 jointly ask for. diff --git a/docs/adr-001-securitycanon-boundary.md b/docs/adr-001-securitycanon-boundary.md new file mode 100644 index 0000000..48f913e --- /dev/null +++ b/docs/adr-001-securitycanon-boundary.md @@ -0,0 +1,132 @@ +--- +id: SEC-ADR-001 +decision_record: SEC-DEC-0001 +type: adr +title: "SecurityCanon boundary: abstraction layers, not content extraction" +repo: security-canon +status: accepted +decided: "2026-09-20" +decided_by: repository owner +supersedes_assumption: "SECURITY-WP-0001 as originally drafted" +--- + +# SEC-ADR-001 — SecurityCanon boundary + +Owner decision of 2026-09-20, answering questions 1, 2, 4 and 5 of the +[Mode of Authority assessment](../history/260920-mode-of-authority-and-canon-structure.md). +Question 3 remains open and is treated in §6. + +## Context + +SecurityCanon was bootstrapped on the assumption that it is a destination for +IT-security material extracted from InfoTechCanon. Reviewing +`ModeOfAuthorityCanon-v0.1.md` showed that assumption was incomplete: the draft +is a native contribution, and it collides on terminology with InfoTechCanon's +CARING standard. Four questions were put to the owner. + +## Decision + +### D1 — CARING stays in InfoTechCanon + +CARING is not migrated. It imports eleven InfoTechCanon models, and moving it +would cost more than it returns. + +The governing principle the owner stated: + +> SecurityCanon should help, not hinder, keeping InfoTechCanon practical. + +Content migration is therefore **not urgent and not a goal in itself**. An +artifact moves only when moving it makes both canons more practical, and the +burden of proof is on the move. + +### D2 — Auth Mode and CARING are different layers of abstraction + +Mode of Authority is about **architecture**. CARING is about **implementation**. + +| | Mode of Authority | CARING | +| --- | --- | --- | +| Question | In what relationship to a system is authority exercised? | How is this access-control implementation actually composed? | +| Layer | architecture / design reasoning | implementation analysis and governance | +| Use | describing intent before a system exists | describing and prescribing systems that exist | +| Home | SecurityCanon | InfoTechCanon | + +They are not competitors and neither subsumes the other. The assessment's +"dimension collision" is therefore **not resolved by merging** but by keeping the +layers distinct. + +**Direct terminology overlap must nonetheless be avoided.** Two different layers +may legitimately need related concepts, but they must not use the same word for +different things, nor silently define the same thing twice. The rule: + +1. Where a concept is genuinely shared (Scope, Subject), one canon defines it and + the other imports it. InfoTechCanon owns the shared roots, so shared concepts + are defined there. +2. Where the concepts are genuinely different, the names must be visibly + different. `Operator` (CARING lifecycle role) and `OPERATE` (auth mode) are + the clearest offender and need explicit disambiguation, not renaming by + reflex. +3. Where one layer refines the other — MoA's Actor/Subject split against + CARING's single Subject — the relationship is recorded as a mapping, not a + redefinition. See §6. + +### D3 — Identity is a shared root and stays in InfoTechCanon + +Pulling identity into SecurityCanon would collapse too much into security. +Identity reaches into personhood and its philosophical underpinnings, which are +not security concerns. + +A dedicated identity or personhood canon may eventually be right. That is +explicitly **deferred**, not rejected, and is not in scope for any current +workplan. + +SecurityCanon imports identity concepts from InfoTechCanon. MoA's Principal Type +dimension is a security-side classification that references those concepts; it +does not define identity. + +### D4 — No duplicated service surface + +The requirement is **uniform integration**, not independent tooling: + +> All the specific canons should integrate with InfoTechCanon properly and in +> the same way — commerce-canon, interface-canon, security-canon alike — and be +> referenced by InfoTechCanon in the same way. + +Consequences: + +- SecurityCanon ships **no** CLI, HTTP API, or validation service of its own. +- Integration uses the existing canon-federation interface card mechanism + (`infospace/interfaces/federation.yaml`, schema owned by InfoTechCanon, + authority `CUST-ADR-006`), exactly as CommerceCanon and InterfaceCanon do. +- InfoTechCanon's service surface is the single place canons are inspected and + validated. If SecurityCanon needs a check that does not exist, the change + belongs in InfoTechCanon's service, not in a second service here. +- Any divergence in how the three canons tie in is a defect to fix, not a local + choice. Coordinate through prj-canon-federation. + +## Consequences + +**The repository's purpose changes shape.** SecurityCanon is an +architecture-layer vocabulary canon that InfoTechCanon references, not an +extraction destination. Its first deliverable is the Mode of Authority +vocabulary and its federation card — not a migration. + +**SECURITY-WP-0001 is re-scoped.** The disposition review narrows from "what +moves" to "where does each concept belong, and what is imported". The migration +handoff task is cancelled; nothing currently justifies a migration workplan. + +**InfoTechCanon is not destabilised.** No artifact is removed from it under this +decision, so the invariant that InfoTechCanon validates clean is satisfied +trivially rather than by careful slicing. + +## Open — Q3, the Actor/Subject split + +Not decided. The owner asked for review and discussion of the implications +before deciding whether MoA's Actor/Subject split should change CARING's single +Subject dimension. + +Under D2 the question is narrower than it first appeared: because the two are +different layers, the split does not have to propagate. The live options are a +mapping at the boundary, an additive relation field in CARING, or an upstream +change to a release-candidate standard. This is carried by +`SECURITY-WP-0001-T07` and treated in +[the Actor/Subject implications note](260920-actor-subject-implications.md). diff --git a/workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md b/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md similarity index 54% rename from workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md rename to workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md index f4d78c8..8a4bdbd 100644 --- a/workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md +++ b/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md @@ -1,7 +1,7 @@ --- id: SECURITY-WP-0001 type: workplan -title: "Bootstrap security-canon and plan the InfoTechCanon security extraction" +title: "Bootstrap security-canon and establish the Mode of Authority vocabulary" domain: infotech repo: security-canon status: active @@ -24,15 +24,22 @@ 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 the success gates. -**Revised 2026-09-20** after reviewing `spec/ModeOfAuthorityCanon-v0.1.md`. The +**Revised twice on 2026-09-20.** First 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. +Then again after the owner's decision, recorded as +[SEC-ADR-001](../docs/adr-001-securitycanon-boundary.md): CARING stays in +InfoTechCanon, identity stays a shared root, Mode of Authority is architecture +while CARING is implementation, and no service surface is duplicated. + +**Content migration is no longer a goal of this workplan.** SecurityCanon's +deliverable is the architecture-layer vocabulary and its clean integration; an +artifact moves only where moving it makes both canons more practical. T05 is +cancelled accordingly. ## Establish repository governance and registration @@ -49,7 +56,7 @@ AGENTS with repo identity, README, and repo classification. Register the repository and this workplan in the State Hub by committing the files and running `statehub fix-consistency` — never by hand. -## Disposition review of InfoTechCanon security material +## Boundary and terminology review ```task id: SECURITY-WP-0001-T02 @@ -58,20 +65,18 @@ priority: high state_hub_task_id: "8b9e4cd0-9905-5ae8-9a23-8957110d72e4" ``` -Produce a reviewed disposition record naming, for every security artifact in -InfoTechCanon, whether it moves to SecurityCanon, stays, or splits — with -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. +Narrowed by SEC-ADR-001, which already settles CARING, identity and the +access-control model as staying in InfoTechCanon. What remains is to establish, +for each concept rather than each file, **where it belongs and what is imported**. -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. +Required output is the concept-placement table: one row per concept that appears +in both layers, naming the single owning canon and the import direction. +Assessment section 3 holds the first draft. -Answer explicitly whether CARING migrates at all. It imports eleven InfoTechCanon -models, so staying put and importing the vocabulary is a live option. +Two artifacts are still genuinely open and are the only remaining migration +candidates: the security model and the DevSecOps model. Neither is urgent. +Recommend for each, with rationale, and default to leaving it upstream unless +moving it demonstrably helps both canons. Resolve the open boundary questions rather than assuming them: whether the identity model is security terminology or a shared root; how the small-saas @@ -88,11 +93,11 @@ priority: medium state_hub_task_id: "dd8bc579-6a89-5b77-bfd8-3acdb4a4f472" ``` -Enumerate every inbound reference to the extraction candidates — InfoTechCanon -relationships, indexes, generated views, agent briefs, profiles, evaluations, -mappings, and its Python validation checks — plus references from other repos. -The survey sizes the migration and is the checklist that keeps InfoTechCanon -validating clean after each slice. +Enumerate where InfoTechCanon already speaks about authority — the access-control +model, CARING, the security and DevSecOps models, profiles, evaluations and the +generated surfaces — so the vocabulary is published against what exists rather +than beside it. With migration off the table this is a survey for correct +referencing and non-collision, not a migration sizing exercise. ## Federation interface card and reciprocal navigation @@ -110,19 +115,19 @@ Authority as a SecurityCanon **export**, not only InfoTechCanon imports. Add rec InfoTechCanon and pass the canon-federation validator. Coordinate with prj-canon-federation rather than amending federation governance here. -## Migration workplan handoff +## Migration workplan handoff — cancelled ```task id: SECURITY-WP-0001-T05 -status: wait +status: cancel priority: medium state_hub_task_id: "387bfae1-c7a1-5826-856e-f5364121f849" ``` -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. +Cancelled by SEC-ADR-001. With CARING, identity and the access-control model +staying in InfoTechCanon, there is no migration large enough to need its own +workplan. If T02 later recommends moving the security or DevSecOps model, that is +a bounded change handled under a new task, not a migration programme. ## Promote Mode of Authority into a canon artifact @@ -145,13 +150,18 @@ 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 +Publish the three-way mapping table relating the vocabulary to InfoTechCanon's +access-control model and CARING — section 5 of the +[Actor/Subject implications note](../docs/260920-actor-subject-implications.md) +holds the first draft. + +Close the two open questions that block stability: whether CONSTRUCT is always +distinct from GOVERN under policy-as-code, and 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 +## Decide the terminology separation ```task id: SECURITY-WP-0001-T07 @@ -160,19 +170,24 @@ priority: high state_hub_task_id: "4a0d3df9-d8a2-51c4-a4bc-72488d866068" ``` -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. +SEC-ADR-001 D2 settles the principle — the two are different layers of +abstraction and must not share a word for different things. This task applies it +concretely and records the result as a decision, because it binds both canons. -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. +The unavoidable case is **Actor/Subject**. InfoTechCanon's access-control model +already owns both words and binds them as "Subject is the access-control view of +an actor"; Mode of Authority uses the same two words for two distinct parties. +The [implications note](../docs/260920-actor-subject-implications.md) analyses +this and recommends renaming MoA's second party to `Authority Context`. Decide +it, and answer the owner's request to discuss what follows for CARING §32. -Reserve namespaces as part of the decision. CARING currently owns `itc-caring:`, -which must be rewritten rather than aliased if it migrates. +Also resolve, in the same decision: `Operator` role versus `OPERATE` mode, +Activation versus CARING Condition, Capability versus AccessOperations, Build +Plane versus CONSTRUCT, and Audit Plane versus Evidence Boundary — in each case +by separating names or declaring an import, never by redefining upstream. + +Reserve the `sec-authority:` namespace for the vocabulary. `itc-caring:` stays +with InfoTechCanon. ## Out of scope