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
This commit is contained in:
parent
8251f8022d
commit
383e75f6b2
8 changed files with 621 additions and 106 deletions
124
.repo-manager/index.json
Normal file
124
.repo-manager/index.json
Normal file
|
|
@ -0,0 +1,124 @@
|
|||
{
|
||||
"schema": "repo_manager.index.v1",
|
||||
"slug": "security-canon",
|
||||
"repo_root": "/home/worsch/security-canon",
|
||||
"head_sha": "8251f8022d460924a5273eff6ba2fbc181532a25",
|
||||
"observed_at": "2026-09-20T19:34:32.162255Z",
|
||||
"source_fingerprint": "015164818408dfe0982f7abd9be81a04bbf641d2941b9d68a80390e78b8de932",
|
||||
"source_files": [
|
||||
".repo-classification.yaml",
|
||||
"INTENT.md",
|
||||
"decisions/decisions.md",
|
||||
"workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md"
|
||||
],
|
||||
"work_records": [
|
||||
{
|
||||
"kind": "workplan",
|
||||
"id": "SECURITY-WP-0001",
|
||||
"status": "active",
|
||||
"title": "Bootstrap security-canon and establish the Mode of Authority vocabulary",
|
||||
"source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md",
|
||||
"uuid": "72c0e8f7-c904-59bd-9a7f-55d6de8ac715",
|
||||
"parent_id": null,
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "task",
|
||||
"id": "SECURITY-WP-0001-T01",
|
||||
"status": "done",
|
||||
"title": "Establish repository governance and registration",
|
||||
"source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md",
|
||||
"uuid": "9eabbe55-3529-5821-a248-d05c57a3556f",
|
||||
"parent_id": "SECURITY-WP-0001",
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "task",
|
||||
"id": "SECURITY-WP-0001-T02",
|
||||
"status": "todo",
|
||||
"title": "Boundary and terminology review",
|
||||
"source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md",
|
||||
"uuid": "8b9e4cd0-9905-5ae8-9a23-8957110d72e4",
|
||||
"parent_id": "SECURITY-WP-0001",
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "task",
|
||||
"id": "SECURITY-WP-0001-T03",
|
||||
"status": "todo",
|
||||
"title": "Reference-impact survey",
|
||||
"source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md",
|
||||
"uuid": "dd8bc579-6a89-5b77-bfd8-3acdb4a4f472",
|
||||
"parent_id": "SECURITY-WP-0001",
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "task",
|
||||
"id": "SECURITY-WP-0001-T04",
|
||||
"status": "todo",
|
||||
"title": "Federation interface card and reciprocal navigation",
|
||||
"source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md",
|
||||
"uuid": "a844ccdc-f75d-53b6-858e-c92f30aad7ce",
|
||||
"parent_id": "SECURITY-WP-0001",
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "task",
|
||||
"id": "SECURITY-WP-0001-T05",
|
||||
"status": "cancel",
|
||||
"title": "Migration workplan handoff \u2014 cancelled",
|
||||
"source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md",
|
||||
"uuid": "387bfae1-c7a1-5826-856e-f5364121f849",
|
||||
"parent_id": "SECURITY-WP-0001",
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "task",
|
||||
"id": "SECURITY-WP-0001-T06",
|
||||
"status": "todo",
|
||||
"title": "Promote Mode of Authority into a canon artifact",
|
||||
"source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md",
|
||||
"uuid": "de5fc42c-2e18-5f03-b86c-a5ad45a9bb0a",
|
||||
"parent_id": "SECURITY-WP-0001",
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "task",
|
||||
"id": "SECURITY-WP-0001-T07",
|
||||
"status": "todo",
|
||||
"title": "Decide the terminology separation",
|
||||
"source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md",
|
||||
"uuid": "4a0d3df9-d8a2-51c4-a4bc-72488d866068",
|
||||
"parent_id": "SECURITY-WP-0001",
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "decision",
|
||||
"id": "SEC-DEC-0001",
|
||||
"status": "accepted",
|
||||
"title": "SecurityCanon boundary: CARING stays in InfoTechCanon; Auth Mode is architecture-layer vocabulary",
|
||||
"source_path": "decisions/decisions.md",
|
||||
"uuid": null,
|
||||
"parent_id": null,
|
||||
"extra": {
|
||||
"record": {
|
||||
"id": "SEC-DEC-0001",
|
||||
"kind": "decision",
|
||||
"title": "SecurityCanon boundary: CARING stays in InfoTechCanon; Auth Mode is architecture-layer vocabulary",
|
||||
"status": "accepted",
|
||||
"created": "2026-09-20T19:30:50.120170Z",
|
||||
"updated": "2026-09-20T19:30:50.120170Z"
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"events": [
|
||||
{
|
||||
"type": "repo.reconciled",
|
||||
"workplan_count": 1,
|
||||
"task_count": 7,
|
||||
"source": "repo-manager",
|
||||
"emitted_at": "2026-09-20T19:34:32.162320Z"
|
||||
}
|
||||
]
|
||||
}
|
||||
108
INTENT.md
108
INTENT.md
|
|
@ -9,14 +9,17 @@ and avoid redefining concepts another canon already owns.
|
|||
## Origin and demand
|
||||
|
||||
The initial demand is the repository owner's 2026-09-20 request to refine
|
||||
InfoTechCanon by moving its IT-security material into a dedicated canon.
|
||||
InfoTechCanon has accumulated security content — a security model, an access
|
||||
control model, a DevSecOps model, the CARING access governance standard, and the
|
||||
CARING Kubernetes RBAC benchmark — that is orthogonal to its taxonomy-layer role
|
||||
and better served by a canon with its own review cadence and consumers.
|
||||
InfoTechCanon by giving its IT-security material a dedicated home.
|
||||
|
||||
Extraction is a migration, not a rewrite. Source artifacts keep their provenance,
|
||||
and InfoTechCanon retains the shared roots that security terminology imports.
|
||||
Reviewing the Mode of Authority draft changed what that means. SecurityCanon's
|
||||
first contribution is **architecture-layer security vocabulary of its own**, not
|
||||
a transfer of InfoTechCanon's content. Per [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md),
|
||||
content migration is neither urgent nor a goal in itself:
|
||||
|
||||
> SecurityCanon should help, not hinder, keeping InfoTechCanon practical.
|
||||
|
||||
An artifact moves only when moving it makes both canons more practical, and the
|
||||
burden of proof is on the move. Anything that does move keeps its provenance.
|
||||
|
||||
## Layer and boundary
|
||||
|
||||
|
|
@ -37,7 +40,11 @@ depends:
|
|||
- **whitehat-security** owns adversarial evidence and findings practice.
|
||||
- **InfoTechCanon** remains the authority for the shared roots — artifact,
|
||||
ownership, relationship, mapping, assimilation, profile, pattern, conformance,
|
||||
provenance, and interface mechanisms — that this canon imports.
|
||||
provenance, and interface mechanisms — that this canon imports. It also keeps
|
||||
**CARING**, the access-control model, and the **identity** model: CARING because
|
||||
it is implementation-layer and imports eleven InfoTechCanon models, identity
|
||||
because it is a shared root reaching into personhood rather than a security
|
||||
concern. A dedicated identity or personhood canon is deferred, not rejected.
|
||||
- Consumers own their own adoption evidence and importing profiles.
|
||||
|
||||
A generic security semantic contract belongs here; a security obligation imposed
|
||||
|
|
@ -62,6 +69,13 @@ network-shaped rather than purely hierarchical, pattern-oriented rather than mer
|
|||
taxonomic, externally mappable without being externally constrained, and
|
||||
orthogonal without becoming isolated.
|
||||
|
||||
It adds one stance of its own: **architecture, not implementation.** SecurityCanon
|
||||
describes the relationships in which authority is exercised, before and
|
||||
independently of the mechanisms that enforce them. CARING occupies the
|
||||
implementation layer in InfoTechCanon. The two are different layers of
|
||||
abstraction, and neither subsumes the other — but they must not use the same word
|
||||
for different things.
|
||||
|
||||
External standards influence SecurityCanon through mappings and assimilation.
|
||||
They do not define its internal semantics directly.
|
||||
|
||||
|
|
@ -69,11 +83,16 @@ They do not define its internal semantics directly.
|
|||
|
||||
1. Every canonical security concept has a clear owner.
|
||||
2. Concepts are imported from their owning canon, never redefined.
|
||||
3. Mappings to external bodies of knowledge are explicit, versioned, scoped, and justified.
|
||||
4. Migrated artifacts preserve provenance and their InfoTechCanon history.
|
||||
5. Profiles constrain standards for concrete implementation contexts.
|
||||
6. Artifacts are useful to both humans and agents.
|
||||
7. Evolution preserves provenance, compatibility information, and rationale.
|
||||
3. Direct terminology overlap with InfoTechCanon is avoided: where a concept is
|
||||
shared it is defined once upstream and imported; where concepts genuinely
|
||||
differ, the names must visibly differ.
|
||||
4. Mappings to external bodies of knowledge are explicit, versioned, scoped, and justified.
|
||||
5. Migrated artifacts preserve provenance and their InfoTechCanon history.
|
||||
6. Profiles constrain standards for concrete implementation contexts.
|
||||
7. Artifacts are useful to both humans and agents.
|
||||
8. Evolution preserves provenance, compatibility information, and rationale.
|
||||
9. Integration with InfoTechCanon is uniform with the other domain canons, and
|
||||
the service surface is never duplicated.
|
||||
|
||||
## Non-goals
|
||||
|
||||
|
|
@ -82,30 +101,44 @@ OWASP, or MITRE ATT&CK. It does not define one mandatory security model every
|
|||
system must fully implement, operate consumer systems, enforce policy, issue
|
||||
credentials, or provide production authorization or detection services.
|
||||
|
||||
It also ships **no service surface of its own** — no CLI, HTTP API, or validation
|
||||
service. InfoTechCanon's service is the single place canons are inspected and
|
||||
validated, and SecurityCanon ties into it through the same canon-federation
|
||||
interface card mechanism that CommerceCanon and InterfaceCanon use. A check that
|
||||
does not exist yet is a change to InfoTechCanon's service, not a second service
|
||||
here.
|
||||
|
||||
## Direction of travel
|
||||
|
||||
The repository should initially establish the canon skeleton and federation
|
||||
interface, then receive the security material extracted from InfoTechCanon with
|
||||
its provenance intact, then publish mappings and at least one worked profile.
|
||||
The repository should first promote the Mode of Authority draft into a checkable
|
||||
architecture-layer vocabulary with its orientation surfaces, publish its
|
||||
federation interface card declaring that vocabulary as an export, and publish the
|
||||
mapping that relates it to InfoTechCanon's access-control model and CARING.
|
||||
|
||||
Only then, and only where it demonstrably helps both canons, does content move.
|
||||
Stable promotion requires reviewed mappings and concrete consumer evidence.
|
||||
|
||||
## Outcome
|
||||
|
||||
InfoTechCanon's IT-security material lives in SecurityCanon as a coherent,
|
||||
independently reviewable canon: security terminology, the CARING access
|
||||
governance standard and its Kubernetes RBAC benchmark, published with declared
|
||||
imports from InfoTechCanon, a federation interface card, and preserved
|
||||
provenance — while InfoTechCanon retains only the shared roots those artifacts
|
||||
import and carries no dangling references.
|
||||
SecurityCanon is a coherent architecture-layer security vocabulary that
|
||||
InfoTechCanon references: Mode of Authority published as a checkable artifact
|
||||
with declared imports, a federation interface card declaring it as an export,
|
||||
orientation surfaces that let a reader or agent find the right term, and a
|
||||
mapping that relates it cleanly to InfoTechCanon's access-control model and
|
||||
CARING — with InfoTechCanon left more practical than before, not less.
|
||||
|
||||
## Invariants
|
||||
|
||||
- InfoTechCanon remains valid at every step: `make check` passes and its
|
||||
validation reports zero errors before and after each migration slice.
|
||||
- Migrated artifacts keep their provenance and their InfoTechCanon history;
|
||||
extraction is a move with recorded lineage, not a rewrite.
|
||||
- InfoTechCanon remains valid and remains practical: `make check` passes and its
|
||||
validation reports zero errors, and no change here makes working in
|
||||
InfoTechCanon harder.
|
||||
- Any migrated artifact keeps its provenance and its InfoTechCanon history;
|
||||
a move is a move with recorded lineage, never a rewrite.
|
||||
- Concepts are imported from their owning canon, never redefined on both sides.
|
||||
- No concept is left unowned, and no concept is claimed by two canons.
|
||||
- No word means one thing here and a different thing in InfoTechCanon.
|
||||
- Integration stays uniform with CommerceCanon and InterfaceCanon; no service
|
||||
surface is duplicated.
|
||||
- The State Hub stays a read model: workplan files here are authoritative and
|
||||
are registered by `fix-consistency`, never by hand.
|
||||
|
||||
|
|
@ -113,19 +146,20 @@ import and carries no dangling references.
|
|||
|
||||
1. Repository registered in the State Hub with a topic, classification, and
|
||||
federation interface card; reciprocal navigation with InfoTechCanon passes
|
||||
the canon-federation validator.
|
||||
2. A reviewed disposition record naming, for every security artifact in
|
||||
InfoTechCanon, whether it moves, stays, or splits — with rationale.
|
||||
3. Migration complete: the artifacts dispositioned as `move` are present here
|
||||
with provenance, and absent from InfoTechCanon.
|
||||
4. Both canons validate clean after migration, with no unresolved cross-canon
|
||||
references in either direction.
|
||||
the canon-federation validator, by the same mechanism the other canons use.
|
||||
2. Mode of Authority promoted into a checkable artifact with machine-readable
|
||||
modes and dimensions, and its open questions on CONSTRUCT-versus-GOVERN and
|
||||
substrate authority answered.
|
||||
3. A published mapping relating the vocabulary to InfoTechCanon's access-control
|
||||
model and CARING, with no term colliding across the two canons.
|
||||
4. Orientation surfaces present: the vocabulary card, the design heuristic as
|
||||
the entry point, and the role/plane/mode disambiguation page.
|
||||
5. At least one worked profile or benchmark demonstrates the canon is usable by
|
||||
a consumer, and its scope statement is reviewed against intent.
|
||||
|
||||
## Project retirement
|
||||
|
||||
Archive this repository only if the extraction is abandoned and the material
|
||||
returns to InfoTechCanon. On success this repository does not retire — it
|
||||
becomes a standing canon and its project flavor is reconsidered, as
|
||||
CommerceCanon and InterfaceCanon were.
|
||||
Archive this repository only if the vocabulary is abandoned or absorbed
|
||||
upstream. On success this repository does not retire — it becomes a standing
|
||||
canon and its project flavor is reconsidered, as CommerceCanon and
|
||||
InterfaceCanon were.
|
||||
|
|
|
|||
24
README.md
24
README.md
|
|
@ -5,9 +5,15 @@ Orthogonal vocabulary and canonical model for security-related concepts.
|
|||
SecurityCanon extends InfoTechCanon with a focused security domain model, in the
|
||||
same architectural role that [CommerceCanon](../commerce-canon) holds for
|
||||
commercial terminology and [InterfaceCanon](../interface-canon) for interface
|
||||
terminology. Its initial content is the IT-security material extracted from
|
||||
InfoTechCanon: the security, access control, and DevSecOps models, the CARING
|
||||
access governance standard, and the CARING Kubernetes RBAC benchmark.
|
||||
terminology.
|
||||
|
||||
Its subject is **architecture, not implementation**: the relationships in which
|
||||
authority is exercised, described before and independently of the mechanisms
|
||||
that enforce them. Its first contribution is the **Mode of Authority** vocabulary
|
||||
— seven auth modes (`USE`, `OBSERVE`, `OPERATE`, `ADMINISTER`, `GOVERN`,
|
||||
`CONSTRUCT`, `SOVEREIGN`) read relative to a scope. CARING and the access-control
|
||||
and identity models stay in InfoTechCanon, at the implementation layer and as
|
||||
shared roots; see [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md).
|
||||
|
||||
| | |
|
||||
| --- | --- |
|
||||
|
|
@ -15,12 +21,20 @@ access governance standard, and the CARING Kubernetes RBAC benchmark.
|
|||
| **Domain** | infotech |
|
||||
| **Workplan prefix** | `SECURITY-WP-` |
|
||||
| **Upstream canon** | [InfoTechCanon](../info-tech-canon) |
|
||||
| **Service surface** | none — reuses InfoTechCanon's |
|
||||
|
||||
Start with [INTENT.md](INTENT.md) and [SCOPE.md](SCOPE.md).
|
||||
Agent instructions are in [AGENTS.md](AGENTS.md); active work is in
|
||||
[workplans/](workplans/).
|
||||
|
||||
| Document | What it holds |
|
||||
| --- | --- |
|
||||
| [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md) | the boundary decision — what stays upstream, and why |
|
||||
| [Mode of Authority assessment](history/260920-mode-of-authority-and-canon-structure.md) | review of the v0.1 draft and the proposed canon structure |
|
||||
| [Actor/Subject implications](docs/260920-actor-subject-implications.md) | the one open terminology question, analysed |
|
||||
|
||||
## Status
|
||||
|
||||
Bootstrap. The repository is registered and governed, but holds no migrated
|
||||
canon content yet. See [SECURITY-WP-0001](workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md).
|
||||
Bootstrap. The repository is registered and governed. Its only content is the
|
||||
Mode of Authority v0.1 research draft, not yet promoted into a canon artifact.
|
||||
See [SECURITY-WP-0001](workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md).
|
||||
|
|
|
|||
62
SCOPE.md
62
SCOPE.md
|
|
@ -1,12 +1,15 @@
|
|||
# SCOPE
|
||||
|
||||
Reviewed: 2026-09-20 (Europe/Berlin).
|
||||
Reviewed: 2026-09-20 (Europe/Berlin), after [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md).
|
||||
|
||||
## Current repository scope
|
||||
|
||||
Bootstrap. The repository carries governance files — INTENT, GOAL, SCOPE,
|
||||
AGENTS, repo classification — and one active workplan. It holds no canon
|
||||
content and no service code yet.
|
||||
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.
|
||||
|
||||
## Ownership and boundaries
|
||||
|
||||
|
|
@ -16,6 +19,11 @@ shared roots from InfoTechCanon and does not redefine them.
|
|||
|
||||
Out of scope, with the owner named:
|
||||
|
||||
- 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
|
||||
- security architecture and standards of record for the estate — NetKingdom
|
||||
- authorization decisions — flex-auth
|
||||
- login, OIDC, MFA — key-cape / Keycloak
|
||||
|
|
@ -26,27 +34,39 @@ Out of scope, with the owner named:
|
|||
|
||||
## Planned scope
|
||||
|
||||
The extraction candidates in InfoTechCanon, pending the disposition review in
|
||||
`SECURITY-WP-0001-T02`:
|
||||
The near-term deliverable is the architecture-layer vocabulary, not a migration.
|
||||
|
||||
| Source path in info-tech-canon | Kind |
|
||||
| Deliverable | Task |
|
||||
| --- | --- |
|
||||
| `infospace/models/security/` | model |
|
||||
| `infospace/models/access-control/` | model |
|
||||
| `infospace/models/devsecops/` | model |
|
||||
| `infospace/standards/caring/` | standard |
|
||||
| `infospace/standards/caring/benchmarks/kubernetes-rbac/` | benchmark |
|
||||
| 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` |
|
||||
|
||||
Open boundary questions the disposition review must answer, not assume:
|
||||
InfoTechCanon artifacts this canon **references rather than absorbs**:
|
||||
|
||||
- whether `infospace/models/identity/` is security terminology or a shared root
|
||||
that stays in InfoTechCanon;
|
||||
- how the small-saas profile's security artifacts (policy, control, evidence,
|
||||
incident) split between the two canons;
|
||||
- which InfoTechCanon concepts become declared imports rather than moves.
|
||||
| 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`.
|
||||
|
||||
## Exclusions and evolution
|
||||
|
||||
No service surface, CLI, HTTP API, or validation tooling is in scope until the
|
||||
canon content exists and a demand for them is recorded. Whether SecurityCanon
|
||||
reuses InfoTechCanon's Python service or ships its own is deferred.
|
||||
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.
|
||||
|
|
|
|||
13
decisions/decisions.md
Normal file
13
decisions/decisions.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
# Decision records
|
||||
|
||||
## SEC-DEC-0001 — SecurityCanon boundary: CARING stays in InfoTechCanon; Auth Mode is architecture-layer vocabulary
|
||||
|
||||
```yaml
|
||||
id: SEC-DEC-0001
|
||||
kind: decision
|
||||
title: 'SecurityCanon boundary: CARING stays in InfoTechCanon; Auth Mode is architecture-layer
|
||||
vocabulary'
|
||||
status: accepted
|
||||
created: '2026-09-20T19:30:50.120170Z'
|
||||
updated: '2026-09-20T19:30:50.120170Z'
|
||||
```
|
||||
163
docs/260920-actor-subject-implications.md
Normal file
163
docs/260920-actor-subject-implications.md
Normal file
|
|
@ -0,0 +1,163 @@
|
|||
---
|
||||
id: SEC-NOTE-260920
|
||||
type: analysis
|
||||
title: "Implications of the Actor/Subject split for CARING and the access-control model"
|
||||
repo: security-canon
|
||||
status: for-discussion
|
||||
created: "2026-09-20"
|
||||
relates_to: SEC-ADR-001
|
||||
carried_by: SECURITY-WP-0001-T07
|
||||
---
|
||||
|
||||
# Implications of the Actor/Subject split
|
||||
|
||||
Question 3 of the [Mode of Authority assessment](../history/260920-mode-of-authority-and-canon-structure.md),
|
||||
left open by [SEC-ADR-001](adr-001-securitycanon-boundary.md) 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:
|
||||
|
||||
```text
|
||||
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
|
||||
|
||||
```text
|
||||
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:
|
||||
|
||||
```text
|
||||
Principal
|
||||
Effective actor
|
||||
Delegator
|
||||
Tool or agent
|
||||
Policy ceiling
|
||||
Execution context
|
||||
Audit identity
|
||||
```
|
||||
|
||||
with an explicit agent access formula:
|
||||
|
||||
```text
|
||||
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:
|
||||
|
||||
```text
|
||||
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.
|
||||
132
docs/adr-001-securitycanon-boundary.md
Normal file
132
docs/adr-001-securitycanon-boundary.md
Normal file
|
|
@ -0,0 +1,132 @@
|
|||
---
|
||||
id: SEC-ADR-001
|
||||
decision_record: SEC-DEC-0001
|
||||
type: adr
|
||||
title: "SecurityCanon boundary: abstraction layers, not content extraction"
|
||||
repo: security-canon
|
||||
status: accepted
|
||||
decided: "2026-09-20"
|
||||
decided_by: repository owner
|
||||
supersedes_assumption: "SECURITY-WP-0001 as originally drafted"
|
||||
---
|
||||
|
||||
# SEC-ADR-001 — SecurityCanon boundary
|
||||
|
||||
Owner decision of 2026-09-20, answering questions 1, 2, 4 and 5 of the
|
||||
[Mode of Authority assessment](../history/260920-mode-of-authority-and-canon-structure.md).
|
||||
Question 3 remains open and is treated in §6.
|
||||
|
||||
## Context
|
||||
|
||||
SecurityCanon was bootstrapped on the assumption that it is a destination for
|
||||
IT-security material extracted from InfoTechCanon. Reviewing
|
||||
`ModeOfAuthorityCanon-v0.1.md` showed that assumption was incomplete: the draft
|
||||
is a native contribution, and it collides on terminology with InfoTechCanon's
|
||||
CARING standard. Four questions were put to the owner.
|
||||
|
||||
## Decision
|
||||
|
||||
### D1 — CARING stays in InfoTechCanon
|
||||
|
||||
CARING is not migrated. It imports eleven InfoTechCanon models, and moving it
|
||||
would cost more than it returns.
|
||||
|
||||
The governing principle the owner stated:
|
||||
|
||||
> SecurityCanon should help, not hinder, keeping InfoTechCanon practical.
|
||||
|
||||
Content migration is therefore **not urgent and not a goal in itself**. An
|
||||
artifact moves only when moving it makes both canons more practical, and the
|
||||
burden of proof is on the move.
|
||||
|
||||
### D2 — Auth Mode and CARING are different layers of abstraction
|
||||
|
||||
Mode of Authority is about **architecture**. CARING is about **implementation**.
|
||||
|
||||
| | Mode of Authority | CARING |
|
||||
| --- | --- | --- |
|
||||
| Question | In what relationship to a system is authority exercised? | How is this access-control implementation actually composed? |
|
||||
| Layer | architecture / design reasoning | implementation analysis and governance |
|
||||
| Use | describing intent before a system exists | describing and prescribing systems that exist |
|
||||
| Home | SecurityCanon | InfoTechCanon |
|
||||
|
||||
They are not competitors and neither subsumes the other. The assessment's
|
||||
"dimension collision" is therefore **not resolved by merging** but by keeping the
|
||||
layers distinct.
|
||||
|
||||
**Direct terminology overlap must nonetheless be avoided.** Two different layers
|
||||
may legitimately need related concepts, but they must not use the same word for
|
||||
different things, nor silently define the same thing twice. The rule:
|
||||
|
||||
1. Where a concept is genuinely shared (Scope, Subject), one canon defines it and
|
||||
the other imports it. InfoTechCanon owns the shared roots, so shared concepts
|
||||
are defined there.
|
||||
2. Where the concepts are genuinely different, the names must be visibly
|
||||
different. `Operator` (CARING lifecycle role) and `OPERATE` (auth mode) are
|
||||
the clearest offender and need explicit disambiguation, not renaming by
|
||||
reflex.
|
||||
3. Where one layer refines the other — MoA's Actor/Subject split against
|
||||
CARING's single Subject — the relationship is recorded as a mapping, not a
|
||||
redefinition. See §6.
|
||||
|
||||
### D3 — Identity is a shared root and stays in InfoTechCanon
|
||||
|
||||
Pulling identity into SecurityCanon would collapse too much into security.
|
||||
Identity reaches into personhood and its philosophical underpinnings, which are
|
||||
not security concerns.
|
||||
|
||||
A dedicated identity or personhood canon may eventually be right. That is
|
||||
explicitly **deferred**, not rejected, and is not in scope for any current
|
||||
workplan.
|
||||
|
||||
SecurityCanon imports identity concepts from InfoTechCanon. MoA's Principal Type
|
||||
dimension is a security-side classification that references those concepts; it
|
||||
does not define identity.
|
||||
|
||||
### D4 — No duplicated service surface
|
||||
|
||||
The requirement is **uniform integration**, not independent tooling:
|
||||
|
||||
> All the specific canons should integrate with InfoTechCanon properly and in
|
||||
> the same way — commerce-canon, interface-canon, security-canon alike — and be
|
||||
> referenced by InfoTechCanon in the same way.
|
||||
|
||||
Consequences:
|
||||
|
||||
- SecurityCanon ships **no** CLI, HTTP API, or validation service of its own.
|
||||
- Integration uses the existing canon-federation interface card mechanism
|
||||
(`infospace/interfaces/federation.yaml`, schema owned by InfoTechCanon,
|
||||
authority `CUST-ADR-006`), exactly as CommerceCanon and InterfaceCanon do.
|
||||
- InfoTechCanon's service surface is the single place canons are inspected and
|
||||
validated. If SecurityCanon needs a check that does not exist, the change
|
||||
belongs in InfoTechCanon's service, not in a second service here.
|
||||
- Any divergence in how the three canons tie in is a defect to fix, not a local
|
||||
choice. Coordinate through prj-canon-federation.
|
||||
|
||||
## Consequences
|
||||
|
||||
**The repository's purpose changes shape.** SecurityCanon is an
|
||||
architecture-layer vocabulary canon that InfoTechCanon references, not an
|
||||
extraction destination. Its first deliverable is the Mode of Authority
|
||||
vocabulary and its federation card — not a migration.
|
||||
|
||||
**SECURITY-WP-0001 is re-scoped.** The disposition review narrows from "what
|
||||
moves" to "where does each concept belong, and what is imported". The migration
|
||||
handoff task is cancelled; nothing currently justifies a migration workplan.
|
||||
|
||||
**InfoTechCanon is not destabilised.** No artifact is removed from it under this
|
||||
decision, so the invariant that InfoTechCanon validates clean is satisfied
|
||||
trivially rather than by careful slicing.
|
||||
|
||||
## Open — Q3, the Actor/Subject split
|
||||
|
||||
Not decided. The owner asked for review and discussion of the implications
|
||||
before deciding whether MoA's Actor/Subject split should change CARING's single
|
||||
Subject dimension.
|
||||
|
||||
Under D2 the question is narrower than it first appeared: because the two are
|
||||
different layers, the split does not have to propagate. The live options are a
|
||||
mapping at the boundary, an additive relation field in CARING, or an upstream
|
||||
change to a release-candidate standard. This is carried by
|
||||
`SECURITY-WP-0001-T07` and treated in
|
||||
[the Actor/Subject implications note](260920-actor-subject-implications.md).
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
id: SECURITY-WP-0001
|
||||
type: workplan
|
||||
title: "Bootstrap security-canon and plan the InfoTechCanon security extraction"
|
||||
title: "Bootstrap security-canon and establish the Mode of Authority vocabulary"
|
||||
domain: infotech
|
||||
repo: security-canon
|
||||
status: active
|
||||
|
|
@ -24,15 +24,22 @@ in this workplan: it depends on the disposition review in T02 and gets its own
|
|||
workplan once the boundary is settled. See [INTENT.md](../INTENT.md) for the
|
||||
layer claim and the success gates.
|
||||
|
||||
**Revised 2026-09-20** after reviewing `spec/ModeOfAuthorityCanon-v0.1.md`. The
|
||||
**Revised twice on 2026-09-20.** First after reviewing `spec/ModeOfAuthorityCanon-v0.1.md`. The
|
||||
[Mode of Authority assessment](../history/260920-mode-of-authority-and-canon-structure.md)
|
||||
found that SecurityCanon is not only a recipient of extracted material: the Mode
|
||||
of Authority draft is a native contribution and is plausibly the organizing spine
|
||||
of the canon. It also found that Mode of Authority and CARING independently
|
||||
invented overlapping dimensions — Scope, Subject, Activation/Condition,
|
||||
Capability/Operations — that collide by name while differing in meaning.
|
||||
Consequently the vocabulary is settled *before* the migration, not after: T06 and
|
||||
T07 are new and precede T05.
|
||||
Then again after the owner's decision, recorded as
|
||||
[SEC-ADR-001](../docs/adr-001-securitycanon-boundary.md): CARING stays in
|
||||
InfoTechCanon, identity stays a shared root, Mode of Authority is architecture
|
||||
while CARING is implementation, and no service surface is duplicated.
|
||||
|
||||
**Content migration is no longer a goal of this workplan.** SecurityCanon's
|
||||
deliverable is the architecture-layer vocabulary and its clean integration; an
|
||||
artifact moves only where moving it makes both canons more practical. T05 is
|
||||
cancelled accordingly.
|
||||
|
||||
## Establish repository governance and registration
|
||||
|
||||
|
|
@ -49,7 +56,7 @@ AGENTS with repo identity, README, and repo classification. Register the
|
|||
repository and this workplan in the State Hub by committing the files and
|
||||
running `statehub fix-consistency` — never by hand.
|
||||
|
||||
## Disposition review of InfoTechCanon security material
|
||||
## Boundary and terminology review
|
||||
|
||||
```task
|
||||
id: SECURITY-WP-0001-T02
|
||||
|
|
@ -58,20 +65,18 @@ priority: high
|
|||
state_hub_task_id: "8b9e4cd0-9905-5ae8-9a23-8957110d72e4"
|
||||
```
|
||||
|
||||
Produce a reviewed disposition record naming, for every security artifact in
|
||||
InfoTechCanon, whether it moves to SecurityCanon, stays, or splits — with
|
||||
rationale and the resulting import declarations. Candidates are the security,
|
||||
access control, and DevSecOps models, the CARING access governance standard, and
|
||||
its Kubernetes RBAC benchmark.
|
||||
Narrowed by SEC-ADR-001, which already settles CARING, identity and the
|
||||
access-control model as staying in InfoTechCanon. What remains is to establish,
|
||||
for each concept rather than each file, **where it belongs and what is imported**.
|
||||
|
||||
The review is **three-way**, not two-way: it reconciles the Mode of Authority
|
||||
vocabulary, the InfoTechCanon access-control model, and CARING. Required output
|
||||
includes the dimension-collision table — one row per overlapping concept, naming
|
||||
the single surviving definition and its owning tier. Assessment section 3 holds
|
||||
the first draft of that table.
|
||||
Required output is the concept-placement table: one row per concept that appears
|
||||
in both layers, naming the single owning canon and the import direction.
|
||||
Assessment section 3 holds the first draft.
|
||||
|
||||
Answer explicitly whether CARING migrates at all. It imports eleven InfoTechCanon
|
||||
models, so staying put and importing the vocabulary is a live option.
|
||||
Two artifacts are still genuinely open and are the only remaining migration
|
||||
candidates: the security model and the DevSecOps model. Neither is urgent.
|
||||
Recommend for each, with rationale, and default to leaving it upstream unless
|
||||
moving it demonstrably helps both canons.
|
||||
|
||||
Resolve the open boundary questions rather than assuming them: whether the
|
||||
identity model is security terminology or a shared root; how the small-saas
|
||||
|
|
@ -88,11 +93,11 @@ priority: medium
|
|||
state_hub_task_id: "dd8bc579-6a89-5b77-bfd8-3acdb4a4f472"
|
||||
```
|
||||
|
||||
Enumerate every inbound reference to the extraction candidates — InfoTechCanon
|
||||
relationships, indexes, generated views, agent briefs, profiles, evaluations,
|
||||
mappings, and its Python validation checks — plus references from other repos.
|
||||
The survey sizes the migration and is the checklist that keeps InfoTechCanon
|
||||
validating clean after each slice.
|
||||
Enumerate where InfoTechCanon already speaks about authority — the access-control
|
||||
model, CARING, the security and DevSecOps models, profiles, evaluations and the
|
||||
generated surfaces — so the vocabulary is published against what exists rather
|
||||
than beside it. With migration off the table this is a survey for correct
|
||||
referencing and non-collision, not a migration sizing exercise.
|
||||
|
||||
## Federation interface card and reciprocal navigation
|
||||
|
||||
|
|
@ -110,19 +115,19 @@ Authority as a SecurityCanon **export**, not only InfoTechCanon imports. Add rec
|
|||
InfoTechCanon and pass the canon-federation validator. Coordinate with
|
||||
prj-canon-federation rather than amending federation governance here.
|
||||
|
||||
## Migration workplan handoff
|
||||
## Migration workplan handoff — cancelled
|
||||
|
||||
```task
|
||||
id: SECURITY-WP-0001-T05
|
||||
status: wait
|
||||
status: cancel
|
||||
priority: medium
|
||||
state_hub_task_id: "387bfae1-c7a1-5826-856e-f5364121f849"
|
||||
```
|
||||
|
||||
With the disposition (T02), reference survey (T03), vocabulary promotion (T06)
|
||||
and dimension decision (T07) settled, draft the migration workplan — slice order,
|
||||
provenance handling, and the per-slice validation gate for both canons.
|
||||
Migrating into an unsettled spine is the failure this ordering prevents.
|
||||
Cancelled by SEC-ADR-001. With CARING, identity and the access-control model
|
||||
staying in InfoTechCanon, there is no migration large enough to need its own
|
||||
workplan. If T02 later recommends moving the security or DevSecOps model, that is
|
||||
a bounded change handled under a new task, not a migration programme.
|
||||
|
||||
## Promote Mode of Authority into a canon artifact
|
||||
|
||||
|
|
@ -145,13 +150,18 @@ provenance. It currently sits in `spec/`, which the Repository Layout Standard
|
|||
reserves for implementation guidance; a self-declared research draft belongs in
|
||||
`research/` until promoted.
|
||||
|
||||
Close the two open questions that block stability: Q2, whether CONSTRUCT is
|
||||
always distinct from GOVERN under policy-as-code, and Q3, how substrate
|
||||
authority is represented. Purpose and Time appear in the Access Situation tuple
|
||||
Publish the three-way mapping table relating the vocabulary to InfoTechCanon's
|
||||
access-control model and CARING — section 5 of the
|
||||
[Actor/Subject implications note](../docs/260920-actor-subject-implications.md)
|
||||
holds the first draft.
|
||||
|
||||
Close the two open questions that block stability: whether CONSTRUCT is always
|
||||
distinct from GOVERN under policy-as-code, and how substrate authority is
|
||||
represented. Purpose and Time appear in the Access Situation tuple
|
||||
without sections; resolve Purpose as an import from InfoTechCanon's PURPOSES
|
||||
extension rather than defining it here.
|
||||
|
||||
## Decide the dimension collision
|
||||
## Decide the terminology separation
|
||||
|
||||
```task
|
||||
id: SECURITY-WP-0001-T07
|
||||
|
|
@ -160,19 +170,24 @@ priority: high
|
|||
state_hub_task_id: "4a0d3df9-d8a2-51c4-a4bc-72488d866068"
|
||||
```
|
||||
|
||||
Record a decision — not a task note — resolving each overlapping dimension to
|
||||
one definition in one tier, because the outcome binds both canons. At minimum:
|
||||
Scope, Subject versus the Actor/Subject split, Activation versus CARING
|
||||
Condition, Capability versus AccessOperations, Build Plane versus CONSTRUCT,
|
||||
Audit Plane versus Evidence Boundary, and the `Operator` role versus the
|
||||
`OPERATE` mode.
|
||||
SEC-ADR-001 D2 settles the principle — the two are different layers of
|
||||
abstraction and must not share a word for different things. This task applies it
|
||||
concretely and records the result as a decision, because it binds both canons.
|
||||
|
||||
Also decide the prior question the assessment raises: whether Mode of Authority
|
||||
is security terminology owned here, or general information-systems terminology
|
||||
that belongs in InfoTechCanon with SecurityCanon consuming it.
|
||||
The unavoidable case is **Actor/Subject**. InfoTechCanon's access-control model
|
||||
already owns both words and binds them as "Subject is the access-control view of
|
||||
an actor"; Mode of Authority uses the same two words for two distinct parties.
|
||||
The [implications note](../docs/260920-actor-subject-implications.md) analyses
|
||||
this and recommends renaming MoA's second party to `Authority Context`. Decide
|
||||
it, and answer the owner's request to discuss what follows for CARING §32.
|
||||
|
||||
Reserve namespaces as part of the decision. CARING currently owns `itc-caring:`,
|
||||
which must be rewritten rather than aliased if it migrates.
|
||||
Also resolve, in the same decision: `Operator` role versus `OPERATE` mode,
|
||||
Activation versus CARING Condition, Capability versus AccessOperations, Build
|
||||
Plane versus CONSTRUCT, and Audit Plane versus Evidence Boundary — in each case
|
||||
by separating names or declaring an import, never by redefining upstream.
|
||||
|
||||
Reserve the `sec-authority:` namespace for the vocabulary. `itc-caring:` stays
|
||||
with InfoTechCanon.
|
||||
|
||||
## Out of scope
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue