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.