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
4.1 KiB
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-itc1to0.4.0-RC2-itc2. Source version stays0.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.