Name secrets-engine OpenBao registration and custody owner gates

Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a1046b-5629-7f52-badd-f718eadb6042

docs/secrets-engine-openbao-owner-packet.md

@@ -0,0 +1,78 @@
+# Secrets Engine OpenBao owner packet
+
+Prepared 2026-10-04. Source preparation only; not approved for live execution.
+Owning work: KEY-WP-0037-T02 (protected custody), T03 (live registration),
+T04 (actual issuance evidence). Provider contract stays KEY-WP-0009 completed.
+
+## Reviewed existing contract
+
+KeyCape base: 672e1faf4b3401ff7bf68bb0b29f8dc50ca51ac6.
+Accepted source: `config/service-clients.example.yaml` and
+`docs/openbao-service-auth-contract.md`. Deployment authority:
+`net-kingdom/sso-mfa/k8s/keycape/deployment.yaml` and deployment-owned config.
+Existing preservation/rollout reference:
+`net-kingdom/sso-mfa/k8s/keycape/approval-clients-rollout.py` and its synthetic
+exercise/tests. That helper targets approval clients and must not be invoked
+for this service registration without an owner-specific reviewed adaptation.
+
+Exact registration: clientId/audience secrets-engine-openbao; subject
+service:secrets-engine; principal_type service; tenant tenant:platform;
+roles [secrets-engine]; scopes [openbao:login]; grants [client_credentials];
+confidential; secretRef env:KEYCAPE_SECRETS_ENGINE_OPENBAO_CLIENT_SECRET;
+tokenLifetime 15m. Issuer https://kc.coulomb.social, RS256 with JWKS /jwks,
+POST /token and client_secret_basic. No resource-audience override, refresh
+or ID token. AAL1 client-secret authentication never grants human approval.
+
+## Candidate custody coordinates requiring owner acceptance
+
+These are proposals, not existing allocated/provisioned resources:
+
+- Authoritative platform KV candidate:
+  platform/services/keycape/secrets-engine-openbao, field CLIENT_SECRET.
+- Issuer-side sso Secret candidate: keycape-secrets-engine-openbao-client,
+  key client-secret, delivered from the exact KV field by an ESO reader scoped
+  to that single path, 15-minute reader tokens and explicit safe target metadata.
+- Only one new Deployment env reference: KEYCAPE_SECRETS_ENGINE_OPENBAO_CLIENT_SECRET
+  from that Secret/key. Do not copy values into deployment YAML or config.
+- Client-side consumer: an explicitly chosen mode-0600 file outside every Git
+  worktree, accepted by secrets-engine's service-auth provider. Its actual host,
+  owner, path, delivery mechanism and lifecycle must be named by secrets-engine
+  and platform before approval; no directory or secret value is guessed here.
+
+Platform must allocate/review separate custody CCR and issuer-reader metadata.
+The consumer file delivery cannot be treated as implied by issuer-side ESO.
+A single random confidential value serves the issuer and the consumer in their
+separate approved copies; approval/verifier/requester credentials stay separate.
+No existing live version, receipt, protected copy or registration is asserted.
+
+## Concrete preparation still required
+
+1. Platform and secrets-engine accept/correct the proposed exact custody
+   coordinates, and name consumer delivery plus revocation/rotation ownership.
+2. Prepare the silent attended custody child with bounded generation/write,
+   compare-before-write, no secret argv/output, native receipt, failure cleanup
+   and version-preserving retry; fix consumer coordinates before founder approval.
+3. NetKingdom prepares the exact-match single-client merge and one env binding,
+   pins the actual image digest and source, verifies preservation/rollback with
+   synthetic credentials and reviews cluster dry-run/diff/headroom. No blind
+   whole-config reapplication or unrelated issuer changes.
+4. Founder approves the exact separate live custody and registration packet.
+   The previously approved informed-decision reader design grants neither.
+5. Native live issuance validates signature and the complete claim set, denies
+   wrong secret/excess scope, and verifies existing human login. After that,
+   platform performs its separately approved isolated OpenBao provisioning and
+   login-only policy proof, TTL/use-limit/expiry denial and explicit self-revoke.
+
+Rollback removes only this new registration/binding after disabling issuance,
+revokes the new readers, and destroys/retires the copies per the approved CCR.
+Previously issued self-contained JWTs survive until 15-minute expiry; resulting
+OpenBao tokens have independently bounded TTL/use limits. Avoid claiming instant
+JWT recall. Cleanup failures remain unresolved evidence.
+
+## Current evidence boundary
+
+No live resources, registration, client secret, tokens or issuer were read or
+changed by this review. Existing source tests can establish only the provider
+contract. State Hub request b4fc62ea-f92c-4410-919a-9f3cce2d406b on thread
+f84637fa-2355-4971-a2dc-7f1fd01710a8 requested the owner work; this packet closes
+the missing owning-task identification, not the live acceptance gate.