tegwick
329e48f64a
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 46s
KEY-WP-0013-T05's tenant blocker did not need the decision it was waiting on. The two proposed resolutions differ in where a human's tenant comes from -- the directory record, or the client registration -- and an implementation exists that is correct under either, so the choice can be made later without another migration. A client registration may now declare a tenant. humanTenant() resolves it by four rules: no declaration keeps the directory answer unchanged; a declared zone applies where the directory has placed the user nowhere; agreement passes; and a declared zone conflicting with a directory assignment refuses issuance rather than relabelling the user. The refusal is the design, not an edge case. A registration can bind a zone for unplaced users and can never move a placed one, so this gets the approval chain its tenant:platform without writing a general cross-tenant override into the issuer. It fails closed rather than picking a winner, because either answer would be a silent cross-tenant assertion, and it reports 403 with error_type: tenant_binding so an operator can tell a misconfigured registration from a rejected login. If the owners later populate directory tenants, the same code stops supplying the zone and starts enforcing agreement with it. Safe only because client registrations are static and deployment-owned. The tenant contract records that this rule must be revisited if dynamic client registration is ever admitted. Tests cover all four rules; neutering the conflict check fails the relabel test rather than passing silently. T05 now waits on one thing only: the client_id and callback URI from informed-decision once it has a deployed origin. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016uV8zoCKpA1WRAxsKRYbdH Assistant: claude-code Assistant-Model: opus Assistant-Process: 1182213@bnt-lap001 Assistant-Session: 966597b9-ae61-46a4-8b9e-1594ab3ec4ad |
||
|---|---|---|
| .. | ||
| 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 | ||