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
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)
|
||||
```
|
||||
Loading…
Add table
Add a link
Reference in a new issue