tegwick
a267c98087
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
92 lines
3.9 KiB
YAML
92 lines
3.9 KiB
YAML
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.
|