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
3.4 KiB
| id | decision_record | type | title | repo | status | decided | implements |
|---|---|---|---|---|---|---|---|
| SEC-ADR-002 | SECURITY-DEC-2026-002 | adr | Terminology separation between Auth Mode and the implementation layer | security-canon | accepted | 2026-09-20 | SEC-ADR-001 D2 |
SEC-ADR-002 — Terminology separation
Applies SEC-ADR-001 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 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 asauthority_context =in the promoted vocabulary; the draft is retained verbatim inresearch/and the rename is recorded in its §12 change list. - A disambiguation page is a permanent part of the canon's orientation surface, not a transitional aid.
- The mapping carries the cross-layer relationships, including the deliberate blanks where one layer has no equivalent.