Publish the SecurityCanon federation interface card (T04)
Declares one export surface, sec-authority, carrying the Mode of Authority vocabulary and its machine-readable catalogs, with InfoTechCanon, InterfaceCanon, CommerceCanon and the Custodian as peers under CUST-ADR-006. The card validates against InfoTechCanon's interface-card schema. Imports are pinned against InfoTechCanon e1f98da0 in imports.json, recording path and SHA-256 for each of the five sources; all five were verified to match Git blobs at that commit with the sources unchanged in the review checkout. Reciprocal navigation runs both ways: this repository's interfaces README links the peer cards, and InfoTechCanon carries the SecurityCanon boundary review with its own README link, following the InterfaceCanon precedent. The prj-canon-federation G7 validator passes, and InfoTechCanon make check passes with 46 tests and clean validation. The validator pins card paths for three repositories only, so this card meets the same contract without yet being registered there; that is prj-canon-federation's change to make and the card says so. 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
b1fa25ebe3
commit
a267c98087
4 changed files with 195 additions and 1 deletions
27
infospace/interfaces/README.md
Normal file
27
infospace/interfaces/README.md
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
# Canon federation interface
|
||||
|
||||
The [interface card](federation.yaml) publishes this canon's federation boundary
|
||||
under [accepted ADR-006](../../../the-custodian/canon/architecture/adr-006-canon-federation-concept-ownership.md).
|
||||
|
||||
- [info-tech-canon interface](../../../info-tech-canon/infospace/interfaces/federation.yaml)
|
||||
— shared-concept upstream
|
||||
- [SecurityCanon boundary review](../../../info-tech-canon/infospace/interfaces/security-canon-boundary.md)
|
||||
— InfoTechCanon-side acceptance of this extension boundary
|
||||
- [interface-canon interface](../../../interface-canon/infospace/interfaces/federation.yaml)
|
||||
- [commerce-canon interface](../../../commerce-canon/infospace/interfaces/federation.yaml)
|
||||
- [the-custodian interface](../../../the-custodian/canon/interfaces/federation.yaml)
|
||||
|
||||
SecurityCanon exports one surface, `sec-authority`: the architecture-layer
|
||||
[Mode of Authority](../vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md)
|
||||
vocabulary. It imports shared roots from InfoTechCanon and redefines none of
|
||||
them; the [pinned manifest](../vocabulary/mode-of-authority/imports.json) records
|
||||
each source path and content hash at the declared commit.
|
||||
|
||||
Reciprocal navigation does not imply reciprocal semantic imports. InfoTechCanon
|
||||
retains the shared roots, CARING, the access-control model and the identity
|
||||
model; see [SEC-ADR-001](../../docs/adr-001-securitycanon-boundary.md).
|
||||
|
||||
The G7 validator in `prj-canon-federation` currently pins card paths for
|
||||
info-tech-canon, commerce-canon and the-custodian. Adding `security-canon` to
|
||||
`CARD_PATHS` is that project's change to make; this card is written to satisfy
|
||||
the same contract in the meantime.
|
||||
92
infospace/interfaces/federation.yaml
Normal file
92
infospace/interfaces/federation.yaml
Normal file
|
|
@ -0,0 +1,92 @@
|
|||
id: security-canon/federation-interface
|
||||
title: SecurityCanon Federation Interface Card
|
||||
consumer: security-canon
|
||||
canon_surfaces: [sec-authority]
|
||||
status: draft
|
||||
version: 0.1.0
|
||||
owner: security-canon
|
||||
scope: >-
|
||||
SECURITY-WP-0001-T04 federation boundary. Publishes the architecture-layer
|
||||
authority vocabulary. Not a complete inventory of the repository, and not a
|
||||
runtime adoption claim.
|
||||
schema_source:
|
||||
repository: info-tech-canon
|
||||
path: infospace/schemas/interface-card.schema.yaml
|
||||
authority:
|
||||
repository: the-custodian
|
||||
artifact: CUST-ADR-006
|
||||
path: canon/architecture/adr-006-canon-federation-concept-ownership.md
|
||||
revision: accepted-1
|
||||
abstraction_layer: architecture
|
||||
layer_note: >-
|
||||
SecurityCanon describes the relationships in which authority is exercised.
|
||||
CARING, in InfoTechCanon, analyses how an access-control implementation is
|
||||
composed. Different layers; neither subsumes the other. See SEC-ADR-001.
|
||||
peers:
|
||||
- repository: info-tech-canon
|
||||
relationship: shared-concept upstream; security-domain extension
|
||||
review_record: infospace/interfaces/security-canon-boundary.md
|
||||
import_manifest: infospace/vocabulary/mode-of-authority/imports.json
|
||||
- repository: interface-canon
|
||||
relationship: structural precedent for a focused domain canon
|
||||
- repository: commerce-canon
|
||||
relationship: structural precedent for a focused domain canon
|
||||
- repository: the-custodian
|
||||
relationship: governance authority
|
||||
exports:
|
||||
- artifact: sec-authority
|
||||
ledger_model: sec-authority
|
||||
kind: vocabulary
|
||||
path: infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md
|
||||
status: draft
|
||||
version: 0.2.0
|
||||
concepts:
|
||||
- AuthMode
|
||||
- AuthorityContext
|
||||
- AuthorityRealm
|
||||
- AuthorityProvenance
|
||||
- Activation
|
||||
- EvidenceBoundary
|
||||
- AccessSituation
|
||||
machine_readable:
|
||||
- infospace/vocabulary/mode-of-authority/auth-modes.yaml
|
||||
- infospace/vocabulary/mode-of-authority/dimensions.yaml
|
||||
availability: >-
|
||||
draft reference; adoption requires consumer review. No consumer adoption
|
||||
is recorded.
|
||||
imports:
|
||||
- repository: info-tech-canon
|
||||
artifacts: [itc-core, itc-access, itc-ident, itc-org, itc-purposes]
|
||||
manifest: infospace/vocabulary/mode-of-authority/imports.json
|
||||
source_commit: e1f98da015f32545254747c8e9f59b780c423d5b
|
||||
concepts: [Actor, Subject, Principal, Scope, AccessOperations, PrincipalType, Purpose]
|
||||
source_of_truth:
|
||||
vocabulary: security-canon
|
||||
shared_roots: info-tech-canon
|
||||
implementation_layer: info-tech-canon (CARING)
|
||||
mapping_rules:
|
||||
- Shared concepts retain their InfoTechCanon owner and are imported, never redefined.
|
||||
- Where concepts genuinely differ across layers, the names must visibly differ.
|
||||
- CARING may reference this vocabulary; this vocabulary does not redefine CARING.
|
||||
- Nothing flows upward as a redefinition of an InfoTechCanon concept.
|
||||
known_deviations:
|
||||
- >-
|
||||
The v0.1 research draft named its on-behalf-of dimension Subject, colliding
|
||||
with the InfoTechCanon-owned Actor/Subject binding. Renamed to
|
||||
AuthorityContext in 0.2.0 under SECURITY-DEC-2026-002; the draft is retained
|
||||
verbatim in research/ and reads subject = where the vocabulary reads
|
||||
authority_context =.
|
||||
- >-
|
||||
CARING section 32 carries a richer form of the actor/authority-context split,
|
||||
scoped to non-human subjects. The relationship is recorded as a mapping.
|
||||
Generalising it is InfoTechCanon's to accept and is not asserted here.
|
||||
- >-
|
||||
The G7 validator in prj-canon-federation pins card paths for info-tech-canon,
|
||||
commerce-canon and the-custodian only. Registering this card there is
|
||||
prj-canon-federation's change to make.
|
||||
expectations:
|
||||
- Review source changes and retain commit and content-hash provenance.
|
||||
- >-
|
||||
This card is published from the SecurityCanon side. InfoTechCanon acceptance
|
||||
of the boundary is recorded separately in the review record named above.
|
||||
- No stable promotion is asserted; the vocabulary is draft 0.2.0.
|
||||
41
infospace/vocabulary/mode-of-authority/imports.json
Normal file
41
infospace/vocabulary/mode-of-authority/imports.json
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
{
|
||||
"manifest": "sec-authority:ModeOfAuthority imports",
|
||||
"artifact": "sec-authority:ModeOfAuthority",
|
||||
"artifact_version": "0.2.0",
|
||||
"source_repository": "info-tech-canon",
|
||||
"source_commit": "e1f98da015f32545254747c8e9f59b780c423d5b",
|
||||
"pinned_at": "2026-09-20",
|
||||
"note": "Concepts imported, not redefined. SHA-256 values are of the Git blob at source_commit.",
|
||||
"imports": [
|
||||
{
|
||||
"artifact": "InfoTechCanonCore",
|
||||
"path": "infospace/kernel/InfoTechCanonCore.md",
|
||||
"sha256": "74661caea603876f71b4258963bd11a338cba63ef57a00fb8c41e2e51d07742c",
|
||||
"concepts": ["Artifact", "Ownership", "Relationship"]
|
||||
},
|
||||
{
|
||||
"artifact": "InfoTechCanonAccessControlModel",
|
||||
"path": "infospace/models/access-control/InfoTechCanonAccessControlModel.md",
|
||||
"sha256": "456e2534264b806098ac7be85d25e5e1cd1150b1e34934b07f46dabd909343bf",
|
||||
"concepts": ["Subject", "Principal", "Scope", "AccessOperations"]
|
||||
},
|
||||
{
|
||||
"artifact": "InfoTechCanonIdentityModel",
|
||||
"path": "infospace/models/identity/InfoTechCanonIdentityModel.md",
|
||||
"sha256": "20bc844d9de07041c40009cc5e3d6eeb42aeb7adcbb86b0194d4b2517aa23f32",
|
||||
"concepts": ["PrincipalType"]
|
||||
},
|
||||
{
|
||||
"artifact": "InfoTechCanonOrganizationModel",
|
||||
"path": "infospace/models/organization/InfoTechCanonOrganizationModel.md",
|
||||
"sha256": "bdb1277e78c3a0802f8ea08e058be093452390e61ca0f7e979051e48680fe6c3",
|
||||
"concepts": ["Actor"]
|
||||
},
|
||||
{
|
||||
"artifact": "InfoTechCanonPurposeDemandExtension",
|
||||
"path": "infospace/models/governance/InfoTechCanonPurposeDemandExtension.md",
|
||||
"sha256": "74637a7ed997691abf2c1370fffaa173010939a070d69853dc1f0a86cc8343bb",
|
||||
"concepts": ["Purpose"]
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
@ -103,7 +103,7 @@ referencing and non-collision, not a migration sizing exercise.
|
|||
|
||||
```task
|
||||
id: SECURITY-WP-0001-T04
|
||||
status: todo
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "a844ccdc-f75d-53b6-858e-c92f30aad7ce"
|
||||
```
|
||||
|
|
@ -230,3 +230,37 @@ remain open.
|
|||
|
||||
Generalising CARING §32 beyond non-human subjects was deliberately **not** bundled
|
||||
in; it is InfoTechCanon's to accept as a demand signal.
|
||||
|
||||
## Result — 2026-09-20 (T04)
|
||||
|
||||
[Federation interface card](../infospace/interfaces/federation.yaml) published at
|
||||
version 0.1.0, validating against InfoTechCanon's `interface-card.schema.yaml`.
|
||||
It declares one export surface, `sec-authority`, carrying the Mode of Authority
|
||||
vocabulary and its machine-readable catalogs, and names InfoTechCanon,
|
||||
InterfaceCanon, CommerceCanon and the Custodian as peers under CUST-ADR-006.
|
||||
|
||||
Imports are pinned in
|
||||
[`imports.json`](../infospace/vocabulary/mode-of-authority/imports.json) against
|
||||
InfoTechCanon `e1f98da0`, recording the path and SHA-256 of each source. All five
|
||||
hashes were verified to match Git blobs at that commit with the sources unchanged
|
||||
in the review checkout.
|
||||
|
||||
Reciprocal navigation runs both ways: this repository's
|
||||
[interfaces README](../infospace/interfaces/README.md) links the peer cards, and
|
||||
InfoTechCanon carries the
|
||||
[SecurityCanon boundary review](../../info-tech-canon/infospace/interfaces/security-canon-boundary.md)
|
||||
with its own README link, following the InterfaceCanon precedent.
|
||||
|
||||
Evidence. The prj-canon-federation G7 validator passes — three cards, six
|
||||
reciprocal peer links, 33 navigation links checked, no upstream changes since
|
||||
review. InfoTechCanon `make check` passes with 46 tests, clean validation and a
|
||||
passing small-saas profile after refreshing the generated indexes for the added
|
||||
file. No InfoTechCanon concept was transferred or removed. None of the seven
|
||||
concepts this canon declares appears in any InfoTechCanon `owned_concepts`
|
||||
declaration, so there is no ownership conflict.
|
||||
|
||||
Limits. The G7 validator pins card paths for info-tech-canon, commerce-canon and
|
||||
the-custodian only, so this card is written to the same contract but is not yet
|
||||
registered there; adding it is prj-canon-federation's change to make, and the
|
||||
card records that. The boundary acceptance is an agent review, not human
|
||||
sign-off, and records no consumer adoption or conformance claim.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue