tegwick
8ab4891043
Insert DevOps Secrets Management Canon v1.0 unchanged, with a placement preface that keeps shared roots upstream. Publish it on the federation card. Assistant: grok Assistant-Session: 01a12ce1-7ded-7e03-a845-2ece8a573af4
89 lines
4.6 KiB
Markdown
89 lines
4.6 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.
|
|
|
|
It also publishes the DevOps Secrets Management Standard (`SEC-DSM` 1.0.0) at
|
|
`infospace/standards/devops-secrets-management/`. That standard states the
|
|
normative secrets-management practice. It does not operate custody, issue
|
|
credentials, or decide authorization. SECURITY-WP-0002 records the insertion.
|
|
|
|
## 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 custody and issuance — secrets-engine over OpenBao; operational
|
|
routing and SSH certificates — ops-warden. The practice those systems follow
|
|
is this canon's DevOps Secrets Management Standard; the operation stays theirs
|
|
- 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` |
|
|
| DevOps Secrets Management Standard (`SEC-DSM` 1.0.0) | `SECURITY-WP-0002` |
|
|
|
|
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.
|