diff --git a/infospace/interfaces/README.md b/infospace/interfaces/README.md new file mode 100644 index 0000000..d230fc6 --- /dev/null +++ b/infospace/interfaces/README.md @@ -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. diff --git a/infospace/interfaces/federation.yaml b/infospace/interfaces/federation.yaml new file mode 100644 index 0000000..1cb2808 --- /dev/null +++ b/infospace/interfaces/federation.yaml @@ -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. diff --git a/infospace/vocabulary/mode-of-authority/imports.json b/infospace/vocabulary/mode-of-authority/imports.json new file mode 100644 index 0000000..23e193c --- /dev/null +++ b/infospace/vocabulary/mode-of-authority/imports.json @@ -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"] + } + ] +} diff --git a/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md b/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md index d79dba4..0ecc4d0 100644 --- a/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md +++ b/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md @@ -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.