security-canon/docs/260920-actor-subject-implications.md

id	type	title	repo	status	created	relates_to	carried_by
SEC-NOTE-260920	analysis	Implications of the Actor/Subject split for CARING and the access-control model	security-canon	for-discussion	2026-09-20	SEC-ADR-001	SECURITY-WP-0001-T07

Implications of the Actor/Subject split

Question 3 of the Mode of Authority assessment, left open by SEC-ADR-001 for review and discussion. This note does not decide it.

1. What MoA proposes

MoA §19–20 splits the acting entity from the authority context:

actor   = support-agent      ← the entity performing the action
subject = customer-123       ← whose authority context is being used
relation = IMPERSONATED      ← or DELEGATED

The claim is that actor = subject is the normal case but not the universal one, and that delegation, impersonation, service accounts, token exchange and agentic automation all depend on being able to say so.

The claim is correct. The problem is entirely one of naming.

2. The finding that reframes the question

The split already exists downstream — twice — under different names.

InfoTechCanon access-control model §11.2

Subject is the access-control view of an actor.
Actor semantics are owned by the Organization Model.

So InfoTechCanon already owns both words, and binds them in a specific relationship: Subject is a view of Actor. Actor is owned by the Organization Model, not by access control at all.

MoA uses the same two words for a different relationship: Actor and Subject are two distinct parties, one acting on behalf of the other.

This is not an overlap that can be papered over. Under SEC-ADR-001 D2 — related concepts at different layers must not share a word for different things — this is the clearest violation in the entire vocabulary, and it is MoA's to fix, because InfoTechCanon owns the terms and owned them first.

CARING §32

For non-human subjects, CARING already distinguishes:

Principal
Effective actor
Delegator
Tool or agent
Policy ceiling
Execution context
Audit identity

with an explicit agent access formula:

Effective Agent Access =
    Delegated Human/System Authority
  ∩ Agent Capability Ceiling
  ∩ Scope Boundary
  ∩ Exposure Policy

and it classifies execution paths as Direct, Delegated, Mediated and Induced (§33), with an ImpersonationBlocked restriction (§29).

CARING therefore does not lack the distinction. It has a richer one than MoA — Delegator, audit identity, capability ceiling, induced paths — but it is scoped to non-human subjects and expressed as a formula rather than as a general dimension.

Consequence

The original framing — "does MoA's split replace CARING's single Subject dimension?" — rests on a false premise. CARING's Subject dimension is not single; §32 and §33 already carry the split. The real questions are narrower:

1. What does MoA call its two parties, given InfoTechCanon owns Actor and Subject with a different meaning?
2. Should CARING's §32 vocabulary be generalised beyond non-human subjects?

3. Options for question 1 — naming

Option	Description	Assessment
A. MoA adopts the downstream names	Use CARING's Principal / Effective actor / Delegator.	Rejected. Imports implementation vocabulary into the architecture layer, which inverts the layering SEC-ADR-001 D2 establishes.
B. MoA renames its second term	Keep Actor; rename MoA's Subject to something unambiguous — Authority Context, Mandate Source, or On-Behalf-Of Party.	Recommended. Smallest change, no upstream churn, and it removes the collision at its source. Actor survives because MoA's use is compatible with the Organization Model's ownership of actor semantics.
C. Change InfoTechCanon	Redefine Subject upstream so both readings align.	Rejected. Edits a release-candidate standard and eleven dependent models to accommodate a draft. Contradicts D1's "help, not hinder".
D. Document and live with it	Keep both meanings, add a disambiguation page.	Rejected as a primary answer. A disambiguation page is needed regardless, but it is not a substitute for not having the collision.

Under option B, the MoA notation becomes:

support-agent:
  USE @ tenant/acme
  authority_context = customer-42
  relation = IMPERSONATED

Authority Context is preferred over the alternatives because it names what the field actually holds — the authority being drawn on — rather than a party, which keeps it true when the on-behalf-of target is a role or a mandate rather than a person.

4. Options for question 2 — generalising CARING §32

The split matters for human-on-human cases too: a support agent impersonating a customer involves no non-human subject, yet needs exactly the same treatment.

Option	Description	Assessment
A. Leave CARING unchanged	Non-human scoping stands; SecurityCanon maps into it.	Viable. Zero upstream cost. Leaves a real gap for human impersonation.
B. Generalise the §32 role set	Drop "for non-human subjects"; the roles apply to any subject.	Recommended, if and when InfoTechCanon wants it. Additive, non-breaking, and the formula already generalises unchanged.
C. Add a full dimension	Promote actor/authority-context to a twelfth CARING dimension.	Premature. §32 and §33 cover the cases; a new dimension would duplicate them.

Option B is an InfoTechCanon change, not a SecurityCanon one. Per SEC-ADR-001 it should be raised as a demand signal against InfoTechCanon and accepted on its own merits, not bundled into SecurityCanon's vocabulary work. Nothing in SecurityCanon blocks on it.

5. What SecurityCanon does regardless of the outcome

Independent of both questions, the vocabulary promotion (SECURITY-WP-0001-T06) must publish a mapping table at the boundary, because three vocabularies describe these entities today and readers will meet all three:

MoA (architecture)	ITC access control	CARING (implementation)
Actor	Subject / Principal	Principal, Effective actor
Authority Context (proposed)	—	Delegator
relation = DELEGATED	—	Delegated Access (§33.2)
relation = IMPERSONATED	—	Customer impersonation; ImpersonationBlocked
—	—	Audit identity, capability ceiling

The blank cells are informative: MoA has no notion of a capability ceiling, and InfoTechCanon's access-control model has no on-behalf-of relation at all. Neither gap is urgent, and neither is a reason to move content between canons.

6. Recommendation

Adopt 3B — rename MoA's second party to Authority Context — and treat 4B as a separate, optional demand signal against InfoTechCanon. Publish the mapping table in §5 as part of the vocabulary promotion either way.

This keeps the collision out of the canon without touching a release-candidate standard, which is what SEC-ADR-001 D1 and D2 jointly ask for.