2026-09-05 00:41:17 +02:00
|
|
|
# Non-secret static registration fragments for KeyCape's bounded JWT consumers. Merge these entries into the deployment-owned KeyCape config.
|
2026-08-23 13:10:13 +02:00
|
|
|
# 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"
|
2026-09-05 00:41:17 +02:00
|
|
|
|
|
|
|
|
- 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"
|
Align approval registrations to the tenant:platform decision
Operator decision 5ed3fb35-eca9-413a-82b9-95171ba85bf6 accepts tenant:platform
as the platform management tenant for the Glas approval chain, requiring exact
spelling across the approval store, the service-client JWT claim and the
lifecycle CheckRequest.
Changes the tenant field on secrets-engine-approval and approval-engine-operator
only, in the registration fixture and the provisioning packet. Unrelated clients
and the human directory default keep tenant:coulomb, and no audience, scope,
subject, role, lifetime or MFA grant changes.
Adds issuance evidence that the approval shape emits tenant:platform exactly and
never an alias the caller requests, that the OpenBao client gains no
cross-tenant reach, and a fixture guard pinning every reviewed client's tenant.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NV9oijZukGyGbRQGGKnK4P
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 713576@bnt-lap001
Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6
2026-09-06 22:30:32 +02:00
|
|
|
# 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"
|
2026-09-05 00:41:17 +02:00
|
|
|
roles: ["secrets-engine"]
|
|
|
|
|
tokenLifetime: "15m"
|
|
|
|
|
|
Record the operator withdrawal and the gate-house tenant conditions
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
2026-09-09 23:30:09 +02:00
|
|
|
# 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.
|
2026-09-05 00:41:17 +02:00
|
|
|
- clientId: "approval-engine-operator"
|
Record the operator withdrawal and the gate-house tenant conditions
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
2026-09-09 23:30:09 +02:00
|
|
|
displayName: "approval-engine lifecycle operator (withdrawn: no presenter)"
|
2026-09-05 00:41:17 +02:00
|
|
|
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"
|
Align approval registrations to the tenant:platform decision
Operator decision 5ed3fb35-eca9-413a-82b9-95171ba85bf6 accepts tenant:platform
as the platform management tenant for the Glas approval chain, requiring exact
spelling across the approval store, the service-client JWT claim and the
lifecycle CheckRequest.
Changes the tenant field on secrets-engine-approval and approval-engine-operator
only, in the registration fixture and the provisioning packet. Unrelated clients
and the human directory default keep tenant:coulomb, and no audience, scope,
subject, role, lifetime or MFA grant changes.
Adds issuance evidence that the approval shape emits tenant:platform exactly and
never an alias the caller requests, that the OpenBao client gains no
cross-tenant reach, and a fixture guard pinning every reviewed client's tenant.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NV9oijZukGyGbRQGGKnK4P
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 713576@bnt-lap001
Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6
2026-09-06 22:30:32 +02:00
|
|
|
# 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"
|
2026-09-05 00:41:17 +02:00
|
|
|
roles: ["approval-operator"]
|
|
|
|
|
tokenLifetime: "15m"
|
Register the approver client now its callback exists
informed-decision submitted client_id informed-decision-approver and redirect
https://decisions.coulomb.social/auth/callback, with the origin already live and
verified by them rather than reported: both / and /auth/callback return 200 on a
Let's Encrypt certificate valid to 2026-12-09. The host is decisions, not the
decide of an earlier draft. Its path serves a placeholder for now, which does not
matter -- the redirect is matched as an exact string and never fetched.
Published as a public authorization_code client with S256 PKCE, audience
approval-engine, scopes openid/approval:read/approval:approve, mfaRequired true
and a declared tenant:platform. No secretRef, since PKCE is the whole proof.
TestApproverRegistrationShapeIsExact pins every field, so widening a scope or
relaxing MFA fails the build rather than reading as an edit, and asserts the
registration passes startup validation -- proving the KEY-WP-0028 tenant
exemption holds for the registration that actually depends on it.
Two existing guards fired on the way in and neither was loosened. The tenant pin
refused an unreviewed client carrying a tenant, which is its purpose, so the
approver was added to its reviewed set deliberately. And the audience test
panicked slicing secretRef[4:], an assumption that held while the fixture had
only confidential clients; the approver is the first public one, so the loop now
guards on the env: prefix.
The declared tenant reaches the token by the GH-DEC-2026-013 gap route by
construction, and tenant_source says so: registration, never directory.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NV9oijZukGyGbRQGGKnK4P
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 713576@bnt-lap001
Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6
2026-09-10 22:50:13 +02:00
|
|
|
|
|
|
|
|
# Human approver browser client. Submitted by informed-decision 2026-09-10
|
|
|
|
|
# (INFD-WP-0001-T07) with the origin already live: both / and /auth/callback
|
|
|
|
|
# return 200 from 92.205.62.239 on a Let's Encrypt certificate
|
|
|
|
|
# CN=decisions.coulomb.social valid 2026-09-10 to 2026-12-09, deployed by
|
|
|
|
|
# railiance-apps. The host is decisions.coulomb.social, NOT the
|
|
|
|
|
# decide.coulomb.social an earlier draft proposed; register the string verbatim.
|
|
|
|
|
#
|
|
|
|
|
# The path currently serves an nginx placeholder while their surface is gated on
|
|
|
|
|
# APPROVAL-WP-0002-T01. That does not affect this registration: the redirect is
|
|
|
|
|
# matched as an exact string at /authorize and never fetched.
|
|
|
|
|
#
|
|
|
|
|
# No secretRef: this is a public client and authenticates with PKCE alone. No
|
|
|
|
|
# serviceSubject or roles either — on a browser client both are silently ignored
|
|
|
|
|
# and config validation rejects them (KEY-WP-0028); the subject and roles come
|
|
|
|
|
# from the directory user.
|
|
|
|
|
- clientId: "informed-decision-approver"
|
|
|
|
|
displayName: "informed-decision approver surface"
|
|
|
|
|
audience: "approval-engine"
|
|
|
|
|
redirectUris:
|
|
|
|
|
- "https://decisions.coulomb.social/auth/callback"
|
|
|
|
|
allowedScopes: ["openid", "approval:read", "approval:approve"]
|
|
|
|
|
grantTypes: ["authorization_code"]
|
|
|
|
|
clientType: "public"
|
|
|
|
|
# Declared, not inherited. Nothing populates domain.User.Tenant for approver
|
|
|
|
|
# users, so this reaches the token by the GH-DEC-2026-013 declared-gap route
|
|
|
|
|
# by construction, and the token says so: tenant_source is "registration",
|
|
|
|
|
# never "directory". Admissible for approval-engine's store-isolation gate;
|
|
|
|
|
# NOT admissible for any doctrine turning on this person's membership of the
|
|
|
|
|
# zone. See docs/tenant-claim-contract.md.
|
|
|
|
|
tenant: "tenant:platform"
|
|
|
|
|
# Approval is a human-in-the-loop control, so MFA is required rather than
|
|
|
|
|
# left to the provider default.
|
|
|
|
|
mfaRequired: true
|