flex-auth/examples
tegwick 9f3e7e363a
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
Build and Publish Container Image / build-and-push (push) Successful in 53s
Add schemaguard; correct check_request subject.type against shipped reality
approval-engine suggested a conformance check after the examples-contradict-
prose class hit a third repository -- theirs. Fifteen lines, they said, and
it would have caught our caring fixture and our provenance omission. Worth
stealing, so we stole it.

internal/schemaguard validates published examples against published schemas.
It implements only the JSON Schema subset these schemas use, and the property
that makes it trustworthy is that an unrecognised keyword FAILS rather than
skips: a validator that silently approves what it does not understand invites
reliance it cannot support. It found three things on first run.

ONE, AND THE LARGEST: check_request.schema.json pointed subject.type at
CARING's subject_type enum (Human, Service, ...), and no consumer sends that
vocabulary. user-engine sends human, tenant-engine and secrets-engine send
service, and ops-warden sends adm/agt/atm -- an actor-type vocabulary CARING
does not model at all. Our published schema declared three live integrations
non-conformant. A rule that outlaws shipped correct behaviour is the rule
that is wrong, so the $ref is replaced with an opaque non-empty string and a
description saying why. CARING's enum remains correct where it belongs: the
registry's subject_manifest.yaml, where Service is right.

TWO: policy_package_note, which this session added to the caring example's
decision provenance, is undeclared under additionalProperties:false. Our own
annotation broke the conformance it was annotating. Moved to the envelope's
outer provenance.

THREE: the secrets-engine fixtures carried partial approval-claims, missing
binding, freshness and validity. A partial claim in a fixture is how a
consumer learns the wrong shape -- the same mechanism that produced the
destroy defect. They are now complete and valid against approval-engine's
schema, including the now-required binding.pdp_digest, and a test validates
them against that schema when the sibling repo is present.

The destroy replay fixture is regenerated accordingly and the replay README's
pinned digests updated, since a stale digest table is the same defect wearing
a different hat.

Closed the binding-mapping open item. approval-engine declined to publish a
vocabulary mapping and their reasoning is better than the request: a PIP
asserting secrets.kv.destroy MEANS destroy would author semantics over two
vocabularies it owns neither of, and a wrong mapping silently accepts a claim
approved for a different action. pdp_digest is the mapping precisely because
it does not translate. It is now always present and nullable, so the destroy
gate is pdp_digest non-null and equal, enforced at the PEP.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTbVXpEiXA7mNJVpDnEPcB

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 412054@bnt-lap001
Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19
2026-09-06 14:21:28 +02:00
..
caring Add schemaguard; correct check_request subject.type against shipped reality 2026-09-06 14:21:28 +02:00
claims Align IAM Profile consumption with v0.2 2026-05-22 14:35:30 +02:00
markitect Add Markitect check fixtures 2026-05-17 06:32:05 +02:00
ops-warden feat(policy): adopt security zone stances 2026-08-22 15:17:13 +02:00
qonto-assistant Register qonto-assistant as a protected system (finance.qonto.read) 2026-07-24 00:19:26 +02:00
railiance-platform feat(policy): add credential grant authorization package 2026-08-23 13:59:03 +02:00
secrets-engine Add schemaguard; correct check_request subject.type against shipped reality 2026-09-06 14:21:28 +02:00
tenant-engine Record tenant-engine guardrail pin and handoff caveats 2026-08-16 10:07:31 +02:00
topaz Implement Topaz adapter 2026-05-17 06:58:04 +02:00
user-engine Close FLEX-WP-0009 with live user-engine policy evidence 2026-08-16 01:16:23 +02:00
README.md FLEX-WP-0006: implement ops-warden signing gate policy 2026-06-23 21:17:42 +02:00

examples/

Runnable examples used both as documentation and as test fixtures.

Expected layout (filled in across FLEX-WP-0002 / FLEX-WP-0003 / FLEX-WP-0005):

examples/
  claims/                  # key-cape lightweight-mode and Keycloak heavy-mode
                           # claim envelopes (P5.5)
  caring/                  # executable CARING descriptor, request,
                           # decision, registry, and audit fixtures (P2.1)
  markitect/               # FlexAuthResourceManifest fixtures, decision
                           # fixtures, and Rego-in-Markdown policy packages
  ops-warden/              # SSH certificate signing policy-gate fixtures
                           # for ops-warden policy.enabled smoke checks
  topaz/                   # docker-compose + sample directory and policy
                           # for the Topaz alignment spike (P5.4)
  policies/                # generic Rego-in-Markdown packages used by
                           # the standalone core tests