# KeyCape service-auth consumer boundary

secrets-engine now implements the consumer half of KeyCape's accepted
`secrets-engine-openbao` service-auth contract. It performs one explicit HTTPS
`client_credentials` exchange, keeps the resulting JWT in memory, and validates
the non-cryptographic contract before any future OpenBao login:

- subject `service:secrets-engine`, audience/client `secrets-engine-openbao`;
- service principal in `tenant:coulomb`, role `secrets-engine`;
- exact `openbao:login` scope and KeyCape AAL1 client-secret assurance;
- RS256 declaration, bounded issue/expiry timestamps, maximum 15-minute life,
  and renewal when no more than three minutes remain;
- no ID token, refresh token, implicit retry provider, or fallback identity.

The confidential-client secret must be an explicitly selected mode-0600 file
outside every Git worktree. It is sent with HTTP Basic authentication and never
placed in a request body, command argument, evidence record, or object
representation.

JWT payload parsing does not prove a signature. OpenBao must verify RS256
against the configured issuer before issuing a token. railiance-platform owns
the exact OpenBao JWT auth mount/role, issuer keys, claim bindings, token
policy, TTL/use limits, and cryptographic verification.

When `SECRETS_ENGINE_OPENBAO_JWT_LOGIN` names that contract, the CLI selects
`service-jwt` and logs in for one command, then self-revokes the OpenBao
token. Failure of that path never falls back to `--bootstrap-token-file`,
`BAO_TOKEN`, or AppRole. Until the contract is published, `--auth auto` keeps
those named providers and `--auth service-jwt` fail-closes. See
[openbao-jwt-login.md](openbao-jwt-login.md).

Canonical provider contract:
`key-cape/docs/openbao-service-auth-contract.md` (reviewed 2026-08-23).