tegwick
8ab4891043
Insert DevOps Secrets Management Canon v1.0 unchanged, with a placement preface that keeps shared roots upstream. Publish it on the federation card. Assistant: grok Assistant-Session: 01a12ce1-7ded-7e03-a845-2ece8a573af4
118 lines
4.9 KiB
YAML
118 lines
4.9 KiB
YAML
id: security-canon/federation-interface
|
|
title: SecurityCanon Federation Interface Card
|
|
consumer: security-canon
|
|
canon_surfaces: [sec-authority, sec-dsm]
|
|
status: draft
|
|
version: 0.2.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.
|
|
- artifact: sec-dsm
|
|
ledger_model: sec-dsm
|
|
kind: standard
|
|
path: infospace/standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md
|
|
status: stable
|
|
version: 1.0.0
|
|
concepts:
|
|
- SecretsPreferenceHierarchy
|
|
- DynamicCredential
|
|
- ProducerCredential
|
|
- SecretsDecisionProcedure
|
|
- SecretsException
|
|
availability: >-
|
|
Stable practice standard. Gate House adopts it as the secrets best-practice
|
|
guide. ops-mason and ops-warden follow it. Custody and issuance stay with
|
|
secrets-engine; lane operation stays with ops-warden; route construction
|
|
stays with ops-mason.
|
|
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
|
|
secrets_practice: security-canon (SEC-DSM)
|
|
shared_roots: info-tech-canon
|
|
implementation_layer: info-tech-canon (CARING)
|
|
estate_doctrine: gate-house
|
|
credential_custody: secrets-engine
|
|
route_construction: ops-mason
|
|
lane_operation: ops-warden
|
|
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.
|
|
- >-
|
|
Section 4 of SEC-DSM uses Principal, Capability, and Authority as practice
|
|
language. Those concepts stay owned upstream. The standard's preface records
|
|
the reading. It does not add them to owned_concepts.
|
|
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.
|