2026-09-20 20:32:05 +02:00
|
|
|
# SCOPE
|
|
|
|
|
|
Re-scope SecurityCanon to architecture-layer vocabulary (SEC-ADR-001)
Owner decision of 2026-09-20 answering four of the five open questions from the
Mode of Authority assessment, recorded as SEC-DEC-0001 with the reasoning in
docs/adr-001-securitycanon-boundary.md.
CARING stays in InfoTechCanon: it is implementation-layer and imports eleven
InfoTechCanon models, and SecurityCanon should help rather than hinder keeping
InfoTechCanon practical. Identity stays a shared root, since pulling it in would
collapse too much into security and it reaches into personhood; a dedicated
identity or personhood canon is deferred, not rejected. Mode of Authority is
architecture where CARING is implementation — different layers of abstraction,
neither subsuming the other, but they must not use the same word for different
things. No service surface is duplicated: integration is uniform across
commerce-canon, interface-canon and security-canon through the canon-federation
interface card, and InfoTechCanon's service stays the only one.
Content migration is therefore no longer a goal. T02 narrows from a disposition
review to concept placement, T03 becomes a non-collision survey, and T05, the
migration workplan handoff, is cancelled. T06 gains the three-way mapping table
and T07 becomes the terminology separation decision.
The remaining open question is analysed in docs/260920-actor-subject-implications.md.
InfoTechCanon's access-control model already owns Actor and Subject and binds
them as "Subject is the access-control view of an actor", while Mode of Authority
uses the same two words for two distinct parties; and CARING already carries the
split for non-human subjects. The note recommends renaming Mode of Authority's
second party to Authority Context rather than changing a release-candidate
standard.
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
2026-09-20 21:34:45 +02:00
|
|
|
Reviewed: 2026-09-20 (Europe/Berlin), after [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md).
|
2026-09-20 20:32:05 +02:00
|
|
|
|
|
|
|
|
## Current repository scope
|
|
|
|
|
|
Re-scope SecurityCanon to architecture-layer vocabulary (SEC-ADR-001)
Owner decision of 2026-09-20 answering four of the five open questions from the
Mode of Authority assessment, recorded as SEC-DEC-0001 with the reasoning in
docs/adr-001-securitycanon-boundary.md.
CARING stays in InfoTechCanon: it is implementation-layer and imports eleven
InfoTechCanon models, and SecurityCanon should help rather than hinder keeping
InfoTechCanon practical. Identity stays a shared root, since pulling it in would
collapse too much into security and it reaches into personhood; a dedicated
identity or personhood canon is deferred, not rejected. Mode of Authority is
architecture where CARING is implementation — different layers of abstraction,
neither subsuming the other, but they must not use the same word for different
things. No service surface is duplicated: integration is uniform across
commerce-canon, interface-canon and security-canon through the canon-federation
interface card, and InfoTechCanon's service stays the only one.
Content migration is therefore no longer a goal. T02 narrows from a disposition
review to concept placement, T03 becomes a non-collision survey, and T05, the
migration workplan handoff, is cancelled. T06 gains the three-way mapping table
and T07 becomes the terminology separation decision.
The remaining open question is analysed in docs/260920-actor-subject-implications.md.
InfoTechCanon's access-control model already owns Actor and Subject and binds
them as "Subject is the access-control view of an actor", while Mode of Authority
uses the same two words for two distinct parties; and CARING already carries the
split for non-human subjects. The note recommends renaming Mode of Authority's
second party to Authority Context rather than changing a release-candidate
standard.
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
2026-09-20 21:34:45 +02:00
|
|
|
Bootstrap. The repository carries governance files — INTENT, SCOPE, AGENTS,
|
|
|
|
|
repo classification — the [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md)
|
|
|
|
|
boundary decision, the Mode of Authority review in `history/`, and one active
|
|
|
|
|
workplan. The only content is the Mode of Authority v0.1 research draft, not yet
|
|
|
|
|
promoted into a canon artifact. There is no service code, and by decision there
|
|
|
|
|
will be none.
|
2026-09-20 20:32:05 +02:00
|
|
|
|
|
|
|
|
## Ownership and boundaries
|
|
|
|
|
|
|
|
|
|
Following [INTENT.md](INTENT.md), SecurityCanon occupies the Taxonomy layer and
|
|
|
|
|
owns security concept definitions and their cross-canon mappings. It imports
|
|
|
|
|
shared roots from InfoTechCanon and does not redefine them.
|
|
|
|
|
|
|
|
|
|
Out of scope, with the owner named:
|
|
|
|
|
|
Re-scope SecurityCanon to architecture-layer vocabulary (SEC-ADR-001)
Owner decision of 2026-09-20 answering four of the five open questions from the
Mode of Authority assessment, recorded as SEC-DEC-0001 with the reasoning in
docs/adr-001-securitycanon-boundary.md.
CARING stays in InfoTechCanon: it is implementation-layer and imports eleven
InfoTechCanon models, and SecurityCanon should help rather than hinder keeping
InfoTechCanon practical. Identity stays a shared root, since pulling it in would
collapse too much into security and it reaches into personhood; a dedicated
identity or personhood canon is deferred, not rejected. Mode of Authority is
architecture where CARING is implementation — different layers of abstraction,
neither subsuming the other, but they must not use the same word for different
things. No service surface is duplicated: integration is uniform across
commerce-canon, interface-canon and security-canon through the canon-federation
interface card, and InfoTechCanon's service stays the only one.
Content migration is therefore no longer a goal. T02 narrows from a disposition
review to concept placement, T03 becomes a non-collision survey, and T05, the
migration workplan handoff, is cancelled. T06 gains the three-way mapping table
and T07 becomes the terminology separation decision.
The remaining open question is analysed in docs/260920-actor-subject-implications.md.
InfoTechCanon's access-control model already owns Actor and Subject and binds
them as "Subject is the access-control view of an actor", while Mode of Authority
uses the same two words for two distinct parties; and CARING already carries the
split for non-human subjects. The note recommends renaming Mode of Authority's
second party to Authority Context rather than changing a release-candidate
standard.
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
2026-09-20 21:34:45 +02:00
|
|
|
- the CARING access governance standard and its Kubernetes RBAC benchmark,
|
|
|
|
|
the access-control model, and the identity model — **InfoTechCanon**, by
|
|
|
|
|
SEC-ADR-001 D1 and D3
|
|
|
|
|
- any CLI, HTTP API, or validation service — **InfoTechCanon's service surface**,
|
|
|
|
|
by SEC-ADR-001 D4; integration is via the canon-federation interface card
|
2026-09-20 20:32:05 +02:00
|
|
|
- security architecture and standards of record for the estate — NetKingdom
|
|
|
|
|
- authorization decisions — flex-auth
|
|
|
|
|
- login, OIDC, MFA — key-cape / Keycloak
|
|
|
|
|
- secret custody and credential issuance — OpenBao, ops-warden
|
|
|
|
|
- adversarial evidence and findings practice — whitehat-security
|
|
|
|
|
- shared artifact/ownership/mapping/profile mechanisms — InfoTechCanon
|
|
|
|
|
- consumer runtime state, enforcement, observation, and adoption evidence — the consumers
|
|
|
|
|
|
|
|
|
|
## Planned scope
|
|
|
|
|
|
Re-scope SecurityCanon to architecture-layer vocabulary (SEC-ADR-001)
Owner decision of 2026-09-20 answering four of the five open questions from the
Mode of Authority assessment, recorded as SEC-DEC-0001 with the reasoning in
docs/adr-001-securitycanon-boundary.md.
CARING stays in InfoTechCanon: it is implementation-layer and imports eleven
InfoTechCanon models, and SecurityCanon should help rather than hinder keeping
InfoTechCanon practical. Identity stays a shared root, since pulling it in would
collapse too much into security and it reaches into personhood; a dedicated
identity or personhood canon is deferred, not rejected. Mode of Authority is
architecture where CARING is implementation — different layers of abstraction,
neither subsuming the other, but they must not use the same word for different
things. No service surface is duplicated: integration is uniform across
commerce-canon, interface-canon and security-canon through the canon-federation
interface card, and InfoTechCanon's service stays the only one.
Content migration is therefore no longer a goal. T02 narrows from a disposition
review to concept placement, T03 becomes a non-collision survey, and T05, the
migration workplan handoff, is cancelled. T06 gains the three-way mapping table
and T07 becomes the terminology separation decision.
The remaining open question is analysed in docs/260920-actor-subject-implications.md.
InfoTechCanon's access-control model already owns Actor and Subject and binds
them as "Subject is the access-control view of an actor", while Mode of Authority
uses the same two words for two distinct parties; and CARING already carries the
split for non-human subjects. The note recommends renaming Mode of Authority's
second party to Authority Context rather than changing a release-candidate
standard.
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
2026-09-20 21:34:45 +02:00
|
|
|
The near-term deliverable is the architecture-layer vocabulary, not a migration.
|
2026-09-20 20:32:05 +02:00
|
|
|
|
Re-scope SecurityCanon to architecture-layer vocabulary (SEC-ADR-001)
Owner decision of 2026-09-20 answering four of the five open questions from the
Mode of Authority assessment, recorded as SEC-DEC-0001 with the reasoning in
docs/adr-001-securitycanon-boundary.md.
CARING stays in InfoTechCanon: it is implementation-layer and imports eleven
InfoTechCanon models, and SecurityCanon should help rather than hinder keeping
InfoTechCanon practical. Identity stays a shared root, since pulling it in would
collapse too much into security and it reaches into personhood; a dedicated
identity or personhood canon is deferred, not rejected. Mode of Authority is
architecture where CARING is implementation — different layers of abstraction,
neither subsuming the other, but they must not use the same word for different
things. No service surface is duplicated: integration is uniform across
commerce-canon, interface-canon and security-canon through the canon-federation
interface card, and InfoTechCanon's service stays the only one.
Content migration is therefore no longer a goal. T02 narrows from a disposition
review to concept placement, T03 becomes a non-collision survey, and T05, the
migration workplan handoff, is cancelled. T06 gains the three-way mapping table
and T07 becomes the terminology separation decision.
The remaining open question is analysed in docs/260920-actor-subject-implications.md.
InfoTechCanon's access-control model already owns Actor and Subject and binds
them as "Subject is the access-control view of an actor", while Mode of Authority
uses the same two words for two distinct parties; and CARING already carries the
split for non-human subjects. The note recommends renaming Mode of Authority's
second party to Authority Context rather than changing a release-candidate
standard.
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
2026-09-20 21:34:45 +02:00
|
|
|
| Deliverable | Task |
|
2026-09-20 20:32:05 +02:00
|
|
|
| --- | --- |
|
Re-scope SecurityCanon to architecture-layer vocabulary (SEC-ADR-001)
Owner decision of 2026-09-20 answering four of the five open questions from the
Mode of Authority assessment, recorded as SEC-DEC-0001 with the reasoning in
docs/adr-001-securitycanon-boundary.md.
CARING stays in InfoTechCanon: it is implementation-layer and imports eleven
InfoTechCanon models, and SecurityCanon should help rather than hinder keeping
InfoTechCanon practical. Identity stays a shared root, since pulling it in would
collapse too much into security and it reaches into personhood; a dedicated
identity or personhood canon is deferred, not rejected. Mode of Authority is
architecture where CARING is implementation — different layers of abstraction,
neither subsuming the other, but they must not use the same word for different
things. No service surface is duplicated: integration is uniform across
commerce-canon, interface-canon and security-canon through the canon-federation
interface card, and InfoTechCanon's service stays the only one.
Content migration is therefore no longer a goal. T02 narrows from a disposition
review to concept placement, T03 becomes a non-collision survey, and T05, the
migration workplan handoff, is cancelled. T06 gains the three-way mapping table
and T07 becomes the terminology separation decision.
The remaining open question is analysed in docs/260920-actor-subject-implications.md.
InfoTechCanon's access-control model already owns Actor and Subject and binds
them as "Subject is the access-control view of an actor", while Mode of Authority
uses the same two words for two distinct parties; and CARING already carries the
split for non-human subjects. The note recommends renaming Mode of Authority's
second party to Authority Context rather than changing a release-candidate
standard.
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
2026-09-20 21:34:45 +02:00
|
|
|
| Mode of Authority promoted to a checkable Tier-1 artifact | `SECURITY-WP-0001-T06` |
|
|
|
|
|
| Terminology separation from CARING and the access-control model | `SECURITY-WP-0001-T07` |
|
|
|
|
|
| Federation interface card declaring Auth Mode as an export | `SECURITY-WP-0001-T04` |
|
|
|
|
|
| Orientation surfaces: vocabulary card, design heuristic, disambiguation page | `SECURITY-WP-0001-T06` |
|
2026-09-20 20:32:05 +02:00
|
|
|
|
Re-scope SecurityCanon to architecture-layer vocabulary (SEC-ADR-001)
Owner decision of 2026-09-20 answering four of the five open questions from the
Mode of Authority assessment, recorded as SEC-DEC-0001 with the reasoning in
docs/adr-001-securitycanon-boundary.md.
CARING stays in InfoTechCanon: it is implementation-layer and imports eleven
InfoTechCanon models, and SecurityCanon should help rather than hinder keeping
InfoTechCanon practical. Identity stays a shared root, since pulling it in would
collapse too much into security and it reaches into personhood; a dedicated
identity or personhood canon is deferred, not rejected. Mode of Authority is
architecture where CARING is implementation — different layers of abstraction,
neither subsuming the other, but they must not use the same word for different
things. No service surface is duplicated: integration is uniform across
commerce-canon, interface-canon and security-canon through the canon-federation
interface card, and InfoTechCanon's service stays the only one.
Content migration is therefore no longer a goal. T02 narrows from a disposition
review to concept placement, T03 becomes a non-collision survey, and T05, the
migration workplan handoff, is cancelled. T06 gains the three-way mapping table
and T07 becomes the terminology separation decision.
The remaining open question is analysed in docs/260920-actor-subject-implications.md.
InfoTechCanon's access-control model already owns Actor and Subject and binds
them as "Subject is the access-control view of an actor", while Mode of Authority
uses the same two words for two distinct parties; and CARING already carries the
split for non-human subjects. The note recommends renaming Mode of Authority's
second party to Authority Context rather than changing a release-candidate
standard.
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
2026-09-20 21:34:45 +02:00
|
|
|
InfoTechCanon artifacts this canon **references rather than absorbs**:
|
2026-09-20 20:32:05 +02:00
|
|
|
|
Re-scope SecurityCanon to architecture-layer vocabulary (SEC-ADR-001)
Owner decision of 2026-09-20 answering four of the five open questions from the
Mode of Authority assessment, recorded as SEC-DEC-0001 with the reasoning in
docs/adr-001-securitycanon-boundary.md.
CARING stays in InfoTechCanon: it is implementation-layer and imports eleven
InfoTechCanon models, and SecurityCanon should help rather than hinder keeping
InfoTechCanon practical. Identity stays a shared root, since pulling it in would
collapse too much into security and it reaches into personhood; a dedicated
identity or personhood canon is deferred, not rejected. Mode of Authority is
architecture where CARING is implementation — different layers of abstraction,
neither subsuming the other, but they must not use the same word for different
things. No service surface is duplicated: integration is uniform across
commerce-canon, interface-canon and security-canon through the canon-federation
interface card, and InfoTechCanon's service stays the only one.
Content migration is therefore no longer a goal. T02 narrows from a disposition
review to concept placement, T03 becomes a non-collision survey, and T05, the
migration workplan handoff, is cancelled. T06 gains the three-way mapping table
and T07 becomes the terminology separation decision.
The remaining open question is analysed in docs/260920-actor-subject-implications.md.
InfoTechCanon's access-control model already owns Actor and Subject and binds
them as "Subject is the access-control view of an actor", while Mode of Authority
uses the same two words for two distinct parties; and CARING already carries the
split for non-human subjects. The note recommends renaming Mode of Authority's
second party to Authority Context rather than changing a release-candidate
standard.
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
2026-09-20 21:34:45 +02:00
|
|
|
| Path in info-tech-canon | Relationship |
|
|
|
|
|
| --- | --- |
|
|
|
|
|
| `infospace/standards/caring/` | implementation layer; imports the vocabulary |
|
|
|
|
|
| `infospace/models/access-control/` | owns Subject, Principal, IdentityReference |
|
|
|
|
|
| `infospace/models/identity/` | shared root; stays upstream |
|
|
|
|
|
| `infospace/models/security/` | boundary under review in `SECURITY-WP-0001-T02` |
|
|
|
|
|
| `infospace/models/devsecops/` | boundary under review in `SECURITY-WP-0001-T02` |
|
|
|
|
|
|
|
|
|
|
Open questions, carried and not assumed:
|
|
|
|
|
|
|
|
|
|
- whether the security and DevSecOps models are better placed here or upstream —
|
|
|
|
|
the only remaining migration candidates, and neither is urgent;
|
|
|
|
|
- how the small-saas profile's security artifacts relate to this canon;
|
|
|
|
|
- the Actor/Subject naming question, analysed in
|
|
|
|
|
[the implications note](docs/260920-actor-subject-implications.md) and decided
|
|
|
|
|
under `SECURITY-WP-0001-T07`.
|
2026-09-20 20:32:05 +02:00
|
|
|
|
|
|
|
|
## Exclusions and evolution
|
|
|
|
|
|
Re-scope SecurityCanon to architecture-layer vocabulary (SEC-ADR-001)
Owner decision of 2026-09-20 answering four of the five open questions from the
Mode of Authority assessment, recorded as SEC-DEC-0001 with the reasoning in
docs/adr-001-securitycanon-boundary.md.
CARING stays in InfoTechCanon: it is implementation-layer and imports eleven
InfoTechCanon models, and SecurityCanon should help rather than hinder keeping
InfoTechCanon practical. Identity stays a shared root, since pulling it in would
collapse too much into security and it reaches into personhood; a dedicated
identity or personhood canon is deferred, not rejected. Mode of Authority is
architecture where CARING is implementation — different layers of abstraction,
neither subsuming the other, but they must not use the same word for different
things. No service surface is duplicated: integration is uniform across
commerce-canon, interface-canon and security-canon through the canon-federation
interface card, and InfoTechCanon's service stays the only one.
Content migration is therefore no longer a goal. T02 narrows from a disposition
review to concept placement, T03 becomes a non-collision survey, and T05, the
migration workplan handoff, is cancelled. T06 gains the three-way mapping table
and T07 becomes the terminology separation decision.
The remaining open question is analysed in docs/260920-actor-subject-implications.md.
InfoTechCanon's access-control model already owns Actor and Subject and binds
them as "Subject is the access-control view of an actor", while Mode of Authority
uses the same two words for two distinct parties; and CARING already carries the
split for non-human subjects. The note recommends renaming Mode of Authority's
second party to Authority Context rather than changing a release-candidate
standard.
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
2026-09-20 21:34:45 +02:00
|
|
|
No service surface is in scope, now or later: SEC-ADR-001 D4 settles that
|
|
|
|
|
SecurityCanon reuses InfoTechCanon's service rather than shipping its own. A
|
|
|
|
|
check that does not exist is a change request against InfoTechCanon.
|
|
|
|
|
|
|
|
|
|
A dedicated identity or personhood canon may eventually be right. It is deferred
|
|
|
|
|
and belongs to no current workplan.
|