tegwick
9320e6569f
Assistant: codex Assistant-Model: gpt-6.1-sol Assistant-Session: 01a10238-7ecc-78e2-903d-075f50e913cc
82 lines
4.1 KiB
Markdown
82 lines
4.1 KiB
Markdown
# SCOPE
|
|
|
|
Reviewed: 2026-10-03 (Europe/Berlin), following the completed vocabulary work and [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md).
|
|
|
|
## Current repository scope
|
|
|
|
The repository publishes Mode of Authority draft 0.2.0 vocabulary artifacts,
|
|
mode/dimension catalogs, declared imports, a federation interface, cross-canon
|
|
mappings and orientation surfaces. SECURITY-WP-0001 is finished. The retained
|
|
v0.1 research draft is historical, not the current orientation artifact. There
|
|
is no service code; SEC-ADR-001 keeps validation in InfoTechCanon's service.
|
|
|
|
## 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 — access-engine (runtime/product flex-auth)
|
|
- login, OIDC, MFA — key-cape / Keycloak
|
|
- credential lifecycle — secrets-engine over OpenBao custody; operational
|
|
routing and SSH certificates — 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, answered under SECURITY-WP-0001 and no longer carried:
|
|
|
|
- the security and DevSecOps models stay in InfoTechCanon. Both were the only
|
|
remaining migration candidates and neither cleared the bar of demonstrably
|
|
helping both canons (SECURITY-DEC-2026-003);
|
|
- the small-saas profile's security artifacts stay whole in InfoTechCanon. A
|
|
SecurityCanon example references them by id across the federation interface
|
|
rather than relocating them;
|
|
- the Actor/Subject naming question, analysed in
|
|
[the implications note](docs/260920-actor-subject-implications.md) and decided
|
|
under `SECURITY-WP-0001-T07`: the on-behalf-of dimension is `AuthorityContext`
|
|
and no upstream concept is redefined.
|
|
|
|
Concept placement across the boundary — one owning canon and one import
|
|
direction per shared concept — is recorded in
|
|
[concept-placement.md](infospace/interfaces/concept-placement.md), with the
|
|
supporting survey of InfoTechCanon's existing authority vocabulary in
|
|
[infotechcanon-authority-survey.md](infospace/mappings/infotechcanon-authority-survey.md).
|
|
|
|
## 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.
|