diff --git a/.repo-classification.yaml b/.repo-classification.yaml new file mode 100644 index 0000000..648405e --- /dev/null +++ b/.repo-classification.yaml @@ -0,0 +1,11 @@ +repo_classification: + standard: Repo Classification Standard + version: '1.0' + classified_at: '2026-09-20' + classified_by: agent + category: project + domain: infotech + secondary_domains: [] + capability_tags: [canon, security, access-governance, terminology, knowledge] + business_stake: [technology, product, operations] + business_mechanics: [coordination, operation] diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..deca60b --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,30 @@ +# Agent instructions — security-canon + +## Repo Identity + +**Purpose:** Orthogonal vocabulary and canonical model for security-related concepts, extending InfoTechCanon. + +**Domain:** infotech +**Repo slug:** security-canon +**Topic ID:** `fe2aaa78-9c20-4feb-b3d2-4fe0529572a3` +**Workplan prefix:** `SECURITY-WP-` +**Upstream canon:** info-tech-canon + +Orient: INTENT.md → GOAL.md → SCOPE.md → workplans/. + + +## State Hub Integration + + +| Context | URL | +|---------|-----| +| Local workstation | `http://127.0.0.1:8000` | +| Remote (railiance01, in-cluster) | `http://10.43.68.154:8000` | +| Optional local edge relay | `http://127.0.0.1:18080` | + +Do not instruct a remote agent to use `http://127.0.0.1:18000`. That reverse tunnel is retired; on railiance01 reach the hub at the in-cluster address above. + + +## Cross-repo waits + +If blocked on another repo, look for a `prj-` driver workplan and follow `coordination-engine` `spec/cross-owner-wait-mode-v0.1.md`. Do not mint a stranded `wait`, implement `flavor: residual`, or message `ops-warden` for secrets. diff --git a/GOAL.md b/GOAL.md new file mode 100644 index 0000000..6b3c6cb --- /dev/null +++ b/GOAL.md @@ -0,0 +1,49 @@ +--- +repo: security-canon +repo_flavor: project +project_status: draft +started: "2026-09-20" +--- + +# Goal — security-canon + +## 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. + +## 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. +- 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. +- The State Hub stays a read model: workplan files here are authoritative and + are registered by `fix-consistency`, never by hand. + +## Success gates + +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. +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. diff --git a/INTENT.md b/INTENT.md new file mode 100644 index 0000000..e043682 --- /dev/null +++ b/INTENT.md @@ -0,0 +1,90 @@ +# Intent + +SecurityCanon provides an implementation-neutral vocabulary and canonical model +for security-related concepts. It extends InfoTechCanon in the same architectural +role that CommerceCanon serves for commercial terminology and InterfaceCanon for +interface terminology: import shared roots, contribute a focused domain model, +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. + +Extraction is a migration, not a rewrite. Source artifacts keep their provenance, +and InfoTechCanon retains the shared roots that security terminology imports. + +## Layer and boundary + +SecurityCanon declares itself part of the **Taxonomy** layer under the NetKingdom +Security Layer Model. It produces security terminology, semantic contracts, and +compatibility rules for independently owned systems. + +SecurityCanon owns security concept definitions and their cross-canon mappings. +It does not own a runtime position, enforcement, or state on which another layer +depends: + +- **NetKingdom** owns its security architecture, its standards of record, + including the security layer model, and any NetKingdom-specific profiles that + import this canon. +- **flex-auth** owns authorization decisions; **key-cape** and Keycloak own + login, OIDC, and MFA; **OpenBao** owns secret custody. SecurityCanon describes + those concepts; it does not perform them. +- **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. +- Consumers own their own adoption evidence and importing profiles. + +A generic security semantic contract belongs here; a security obligation imposed +on a concrete estate belongs to the owner of that estate. + +## Primary utility + +SecurityCanon helps turn security integration by interpretation into integration +by declared semantic contract. It provides: + +- canonical security concepts with clear ownership, +- orthogonal security standards that import rather than redefine, +- mappings to external security standards, frameworks, and regulations, +- benchmarks that test a standard against a concrete native access model, +- application profiles for concrete implementation contexts, +- and retrieval-friendly markdown artifacts for humans, agents, and tools. + +## Design stance + +SecurityCanon follows InfoTechCanon's stance: markdown-first but machine-readable, +network-shaped rather than purely hierarchical, pattern-oriented rather than merely +taxonomic, externally mappable without being externally constrained, and +orthogonal without becoming isolated. + +External standards influence SecurityCanon through mappings and assimilation. +They do not define its internal semantics directly. + +## Core commitments + +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. + +## Non-goals + +SecurityCanon does not replace external standards such as NIST, ISO 27001, CIS, +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. + +## 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. +Stable promotion requires reviewed mappings and concrete consumer evidence. diff --git a/README.md b/README.md index 1ee5ac3..a836d1a 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,26 @@ # security-canon -Othogonal vocabulary and canonical model for security related concepts. \ No newline at end of file +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. + +| | | +| --- | --- | +| **Flavor** | project | +| **Domain** | infotech | +| **Workplan prefix** | `SECURITY-WP-` | +| **Upstream canon** | [InfoTechCanon](../info-tech-canon) | + +Start with [INTENT.md](INTENT.md), [GOAL.md](GOAL.md), and [SCOPE.md](SCOPE.md). +Agent instructions are in [AGENTS.md](AGENTS.md); active work is in +[workplans/](workplans/). + +## 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). diff --git a/SCOPE.md b/SCOPE.md new file mode 100644 index 0000000..f3755de --- /dev/null +++ b/SCOPE.md @@ -0,0 +1,52 @@ +# SCOPE + +Reviewed: 2026-09-20 (Europe/Berlin). + +## 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. + +## Ownership and boundaries + +Following [INTENT.md](INTENT.md), SecurityCanon occupies the Taxonomy layer and +owns security concept definitions and their cross-canon mappings. It imports +shared roots from InfoTechCanon and does not redefine them. + +Out of scope, with the owner named: + +- security architecture and standards of record for the estate — NetKingdom +- authorization decisions — flex-auth +- login, OIDC, MFA — key-cape / Keycloak +- secret custody and credential issuance — OpenBao, ops-warden +- adversarial evidence and findings practice — whitehat-security +- shared artifact/ownership/mapping/profile mechanisms — InfoTechCanon +- consumer runtime state, enforcement, observation, and adoption evidence — the consumers + +## Planned scope + +The extraction candidates in InfoTechCanon, pending the disposition review in +`SECURITY-WP-0001-T02`: + +| Source path in info-tech-canon | Kind | +| --- | --- | +| `infospace/models/security/` | model | +| `infospace/models/access-control/` | model | +| `infospace/models/devsecops/` | model | +| `infospace/standards/caring/` | standard | +| `infospace/standards/caring/benchmarks/kubernetes-rbac/` | benchmark | + +Open boundary questions the disposition review must answer, not assume: + +- 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. + +## 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. diff --git a/spec/ModeOfAuthorityCanon-v0.1.md b/spec/ModeOfAuthorityCanon-v0.1.md new file mode 100755 index 0000000..b789a3c --- /dev/null +++ b/spec/ModeOfAuthorityCanon-v0.1.md @@ -0,0 +1,1346 @@ +# Mode of Authority Canon + +**Version:** 0.1 +**Status:** Research Draft +**Short term:** **Auth Mode** +**Concept:** **Mode of Authority** + +--- + +## 1. Purpose + +The **Mode of Authority Canon** provides a compact vocabulary for reasoning about authority in information systems. + +It is intended to improve discussion and design of: + +- identity and access management, +- authorization, +- privileged access, +- administration, +- operations, +- software construction and deployment, +- multi-tenant systems, +- federated infrastructures, +- security boundaries, +- emergency access, +- delegation, +- impersonation, +- auditability, +- human, workload and agentic identities. + +The canon addresses a question that conventional permission and role models do not answer directly: + +> **In what relationship to a system is an actor exercising authority?** + +This relationship is called the actor's **Mode of Authority**, abbreviated **Auth Mode**. + +--- + +# 2. Core Definition + +## 2.1 Mode of Authority + +A **Mode of Authority** is: + +> A semantic classification of the intended relationship between an actor and a system scope, describing the nature and purpose of the authority being exercised. + +Examples include: + +- using a system, +- observing it, +- operating it, +- administering it, +- governing its authority regime, +- constructing future versions of it, +- establishing or recovering its fundamental authority boundary. + +An Auth Mode does **not** itself define individual permissions. + +--- + +# 3. Distinction from Access Mode + +The term **access mode** is commonly used for operations such as: + +- read, +- write, +- execute, +- create, +- delete. + +The canon therefore distinguishes: + +### Access Mode / Access Operation + +Describes: + +> **What operation may be performed on a resource?** + +Examples: + +```text +read +write +execute +delete +assign +approve +``` + +### Mode of Authority / Auth Mode + +Describes: + +> **In what relationship to the system is the actor exercising authority?** + +Examples: + +```text +USE +OBSERVE +OPERATE +ADMINISTER +GOVERN +CONSTRUCT +SOVEREIGN +``` + +The two dimensions are orthogonal. + +For example: + +```text +read + USE +``` + +may mean reading a customer's document. + +Whereas: + +```text +read + OBSERVE +``` + +may mean reading telemetry about the document service. + +--- + +# 4. Access Situation + +An **Access Situation** is the complete context in which authority is exercised. + +Conceptually: + +```text +AccessSituation = + Actor + × Subject + × AuthMode + × Scope + × AccessOperations + × AuthorityProvenance + × Activation + × Environment + × EvidenceBoundary + × Time + × Purpose +``` + +Not every implementation needs to materialize every dimension. + +The model exists primarily to support precise reasoning. + +--- + +# 5. Fundamental Principles + +## A1 — Authority is scope-relative + +There is no meaningful authority without a scope. + +Examples: + +```text +ADMINISTER @ tenant/acme +ADMINISTER @ kubernetes/namespace/foo +SOVEREIGN @ database/postgres +GOVERN @ cloud-organization +``` + +Authority at one scope does not automatically imply authority at another. + +--- + +## A2 — Mode and privilege magnitude are different concepts + +Auth Modes are **not a privilege ladder**. + +For example: + +- an auditor may OBSERVE information hidden from ordinary administrators, +- a developer may CONSTRUCT future production behavior while having no production access, +- a governor may constrain administrators without being able to perform their operational tasks. + +Therefore: + +```text +USE < ADMINISTER < SOVEREIGN +``` + +must not be treated as the semantic model. + +Auth Modes classify **kind of authority**, not simply amount of authority. + +--- + +## A3 — Auditability is independent of Auth Mode + +A mode does not determine whether actions can be audited. + +Instead, auditability depends on the **Evidence Boundary**. + +The central question is: + +> Can the actor being observed also alter, suppress, bypass or invalidate the evidence used to observe that actor? + +Examples include: + +```text +target-system-audited +independently-audited +substrate-audited +outside-target-audit +can-alter-audit-configuration +can-alter-audit-evidence +``` + +Sovereign authority therefore does not necessarily mean unaudited authority. + +--- + +## A4 — Federation does not imply authorization + +Federation primarily establishes trusted assertions between independent authority realms. + +A remote realm may assert: + +```text +This actor is Alice. +Alice belongs to group Researcher. +``` + +The receiving realm independently decides: + +```text +What may Alice do here? +``` + +Therefore: + +> Federation conveys trusted claims. It does not intrinsically convey authorization or sovereignty. + +--- + +## A5 — Sovereignty is relative, not absolute + +There need not be a universal root or "God account". + +Instead there can be independent sovereign authorities such as: + +```text +SOVEREIGN @ identity-realm +SOVEREIGN @ database +SOVEREIGN @ cluster +SOVEREIGN @ cloud-account +SOVEREIGN @ platform +``` + +A higher or underlying authority may dominate another scope without thereby becoming universally sovereign. + +--- + +# 6. Canonical Auth Modes + +Version 0.1 defines seven fundamental Modes of Authority. + +```text +USE +OBSERVE +OPERATE +ADMINISTER +GOVERN +CONSTRUCT +SOVEREIGN +``` + +--- + +# 7. USE + +## Intent + +> Exercise the system for its designated domain purpose. + +USE concerns the value the system exists to provide. + +Examples: + +- sending a message, +- editing a document, +- placing an order, +- executing a business process, +- querying application data, +- consuming an API, +- creating a customer record. + +Typical principal types include: + +```text +human +application +service +agent +``` + +Example: + +```text +alice + USE @ crm/customer-management +``` + +USE does not imply low privilege. + +A business user may legitimately perform highly consequential actions while still operating entirely in USE mode. + +--- + +# 8. OBSERVE + +## Intent + +> Establish knowledge about the system, its behavior or its state. + +OBSERVE is concerned with understanding the system rather than obtaining its ordinary domain value. + +Examples: + +- reading logs, +- viewing metrics, +- inspecting traces, +- querying health information, +- reading audit records, +- examining security events, +- viewing configuration for diagnostic purposes. + +Example: + +```text +sre + OBSERVE @ production/platform +``` + +OBSERVE is distinct from ordinary read access. + +Compare: + +```text +read customer invoice +→ USE +``` + +with: + +```text +read latency metrics for invoice service +→ OBSERVE +``` + +The access operation is `read` in both cases. + +The Auth Mode differs. + +--- + +# 9. OPERATE + +## Intent + +> Maintain or change the operational state of an instantiated system while preserving its intended definition. + +Typical actions include: + +- start, +- stop, +- restart, +- scale, +- fail over, +- restore, +- trigger backup, +- rotate an operational instance, +- drain a node, +- restart a workload, +- terminate a stuck process. + +Example: + +```text +ops-agent + OPERATE @ production/database +``` + +OPERATE answers: + +> How do we keep this system functioning? + +It is distinct from ADMINISTER. + +For example: + +```text +restart database +→ OPERATE +``` + +whereas: + +```text +change database authentication configuration +→ ADMINISTER +``` + +--- + +# 10. ADMINISTER + +## Intent + +> Configure resources and delegated authority within an established governance regime. + +Typical actions include: + +- configure resources, +- create users, +- assign roles, +- manage groups, +- create projects, +- change settings, +- provision resources, +- delegate bounded authority. + +Example: + +```text +tenant-admin + ADMINISTER @ tenant/acme +``` + +ADMINISTER operates **inside rules established elsewhere**. + +An administrator may have broad discretion without being allowed to redefine the constraints governing that discretion. + +--- + +# 11. GOVERN + +## Intent + +> Define the rules under which authority may be exercised. + +GOVERN is **authority over authority**. + +Typical concerns include: + +- policy ceilings, +- organizational constraints, +- delegation rules, +- security requirements, +- allowed identity providers, +- tenant boundaries, +- trust policy, +- separation-of-duty requirements, +- requirements for privileged activation. + +Example: + +```text +security-governor + GOVERN @ organization +``` + +A useful distinguishing question is: + +> Can this actor decide what another administrator is allowed to decide? + +If yes, the activity is likely GOVERN rather than ADMINISTER. + +Example: + +```text +Administrator: + assign application roles + +Governor: + determine which roles administrators may assign +``` + +--- + +# 12. CONSTRUCT + +## Intent + +> Change definitions or artifacts from which system behavior is produced. + +CONSTRUCT covers authority over the **possible future system** rather than necessarily over its current running instance. + +Typical objects include: + +- source code, +- infrastructure-as-code, +- build definitions, +- container images, +- database migrations, +- schemas, +- firmware, +- policy-as-code, +- deployment templates, +- release artifacts, +- CI/CD pipelines. + +Example: + +```text +coding-agent + CONSTRUCT @ product/payment-service +``` + +A principal may have substantial CONSTRUCT authority while having no production runtime authority. + +This distinction is particularly important for: + +- software supply-chain security, +- CI/CD, +- infrastructure automation, +- agentic software development. + +A useful distinction is: + +```text +ADMINISTER + changes the instantiated system + +CONSTRUCT + changes definitions capable of producing systems +``` + +--- + +# 13. SOVEREIGN + +## Intent + +> Establish, recover, replace or bypass the normal authority regime of a scope. + +SOVEREIGN authority exists at or beyond the authority boundary being governed. + +Typical situations include: + +- initial bootstrap, +- establishing trust roots, +- root-account recovery, +- rebuilding the control plane, +- replacing authentication infrastructure, +- restoring authority after catastrophic failure, +- resetting governance mechanisms, +- overriding mechanisms that normally constrain administrators. + +Example: + +```text +recovery-principal + SOVEREIGN @ identity-realm +``` + +SOVEREIGN does **not** mean: + +```text +all-powerful everywhere +``` + +It means: + +> sovereign relative to a defined scope and authority boundary. + +Therefore: + +```text +SOVEREIGN @ database +``` + +does not necessarily imply: + +```text +SOVEREIGN @ host +``` + +and: + +```text +SOVEREIGN @ tenant +``` + +does not imply: + +```text +SOVEREIGN @ platform +``` + +--- + +# 14. Root + +`root` is treated as an implementation-specific manifestation of sovereign or highly privileged authority rather than as a canonical Auth Mode. + +Depending on the system: + +```text +root +``` + +may mean: + +- SOVEREIGN, +- ADMINISTER with extremely broad permissions, +- OPERATE + ADMINISTER, +- or authority inherited from an underlying substrate. + +Therefore the canon prefers explicit descriptions such as: + +```text +SOVEREIGN @ host +SOVEREIGN @ account +ADMINISTER @ cluster +``` + +over the ambiguous statement: + +```text +has root +``` + +--- + +# 15. Scope + +Every Auth Mode must be interpreted relative to a **Scope**. + +Scopes frequently form hierarchies: + +```text +platform +└── organization + └── tenant + └── project + └── resource +``` + +But a scope model may also form a graph. + +Examples include: + +- trust domains, +- federations, +- cross-account relationships, +- shared infrastructure, +- dependency relationships. + +A scope describes: + +> Where does this authority apply? + +Examples: + +```text +USE @ tenant/acme +ADMINISTER @ namespace/payments +GOVERN @ organization/example +SOVEREIGN @ cluster/prod-1 +``` + +--- + +# 16. Authority Realms + +An **Authority Realm** is a scope possessing an independently meaningful authority boundary. + +Examples may include: + +- operating system, +- database, +- Kubernetes cluster, +- cloud account, +- cloud organization, +- identity realm, +- SaaS tenant, +- trust domain. + +A realm may possess its own: + +```text +SOVEREIGN +GOVERN +ADMINISTER +OPERATE +OBSERVE +USE +``` + +authorities. + +Realms need not share a common sovereign. + +--- + +# 17. Central Governance + +A centrally governed infrastructure commonly resembles: + +```text +Platform +└── Organization + ├── Tenant A + ├── Tenant B + └── Tenant C +``` + +Authority may propagate downward through governance. + +For example: + +```text +GOVERN @ platform +GOVERN @ organization +ADMINISTER @ tenant +USE @ application +``` + +A central platform may possess cross-scope sovereign capabilities. + +This should nevertheless be stated explicitly rather than assumed. + +--- + +# 18. Federation + +Federation connects independently administered authority realms. + +Conceptually: + +```text +Realm A ──trust──> Realm B +Realm C ──trust──> Realm B +``` + +Trust relationships need not be symmetric. + +For example: + +```text +A trusts B +``` + +does not imply: + +```text +B trusts A +``` + +A federation may have: + +```text +GOVERN @ federation +``` + +without possessing: + +```text +SOVEREIGN @ member-realms +``` + +A genuine federation therefore need not contain a global root. + +--- + +# 19. Actor and Subject + +Authority sometimes involves one entity acting on behalf of another. + +The canon therefore distinguishes: + +## Actor + +The entity actually performing the action. + +## Subject + +The identity or authority context on whose behalf the action is performed. + +Normally: + +```text +actor = subject +``` + +But not always. + +Example: + +```text +actor = support-agent +subject = customer-123 +``` + +This distinction is important for: + +- delegation, +- impersonation, +- automation, +- service accounts, +- agents, +- token exchange. + +--- + +# 20. Delegation and Impersonation + +These are not Auth Modes. + +They describe how authority is exercised. + +## Delegation + +The actor retains its identity while exercising delegated authority. + +```text +actor = deployment-agent +subject = release-authority +relation = delegated +``` + +## Impersonation + +The actor acts using another subject's authority context. + +```text +actor = support-agent +subject = customer +relation = impersonated +``` + +The underlying Auth Mode may still be: + +```text +USE +ADMINISTER +OPERATE +``` + +etc. + +--- + +# 21. Activation + +Activation describes **when and under what conditions authority becomes exercisable**. + +Examples include: + +```text +STANDING +JUST_IN_TIME +SCHEDULED +APPROVED +INCIDENT +BREAK_GLASS +RECOVERY +``` + +Activation is orthogonal to Auth Mode. + +Examples: + +```text +ADMINISTER +activation=JUST_IN_TIME +``` + +```text +OPERATE +activation=INCIDENT +``` + +```text +SOVEREIGN +activation=BREAK_GLASS +``` + +Therefore **break-glass is not an Auth Mode**. + +--- + +# 22. Authority Provenance + +Authority Provenance describes where authority originates. + +Candidate values include: + +```text +LOCAL +PARENT_SCOPE +SUBSTRATE +DELEGATED +FEDERATED +ASSUMED +IMPERSONATED +``` + +Example: + +```text +alice + USE @ application/project-x + provenance=FEDERATED +``` + +The application may trust Alice's identity from another realm while making its own authorization decision locally. + +--- + +# 23. Principal Type + +Auth Modes apply independently of principal type. + +Candidate principal types include: + +```text +HUMAN +WORKLOAD +SERVICE +AGENT +CONTROLLER +DEVICE +``` + +Examples: + +```text +human + ADMINISTER @ tenant +``` + +```text +service + USE @ database +``` + +```text +agent + CONSTRUCT @ repository +``` + +```text +controller + OPERATE @ cluster +``` + +Principal type therefore must not be encoded into the Auth Mode taxonomy. + +--- + +# 24. Environment + +Authority often differs by environment. + +Candidate values include: + +```text +DEVELOPMENT +TEST +STAGING +PRODUCTION +RECOVERY +``` + +For example: + +```text +alice + SOVEREIGN @ development/environment +``` + +does not imply: + +```text +alice + SOVEREIGN @ production/environment +``` + +This is especially important for CONSTRUCT authority. + +--- + +# 25. Evidence Boundary + +The **Evidence Boundary** identifies which system is responsible for observing and preserving evidence of authority use. + +An authority may be: + +```text +target-audited +external-audited +substrate-audited +multi-party-audited +outside-audit-boundary +``` + +Additional questions include: + +```text +Can the actor disable logging? + +Can the actor modify historical evidence? + +Can the actor change the audit destination? + +Can the actor compromise the authority observing it? +``` + +Audit guarantees must therefore always be interpreted relative to an authority boundary. + +--- + +# 26. Compact Notation + +A minimal notation can use: + +```text +MODE @ SCOPE +``` + +Examples: + +```text +USE @ tenant/acme + +OBSERVE @ platform/prod + +OPERATE @ cluster/prod-1 + +ADMINISTER @ tenant/acme + +GOVERN @ organization/example + +CONSTRUCT @ product/payment-api + +SOVEREIGN @ identity-realm +``` + +Modifiers can be appended: + +```text +alice: + ADMINISTER @ tenant/acme + activation=JIT + duration=2h +``` + +Example involving federation: + +```text +bob: + USE @ realm-b/project-x + identity=realm-a/bob + provenance=FEDERATED +``` + +Example involving impersonation: + +```text +support-agent: + USE @ tenant/acme + subject=customer-42 + relation=IMPERSONATED +``` + +Example involving emergency recovery: + +```text +recovery-principal: + SOVEREIGN @ identity-realm + activation=BREAK_GLASS + evidence=EXTERNAL +``` + +--- + +# 27. Non-Canonical Candidate Modes + +The following concepts should currently **not** become fundamental Auth Modes: + +```text +AUDIT +SECURITY +SUPPORT +BACKUP +DEVELOPER +OWNER +BILLING +AUTOMATION +AGENT +FEDERATION +BREAK_GLASS +SUPERADMIN +ROOT +``` + +They can currently be represented more precisely through combinations of: + +```text +Auth Mode ++ Scope ++ Principal Type ++ Activation ++ Purpose ++ Provenance ++ Operations +``` + +Examples: + +```text +auditor +→ OBSERVE @ evidence +``` + +```text +backup operator +→ OPERATE @ backup-system +``` + +```text +developer +→ CONSTRUCT @ product +``` + +```text +security administrator +→ ADMINISTER @ security-controls +``` + +```text +security policy owner +→ GOVERN @ security-controls +``` + +--- + +# 28. Canonical Auth Mode Summary + +| Auth Mode | Fundamental question | +|---|---| +| **USE** | How do I obtain the value this system exists to provide? | +| **OBSERVE** | What is this system doing? | +| **OPERATE** | How do I keep this instantiated system functioning? | +| **ADMINISTER** | How do I configure this system within existing rules? | +| **GOVERN** | What rules constrain how authority may be exercised? | +| **CONSTRUCT** | How do I change what future incarnations of this system can be? | +| **SOVEREIGN** | How is the authority regime itself established, recovered or replaced? | + +--- + +# 29. Design Heuristic + +When analyzing an authority situation, ask in order: + +```text +1. Who is the actor? + +2. On whose behalf is it acting? + +3. What Auth Mode is being exercised? + +4. Over what scope? + +5. What operations are permitted? + +6. Where does the authority originate? + +7. Under what conditions is it activated? + +8. What authority realm enforces it? + +9. Who observes and preserves evidence? + +10. Who can override the enforcement mechanism? +``` + +This produces substantially clearer security descriptions than labels such as: + +```text +user +admin +superadmin +root +``` + +alone. + +--- + +# 30. Research Hypothesis + +Version 0.1 proposes that the seven canonical Auth Modes are sufficient to describe most authority relationships found in contemporary information systems: + +```text +USE +OBSERVE +OPERATE +ADMINISTER +GOVERN +CONSTRUCT +SOVEREIGN +``` + +without requiring platform-specific modes. + +The hypothesis should be tested against representative systems including: + +- Unix/Linux, +- databases, +- Kubernetes, +- cloud IAM, +- identity platforms, +- secrets management, +- SaaS multi-tenancy, +- software-development platforms, +- CI/CD systems, +- federated identity, +- workload identity, +- agentic systems. + +A new canonical Auth Mode should only be introduced if a recurring authority relationship cannot be represented cleanly by: + +```text +existing Auth Mode ++ scope ++ operation ++ provenance ++ activation ++ purpose +``` + +--- + +# 31. Open Research Questions + +Version 0.1 deliberately leaves several questions open. + +### Q1 — Are seven modes sufficient? + +The canon must be stress-tested against concrete platforms and pathological authority situations. + +### Q2 — Is CONSTRUCT always distinct from GOVERN? + +Policy-as-code and executable governance mechanisms may blur the distinction. + +### Q3 — How should substrate authority be represented? + +Examples include: + +```text +hypervisor over VM +cloud provider over tenant +host root over container +hardware operator over software +``` + +### Q4 — Can sovereignty itself be decomposed? + +Potential distinctions include: + +```text +bootstrap sovereignty +recovery sovereignty +cryptographic sovereignty +substrate sovereignty +``` + +These may be dimensions rather than modes. + +### Q5 — How should mutually constraining sovereigns be modeled? + +Examples include: + +- threshold cryptography, +- multi-party approval, +- HSM governance, +- jointly controlled federations. + +### Q6 — How should autonomous agents change the model? + +An agent may simultaneously possess: + +```text +CONSTRUCT +OPERATE +ADMINISTER +``` + +authority and may potentially modify mechanisms affecting its own future authority. + +### Q7 — Can Auth Mode become a machine-readable authorization attribute? + +For example: + +```text +auth_mode = "operate" +scope = "cluster/prod" +activation = "incident" +``` + +could become input to ABAC or policy engines. + +--- + +# 32. Version 0.1 Position + +The Mode of Authority Canon starts from one central observation: + +> Permissions describe what an actor can do. +> Modes of Authority describe what kind of relationship allows the actor to do it. + +This distinction provides a semantic layer between architectural intent and concrete authorization mechanisms. + +The initial canonical vocabulary is: + +```text +USE +OBSERVE +OPERATE +ADMINISTER +GOVERN +CONSTRUCT +SOVEREIGN +``` + +All are: + +- scope-relative, +- independent of principal type, +- independent of access operation, +- independent of activation mechanism, +- independent of auditability, +- applicable to centralized and federated systems. + +This constitutes the **Mode of Authority Canon v0.1**. diff --git a/workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md b/workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md new file mode 100644 index 0000000..75d78a9 --- /dev/null +++ b/workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md @@ -0,0 +1,104 @@ +--- +id: SECURITY-WP-0001 +type: workplan +title: "Bootstrap security-canon and plan the InfoTechCanon security extraction" +domain: infotech +repo: security-canon +status: active +owner: claude +topic_slug: security-canon +created: "2026-09-20" +updated: "2026-09-20" +--- + +# Bootstrap and extraction plan + +The repository owner asked on 2026-09-20 to refine InfoTechCanon by moving its +IT-security material into a dedicated canon. This workplan establishes +SecurityCanon as a governed, registered repository and produces the reviewed +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 [GOAL.md](../GOAL.md) for the success gates. + +## Establish repository governance and registration + +```task +id: SECURITY-WP-0001-T01 +status: done +priority: high +``` + +Clone the Forgejo stub to the workstation, scaffold the repository to the +repo-manager standard, and write the governance files: INTENT, GOAL, SCOPE, +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 + +```task +id: SECURITY-WP-0001-T02 +status: todo +priority: high +``` + +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. + +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 +InfoTechCanon concepts become declared imports instead of moves. Record the +answers as a decision, since they bind both canons. + +## Reference-impact survey + +```task +id: SECURITY-WP-0001-T03 +status: todo +priority: medium +``` + +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. + +## Federation interface card and reciprocal navigation + +```task +id: SECURITY-WP-0001-T04 +status: todo +priority: medium +``` + +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 +InfoTechCanon and pass the canon-federation validator. Coordinate with +prj-canon-federation rather than amending federation governance here. + +## Migration workplan handoff + +```task +id: SECURITY-WP-0001-T05 +status: wait +priority: medium +``` + +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. + +## Out of scope + +No canon content is authored or moved under this workplan. No service surface, +CLI, HTTP API, or validation tooling is built for SecurityCanon; whether it +reuses InfoTechCanon's Python service is deferred until content exists.