Confirm groups and MFA for the secrets-engine-openbao operator reader

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 132360@bnt-lap001
Assistant-Session: 769b1afd-4330-4c86-96b2-e510e26db42b

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

@@ -35,10 +35,12 @@ These are proposals, not existing allocated/provisioned resources:
   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.
+- Client-side consumer (superseded 2026-10-06 by founder direction and the
+  ops-mason plan `plans/keycape-secrets-engine-openbao-client-custody.md`,
+  MASON-WP-0009): there is no persistent workstation copy. The value lives only
+  in OpenBao. secrets-engine reads it per command into memory through the attended
+  OIDC role `keycape-secrets-engine-openbao-operator-workload-kv-read` on
+  `auth/netkingdom`, then revokes that token.
 
 Platform must allocate/review separate custody CCR and issuer-reader metadata.
 The consumer file delivery cannot be treated as implied by issuer-side ESO.
@@ -46,6 +48,24 @@ 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.
 
+## KeyCape confirmation for the operator OIDC reader (2026-10-06)
+
+The reader logs in through the `openbao-admin` public client (authorization
+code, scopes include `groups`). Source behaviour at e22029e:
+
+- Groups: human ID tokens always carry `groups` from LLDAP
+  (`src/internal/server/oidc/token.go`, `claims["groups"]`), so
+  `groups_claim: groups` with bound `net-kingdom-admins` is satisfiable. This
+  matches CCR-2026-0019.
+- MFA: `openbao-admin` has no `mfaRequired` pin. MFA is enforced because the
+  deployed provider default is `privacyidea.requireForAll: true` (NetKingdom
+  README). That is a deployment default rather than a client pin, so the role
+  should bind the assurance claim as well: `bound_claims_type: string`,
+  `"/assurance/level": "aal2"`. The token carries `assurance` as
+  `{level, methods, mfa, at}`, and `aal2` appears only after a verified factor.
+  Pinning `mfaRequired: true` on `openbao-admin` is the stronger NetKingdom
+  option, but it changes every OpenBao admin login and needs its own go.
+
 ## Concrete preparation still required
 
 1. Platform and secrets-engine accept/correct the proposed exact custody