81 lines
4.1 KiB
Markdown
81 lines
4.1 KiB
Markdown
|
# 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.
|