tegwick
a4ec38feb2
Publishes sec-authority:ModeOfAuthority v0.2.0 with machine-readable auth-modes.yaml and dimensions.yaml, and moves the v0.1 draft verbatim to research/ as provenance — it had been sitting in spec/, which the Repository Layout Standard reserves for implementation guidance. Terminology separation decided as SECURITY-DEC-2026-002 / SEC-ADR-002. The v0.1 Subject dimension becomes AuthorityContext, because InfoTechCanon's access-control model already owns Actor and Subject and binds them as "Subject is the access-control view of an actor"; reusing the pair for two distinct parties would have made one word mean two things across the canons. Operator versus OPERATE, Build Plane versus CONSTRUCT, Policy Plane versus GOVERN, Audit Plane versus EvidenceBoundary and Condition versus Activation are separated rather than merged, and Scope, AccessOperations, Purpose and PrincipalType are declared imports. Namespace sec-authority: reserved; itc-caring: and itc-access: stay upstream and are not aliased. Two of the draft's open questions are closed. CONSTRUCT stays distinct from GOVERN, the test being the object of authority — the artifact versus the constraint it must satisfy — which keeps "who may edit the policy" separable from "who decides what it must say". Substrate authority becomes a DOMINATES relation between Authority Realms carrying dominance_kind, observable and evidence_boundary, which makes the relative-sovereignty principle checkable instead of merely asserted. Orientation surfaces published: the one-page vocabulary card, the ten-question design heuristic promoted from the draft's appendix to section 3 of the artifact, the role/plane/mode disambiguation page, and the cross-layer mapping to InfoTechCanon with its deliberate blanks where one layer has no equivalent. Generalising CARING section 32 beyond non-human subjects is deliberately not bundled in; it is InfoTechCanon's to accept as a demand signal. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 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
52 lines
2.6 KiB
Markdown
52 lines
2.6 KiB
Markdown
# security-canon
|
|
|
|
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 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).
|
|
|
|
| | |
|
|
| --- | --- |
|
|
| **Flavor** | project |
|
|
| **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 |
|
|
| [SEC-ADR-002](docs/adr-002-terminology-separation.md) | the terminology separation — why `AuthorityContext`, not `Subject` |
|
|
| [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
|
|
|
|
Draft. The Mode of Authority vocabulary is published as a canon artifact with
|
|
machine-readable modes and dimensions; the v0.1 research draft is retained in
|
|
`research/` as provenance. Stable promotion needs reviewed mappings and concrete
|
|
consumer evidence. See
|
|
[SECURITY-WP-0001](workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md).
|
|
|
|
## Orientation
|
|
|
|
| Start here | For |
|
|
| --- | --- |
|
|
| [Vocabulary card](docs/vocabulary-card.md) | the seven modes and the notation, on one page |
|
|
| [Mode of Authority](infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md) | the canon artifact |
|
|
| [Disambiguation](docs/disambiguation.md) | *operator* or `OPERATE`? role, plane, or mode? |
|
|
| [Mapping to InfoTechCanon](infospace/mappings/mode-of-authority-to-infotechcanon.md) | how it relates to the access-control model and CARING |
|