coulomb/key-cape
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
key-cape/INTENT.md
tegwick 9cb950752f Declare key-cape's layer as Tooling in INTENT.md frontmatter. 
Discharges the §11 declaration obligation found in FLEX-WP-0030 B2 and
raised by gate-house (GH-WP-0004-T08). Form per GH-DEC-2026-017: INTENT.md
governs, no sidecar, no standard version. Records the PIP-shaped tension of
the token endpoint and the access-engine claims boundary from this side.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
2026-09-21 12:36:03 +02:00

6.8 KiB
Raw Blame History

layer role repository declared_by declared_at ruling tooling_contacts non_tooling_clients
Tooling — key-cape INTENT.md 2026-09-21 GH-DEC-2026-017
target shape rationale
authelia, lldap, privacyidea packaged-backend Implementation dependencies inside key-cape's own tooling boundary, not separately owned estate capabilities.
target shape rationale
kubernetes-secret (secretRef) delivered-reference Confidential client secrets arrive as env secretRefs from a separate Secret delivered by the platform owner; key-cape holds no OpenBao client and never carries secret values in config.
target layer rationale
state-hub not-catalogued Work records, workplans and progress events only.

INTENT

KeyCape's layer is Tooling under the NetKingdom security layer model; the machine-readable declaration is the frontmatter above, and this sentence is not. It provides deterministic authentication and identity claims through the versioned IAM profile, packaging Authelia, LLDAP, and privacyIDEA. Authorization decisions belong to access-engine; KeyCape is not an authorization decision point. Issuing a role or scope claim does not decide access to a resource.

These backend components are implementation dependencies of KeyCape's tooling boundary. Separate catalog entries are unnecessary until they expose independently owned estate capabilities. Staff integration follows engine APIs as required by the layer model; this declaration does not certify every existing caller path.

Purpose

This repository exists to provide a lightweight, profile-conformant identity and access management (IAM) system.

It ensures that applications can rely on a stable, versioned authentication contract independent of the underlying IAM implementation.

Primary Utility

The repository provides an implementation of a versioned IAM profile that:

  • Delivers OIDC/PKCE-based authentication with strong security constraints
  • Normalizes identity data across heterogeneous backend systems
  • Enforces strict adherence to the defined IAM contract
  • Enables seamless migration between lightweight and expanded IAM modes

It transforms IAM from a system dependency into a replaceable, contract-driven capability.

Intended Users

  • Application developers integrating against the IAM profile
  • Infrastructure operators (adm) deploying IAM in constrained environments
  • Automation systems (atm) managing identity, migration, and validation workflows
  • LLM agents (agt) interacting with authenticated services

Strategic Role in the System

This repository serves as the lightweight IAM layer:

  • It provides a resource-efficient implementation of the IAM profile for environments with limited resources

  • It anchors IAM around a profile contract rather than a specific implementation

  • It enables a two-mode architecture:

    • Lightweight mode (this implementation)
    • Expanded mode (a heavier, full-featured implementation)

The profile ensures that both modes are interchangeable without application changes.

Strategic Boundaries

This repository is not intended to:

  • Become a full-featured, general-purpose IAM platform
  • Extend beyond the defined IAM profile
  • Support features that weaken security guarantees (e.g., implicit flow, wildcard redirects)
  • Replace or wrap the heavier expanded-mode implementation

Its responsibility is limited to strict, secure, and transparent profile implementation.

Design Principles

  • Contract over implementation Applications depend on the IAM profile, not on KeyCape internals

  • Security through constraint Only explicitly allowed features are supported; unsafe patterns are rejected

  • Explicitness over convenience Unsupported features must fail clearly and predictably

  • Replaceability by design The system must be swappable with a heavier profile implementation without breaking integrations

  • Canonical identity model Identity data must be normalized and consistent across all backends

Maturity Target

A mature version of this repository should:

  • Fully implement and enforce the IAM profile with zero ambiguity
  • Provide complete migration pathways between lightweight and expanded modes
  • Offer deterministic and testable behavior across all supported scenarios
  • Act as a reference implementation of the IAM profile
  • Enable IAM deployments that are minimal, secure, and operationally efficient

Stability Note

Changes to this file represent a deliberate shift in the IAM contract, scope, or architectural role of this repository.

Such changes must be made with explicit intent, as they directly affect all dependent applications.