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
2.6 KiB
2.6 KiB
| id | type | title | repo | status | created | source |
|---|---|---|---|---|---|---|
| SEC-CARD-001 | reference | Auth Mode vocabulary card | security-canon | draft | 2026-09-20 | infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md |
Auth Mode — vocabulary card
One page. Full definitions in SecurityCanonModeOfAuthority.
Notation
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
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
auditor → OBSERVE @ evidence
developer → CONSTRUCT @ product
backup operator → OPERATE @ backup-system
break-glass → <mode>, activation=BREAK_GLASS
"has root" → SOVEREIGN @ host (say the scope)