Promote Mode of Authority to a canon artifact (T06, T07)
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
This commit is contained in:
parent
be6b0631ce
commit
a4ec38feb2
12 changed files with 1046 additions and 13 deletions
|
|
@ -2,9 +2,9 @@
|
|||
"schema": "repo_manager.index.v1",
|
||||
"slug": "security-canon",
|
||||
"repo_root": "/home/worsch/security-canon",
|
||||
"head_sha": "55b57382ffc60db70eecddb283a880f9a4ac7bbb",
|
||||
"observed_at": "2026-09-20T19:36:23.067664Z",
|
||||
"source_fingerprint": "a1728e9ad28986c53662b1955b58d84f038af9b211c82dba8a8bd23b9c1e9335",
|
||||
"head_sha": "be6b0631ce639d743a822f80c0f8d7f4a6d3347d",
|
||||
"observed_at": "2026-09-20T19:42:55.115596Z",
|
||||
"source_fingerprint": "f13b65255a16d0a8daec0cd40d04c406493b7ff394252a0afeb22faa1117227d",
|
||||
"source_files": [
|
||||
".repo-classification.yaml",
|
||||
"INTENT.md",
|
||||
|
|
@ -75,7 +75,7 @@
|
|||
{
|
||||
"kind": "task",
|
||||
"id": "SECURITY-WP-0001-T06",
|
||||
"status": "todo",
|
||||
"status": "done",
|
||||
"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",
|
||||
|
|
@ -85,7 +85,7 @@
|
|||
{
|
||||
"kind": "task",
|
||||
"id": "SECURITY-WP-0001-T07",
|
||||
"status": "todo",
|
||||
"status": "done",
|
||||
"title": "Decide the terminology separation",
|
||||
"source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md",
|
||||
"uuid": "4a0d3df9-d8a2-51c4-a4bc-72488d866068",
|
||||
|
|
@ -98,7 +98,7 @@
|
|||
"status": "accepted",
|
||||
"title": "SecurityCanon boundary: CARING stays in InfoTechCanon; Auth Mode is architecture-layer vocabulary",
|
||||
"source_path": "decisions/decisions.md",
|
||||
"uuid": null,
|
||||
"uuid": "f6496e7d-4622-4cc6-b5b1-b62172dd148e",
|
||||
"parent_id": null,
|
||||
"extra": {
|
||||
"record": {
|
||||
|
|
@ -107,7 +107,27 @@
|
|||
"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"
|
||||
"updated": "2026-09-20T19:30:50.120170Z",
|
||||
"state_hub_decision_id": "f6496e7d-4622-4cc6-b5b1-b62172dd148e"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"kind": "decision",
|
||||
"id": "SECURITY-DEC-2026-002",
|
||||
"status": "accepted",
|
||||
"title": "Terminology separation: Auth Mode renames Subject to AuthorityContext; no upstream redefinition",
|
||||
"source_path": "decisions/decisions.md",
|
||||
"uuid": null,
|
||||
"parent_id": null,
|
||||
"extra": {
|
||||
"record": {
|
||||
"id": "SECURITY-DEC-2026-002",
|
||||
"kind": "decision",
|
||||
"title": "Terminology separation: Auth Mode renames Subject to AuthorityContext; no upstream redefinition",
|
||||
"status": "accepted",
|
||||
"created": "2026-09-20T19:42:12.263921Z",
|
||||
"updated": "2026-09-20T19:42:12.263921Z"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -118,7 +138,7 @@
|
|||
"workplan_count": 1,
|
||||
"task_count": 7,
|
||||
"source": "repo-manager",
|
||||
"emitted_at": "2026-09-20T19:36:23.067751Z"
|
||||
"emitted_at": "2026-09-20T19:42:55.115676Z"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
|
|||
18
README.md
18
README.md
|
|
@ -30,11 +30,23 @@ Agent instructions are in [AGENTS.md](AGENTS.md); active work is in
|
|||
| 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
|
||||
|
||||
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).
|
||||
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 |
|
||||
|
|
|
|||
|
|
@ -12,3 +12,15 @@ created: '2026-09-20T19:30:50.120170Z'
|
|||
updated: '2026-09-20T19:30:50.120170Z'
|
||||
state_hub_decision_id: "f6496e7d-4622-4cc6-b5b1-b62172dd148e"
|
||||
```
|
||||
|
||||
## SECURITY-DEC-2026-002 — Terminology separation: Auth Mode renames Subject to AuthorityContext; no upstream redefinition
|
||||
|
||||
```yaml
|
||||
id: SECURITY-DEC-2026-002
|
||||
kind: decision
|
||||
title: 'Terminology separation: Auth Mode renames Subject to AuthorityContext; no
|
||||
upstream redefinition'
|
||||
status: accepted
|
||||
created: '2026-09-20T19:42:12.263921Z'
|
||||
updated: '2026-09-20T19:42:12.263921Z'
|
||||
```
|
||||
|
|
|
|||
73
docs/adr-002-terminology-separation.md
Normal file
73
docs/adr-002-terminology-separation.md
Normal file
|
|
@ -0,0 +1,73 @@
|
|||
---
|
||||
id: SEC-ADR-002
|
||||
decision_record: SECURITY-DEC-2026-002
|
||||
type: adr
|
||||
title: "Terminology separation between Auth Mode and the implementation layer"
|
||||
repo: security-canon
|
||||
status: accepted
|
||||
decided: "2026-09-20"
|
||||
implements: SEC-ADR-001 D2
|
||||
---
|
||||
|
||||
# SEC-ADR-002 — Terminology separation
|
||||
|
||||
Applies [SEC-ADR-001](adr-001-securitycanon-boundary.md) D2 — *different layers
|
||||
must not use the same word for different things* — to the concrete overlaps
|
||||
between the Mode of Authority vocabulary, InfoTechCanon's access-control model,
|
||||
and CARING.
|
||||
|
||||
## Decision
|
||||
|
||||
### D1 — `Subject` becomes `AuthorityContext`
|
||||
|
||||
InfoTechCanon's access-control model §11.2 owns `Actor` and `Subject` and binds
|
||||
them: *"Subject is the access-control view of an actor."* The v0.1 draft used the
|
||||
same two words for two distinct parties. The vocabulary renames its dimension to
|
||||
**`AuthorityContext`**, with a companion `relation` field taking `DELEGATED` or
|
||||
`IMPERSONATED`.
|
||||
|
||||
`Actor` is kept, because MoA's use is compatible with the Organization Model's
|
||||
ownership of actor semantics. `AuthorityContext` names what the field holds —
|
||||
the authority drawn on — which stays accurate when the target is a role or
|
||||
mandate rather than a person.
|
||||
|
||||
Rejected: adopting CARING's `Principal`/`Delegator` naming, which would import
|
||||
implementation vocabulary into the architecture layer; and changing InfoTechCanon,
|
||||
which would edit a release-candidate standard and eleven dependent models to
|
||||
accommodate a draft.
|
||||
|
||||
### D2 — Overlapping dimensions are separated, not merged
|
||||
|
||||
| Pair | Resolution |
|
||||
| --- | --- |
|
||||
| `Operator` role vs `OPERATE` mode | Both kept — different axes. Never write bare *operator*; the [disambiguation page](disambiguation.md) is the required companion. |
|
||||
| `Build Plane` vs `CONSTRUCT` | Both kept. Plane is the surface, mode is the authority over it. `CONSTRUCT @ build-plane` is well formed. |
|
||||
| `Policy Plane` vs `GOVERN` | Both kept. `ADMINISTER` over the Policy Plane is not `GOVERN`. |
|
||||
| `Audit Plane` vs `EvidenceBoundary` | Both kept — genuinely different. A rich Audit Plane may accompany a worthless Evidence Boundary. |
|
||||
| CARING `Condition` vs `Activation` | Both kept as layer expressions of one idea. `Activation` is the architecture term. |
|
||||
| CARING `Capability` vs `AccessOperations` | No new term. Imported from InfoTechCanon's access-control model. |
|
||||
| `Scope` | One definition, InfoTechCanon's, imported. |
|
||||
|
||||
### D3 — Namespace
|
||||
|
||||
The vocabulary takes `sec-authority:`. `itc-caring:` and `itc-access:` stay with
|
||||
InfoTechCanon and are not aliased.
|
||||
|
||||
### D4 — CARING §32 generalisation is not bundled here
|
||||
|
||||
Generalising CARING's `Principal / effective actor / Delegator / audit identity`
|
||||
role set beyond non-human subjects would be additive and non-breaking, and would
|
||||
close the human-on-human impersonation gap. It is InfoTechCanon's to accept, and
|
||||
is raised there as a demand signal on its own merits. **Nothing in SecurityCanon
|
||||
blocks on it.**
|
||||
|
||||
## Consequences
|
||||
|
||||
- The v0.1 draft's `subject =` field reads as `authority_context =` in the
|
||||
promoted vocabulary; the draft is retained verbatim in `research/` and the
|
||||
rename is recorded in its §12 change list.
|
||||
- A [disambiguation page](disambiguation.md) is a permanent part of the canon's
|
||||
orientation surface, not a transitional aid.
|
||||
- The [mapping](../infospace/mappings/mode-of-authority-to-infotechcanon.md)
|
||||
carries the cross-layer relationships, including the deliberate blanks where
|
||||
one layer has no equivalent.
|
||||
107
docs/disambiguation.md
Normal file
107
docs/disambiguation.md
Normal file
|
|
@ -0,0 +1,107 @@
|
|||
---
|
||||
id: SEC-DISAMBIG-001
|
||||
type: reference
|
||||
title: "Disambiguation: role, plane, and auth mode"
|
||||
repo: security-canon
|
||||
status: draft
|
||||
created: "2026-09-20"
|
||||
relates_to: SECURITY-DEC-2026-002
|
||||
---
|
||||
|
||||
# Disambiguation — role, plane, and auth mode
|
||||
|
||||
Three vocabularies describe access in this ecosystem. They answer **three
|
||||
different questions**, and several of their values rhyme. This page exists so
|
||||
that a reader who meets a familiar word knows which question it belongs to.
|
||||
|
||||
| Axis | Question | Owner |
|
||||
| --- | --- | --- |
|
||||
| **Auth Mode** | In what *relationship* to the system is authority exercised? | SecurityCanon (architecture) |
|
||||
| **Canonical Role** | What *lifecycle responsibility posture* does a subject hold toward the product? | InfoTechCanon CARING §11 (implementation) |
|
||||
| **Plane** | Which *surface* of the system is touched? | InfoTechCanon CARING §22 (implementation) |
|
||||
|
||||
They compose. A Maintainer (role) may exercise `OPERATE` (mode) on the Runtime
|
||||
Plane (plane). None of the three implies either of the others.
|
||||
|
||||
## The collisions
|
||||
|
||||
### `Operator` is not `OPERATE`
|
||||
|
||||
The sharpest one.
|
||||
|
||||
- **`Operator`** is a CARING canonical role — one of Creator, Builder, Verifier,
|
||||
Maintainer, Integrator, Operator, Manager, Coach, Doer. It describes a
|
||||
*lifecycle posture toward a product*.
|
||||
- **`OPERATE`** is an Auth Mode. It describes *authority to change the running
|
||||
state of an instantiated system*.
|
||||
|
||||
A Maintainer can exercise `OPERATE`. An Operator can exercise `OBSERVE`. The two
|
||||
are independent. When ambiguity is possible, write "the Operator role" or
|
||||
"`OPERATE` mode" — never bare *operator*.
|
||||
|
||||
### `Build Plane` is not `CONSTRUCT`
|
||||
|
||||
Closest in meaning, still different: the plane names the *surface*, the mode
|
||||
names the *authority over it*. `CONSTRUCT @ build-plane` is well formed and says
|
||||
something the plane alone does not.
|
||||
|
||||
### `Policy Plane` is not `GOVERN`
|
||||
|
||||
The Policy Plane is where policy objects live. `GOVERN` is authority over
|
||||
authority. An administrator may hold `ADMINISTER` over the Policy Plane —
|
||||
editing policy objects — without holding `GOVERN`, which decides what the policy
|
||||
must require. Keeping these apart is the point; see the vocabulary §10.1.
|
||||
|
||||
### `Audit Plane` is not `Evidence Boundary`
|
||||
|
||||
Genuinely different concepts. The Audit Plane is a surface. The Evidence
|
||||
Boundary is a *trust question*: can the observed actor alter, suppress or bypass
|
||||
the evidence used to observe it? A system can have a rich Audit Plane and a
|
||||
worthless Evidence Boundary.
|
||||
|
||||
### `Condition` and `activation`
|
||||
|
||||
CARING's Condition dimension and Auth Mode's `activation` overlap
|
||||
substantially. `activation` is the architecture-layer term with the enumerated
|
||||
set (`STANDING`, `JUST_IN_TIME`, `BREAK_GLASS`, …); CARING's Condition is the
|
||||
implementation-layer expression. Use `activation` when describing intent; use
|
||||
Condition when analysing an implementation.
|
||||
|
||||
### `Capability` and `AccessOperations`
|
||||
|
||||
CARING's Capability dimension is richer and is the implementation-layer
|
||||
authority. `AccessOperations` is imported from InfoTechCanon's access-control
|
||||
model. Auth Mode does not define its own operation vocabulary.
|
||||
|
||||
### `Subject` — the one that was renamed
|
||||
|
||||
InfoTechCanon's access-control model owns `Actor` and `Subject`, and binds them:
|
||||
|
||||
> Subject is the access-control view of an actor.
|
||||
|
||||
The Mode of Authority v0.1 draft used the same two words for **two distinct
|
||||
parties**, one acting on behalf of the other. That would have made `Subject`
|
||||
mean two different things across the canons, so the vocabulary renamed its
|
||||
dimension to **`AuthorityContext`**
|
||||
([SECURITY-DEC-2026-002](../decisions/decisions.md)).
|
||||
|
||||
If you are reading the v0.1 draft in `research/`, its `subject =` field is the
|
||||
current `authority_context =`.
|
||||
|
||||
## Quick lookup
|
||||
|
||||
| If you read… | It belongs to… | Meaning |
|
||||
| --- | --- | --- |
|
||||
| `OPERATE` | Auth Mode | authority over running state |
|
||||
| Operator | CARING role | lifecycle posture |
|
||||
| Runtime Plane | CARING plane | surface |
|
||||
| `CONSTRUCT` | Auth Mode | authority over definitions |
|
||||
| Builder | CARING role | lifecycle posture |
|
||||
| Build Plane | CARING plane | surface |
|
||||
| `GOVERN` | Auth Mode | authority over authority |
|
||||
| Policy Plane | CARING plane | surface |
|
||||
| Evidence Boundary | Auth Mode dimension | can evidence be compromised? |
|
||||
| Audit Plane | CARING plane | surface |
|
||||
| `AuthorityContext` | Auth Mode dimension | whose authority is drawn on |
|
||||
| Subject | InfoTechCanon access control | the access-control view of an actor |
|
||||
| Delegator | CARING §32 | who delegated, for non-human subjects |
|
||||
80
docs/vocabulary-card.md
Normal file
80
docs/vocabulary-card.md
Normal file
|
|
@ -0,0 +1,80 @@
|
|||
---
|
||||
id: SEC-CARD-001
|
||||
type: reference
|
||||
title: "Auth Mode vocabulary card"
|
||||
repo: security-canon
|
||||
status: draft
|
||||
created: "2026-09-20"
|
||||
source: infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md
|
||||
---
|
||||
|
||||
# Auth Mode — vocabulary card
|
||||
|
||||
One page. Full definitions in
|
||||
[SecurityCanonModeOfAuthority](../infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md).
|
||||
|
||||
## Notation
|
||||
|
||||
```text
|
||||
MODE @ SCOPE
|
||||
|
||||
alice:
|
||||
ADMINISTER @ tenant/acme
|
||||
activation = JUST_IN_TIME
|
||||
duration = 2h
|
||||
|
||||
support-agent:
|
||||
USE @ tenant/acme
|
||||
authority_context = customer-42
|
||||
relation = IMPERSONATED
|
||||
|
||||
recovery-principal:
|
||||
SOVEREIGN @ identity-realm
|
||||
activation = BREAK_GLASS
|
||||
evidence = EXTERNAL
|
||||
```
|
||||
|
||||
## The seven modes
|
||||
|
||||
| Mode | Question | One-line test |
|
||||
| --- | --- | --- |
|
||||
| `USE` | How do I get the value the system exists to provide? | domain purpose |
|
||||
| `OBSERVE` | What is this system doing? | knowledge about, not value from |
|
||||
| `OPERATE` | How do I keep it functioning? | changes running state, not definition |
|
||||
| `ADMINISTER` | How do I configure it within the rules? | inside rules set elsewhere |
|
||||
| `GOVERN` | What rules constrain authority? | decides what admins may decide |
|
||||
| `CONSTRUCT` | What can future versions be? | changes definitions, not instances |
|
||||
| `SOVEREIGN` | How is the regime established or recovered? | at or beyond the authority boundary |
|
||||
|
||||
**Not a ladder.** These classify the kind of authority, not the amount.
|
||||
|
||||
## Dimensions
|
||||
|
||||
| Dimension | Values |
|
||||
| --- | --- |
|
||||
| `activation` | `STANDING` `JUST_IN_TIME` `SCHEDULED` `APPROVED` `INCIDENT` `BREAK_GLASS` `RECOVERY` |
|
||||
| `provenance` | `LOCAL` `PARENT_SCOPE` `SUBSTRATE` `DELEGATED` `FEDERATED` `ASSUMED` `IMPERSONATED` |
|
||||
| `environment` | `DEVELOPMENT` `TEST` `STAGING` `PRODUCTION` `RECOVERY` |
|
||||
| `evidence` | `target-audited` `external-audited` `substrate-audited` `multi-party-audited` `outside-audit-boundary` |
|
||||
| `principal_type` | `HUMAN` `WORKLOAD` `SERVICE` `AGENT` `CONTROLLER` `DEVICE` *(imported)* |
|
||||
| `relation` | `DELEGATED` `IMPERSONATED` |
|
||||
|
||||
## The ten questions
|
||||
|
||||
```text
|
||||
1. Who is the actor? 6. Where does the authority originate?
|
||||
2. On whose authority? 7. Under what conditions is it activated?
|
||||
3. What Auth Mode? 8. What realm enforces it?
|
||||
4. Over what scope? 9. Who preserves the evidence?
|
||||
5. What operations? 10. Who can override enforcement?
|
||||
```
|
||||
|
||||
## Common translations
|
||||
|
||||
```text
|
||||
auditor → OBSERVE @ evidence
|
||||
developer → CONSTRUCT @ product
|
||||
backup operator → OPERATE @ backup-system
|
||||
break-glass → <mode>, activation=BREAK_GLASS
|
||||
"has root" → SOVEREIGN @ host (say the scope)
|
||||
```
|
||||
120
infospace/mappings/mode-of-authority-to-infotechcanon.md
Normal file
120
infospace/mappings/mode-of-authority-to-infotechcanon.md
Normal file
|
|
@ -0,0 +1,120 @@
|
|||
---
|
||||
id: sec-authority:MoAToInfoTechCanonMapping
|
||||
title: Mode of Authority to InfoTechCanon mapping
|
||||
type: mapping
|
||||
namespace: sec-authority
|
||||
version: 0.1.0
|
||||
status: draft
|
||||
source_artifact: sec-authority:ModeOfAuthority
|
||||
target_repository: info-tech-canon
|
||||
target_artifacts:
|
||||
- itc-access:AccessControlModel
|
||||
- itc-caring:CaringAccessGovernanceStandard
|
||||
decisions:
|
||||
- SECURITY-DEC-2026-001
|
||||
- SECURITY-DEC-2026-002
|
||||
---
|
||||
|
||||
# Mode of Authority → InfoTechCanon mapping
|
||||
|
||||
Relates the architecture-layer vocabulary to the two InfoTechCanon artifacts
|
||||
that speak about the same subject at the implementation layer. Per
|
||||
[SEC-ADR-001](../../docs/adr-001-securitycanon-boundary.md) this is a mapping,
|
||||
not a merge: neither side is rewritten to match the other.
|
||||
|
||||
## 1. Entity vocabulary
|
||||
|
||||
| Mode of Authority | ITC access control | CARING | Relationship |
|
||||
| --- | --- | --- | --- |
|
||||
| `Actor` | `Subject`, `Principal` | `Principal`, effective actor | imported — ITC owns actor semantics via the Organization Model |
|
||||
| `AuthorityContext` | — | `Delegator` | refines; CARING scopes it to non-human subjects |
|
||||
| `relation = DELEGATED` | `delegation` | Delegated Access §33.2 | same concept, three granularities |
|
||||
| `relation = IMPERSONATED` | — | customer impersonation; `ImpersonationBlocked` §29 | CARING adds the restriction |
|
||||
| `PrincipalType` | — | Subject dimension §9 | imported from the ITC identity model |
|
||||
| — | — | audit identity, capability ceiling | **no architecture-layer equivalent** |
|
||||
| — | — | Mediated §33.3, Induced §33.4 access | **no architecture-layer equivalent** |
|
||||
|
||||
The blank cells are informative rather than defects. Capability ceilings and
|
||||
induced access paths are implementation findings; the architecture layer has no
|
||||
business asserting them.
|
||||
|
||||
## 2. Dimension vocabulary
|
||||
|
||||
| Mode of Authority | CARING | Relationship |
|
||||
| --- | --- | --- |
|
||||
| `AuthMode` | Canonical Role §11, Plane §22 | **orthogonal** — three different questions, see [disambiguation](../../docs/disambiguation.md) |
|
||||
| `Scope` | Scope §21 | imported from ITC access control; one definition |
|
||||
| `AccessOperations` | Capability §23 | imported; CARING's is the richer implementation form |
|
||||
| `Activation` | Condition §26 | same idea; `Activation` is the architecture term |
|
||||
| `Environment` | — | architecture-layer only |
|
||||
| `EvidenceBoundary` | Audit Plane §22.10 | **different** — surface versus trust question |
|
||||
| `AuthorityProvenance` | — | architecture-layer only |
|
||||
| `AuthorityRealm`, `DOMINATES` | — | architecture-layer only; models substrate authority |
|
||||
| — | Exposure Mode §25, Exposure Event §29 | implementation-layer only |
|
||||
| — | Lifecycle State §27, Restriction §28 | implementation-layer only |
|
||||
| — | Organization Relation §10 | implementation-layer only |
|
||||
|
||||
## 3. Mode-to-plane affinity
|
||||
|
||||
Affinity, not equivalence. A mode may touch any plane; these are the common
|
||||
pairings, useful for orientation and not normative.
|
||||
|
||||
| Auth Mode | Planes most often touched |
|
||||
| --- | --- |
|
||||
| `USE` | Data, Execution, Commercial, Community |
|
||||
| `OBSERVE` | Audit, Runtime, Data |
|
||||
| `OPERATE` | Runtime, Execution |
|
||||
| `ADMINISTER` | Configuration, Identity, Policy, Secret |
|
||||
| `GOVERN` | Policy, Intent |
|
||||
| `CONSTRUCT` | Build, Intent, Configuration |
|
||||
| `SOVEREIGN` | Identity, Secret, Policy |
|
||||
|
||||
## 4. Mode-to-canonical-role affinity
|
||||
|
||||
Also affinity only. CARING roles describe lifecycle posture; a role does not
|
||||
grant a mode.
|
||||
|
||||
| CARING role | Modes commonly exercised |
|
||||
| --- | --- |
|
||||
| Creator | `GOVERN`, `CONSTRUCT` |
|
||||
| Builder | `CONSTRUCT` |
|
||||
| Verifier | `OBSERVE` |
|
||||
| Maintainer | `CONSTRUCT`, `OPERATE` |
|
||||
| Integrator | `CONSTRUCT`, `ADMINISTER` |
|
||||
| Operator | `OPERATE`, `OBSERVE` |
|
||||
| Manager | `ADMINISTER`, `GOVERN` |
|
||||
| Coach | `OBSERVE`, `USE` with `authority_context` |
|
||||
| Doer | `USE` |
|
||||
|
||||
Note the Operator row: the role and the `OPERATE` mode are not the same thing,
|
||||
and the row says only that they frequently co-occur.
|
||||
|
||||
## 5. Direction of import
|
||||
|
||||
```text
|
||||
InfoTechCanon ──owns──> Actor, Subject, Principal, Scope,
|
||||
AccessOperations, PrincipalType, Purpose
|
||||
│
|
||||
│ imported by
|
||||
▼
|
||||
SecurityCanon ──owns──> AuthMode, AuthorityContext, AuthorityRealm,
|
||||
AuthorityProvenance, Activation, EvidenceBoundary
|
||||
│
|
||||
│ referenceable by
|
||||
▼
|
||||
CARING ──owns──> Canonical Role, Plane, Capability, Exposure,
|
||||
Lifecycle State, Restriction, Organization Relation
|
||||
```
|
||||
|
||||
Nothing flows upward as a redefinition. CARING may reference the vocabulary;
|
||||
the vocabulary imports from the shared roots; the shared roots know nothing of
|
||||
either.
|
||||
|
||||
## 6. Open
|
||||
|
||||
- Whether CARING generalises its §32 role set beyond non-human subjects. Additive
|
||||
and non-breaking if adopted, but it is InfoTechCanon's to accept — raise as a
|
||||
demand signal there, not as a change here. Analysis in the
|
||||
[implications note](../../docs/260920-actor-subject-implications.md) §4.
|
||||
- Whether `AuthMode` becomes a machine-readable authorization attribute
|
||||
consumable by CARING descriptors (v0.1 draft Q7).
|
||||
|
|
@ -0,0 +1,376 @@
|
|||
---
|
||||
id: sec-authority:ModeOfAuthority
|
||||
title: SecurityCanon Mode of Authority
|
||||
short_name: AUTH-MODE
|
||||
type: model
|
||||
standard_family: SecurityCanon
|
||||
repository_context: security-canon
|
||||
recommended_path: infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md
|
||||
status: draft
|
||||
version: 0.2.0
|
||||
source_version: "0.1"
|
||||
source_file: research/260920-mode-of-authority-v0.1.md
|
||||
canonical_owner: SecurityCanonModeOfAuthority
|
||||
namespace: sec-authority
|
||||
classification: vocabulary
|
||||
abstraction_layer: architecture
|
||||
primary_cluster: authority
|
||||
imports:
|
||||
- InfoTechCanonCore
|
||||
- InfoTechCanonAccessControlModel
|
||||
- InfoTechCanonIdentityModel
|
||||
- InfoTechCanonOrganizationModel
|
||||
- InfoTechCanonPurposesExtension
|
||||
related:
|
||||
- InfoTechCanonCaringAccessGovernanceStandard
|
||||
- InfoTechCanonSecurityModel
|
||||
owned_concepts:
|
||||
- AuthMode
|
||||
- AuthorityContext
|
||||
- AuthorityRealm
|
||||
- AuthorityProvenance
|
||||
- Activation
|
||||
- EvidenceBoundary
|
||||
- AccessSituation
|
||||
decisions:
|
||||
- SECURITY-DEC-2026-001
|
||||
- SECURITY-DEC-2026-002
|
||||
---
|
||||
|
||||
# SecurityCanon Mode of Authority
|
||||
|
||||
**Short name:** `AUTH-MODE` · **Concept:** Mode of Authority · **Term:** Auth Mode
|
||||
|
||||
Promoted from the [v0.1 research draft](../../../research/260920-mode-of-authority-v0.1.md),
|
||||
which is retained verbatim as provenance. Changes from v0.1 are listed in §12.
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This vocabulary answers one question that permission and role models do not
|
||||
answer directly:
|
||||
|
||||
> **In what relationship to a system is an actor exercising authority?**
|
||||
|
||||
That relationship is the actor's **Mode of Authority**, or **Auth Mode**.
|
||||
|
||||
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.
|
||||
|
||||
An Auth Mode does not itself define individual permissions.
|
||||
|
||||
## 2. Layer
|
||||
|
||||
This is an **architecture-layer** vocabulary. It describes authority
|
||||
relationships before and independently of the mechanisms that enforce them.
|
||||
|
||||
Per [SEC-ADR-001](../../../docs/adr-001-securitycanon-boundary.md), the
|
||||
implementation layer is owned by InfoTechCanon's CARING standard, which analyses
|
||||
how an access-control implementation is actually composed. The two layers are
|
||||
complementary and neither subsumes the other.
|
||||
|
||||
| | Mode of Authority | CARING |
|
||||
| --- | --- | --- |
|
||||
| Question | In what relationship is authority exercised? | How is this implementation composed? |
|
||||
| Layer | architecture | implementation |
|
||||
| Owner | SecurityCanon | InfoTechCanon |
|
||||
|
||||
## 3. Orientation — start here
|
||||
|
||||
Ask these ten questions, in order. They are the intended entry point to this
|
||||
vocabulary, not an appendix to it.
|
||||
|
||||
```text
|
||||
1. Who is the actor?
|
||||
2. On whose authority 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 the labels
|
||||
`user`, `admin`, `superadmin`, `root` alone.
|
||||
|
||||
## 4. Distinction from access mode
|
||||
|
||||
An **access operation** — read, write, execute, delete, approve — describes
|
||||
*what operation may be performed on a resource*. An Auth Mode describes *in what
|
||||
relationship the actor stands to the system*. The two axes are orthogonal:
|
||||
|
||||
```text
|
||||
read + USE → reading a customer's document
|
||||
read + OBSERVE → reading telemetry about the document service
|
||||
```
|
||||
|
||||
The access operation is `read` in both cases. The Auth Mode differs. Access
|
||||
operations are owned by InfoTechCanon's access-control model and imported here.
|
||||
|
||||
## 5. The seven Auth Modes
|
||||
|
||||
| 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? |
|
||||
|
||||
Machine-readable definitions, including intent, typical actions and boundary
|
||||
cases, are in [`auth-modes.yaml`](auth-modes.yaml).
|
||||
|
||||
## 6. Principles
|
||||
|
||||
### A1 — Authority is scope-relative
|
||||
|
||||
There is no meaningful authority without a scope. 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. `USE < ADMINISTER < SOVEREIGN` must not
|
||||
be treated as the semantic model. An auditor may OBSERVE what administrators
|
||||
cannot see; a developer may CONSTRUCT production behaviour with no production
|
||||
access; a governor may constrain administrators without being able to perform
|
||||
their operational tasks.
|
||||
|
||||
### A3 — Auditability is independent of Auth Mode
|
||||
|
||||
Auditability depends on the **Evidence Boundary**, not the mode. The central
|
||||
question is whether the actor being observed can alter, suppress, bypass or
|
||||
invalidate the evidence used to observe it. Sovereign authority does not
|
||||
necessarily mean unaudited authority.
|
||||
|
||||
### A4 — Federation does not imply authorization
|
||||
|
||||
Federation establishes trusted assertions between independent authority realms.
|
||||
The receiving realm decides independently what the asserted identity may do.
|
||||
|
||||
### A5 — Sovereignty is relative, not absolute
|
||||
|
||||
There need not be a universal root. `SOVEREIGN @ database` does not imply
|
||||
`SOVEREIGN @ host`; `SOVEREIGN @ tenant` does not imply `SOVEREIGN @ platform`.
|
||||
|
||||
### A6 — Naming does not collide with the implementation layer *(new in 0.2.0)*
|
||||
|
||||
Where InfoTechCanon owns a term, this vocabulary imports it rather than
|
||||
redefining it, and where this vocabulary needs a distinct concept it takes a
|
||||
distinct name. See [SECURITY-DEC-2026-002](../../../decisions/decisions.md) and
|
||||
§9.
|
||||
|
||||
## 7. Dimensions
|
||||
|
||||
An **Access Situation** is the complete context in which authority is exercised:
|
||||
|
||||
```text
|
||||
AccessSituation =
|
||||
Actor
|
||||
× AuthorityContext
|
||||
× AuthMode
|
||||
× Scope
|
||||
× AccessOperations
|
||||
× AuthorityProvenance
|
||||
× Activation
|
||||
× Environment
|
||||
× EvidenceBoundary
|
||||
× Time
|
||||
× Purpose
|
||||
```
|
||||
|
||||
Not every implementation materialises every dimension; the model exists to
|
||||
support precise reasoning.
|
||||
|
||||
| Dimension | Owner | Note |
|
||||
| --- | --- | --- |
|
||||
| Actor | InfoTechCanon Organization Model | imported |
|
||||
| **AuthorityContext** | SecurityCanon | renamed from v0.1 `Subject`, see §9 |
|
||||
| **AuthMode** | SecurityCanon | the seven modes |
|
||||
| Scope | InfoTechCanon access-control model | imported |
|
||||
| AccessOperations | InfoTechCanon access-control model | imported |
|
||||
| **AuthorityProvenance** | SecurityCanon | `LOCAL`, `PARENT_SCOPE`, `SUBSTRATE`, `DELEGATED`, `FEDERATED`, `ASSUMED`, `IMPERSONATED` |
|
||||
| **Activation** | SecurityCanon | `STANDING`, `JUST_IN_TIME`, `SCHEDULED`, `APPROVED`, `INCIDENT`, `BREAK_GLASS`, `RECOVERY` |
|
||||
| Environment | SecurityCanon | `DEVELOPMENT`, `TEST`, `STAGING`, `PRODUCTION`, `RECOVERY` |
|
||||
| **EvidenceBoundary** | SecurityCanon | who observes and preserves evidence, and who can compromise it |
|
||||
| Time | — | not modelled in 0.2.0 |
|
||||
| Purpose | InfoTechCanon PURPOSES extension | imported, not redefined here |
|
||||
| PrincipalType | InfoTechCanon identity model | imported; `HUMAN`, `WORKLOAD`, `SERVICE`, `AGENT`, `CONTROLLER`, `DEVICE` |
|
||||
|
||||
Machine-readable definitions are in [`dimensions.yaml`](dimensions.yaml).
|
||||
|
||||
Auth Modes apply independently of principal type. Principal type must not be
|
||||
encoded into the Auth Mode taxonomy.
|
||||
|
||||
## 8. Authority Realm
|
||||
|
||||
An **Authority Realm** is a scope possessing an independently meaningful
|
||||
authority boundary — an operating system, a database, a Kubernetes cluster, a
|
||||
cloud account or organization, an identity realm, a SaaS tenant, a trust domain.
|
||||
|
||||
A realm may possess its own SOVEREIGN, GOVERN, ADMINISTER, OPERATE, OBSERVE and
|
||||
USE authorities. Realms need not share a common sovereign. A federation may hold
|
||||
`GOVERN @ federation` without holding `SOVEREIGN @ member-realms`, so a genuine
|
||||
federation need not contain a global root.
|
||||
|
||||
## 9. Actor and Authority Context
|
||||
|
||||
Authority is sometimes exercised on behalf of another party.
|
||||
|
||||
- **Actor** — the entity actually performing the action.
|
||||
- **Authority Context** — the authority being drawn on, when it is not the
|
||||
actor's own.
|
||||
|
||||
Normally the actor acts on its own authority and the dimension is absent. When
|
||||
it does not:
|
||||
|
||||
```text
|
||||
support-agent:
|
||||
USE @ tenant/acme
|
||||
authority_context = customer-42
|
||||
relation = IMPERSONATED
|
||||
```
|
||||
|
||||
**Delegation** means the actor retains its identity while exercising delegated
|
||||
authority. **Impersonation** means the actor acts within another party's
|
||||
authority context. Neither is an Auth Mode; both describe *how* authority is
|
||||
exercised, and the underlying mode may still be USE, OPERATE, ADMINISTER or any
|
||||
other.
|
||||
|
||||
> **Renamed in 0.2.0.** The v0.1 draft called this dimension `Subject`.
|
||||
> InfoTechCanon's access-control model already owns both `Actor` and `Subject`
|
||||
> and binds them differently — "Subject is the access-control view of an actor" —
|
||||
> so reusing the pair for two distinct parties would have made the same word mean
|
||||
> two things across the canons. `AuthorityContext` names what the field holds,
|
||||
> which stays accurate when the target is a role or mandate rather than a person.
|
||||
> See [SECURITY-DEC-2026-002](../../../decisions/decisions.md) and the
|
||||
> [implications note](../../../docs/260920-actor-subject-implications.md).
|
||||
|
||||
CARING §32 carries a richer form of this distinction — Principal, effective
|
||||
actor, Delegator, audit identity, capability ceiling — scoped to non-human
|
||||
subjects. The relationship is recorded as a
|
||||
[mapping](../../mappings/mode-of-authority-to-infotechcanon.md), not a
|
||||
redefinition.
|
||||
|
||||
## 10. Positions on the v0.1 open questions
|
||||
|
||||
### 10.1 CONSTRUCT and GOVERN are distinct — the artifact does not decide it
|
||||
|
||||
v0.1 asked whether policy-as-code blurs CONSTRUCT and GOVERN. **Position: they
|
||||
remain distinct, and the distinguishing test is the object of authority, not the
|
||||
medium.**
|
||||
|
||||
```text
|
||||
CONSTRUCT authority over definitions from which behaviour is produced
|
||||
GOVERN authority over the rules constraining how authority is exercised
|
||||
```
|
||||
|
||||
Policy-as-code is an artifact *and* a rule, so an actor may hold both modes over
|
||||
it — and that is the point, not a defect:
|
||||
|
||||
```text
|
||||
platform-engineer:
|
||||
CONSTRUCT @ policy-repo/authz # may change the policy source
|
||||
# but NOT GOVERN @ organization # may not decide what the policy must say
|
||||
|
||||
security-governor:
|
||||
GOVERN @ organization # decides what the policy must require
|
||||
# but NOT CONSTRUCT @ policy-repo # does not write or merge it
|
||||
```
|
||||
|
||||
The separation is the security property worth having: whoever can edit the
|
||||
policy file should generally not be the one who decides what it must contain.
|
||||
Collapsing the two modes would make that separation inexpressible. The test is
|
||||
therefore:
|
||||
|
||||
> Does the actor change the *artifact* (CONSTRUCT) or decide the *constraint*
|
||||
> the artifact must satisfy (GOVERN)? An actor holding both over the same scope
|
||||
> is a finding, not a modelling error.
|
||||
|
||||
### 10.2 Substrate authority is a relation between realms
|
||||
|
||||
v0.1 named substrate authority — hypervisor over VM, host root over container,
|
||||
cloud provider over tenant — but recorded it only as
|
||||
`AuthorityProvenance = SUBSTRATE`, which names the fact without modelling which
|
||||
realm dominates which.
|
||||
|
||||
**Position: substrate authority is a relation between Authority Realms, not a
|
||||
mode and not a provenance value alone.** It is written:
|
||||
|
||||
```text
|
||||
realm:host/node-7 DOMINATES realm:container/app-3
|
||||
realm:cloud/aws-account-1 DOMINATES realm:tenant/acme
|
||||
```
|
||||
|
||||
with three properties, which are what actually matter in analysis:
|
||||
|
||||
| Property | Question |
|
||||
| --- | --- |
|
||||
| `dominance_kind` | execution substrate, storage substrate, identity substrate, network substrate? |
|
||||
| `observable` | can the dominated realm detect the dominating realm's exercise of authority? |
|
||||
| `evidence_boundary` | does the dominated realm's evidence survive the dominating realm? |
|
||||
|
||||
This makes A5 checkable. `SOVEREIGN @ container` is true within its realm and
|
||||
simultaneously dominated by `SOVEREIGN @ host` — with no contradiction, and with
|
||||
the security consequence stated explicitly rather than implied.
|
||||
|
||||
`AuthorityProvenance = SUBSTRATE` is retained: it marks authority that *arrives*
|
||||
through a dominance relation, while the relation itself records the structure.
|
||||
|
||||
### 10.3 Still open
|
||||
|
||||
Q1 (are seven modes sufficient), Q4 (decomposing sovereignty), Q5 (mutually
|
||||
constraining sovereigns), Q6 (autonomous agents modifying their own future
|
||||
authority) and Q7 (Auth Mode as a machine-readable ABAC attribute) remain open
|
||||
and are carried in the [v0.1 draft](../../../research/260920-mode-of-authority-v0.1.md) §31.
|
||||
|
||||
## 11. What is deliberately not an Auth Mode
|
||||
|
||||
`AUDIT`, `SECURITY`, `SUPPORT`, `BACKUP`, `DEVELOPER`, `OWNER`, `BILLING`,
|
||||
`AUTOMATION`, `AGENT`, `FEDERATION`, `BREAK_GLASS`, `SUPERADMIN`, `ROOT`.
|
||||
|
||||
Each is representable as a composition:
|
||||
|
||||
```text
|
||||
auditor → OBSERVE @ evidence
|
||||
backup operator → OPERATE @ backup-system
|
||||
developer → CONSTRUCT @ product
|
||||
security administrator → ADMINISTER @ security-controls
|
||||
security policy owner → GOVERN @ security-controls
|
||||
break-glass admin → ADMINISTER, activation=BREAK_GLASS
|
||||
```
|
||||
|
||||
`root` is an implementation-specific manifestation of sovereign or broad
|
||||
authority, not a mode. Prefer `SOVEREIGN @ host` or `ADMINISTER @ cluster` over
|
||||
"has root".
|
||||
|
||||
A new Auth Mode is introduced only when a recurring authority relationship
|
||||
cannot be expressed as an existing mode plus scope, operation, provenance,
|
||||
activation and purpose.
|
||||
|
||||
## 12. Changes from v0.1
|
||||
|
||||
| Change | Reason |
|
||||
| --- | --- |
|
||||
| `Subject` dimension renamed to `AuthorityContext` | collision with InfoTechCanon-owned `Actor`/`Subject` binding (§9) |
|
||||
| Scope, AccessOperations, Purpose, PrincipalType declared as imports | InfoTechCanon owns them; SEC-ADR-001 D2 |
|
||||
| Principle A6 added | naming separation made explicit |
|
||||
| Position taken on CONSTRUCT vs GOVERN | §10.1; was open question Q2 |
|
||||
| Substrate authority modelled as realm dominance | §10.2; was open question Q3 |
|
||||
| Design heuristic moved to §3 | it is the entry point, not an appendix |
|
||||
| Machine-readable modes and dimensions added | `auth-modes.yaml`, `dimensions.yaml` |
|
||||
| Artifact frontmatter, id, namespace, owned concepts added | makes it a canon artifact rather than a paper |
|
||||
|
||||
## 13. Status
|
||||
|
||||
**Draft.** Stable promotion requires reviewed mappings and concrete consumer
|
||||
evidence, per [INTENT.md](../../../INTENT.md). The research hypothesis — that
|
||||
seven modes suffice without platform-specific additions — has not yet been
|
||||
stress-tested against Unix, databases, Kubernetes, cloud IAM, identity
|
||||
platforms, secrets management, CI/CD or agentic systems.
|
||||
97
infospace/vocabulary/mode-of-authority/auth-modes.yaml
Normal file
97
infospace/vocabulary/mode-of-authority/auth-modes.yaml
Normal file
|
|
@ -0,0 +1,97 @@
|
|||
id: sec-authority:AuthModeCatalog
|
||||
title: SecurityCanon Auth Mode Catalog
|
||||
type: catalog
|
||||
namespace: sec-authority
|
||||
version: 0.2.0
|
||||
status: draft
|
||||
source: infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md
|
||||
notation: "MODE @ SCOPE"
|
||||
non_ordered: true
|
||||
non_ordered_note: >-
|
||||
Auth Modes classify the kind of authority, not its magnitude. This list is not
|
||||
a privilege ladder and must not be compared ordinally.
|
||||
|
||||
auth_modes:
|
||||
- id: USE
|
||||
intent: Exercise the system for its designated domain purpose.
|
||||
question: How do I obtain the value this system exists to provide?
|
||||
typical_actions: [send a message, edit a document, place an order, query application data, consume an API]
|
||||
boundary: >-
|
||||
USE does not imply low privilege. A business user may perform highly
|
||||
consequential actions entirely within USE.
|
||||
contrast:
|
||||
OBSERVE: reading a customer invoice is USE; reading latency metrics for the invoice service is OBSERVE
|
||||
|
||||
- id: OBSERVE
|
||||
intent: Establish knowledge about the system, its behavior or its state.
|
||||
question: What is this system doing?
|
||||
typical_actions: [read logs, view metrics, inspect traces, read audit records, examine security events]
|
||||
boundary: >-
|
||||
Distinct from ordinary read access. The access operation may be identical;
|
||||
the relationship to the system differs.
|
||||
contrast:
|
||||
USE: understanding the system rather than obtaining its domain value
|
||||
|
||||
- id: OPERATE
|
||||
intent: >-
|
||||
Maintain or change the operational state of an instantiated system while
|
||||
preserving its intended definition.
|
||||
question: How do I keep this instantiated system functioning?
|
||||
typical_actions: [start, stop, restart, scale, fail over, restore, drain a node, terminate a stuck process]
|
||||
boundary: Changes running state, not definition.
|
||||
contrast:
|
||||
ADMINISTER: restarting a database is OPERATE; changing its authentication configuration is ADMINISTER
|
||||
|
||||
- id: ADMINISTER
|
||||
intent: Configure resources and delegated authority within an established governance regime.
|
||||
question: How do I configure this system within existing rules?
|
||||
typical_actions: [configure resources, create users, assign roles, manage groups, provision resources, delegate bounded authority]
|
||||
boundary: >-
|
||||
Operates inside rules established elsewhere. Broad discretion does not
|
||||
include redefining the constraints on that discretion.
|
||||
contrast:
|
||||
GOVERN: assigning application roles is ADMINISTER; deciding which roles administrators may assign is GOVERN
|
||||
|
||||
- id: GOVERN
|
||||
intent: Define the rules under which authority may be exercised.
|
||||
question: What rules constrain how authority may be exercised?
|
||||
typical_actions: [set policy ceilings, define delegation rules, set separation-of-duty requirements, decide allowed identity providers]
|
||||
boundary: Authority over authority.
|
||||
test: Can this actor decide what another administrator is allowed to decide?
|
||||
contrast:
|
||||
CONSTRUCT: GOVERN decides the constraint; CONSTRUCT changes the artifact that must satisfy it
|
||||
|
||||
- id: CONSTRUCT
|
||||
intent: Change definitions or artifacts from which system behavior is produced.
|
||||
question: How do I change what future incarnations of this system can be?
|
||||
typical_objects: [source code, infrastructure-as-code, build definitions, container images, schemas, policy-as-code, CI/CD pipelines]
|
||||
boundary: >-
|
||||
Authority over the possible future system, not necessarily over the
|
||||
running instance. Substantial CONSTRUCT authority may coexist with no
|
||||
production runtime authority.
|
||||
contrast:
|
||||
ADMINISTER: ADMINISTER changes the instantiated system; CONSTRUCT changes definitions capable of producing systems
|
||||
|
||||
- id: SOVEREIGN
|
||||
intent: Establish, recover, replace or bypass the normal authority regime of a scope.
|
||||
question: How is the authority regime itself established, recovered or replaced?
|
||||
typical_situations: [initial bootstrap, establishing trust roots, root-account recovery, rebuilding the control plane, restoring authority after catastrophic failure]
|
||||
boundary: >-
|
||||
Sovereign relative to a defined scope and authority boundary, never
|
||||
all-powerful everywhere. SOVEREIGN @ database does not imply SOVEREIGN @ host.
|
||||
see_also: Evidence Boundary — sovereign authority is not necessarily unaudited
|
||||
|
||||
not_auth_modes:
|
||||
- {term: AUDIT, expressed_as: "OBSERVE @ evidence"}
|
||||
- {term: BACKUP, expressed_as: "OPERATE @ backup-system"}
|
||||
- {term: DEVELOPER, expressed_as: "CONSTRUCT @ product"}
|
||||
- {term: SUPPORT, expressed_as: "USE or ADMINISTER with authority_context and relation=IMPERSONATED"}
|
||||
- {term: BREAK_GLASS, expressed_as: "any mode with activation=BREAK_GLASS"}
|
||||
- {term: FEDERATION, expressed_as: "any mode with provenance=FEDERATED"}
|
||||
- {term: AGENT, expressed_as: "any mode with principal_type=AGENT"}
|
||||
- {term: SUPERADMIN, expressed_as: "ADMINISTER or SOVEREIGN at a named scope"}
|
||||
- {term: ROOT, expressed_as: "SOVEREIGN @ host, or ADMINISTER @ scope — implementation-specific"}
|
||||
- {term: OWNER, expressed_as: "GOVERN or ADMINISTER at a named scope"}
|
||||
- {term: BILLING, expressed_as: "USE @ billing, or ADMINISTER @ billing"}
|
||||
- {term: AUTOMATION, expressed_as: "any mode with principal_type=WORKLOAD or CONTROLLER"}
|
||||
- {term: SECURITY, expressed_as: "ADMINISTER @ security-controls, or GOVERN @ security-controls"}
|
||||
100
infospace/vocabulary/mode-of-authority/dimensions.yaml
Normal file
100
infospace/vocabulary/mode-of-authority/dimensions.yaml
Normal file
|
|
@ -0,0 +1,100 @@
|
|||
id: sec-authority:AuthorityDimensions
|
||||
title: SecurityCanon Authority Dimensions
|
||||
type: catalog
|
||||
namespace: sec-authority
|
||||
version: 0.2.0
|
||||
status: draft
|
||||
source: infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md
|
||||
|
||||
access_situation:
|
||||
note: >-
|
||||
The complete context in which authority is exercised. Not every
|
||||
implementation materializes every dimension; the model supports reasoning.
|
||||
dimensions: [Actor, AuthorityContext, AuthMode, Scope, AccessOperations,
|
||||
AuthorityProvenance, Activation, Environment, EvidenceBoundary,
|
||||
Time, Purpose]
|
||||
|
||||
owned:
|
||||
- id: AuthorityContext
|
||||
definition: The authority being drawn on, when it is not the actor's own.
|
||||
absent_when: The actor acts on its own authority.
|
||||
companion_field:
|
||||
name: relation
|
||||
values: [DELEGATED, IMPERSONATED]
|
||||
note: >-
|
||||
Delegation keeps the actor's identity while exercising delegated
|
||||
authority; impersonation acts within another party's authority context.
|
||||
Neither is an Auth Mode.
|
||||
renamed_from:
|
||||
v0_1_name: Subject
|
||||
reason: >-
|
||||
InfoTechCanon's access-control model 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 make one word mean two things across
|
||||
the canons.
|
||||
decision: SECURITY-DEC-2026-002
|
||||
|
||||
- id: AuthorityProvenance
|
||||
definition: Where the exercised authority originates.
|
||||
values: [LOCAL, PARENT_SCOPE, SUBSTRATE, DELEGATED, FEDERATED, ASSUMED, IMPERSONATED]
|
||||
note: SUBSTRATE marks authority arriving through a realm dominance relation.
|
||||
|
||||
- id: Activation
|
||||
definition: When and under what conditions authority becomes exercisable.
|
||||
values: [STANDING, JUST_IN_TIME, SCHEDULED, APPROVED, INCIDENT, BREAK_GLASS, RECOVERY]
|
||||
orthogonal_to: AuthMode
|
||||
|
||||
- id: Environment
|
||||
definition: The environment in which the authority applies.
|
||||
values: [DEVELOPMENT, TEST, STAGING, PRODUCTION, RECOVERY]
|
||||
note: Especially significant for CONSTRUCT authority.
|
||||
|
||||
- id: EvidenceBoundary
|
||||
definition: >-
|
||||
Which system is responsible for observing and preserving evidence of
|
||||
authority use, and whether the observed actor can compromise it.
|
||||
values: [target-audited, external-audited, substrate-audited, multi-party-audited, outside-audit-boundary]
|
||||
tests:
|
||||
- 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?
|
||||
principle: Auditability depends on this dimension, not on the Auth Mode (A3).
|
||||
|
||||
- id: AuthorityRealm
|
||||
definition: A scope possessing an independently meaningful authority boundary.
|
||||
examples: [operating system, database, Kubernetes cluster, cloud account, cloud organization, identity realm, SaaS tenant, trust domain]
|
||||
relation:
|
||||
name: DOMINATES
|
||||
definition: >-
|
||||
A realm exercising substrate authority over another realm. Models the
|
||||
hypervisor-over-VM, host-over-container and provider-over-tenant cases.
|
||||
properties:
|
||||
dominance_kind: [execution, storage, identity, network]
|
||||
observable: Can the dominated realm detect the dominating realm's exercise of authority?
|
||||
evidence_boundary: Does the dominated realm's evidence survive the dominating realm?
|
||||
example: "realm:host/node-7 DOMINATES realm:container/app-3"
|
||||
note: >-
|
||||
Dominance does not make the dominating realm universally sovereign (A5).
|
||||
SOVEREIGN @ container and SOVEREIGN @ host coexist without contradiction.
|
||||
|
||||
imported:
|
||||
- id: Actor
|
||||
owner: InfoTechCanonOrganizationModel
|
||||
note: Actor semantics are owned upstream; this vocabulary references them.
|
||||
- id: Scope
|
||||
owner: InfoTechCanonAccessControlModel
|
||||
- id: AccessOperations
|
||||
owner: InfoTechCanonAccessControlModel
|
||||
note: read, write, execute, delete, approve — orthogonal to AuthMode.
|
||||
- id: Purpose
|
||||
owner: InfoTechCanonPurposesExtension
|
||||
note: Named in the Access Situation tuple; defined upstream, not here.
|
||||
- id: PrincipalType
|
||||
owner: InfoTechCanonIdentityModel
|
||||
values: [HUMAN, WORKLOAD, SERVICE, AGENT, CONTROLLER, DEVICE]
|
||||
constraint: Principal type must not be encoded into the Auth Mode taxonomy.
|
||||
|
||||
not_modelled:
|
||||
- id: Time
|
||||
note: Named in the Access Situation tuple; not modelled in 0.2.0.
|
||||
|
|
@ -133,7 +133,7 @@ a bounded change handled under a new task, not a migration programme.
|
|||
|
||||
```task
|
||||
id: SECURITY-WP-0001-T06
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "de5fc42c-2e18-5f03-b86c-a5ad45a9bb0a"
|
||||
```
|
||||
|
|
@ -165,7 +165,7 @@ extension rather than defining it here.
|
|||
|
||||
```task
|
||||
id: SECURITY-WP-0001-T07
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "4a0d3df9-d8a2-51c4-a4bc-72488d866068"
|
||||
```
|
||||
|
|
@ -194,3 +194,39 @@ with InfoTechCanon.
|
|||
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.
|
||||
|
||||
## Result — 2026-09-20 (T06, T07)
|
||||
|
||||
Mode of Authority promoted to
|
||||
[`sec-authority:ModeOfAuthority`](../infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md)
|
||||
v0.2.0, with machine-readable [`auth-modes.yaml`](../infospace/vocabulary/mode-of-authority/auth-modes.yaml)
|
||||
and [`dimensions.yaml`](../infospace/vocabulary/mode-of-authority/dimensions.yaml).
|
||||
The v0.1 draft moved verbatim to
|
||||
[`research/260920-mode-of-authority-v0.1.md`](../research/260920-mode-of-authority-v0.1.md)
|
||||
as provenance; it had been sitting in `spec/`, which the Repository Layout
|
||||
Standard reserves for implementation guidance.
|
||||
|
||||
Orientation surfaces published: the [vocabulary card](../docs/vocabulary-card.md),
|
||||
the ten-question design heuristic promoted to §3 of the artifact, and the
|
||||
[role/plane/mode disambiguation page](../docs/disambiguation.md). The cross-layer
|
||||
[mapping](../infospace/mappings/mode-of-authority-to-infotechcanon.md) records
|
||||
entity and dimension correspondences, mode-to-plane and mode-to-role affinities,
|
||||
and the import direction.
|
||||
|
||||
Terminology separation decided as
|
||||
[SECURITY-DEC-2026-002 / SEC-ADR-002](../docs/adr-002-terminology-separation.md):
|
||||
`Subject` becomes `AuthorityContext`; `Operator`/`OPERATE`, Build Plane/`CONSTRUCT`,
|
||||
Policy Plane/`GOVERN`, Audit Plane/`EvidenceBoundary` and Condition/`Activation`
|
||||
are separated rather than merged; Scope, AccessOperations, Purpose and
|
||||
PrincipalType are declared imports; namespace `sec-authority:` reserved.
|
||||
|
||||
Two v0.1 open questions closed in the artifact §10. CONSTRUCT stays distinct from
|
||||
GOVERN, with the test being the object of authority — the artifact versus the
|
||||
constraint it must satisfy — so that "who may edit the policy" and "who decides
|
||||
what it must say" remain separable. Substrate authority is modelled as a
|
||||
`DOMINATES` relation between Authority Realms carrying `dominance_kind`,
|
||||
`observable` and `evidence_boundary`, which makes A5 checkable. Q1 and Q4–Q7
|
||||
remain open.
|
||||
|
||||
Generalising CARING §32 beyond non-human subjects was deliberately **not** bundled
|
||||
in; it is InfoTechCanon's to accept as a demand signal.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue