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
import-review takes any partner manifest and returns, per concept, whether the
name resolves in the ownership index and to which artifact, and per entry
whether the pinned SHA-256 matches the blob at the declared source commit. Both
run in one pass so neither can be recorded without the other, which is the
failure this workplan exists to prevent. It exits non-zero on a finding, reads
JSON or YAML, needs no partner checkout, and carries its own limit: resolution
proves a name exists and names one owner, nothing more.
Accepted manifests are registered under infospace/interfaces/manifests/ as
provenance-preserving copies owned by the partner, with the partner revision and
retrieval date recorded. Editing a copy to make a check pass is forbidden in the
file itself. Validation re-resolves them and reports drift as
federation_import_drift, a warning naming the partner rather than an error,
because a stale partner pin is not this repository's file to fix.
The review kit gains an extension-boundary-review template requiring hash count,
resolution count and conflict count as three separate lines, and an operating
rule saying one is never evidence of another. Both boundary files carry the
standing-check result.
Verified live: security-canon resolves 11 of 11, interface-canon 23 of 25 with
the two known Interface and Endpoint pins. make check passes with 58 tests,
clean validation and those two warnings.
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
Neither boundary has an ownership conflict now that declarations cover the
corpus, so the central claim of both acceptances holds. Name resolution is a
different matter, and it had never been checked: both original reviews verified
their import manifests by file hash, every hash matched, and that was recorded
as evidence. A hash proves the reviewed file is the pinned file; it says nothing
about whether the concept named in the manifest exists in it.
SecurityCanon: five of twelve imports named concepts their pinned artifact does
not define, corrected on that side to eleven imports. InterfaceCanon: twenty-one
of twenty-five resolve exactly, and two of the four failures were this
repository's omission — SoftwareSystem and SoftwareComponent are Landscape seed
concepts that extraction cannot read and are now declared, making those pins
correct. Interface and Endpoint resolve to the Network Model, which the accepted
clarifications already treat as contextual rather than exact aliases; those pins
are InterfaceCanon's to correct.
Both boundary files carry the re-verification and its method limit.
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
SecurityCanon publishes an architecture-layer vocabulary for authority
relationships, the Mode of Authority, and references shared InfoTechCanon
concepts. This records the InfoTechCanon-side acceptance of that boundary and
adds reciprocal navigation from the federation interface README.
The accepted dispositions keep the layers apart. Mode of Authority describes the
relationship in which authority is exercised; CARING analyses how an
access-control implementation is composed. Auth Mode is orthogonal to access
operation and to CARING's Canonical Role and Plane, so the Operator role and the
OPERATE mode stay distinct concepts and neither is renamed. SecurityCanon does
not reuse Actor or Subject, which ITC-ACCESS owns and binds as "Subject is the
access-control view of an actor"; it renamed its on-behalf-of dimension to
AuthorityContext instead, so no change is required here.
Verified at security-canon b1fa25eb: all five pinned manifest hashes match Git
blobs at this commit and the sources are unchanged in the review checkout, and
none of the seven concepts SecurityCanon declares appears in any InfoTechCanon
owned_concepts declaration, so the boundary introduces no ownership conflict.
No concept is transferred and nothing is removed, so the corpus is unchanged.
Generated indexes and the repository tree are refreshed for the added file;
make check passes with 46 tests, clean validation and a passing small-saas
profile. This is an agent review, not human sign-off, and it records no consumer
adoption or conformance claim.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AUkN13CAqtXWPXuEiEtmJj
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 36656@bnt-lap001
Assistant-Session: 66d6eece-d245-43ca-85e8-68a1b5970a67
