diff --git a/decisions/decisions.md b/decisions/decisions.md index b99f723..97309ca 100644 --- a/decisions/decisions.md +++ b/decisions/decisions.md @@ -25,3 +25,17 @@ created: '2026-09-20T19:42:12.263921Z' updated: '2026-09-20T19:42:12.263921Z' state_hub_decision_id: "7717592b-70cf-43fc-986e-d208d1641f49" ``` + +## SECURITY-DEC-2026-003 — Concept placement: ten declared imports, no migration, identity model is a shared root + +```yaml +id: SECURITY-DEC-2026-003 +kind: decision +title: 'Concept placement: ten declared imports, no migration, identity model is a + shared root' +status: accepted +created: '2026-09-20T20:20:00.000000Z' +updated: '2026-09-20T20:20:00.000000Z' +state_hub_decision_id: "054e60cc-c8df-4335-83d4-28fd438bb0a8" +``` + diff --git a/infospace/interfaces/README.md b/infospace/interfaces/README.md index d230fc6..28bc92e 100644 --- a/infospace/interfaces/README.md +++ b/infospace/interfaces/README.md @@ -25,3 +25,7 @@ The G7 validator in `prj-canon-federation` currently pins card paths for info-tech-canon, commerce-canon and the-custodian. Adding `security-canon` to `CARD_PATHS` is that project's change to make; this card is written to satisfy the same contract in the meantime. + +Concept placement across the two canons — one owning canon and one import +direction per shared concept — is recorded in +[concept-placement.md](concept-placement.md) (SECURITY-DEC-2026-003). diff --git a/infospace/interfaces/concept-placement.md b/infospace/interfaces/concept-placement.md new file mode 100644 index 0000000..ba23b5a --- /dev/null +++ b/infospace/interfaces/concept-placement.md @@ -0,0 +1,97 @@ +# Concept placement — SecurityCanon and InfoTechCanon + +Status: decided for the concepts listed below, recorded as SECURITY-DEC-2026-003. +Date: 2026-09-20. Narrowed by SEC-ADR-001 (SECURITY-DEC-2026-001), which already +settles that CARING, the identity model and the access-control model stay in +InfoTechCanon, and by SECURITY-DEC-2026-002, which settles the terminology +separation. + +Scope of this record: one row per concept that appears in both layers, naming the +single owning canon and the import direction. It does not create, rename or +remove a concept in either canon. + +Pinned import source: info-tech-canon at +`e1f98da015f32545254747c8e9f59b780c423d5b`, as declared in +`infospace/vocabulary/mode-of-authority/imports.json`. + +## Placement table + +| Concept | Owning canon | Owning artifact | Direction | Note | +| --- | --- | --- | --- | --- | +| Artifact | InfoTechCanon | InfoTechCanonCore | ITC → SC (import) | Shared root. | +| Ownership | InfoTechCanon | InfoTechCanonCore | ITC → SC (import) | Shared root. | +| Relationship | InfoTechCanon | InfoTechCanonCore | ITC → SC (import) | Shared root. | +| Actor | InfoTechCanon | Organization Model | ITC → SC (import) | SC does not redefine it; its on-behalf-of dimension is `AuthorityContext`. | +| Subject | InfoTechCanon | ITC-ACCESS | ITC → SC (import) | Bound as "the access-control view of an actor". SC references, never redefines. | +| Principal | InfoTechCanon | ITC-ACCESS | ITC → SC (import) | | +| PrincipalType | InfoTechCanon | Identity Model | ITC → SC (import) | The identity model is a shared root, not security terminology. | +| Scope | InfoTechCanon | ITC-ACCESS | ITC → SC (import) | ITC-ACCESS is the single definition. See residual R-1. | +| AccessOperations | InfoTechCanon | ITC-ACCESS | ITC → SC (import) | Orthogonal to Auth Mode: `read + USE` and `read + OBSERVE` share an operation. | +| Purpose | InfoTechCanon | Purpose and Demand extension | ITC → SC (import) | Resolves to the extension, not to a SecurityCanon definition. | +| Canonical Role | InfoTechCanon | CARING | ITC-only | `Operator` the role and `OPERATE` the auth mode are different axes; neither is renamed. | +| Plane | InfoTechCanon | CARING | ITC-only | Names a surface. `Build Plane` and `CONSTRUCT` stay distinct. | +| Condition | InfoTechCanon | CARING | ITC-only | Overlaps `Activation` in intent; both stand, neither is aliased. | +| Capability | InfoTechCanon | Capability Model / CARING | ITC-only | Richer than AccessOperations; no SC counterpart. | +| Audit Plane | InfoTechCanon | CARING | ITC-only | A surface, not a trust question. Distinct from `EvidenceBoundary`. | +| AuthMode | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned, exportable | Published for import; InfoTechCanon declares no import of it today. | +| AuthorityContext | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | The on-behalf-of dimension, renamed away from Actor/Subject. | +| AuthorityRealm | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | | +| AuthorityProvenance | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | | +| Activation | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | `STANDING`, `JIT`, `APPROVED`, `INCIDENT`, `BREAK_GLASS`, `RECOVERY`. | +| EvidenceBoundary | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | "Can the observed actor alter, suppress or bypass its own evidence?" | +| AccessSituation | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | | +| Environment | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | | +| Time | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | Dimension slot only; no upstream time model is claimed. | + +**Declared imports are closed at this list.** The ten InfoTechCanon concepts +marked `ITC → SC` are exactly those in `imports.json`. Any further InfoTechCanon +concept SecurityCanon comes to need must be added there with a pinned blob hash +before it is used, not referenced informally. + +## Migration candidates — recommendation + +The default is to leave an artifact upstream unless moving it demonstrably helps +both canons. Neither remaining candidate meets that bar. + +- **Security model (`ITC-SEC`) — stays in InfoTechCanon.** It is a domain model + of the shared spine: threat, weakness, vulnerability, exposure, finding, risk, + incident, control, detection and response, wired to governance, task, landscape + and organization. SecurityCanon's contribution is an authority vocabulary, not + a posture model, and would inherit eleven upstream imports to re-pin for no + semantic gain. SecurityCanon references it; it does not host it. +- **DevSecOps model (`ITC-DEVSECOPS`) — stays in InfoTechCanon.** It is delivery + vocabulary that is only incidentally security-flavoured — repositories, + branches, builds, attestation, release, deploy, verify. Moving it would split + delivery semantics from the repository-layout standard and the evidence model + that sit beside it. + +With both candidates resolved upstream, no artifact migrates. This is consistent +with SECURITY-WP-0001-T05, the migration handoff, having been cancelled. + +## Open boundary questions — answers + +- **Is the identity model security terminology or a shared root?** A shared + root. It is imported by the access-control model and exercised by the + small-saas profile's user and tenant artifacts well outside security + reasoning. SecurityCanon imports `PrincipalType` from it and nothing else. +- **How do the small-saas profile's policy, control, evidence and incident + artifacts split?** They do not split. The profile is InfoTechCanon's + end-to-end proof of its own models and stays whole. If SecurityCanon needs a + worked example of Auth Mode, it publishes its own profile that references those + artifacts by id across the federation interface rather than relocating them. +- **Which InfoTechCanon concepts become declared imports rather than moves?** + The ten listed above. No concept is transferred in either direction by this + record. +- **Does the Actor/Subject split replace CARING's Subject dimension?** No — + settled by SECURITY-DEC-2026-002. SecurityCanon renamed its own dimension to + `AuthorityContext`; CARING is not rewritten. + +## Residuals + +- **R-1 — CARING `Scope` and ITC-ACCESS `Scope`.** The review found two + definitions of one concept inside InfoTechCanon. This record names ITC-ACCESS + as the owner; reconciling CARING's wording to it is an InfoTechCanon-internal + change and is not made here. +- **R-2 — CARING section 32 generalisation.** Referenced by SecurityCanon, + explicitly not accepted by the InfoTechCanon-side boundary review. It remains + an InfoTechCanon proposal requiring its own review. diff --git a/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md b/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md index 0ecc4d0..08059c2 100644 --- a/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md +++ b/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md @@ -60,7 +60,7 @@ running `statehub fix-consistency` — never by hand. ```task id: SECURITY-WP-0001-T02 -status: todo +status: done priority: high state_hub_task_id: "8b9e4cd0-9905-5ae8-9a23-8957110d72e4" ``` @@ -264,3 +264,41 @@ the-custodian only, so this card is written to the same contract but is not yet registered there; adding it is prj-canon-federation's change to make, and the card records that. The boundary acceptance is an agent review, not human sign-off, and records no consumer adoption or conformance claim. + +## Result — 2026-09-20 (T02) + +Concept placement decided and recorded as SECURITY-DEC-2026-003 in +`decisions/decisions.md`, with the full record at +`infospace/interfaces/concept-placement.md`. + +The placement table carries 25 rows: 10 InfoTechCanon concepts declared as +imports (Artifact, Ownership, Relationship, Actor, Subject, Principal, +PrincipalType, Scope, AccessOperations, Purpose), 5 InfoTechCanon CARING and +capability concepts that stay upstream with no SecurityCanon counterpart +(Canonical Role, Plane, Condition, Capability, Audit Plane), and 9 SecurityCanon +concepts (AuthMode, AuthorityContext, AuthorityRealm, AuthorityProvenance, +Activation, EvidenceBoundary, AccessSituation, Environment, Time). The declared +import list is closed at what `imports.json` pins; further needs must be added +there with a blob hash before use. + +Both remaining migration candidates stay upstream. The security model is a +posture model of the shared spine with eleven upstream imports and no semantic +gain from moving; the DevSecOps model is delivery vocabulary that is only +incidentally security-flavoured and sits beside the repository-layout standard +and the evidence model. No artifact migrates, consistent with T05 having been +cancelled. + +The open boundary questions are answered rather than assumed: the identity model +is a shared root (SecurityCanon imports PrincipalType only); the small-saas +policy, control, evidence and incident artifacts do not split and stay whole, +with any SecurityCanon example referencing them by id across the federation +interface; declared imports replace moves in both directions. + +Two residuals are recorded, both InfoTechCanon-internal and neither made here: +R-1, CARING `Scope` and ITC-ACCESS `Scope` are two definitions of one concept +and ITC-ACCESS is named the owner; R-2, the CARING section 32 generalisation +remains an unaccepted InfoTechCanon proposal. + +Limits. This is an agent decision recorded on the SecurityCanon side and +reflected in InfoTechCanon's accepted boundary; it is not separate human +sign-off, and it records no consumer adoption or conformance claim.