tegwick
383e75f6b2
Owner decision of 2026-09-20 answering four of the five open questions from the Mode of Authority assessment, recorded as SEC-DEC-0001 with the reasoning in docs/adr-001-securitycanon-boundary.md. CARING stays in InfoTechCanon: it is implementation-layer and imports eleven InfoTechCanon models, and SecurityCanon should help rather than hinder keeping InfoTechCanon practical. Identity stays a shared root, since pulling it in would collapse too much into security and it reaches into personhood; a dedicated identity or personhood canon is deferred, not rejected. Mode of Authority is architecture where CARING is implementation — different layers of abstraction, neither subsuming the other, but they must not use the same word for different things. No service surface is duplicated: integration is uniform across commerce-canon, interface-canon and security-canon through the canon-federation interface card, and InfoTechCanon's service stays the only one. Content migration is therefore no longer a goal. T02 narrows from a disposition review to concept placement, T03 becomes a non-collision survey, and T05, the migration workplan handoff, is cancelled. T06 gains the three-way mapping table and T07 becomes the terminology separation decision. The remaining open question is analysed in docs/260920-actor-subject-implications.md. InfoTechCanon's access-control model already owns Actor and Subject and binds them as "Subject is the access-control view of an actor", while Mode of Authority uses the same two words for two distinct parties; and CARING already carries the split for non-human subjects. The note recommends renaming Mode of Authority's second party to Authority Context rather than changing a release-candidate standard. 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
SCOPE
Reviewed: 2026-09-20 (Europe/Berlin), after SEC-ADR-001.
Current repository scope
Bootstrap. The repository carries governance files — INTENT, SCOPE, AGENTS,
repo classification — the SEC-ADR-001
boundary decision, the Mode of Authority review in history/, and one active
workplan. The only content is the Mode of Authority v0.1 research draft, not yet
promoted into a canon artifact. There is no service code, and by decision there
will be none.
Ownership and boundaries
Following INTENT.md, SecurityCanon occupies the Taxonomy layer and owns security concept definitions and their cross-canon mappings. It imports shared roots from InfoTechCanon and does not redefine them.
Out of scope, with the owner named:
- the CARING access governance standard and its Kubernetes RBAC benchmark, the access-control model, and the identity model — InfoTechCanon, by SEC-ADR-001 D1 and D3
- any CLI, HTTP API, or validation service — InfoTechCanon's service surface, by SEC-ADR-001 D4; integration is via the canon-federation interface card
- security architecture and standards of record for the estate — NetKingdom
- authorization decisions — flex-auth
- login, OIDC, MFA — key-cape / Keycloak
- secret custody and credential issuance — OpenBao, ops-warden
- adversarial evidence and findings practice — whitehat-security
- shared artifact/ownership/mapping/profile mechanisms — InfoTechCanon
- consumer runtime state, enforcement, observation, and adoption evidence — the consumers
Planned scope
The near-term deliverable is the architecture-layer vocabulary, not a migration.
| Deliverable | Task |
|---|---|
| Mode of Authority promoted to a checkable Tier-1 artifact | SECURITY-WP-0001-T06 |
| Terminology separation from CARING and the access-control model | SECURITY-WP-0001-T07 |
| Federation interface card declaring Auth Mode as an export | SECURITY-WP-0001-T04 |
| Orientation surfaces: vocabulary card, design heuristic, disambiguation page | SECURITY-WP-0001-T06 |
InfoTechCanon artifacts this canon references rather than absorbs:
| Path in info-tech-canon | Relationship |
|---|---|
infospace/standards/caring/ |
implementation layer; imports the vocabulary |
infospace/models/access-control/ |
owns Subject, Principal, IdentityReference |
infospace/models/identity/ |
shared root; stays upstream |
infospace/models/security/ |
boundary under review in SECURITY-WP-0001-T02 |
infospace/models/devsecops/ |
boundary under review in SECURITY-WP-0001-T02 |
Open questions, carried and not assumed:
- whether the security and DevSecOps models are better placed here or upstream — the only remaining migration candidates, and neither is urgent;
- how the small-saas profile's security artifacts relate to this canon;
- the Actor/Subject naming question, analysed in
the implications note and decided
under
SECURITY-WP-0001-T07.
Exclusions and evolution
No service surface is in scope, now or later: SEC-ADR-001 D4 settles that SecurityCanon reuses InfoTechCanon's service rather than shipping its own. A check that does not exist is a change request against InfoTechCanon.
A dedicated identity or personhood canon may eventually be right. It is deferred and belongs to no current workplan.