diff --git a/history/2026-09-20_235357+0200-caring-32-generalisation.md b/history/2026-09-20_235357+0200-caring-32-generalisation.md new file mode 100644 index 0000000..244cd8b --- /dev/null +++ b/history/2026-09-20_235357+0200-caring-32-generalisation.md @@ -0,0 +1,80 @@ +# CARING section 32 generalisation — review and decision + +Date: 2026-09-20 (Europe/Berlin) +Residual: R-2, raised by the SecurityCanon boundary review and explicitly not +accepted there, "an InfoTechCanon change requiring its own review". +Decision: **INFO-DEC-2026-001 — accept, narrowly.** + +## The proposal + +SecurityCanon's implications note, section 4, offers three options for the +CARING section 32 role set — Principal, effective actor, Delegator, tool or +agent, policy ceiling, execution context, audit identity — which section 32 +scopes with the words "For non-human subjects". + +| Option | Description | Their assessment | +| --- | --- | --- | +| A | Leave CARING unchanged; SecurityCanon maps into it. | Viable, zero upstream cost, leaves a real gap. | +| B | Drop the non-human scoping; the roles apply to any subject. | Recommended if and when InfoTechCanon wants it. Additive and non-breaking. | +| C | Promote actor and authority context to a twelfth CARING dimension. | Premature; sections 32 and 33 already cover the cases. | + +SecurityCanon raised B as a demand signal and stated that nothing in its own +work blocks on the outcome. That is the correct handling under SEC-ADR-001 and +is why this review is free to decide on the merits rather than under pressure. + +## Assessment + +**The gap is real and is not about agents.** A support operator impersonating a +customer involves no non-human subject anywhere in the path. Without the role +decomposition, that operator's audit identity and policy ceiling collapse into +the customer's — which is precisely the outcome CARING's own exposure analysis +exists to prevent. CARING already names the case: "Customer impersonation" is an +exposure mode and `ImpersonationBlocked` is a control. The vocabulary for +analysing it was gated to subjects the case does not involve. + +**Section 33 is already subject-agnostic.** It classifies access by execution +path — direct, delegated, mediated, induced — and its definitions speak of "the +subject" without qualification. Only its examples are agent-flavoured. So the +canon already applies the *paths* to any subject while restricting the *roles* +along those paths to non-human ones. That asymmetry is not a considered position; +it is an artifact of section 32 having been written under an agent-focused +heading. + +**Option C is correctly rejected.** A twelfth dimension would duplicate sections +32 and 33, and CARING's dimension set is load-bearing for the Kubernetes RBAC +benchmark and the descriptor work. Adding to it is a heavier change than this +gap justifies. + +**Option A is defensible and was the status quo for a reason.** CARING is a +release candidate, and the conservative move is to leave it alone. The argument +against A is that the gap is in the standard, not in SecurityCanon: leaving it +means the canon has vocabulary for agent impersonation and none for human +impersonation, and any consumer meeting the human case has to invent it. + +## Decision + +Accept **Option B, narrowly scoped**: + +- Section 32's role set now applies where a subject's access is exercised + **through another party**, rather than to non-human subjects only. +- Section 32.1, the Agent Access Formula, stays where it is and stays agent- + stated, since the capability ceiling is a property of the tool. A note says how + to read it for a human effective actor. +- No role is removed, renamed or added. Section 33 is untouched. +- Canon version moves from `0.4.0-RC2-itc1` to `0.4.0-RC2-itc2`. Source version + stays `0.4.0-RC2`: this is an InfoTechCanon-side revision of an aligned + standard, not a claim about upstream CARING. + +## Compatibility + +Additive and non-breaking. An implementation that applied the role set only to +non-human subjects remains conformant for those subjects; it simply now has +vocabulary for a case it previously had to describe by analogy. Nothing that was +required becomes optional, and nothing optional becomes required. + +## Limits + +This is an agent review, not human sign-off, and it records no consumer +adoption. It generalises the scope of an existing role set; it does not add the +on-behalf-of relation that the access-control model still lacks, which the +SecurityCanon mapping table records as a blank cell and which remains open. diff --git a/infospace/interfaces/security-canon-boundary.md b/infospace/interfaces/security-canon-boundary.md index 6573ab5..f55b51a 100644 --- a/infospace/interfaces/security-canon-boundary.md +++ b/infospace/interfaces/security-canon-boundary.md @@ -64,9 +64,12 @@ 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. +- 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. diff --git a/infospace/standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md b/infospace/standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md index 01c0295..568bba0 100644 --- a/infospace/standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md +++ b/infospace/standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md @@ -60,7 +60,7 @@ updated_at: 2026-05-23 **CARING:** Canonical Access Roles for Information Needs Governance **Document Status:** Release Candidate, InfoTechCanon-aligned refactor **Source Version:** 0.4.0-RC2 -**Canon Version:** 0.4.0-RC2-itc1 +**Canon Version:** 0.4.0-RC2-itc2 **Document Type:** Specialized InfoTechCanon Standard **Recommended Repository Path:** `standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md` @@ -3321,7 +3321,8 @@ If a namespace is used as a tenant boundary, the analysis must verify whether th CARING treats agents, automations, and services as first-class subjects. -For non-human subjects, access must distinguish: +Where a subject's access is exercised **through another party**, access must +distinguish: ```text @@ -3341,8 +3342,25 @@ Audit identity ``` +This role set was written for non-human subjects and generalised to any subject +in canon version 0.4.0-RC2-itc2, under INFO-DEC-2026-001. The motivating case is +human-on-human: a support operator impersonating a customer involves no agent at +all, yet without this decomposition the operator's audit identity and policy +ceiling collapse into the customer's. Section 33 classifies the execution paths +— delegated, mediated, induced — over which the role set applies, and it is +already subject-agnostic. + +The generalisation is additive. No role is removed or renamed, the formula in +32.1 generalises unchanged, and an implementation that applied the set only to +non-human subjects remains conformant for those subjects. + ### 32.1 Agent Access Formula +The formula below is stated for the agent case, where the capability ceiling is +a property of the tool. For a human effective actor, read the ceiling as the +impersonating operator's own policy ceiling. + + ```text Effective Agent Access =