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
72 lines
3.4 KiB
Markdown
72 lines
3.4 KiB
Markdown
# SCOPE
|
|
|
|
Reviewed: 2026-09-20 (Europe/Berlin), after [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md).
|
|
|
|
## Current repository scope
|
|
|
|
Bootstrap. The repository carries governance files — INTENT, SCOPE, AGENTS,
|
|
repo classification — the [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md)
|
|
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](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](docs/260920-actor-subject-implications.md) 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.
|