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
73 lines
3.4 KiB
Markdown
73 lines
3.4 KiB
Markdown
---
|
|
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.
|