approval-engine answered the presenting-actor question we put to them and the answer withdrew the client: nobody presents approval-engine-operator. Nothing in their repository obtains an OAuth token, and scope by scope the bundle never described a single actor -- approve belongs to the human client, emit is redundant, and no requester identity was ever settled for create. Annotated as withdrawn in the example config and the packet rather than deleted, because they asked for it to stay authenticable under CCR-2026-0018 if a presenter appears. The separation-of-duties observation is kept because it constrains the re-request: approve must not travel with the operational scopes. Raised rather than filed: "do not provision" cannot undo a provision. The client went live in the 2026-09-09 attended rollout, so the estate now holds a confidential credential that can create and approve approvals, that nobody presents, and that no consumer awaits. Standing capability with no counterparty is a worse resting state than either provisioning it for a named presenter or disabling it. Disablement is KeyCape's to execute and not KeyCape's to decide alone, so it goes to the owners rather than into a commit. Also records GH-DEC-2026-013 conditions (a) and (b) in the tenant contract, both of which strengthen what we had written about ourselves. Row four is normative, and in the direction we would not have guessed: a future change preferring the DIRECTORY is also void, because "the directory won" is still a winner and picking any winner turns a refusal into a silent cross-tenant assertion. And lifting the dynamic-registration exclusion now VOIDS the registration-bound shape that day rather than reopening it for review -- our "must be revisited" was too weak. The shape is recorded as a declared bounded gap, not the terminal state. Verification note: the Go suite could not be run green for this commit because a peer session is mid-edit on token.go and human_tenant_test.go for the §5 provenance work. Every file in this commit is YAML or Markdown; both YAML files were parsed and the example config's scope set and tenant were asserted unchanged. 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
69 lines
3.5 KiB
YAML
69 lines
3.5 KiB
YAML
# Non-secret static registration fragments for KeyCape's bounded JWT consumers. Merge these entries into the deployment-owned KeyCape config.
|
|
# The named environment variables must be materialized by an approved
|
|
# out-of-repository custody path; this file never contains their values.
|
|
clients:
|
|
- clientId: "codex-railiance-platform"
|
|
displayName: "Railiance platform coding agent"
|
|
allowedScopes: ["openbao:login"]
|
|
grantTypes: ["client_credentials"]
|
|
clientType: "confidential"
|
|
secretRef: "env:KEYCAPE_CODEX_RAILIANCE_PLATFORM_CLIENT_SECRET"
|
|
serviceSubject: "service:codex:railiance-platform"
|
|
tenant: "tenant:coulomb"
|
|
roles: ["coding-agent"]
|
|
tokenLifetime: "15m"
|
|
|
|
- clientId: "secrets-engine-openbao"
|
|
displayName: "secrets-engine OpenBao login"
|
|
allowedScopes: ["openbao:login"]
|
|
grantTypes: ["client_credentials"]
|
|
clientType: "confidential"
|
|
secretRef: "env:KEYCAPE_SECRETS_ENGINE_OPENBAO_CLIENT_SECRET"
|
|
serviceSubject: "service:secrets-engine"
|
|
tenant: "tenant:coulomb"
|
|
roles: ["secrets-engine"]
|
|
tokenLifetime: "15m"
|
|
|
|
- clientId: "secrets-engine-approval"
|
|
displayName: "secrets-engine approval consume client"
|
|
audience: "approval-engine"
|
|
allowedScopes: ["approval:read", "approval:consume"]
|
|
grantTypes: ["client_credentials"]
|
|
clientType: "confidential"
|
|
secretRef: "env:KEYCAPE_SECRETS_ENGINE_APPROVAL_CLIENT_SECRET"
|
|
serviceSubject: "service:secrets-engine"
|
|
# Landlord-zone platform tenant, decision 5ed3fb35-eca9-413a-82b9-95171ba85bf6.
|
|
# Exact spelling; no alias to tenant:coulomb. See docs/tenant-claim-contract.md.
|
|
tenant: "tenant:platform"
|
|
roles: ["secrets-engine"]
|
|
tokenLifetime: "15m"
|
|
|
|
# WITHDRAWN BY THE REQUESTING OWNER, 2026-09-09. approval-engine asked that this
|
|
# client not be provisioned: nothing in their repository obtains an OAuth token,
|
|
# and scope by scope the bundle does not describe a single actor —
|
|
# approval:approve now belongs to the informed-decision human client,
|
|
# approval:emit is redundant (the server emits its own heartbeat with no token),
|
|
# and no requester identity was ever settled for approval:create. It was a
|
|
# convenience bundle written when a lifecycle operator was assumed to exist.
|
|
#
|
|
# Kept rather than deleted at their request: verifier custody CCR-2026-0018
|
|
# stands, so the client stays authenticable if a presenter ever appears. It is
|
|
# already live from the 2026-09-09 attended rollout, so this annotation does not
|
|
# remove it — see KEY-WP-0013-T02.
|
|
#
|
|
# Do not widen it, and do not treat it as a template. When a presenter is named,
|
|
# approval-engine will re-request NARROWED to that presenter's scopes, and
|
|
# approval:approve must not travel with the operational scopes.
|
|
- clientId: "approval-engine-operator"
|
|
displayName: "approval-engine lifecycle operator (withdrawn: no presenter)"
|
|
audience: "approval-engine"
|
|
allowedScopes: ["approval:create", "approval:read", "approval:approve", "approval:revoke", "approval:supersede", "approval:observe", "approval:emit"]
|
|
grantTypes: ["client_credentials"]
|
|
clientType: "confidential"
|
|
secretRef: "env:KEYCAPE_APPROVAL_ENGINE_OPERATOR_CLIENT_SECRET"
|
|
serviceSubject: "service:approval-engine-operator"
|
|
# Landlord-zone platform tenant, decision 5ed3fb35-eca9-413a-82b9-95171ba85bf6.
|
|
# Exact spelling; no alias to tenant:coulomb. See docs/tenant-claim-contract.md.
|
|
tenant: "tenant:platform"
|
|
roles: ["approval-operator"]
|
|
tokenLifetime: "15m"
|