tegwick
30cf417a18
The role set — Principal, effective actor, Delegator, tool or agent, policy ceiling, execution context, audit identity — now applies wherever a subject's access is exercised through another party, rather than to non-human subjects only. The gap this closes is not about agents. A support operator impersonating a customer involves no non-human subject anywhere in the path, yet without the decomposition that operator's audit identity and policy ceiling collapse into the customer's, which is the outcome CARING's exposure analysis exists to prevent. CARING already names customer impersonation as an exposure mode and ImpersonationBlocked as a control; the vocabulary for analysing it was gated to subjects the case does not involve. Section 33 was already subject-agnostic, so the canon applied the execution paths to any subject while restricting the roles along those paths to non-human ones — an artifact of the section heading, not a considered position. Accepted narrowly. Section 32.1 stays agent-stated, with a note on reading the capability ceiling for a human effective actor. No role is removed, renamed or added, and section 33 is untouched. Option C, a twelfth dimension, is rejected as duplicating sections 32 and 33 while touching a dimension set the Kubernetes RBAC benchmark depends on. Canon version moves to 0.4.0-RC2-itc2; source version stays 0.4.0-RC2, since this revises the InfoTechCanon-aligned standard and claims nothing about upstream CARING. The change is additive: an implementation that applied the set only to non-human subjects stays conformant for those subjects. Review record in history/; the SecurityCanon boundary file and placement record are updated to show R-2 resolved. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 3588@bnt-lap001 Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
124 lines
7.3 KiB
Markdown
124 lines
7.3 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 was
|
|
referenced by SecurityCanon and not accepted at the time of this review. It
|
|
was reviewed separately on 2026-09-20 and **accepted** as INFO-DEC-2026-001;
|
|
see `history/2026-09-20_235357+0200-caring-32-generalisation.md`. CARING moves
|
|
to canon version 0.4.0-RC2-itc2. The change is additive and affects no
|
|
SecurityCanon declaration.
|
|
- 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.
|
|
|
|
## Re-verification — 2026-09-20 (INFO-WP-0027-T04)
|
|
|
|
Re-run against the enlarged InfoTechCanon ownership index (750 entries, up from
|
|
164) after INFO-WP-0027-T02 gave every defining artifact an `owned_concepts`
|
|
declaration. The original acceptance compared SecurityCanon's concepts against
|
|
the declarations that existed then; this re-runs it against declarations that
|
|
now cover the corpus.
|
|
|
|
**No ownership conflict.** None of the nine SecurityCanon-owned concepts —
|
|
AuthMode, AuthorityContext, AuthorityRealm, AuthorityProvenance, Activation,
|
|
EvidenceBoundary, AccessSituation, Time, and the dimension slot for Environment —
|
|
collides with an InfoTechCanon declaration. The boundary's central claim holds.
|
|
|
|
**Five of the twelve declared imports do not resolve by name.** The original
|
|
review verified the manifest by file hash, and every hash matched; it never
|
|
checked that the named concept exists in the named artifact. The enlarged index
|
|
makes that checkable:
|
|
|
|
| Import | Pinned to | Resolves to | Finding |
|
|
| --- | --- | --- | --- |
|
|
| `Artifact` | InfoTechCanonCore | `model/devsecops` | Core owns `CanonArtifact`, "any identifiable unit of canon content". There is no Core `Artifact`. The name now resolves to the DevSecOps build artifact, a different concept. |
|
|
| `Ownership` | InfoTechCanonCore | `model/organization` | The kernel map assigns Ownership and Stewardship to Organization. The pin names the wrong artifact. |
|
|
| `Relationship` | InfoTechCanonCore | `model/identity` | Core owns `RelationshipDefinition`; the identity model owns `Relationship` as its actor-linking taxonomy. The pin names the wrong artifact and arguably the wrong concept. |
|
|
| `AccessOperations` | InfoTechCanonAccessControlModel | unowned | ITC-ACCESS defines `Operation`, "a system-specific or API-specific action". `AccessOperations` is SecurityCanon's own compaction of it. |
|
|
| `PrincipalType` | InfoTechCanonIdentityModel | unowned | The name appears nowhere in the identity or access-control models. |
|
|
|
|
These are SecurityCanon-side manifest corrections, not InfoTechCanon changes. No
|
|
InfoTechCanon concept is renamed, moved or removed to accommodate them, and the
|
|
semantic boundary recorded above is unaffected: each case is a citation naming
|
|
the wrong artifact or a name InfoTechCanon never used, not a contested concept.
|
|
|
|
**Method limit, now closed.** Hash verification proves the reviewed file is the
|
|
file that was pinned. It says nothing about whether the concept named in the
|
|
manifest exists in it. Both checks are needed, and only the first was run in the
|
|
original acceptance.
|
|
|
|
|
|
## Standing check — 2026-09-20 (INFO-WP-0028)
|
|
|
|
This partner's import manifest is registered at
|
|
`infospace/interfaces/manifests/security-canon.json` as a provenance-preserving copy and is
|
|
re-resolved on every `make check`. Hash and name are checked together by
|
|
`info_tech_canon import-review`; a name that stops resolving, or resolves to a
|
|
different owner than the manifest pins, is reported as a
|
|
`federation_import_drift` warning naming this partner. It is a warning and not an
|
|
error because a stale partner pin is not this repository's file to fix.
|
|
|
|
Current result: **11 of 11 declared imports resolve**, all six pinned hashes match, no drift.
|