73 lines
4 KiB
Markdown
73 lines
4 KiB
Markdown
|
# SecurityCanon extension boundary
|
||
|
|
|
||
|
|
Status: accepted for the semantic boundary documented below, reviewed by Claude
|
||
|
|
in the InfoTechCanon repository on 2026-09-20. This is an agent review, not a
|
||
|
|
claim of separate human sign-off or a published peer merge.
|
||
|
|
|
||
|
|
Review target: security-canon draft 0.2.0 at
|
||
|
|
`b1fa25ebe3204b5da0febf70190533711c19fbce`.
|
||
|
|
InfoTechCanon review base and import source:
|
||
|
|
`e1f98da015f32545254747c8e9f59b780c423d5b`.
|
||
|
|
|
||
|
|
SecurityCanon supplies an architecture-layer vocabulary for authority
|
||
|
|
relationships — the Mode of Authority — and references shared InfoTechCanon
|
||
|
|
concepts. InfoTechCanon retains the shared roots, the access-control model, the
|
||
|
|
identity model, and the CARING access governance standard.
|
||
|
|
|
||
|
|
## Accepted dispositions
|
||
|
|
|
||
|
|
- **Layer separation.** Mode of Authority describes the relationship in which
|
||
|
|
authority is exercised; CARING analyses how an access-control implementation is
|
||
|
|
composed. Both may describe the same system without either subsuming the
|
||
|
|
other. Recorded on the SecurityCanon side as SEC-ADR-001.
|
||
|
|
- **Auth Mode is orthogonal to access operation.** `read + USE` and
|
||
|
|
`read + OBSERVE` share an operation and differ in authority relationship.
|
||
|
|
AccessOperations remains owned by ITC-ACCESS and is imported, not redefined.
|
||
|
|
- **Auth Mode is orthogonal to CARING Canonical Role and Plane.** The three
|
||
|
|
answer different questions. The CARING `Operator` role and the `OPERATE` auth
|
||
|
|
mode are not the same concept and neither is renamed; a disambiguation page in
|
||
|
|
SecurityCanon is the required companion.
|
||
|
|
- **Actor/Subject is not reused.** ITC-ACCESS owns `Subject` and binds it as
|
||
|
|
"Subject is the access-control view of an actor", with actor semantics owned by
|
||
|
|
the Organization Model. SecurityCanon renamed its on-behalf-of dimension to
|
||
|
|
`AuthorityContext` rather than overloading either word. No change is required
|
||
|
|
in InfoTechCanon.
|
||
|
|
- **Scope, AccessOperations, PrincipalType and Purpose are imports.** They retain
|
||
|
|
their InfoTechCanon owners. Purpose resolves to the Purpose and Demand
|
||
|
|
extension rather than being defined in SecurityCanon.
|
||
|
|
- **EvidenceBoundary is a new concept, not an alias of the CARING Audit Plane.**
|
||
|
|
The Audit Plane names a surface; EvidenceBoundary asks whether the observed
|
||
|
|
actor can alter, suppress or bypass the evidence used to observe it.
|
||
|
|
- **No InfoTechCanon concept is transferred.** This boundary creates no removal,
|
||
|
|
relocation or deprecation in InfoTechCanon, so the InfoTechCanon corpus is
|
||
|
|
unchanged by it.
|
||
|
|
|
||
|
|
## Evidence and limits
|
||
|
|
|
||
|
|
Reviewed `infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md`,
|
||
|
|
`auth-modes.yaml`, `dimensions.yaml`, `imports.json`,
|
||
|
|
`infospace/mappings/mode-of-authority-to-infotechcanon.md` and
|
||
|
|
`infospace/interfaces/federation.yaml` at the SecurityCanon revision above.
|
||
|
|
|
||
|
|
All five manifest SHA-256 values match Git blobs at the declared InfoTechCanon
|
||
|
|
source revision, and those files are unchanged in the review checkout:
|
||
|
|
InfoTechCanonCore, InfoTechCanonAccessControlModel, InfoTechCanonIdentityModel,
|
||
|
|
InfoTechCanonOrganizationModel, and InfoTechCanonPurposeDemandExtension.
|
||
|
|
|
||
|
|
None of the seven concepts SecurityCanon declares — AuthMode, AuthorityContext,
|
||
|
|
AuthorityRealm, AuthorityProvenance, Activation, EvidenceBoundary,
|
||
|
|
AccessSituation — appears in any InfoTechCanon `owned_concepts` declaration, so
|
||
|
|
this boundary introduces no ownership conflict.
|
||
|
|
|
||
|
|
Limits of this acceptance:
|
||
|
|
|
||
|
|
- Scoped to SecurityCanon draft 0.2.0. No stable promotion is asserted.
|
||
|
|
- Acceptance covers the semantic boundary and import declarations. It records no
|
||
|
|
consumer adoption, no runtime claim, and no conformance statement.
|
||
|
|
- A proposal to generalise CARING section 32 beyond non-human subjects is
|
||
|
|
referenced by SecurityCanon but is **not** accepted here. It would be an
|
||
|
|
InfoTechCanon change requiring its own review.
|
||
|
|
- The G7 validator in `prj-canon-federation` pins card paths for
|
||
|
|
info-tech-canon, commerce-canon and the-custodian. Registering the
|
||
|
|
security-canon card is that project's change; this review does not make it.
|