tegwick
7dda967c27
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 45s
G10 waits on custody and platform owners and cannot close from here. What was doable: verify the handoffs actually went out, replace a remembered live state with an observed one, and find out whether main is safe to deploy. The last question found a defect in this repository's own recent work. Handoffs verified independently rather than trusted: all seven messages are in the hub with receipt ids. This gap was reopened once for claimed-but-unsent delivery, so the claim deserved the same scrutiny. Live state read from the cluster read-only: image main-153258b, only the Qonto secret materialized so the approval clients remain unprovisioned, four registered clients, no tenantEngine block. That also corrects an earlier claim of mine -- the deployed config sets userOU explicitly, so the KEY-WP-0023 default fix was never a production issue. The precondition: KEY-WP-0019 discovers the expected issuer from authelia.tokenBaseURL, and the deployed Authelia derives its advertised issuer from the request Host, advertising the in-cluster address to KeyCape and the browser-facing one to browsers. Verification fails closed, so a mismatch breaks every human login and looks like a broken login rather than a misconfiguration. Which value the token carries needs a real login against production to settle and was not determined here. Two mitigations: docs/operations.md documents pinning authelia.issuer and jwksUrl, with the curl that reveals what the provider advertises for a given Host; and the authentication failure event now carries a specific reason, so id_token_issuer_mismatch is distinguishable from a signature failure or an unreachable key set. The browser still learns nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NV9oijZukGyGbRQGGKnK4P Assistant: claude-code Assistant-Model: opus Assistant-Process: 713576@bnt-lap001 Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6 |
||
|---|---|---|
| .. | ||
| ADHOC-2026-09-05.md | ||
| ADHOC-2026-09-07.md | ||
| KEY-WP-0001-keycape-implementation.md | ||
| KEY-WP-0002-container-image-gitea.md | ||
| KEY-WP-0003-bootstrap-console-oidc-mfa-login.md | ||
| KEY-WP-0004-binky-hedgehog-tenant-onboarding.md | ||
| KEY-WP-0005-iam-profile-core-claims.md | ||
| KEY-WP-0006-client-credentials-service-tokens.md | ||
| KEY-WP-0007-user-engine-portal-oidc-client.md | ||
| KEY-WP-0008-registration-handoff-and-client-mfa-policy.md | ||
| KEY-WP-0009-provider-capabilities-and-service-identities.md | ||
| KEY-WP-0010-openbao-operator-loopback-callback.md | ||
| KEY-WP-0011-live-secret-exposure-recovery.md | ||
| KEY-WP-0012-userinfo-canonical-subject-resolution.md | ||
| KEY-WP-0013-approval-engine-resource-audience.md | ||
| KEY-WP-0014-native-credential-lane-handoff.md | ||
| KEY-WP-0015-scope-intent-assessment.md | ||
| KEY-WP-0016-authorization-code-protocol-hardening.md | ||
| KEY-WP-0017-canonical-model-and-discovery-conformance.md | ||
| KEY-WP-0018-export-completeness-evidence.md | ||
| KEY-WP-0019-upstream-provider-token-verification.md | ||
| KEY-WP-0020-migration-contract-preservation.md | ||
| KEY-WP-0021-snapshot-attribute-validation.md | ||
| KEY-WP-0022-replacement-harness-and-external-conformance.md | ||
| KEY-WP-0023-live-migration-proof.md | ||
| KEY-WP-0024-tenant-roles-opt-in-wiring.md | ||
| KEY-WP-0025-runtime-lifecycle-and-readiness.md | ||
| KEY-WP-0026-packaging-bootstrap-and-credential-handling.md | ||
| KEY-WP-0027-rollout-readiness-and-live-state.md | ||