coulomb/key-cape
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
key-cape/docs/approval-engine-provisioning-request.yaml
tegwick d29032d6c4 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

133 lines
7.6 KiB
YAML
Raw Blame History

# Proposed non-secret admission packet. This is not executable authorization.
# Tenant for both requests is tenant:platform per decision
# 5ed3fb35-eca9-413a-82b9-95171ba85bf6 (landlord zone). Exact spelling required
# across the approval store, these JWT claims and the lifecycle CheckRequest;
# no alias to platform or tenant:coulomb.
status: awaiting-custody-admission
owner: key-cape
resource_audience: approval-engine
issuer: https://kc.coulomb.social
registration_source: config/service-clients.example.yaml
requests:
- client_id: secrets-engine-approval
subject: service:secrets-engine
tenant: tenant:platform
scopes: [approval:read, approval:consume]
lifetime: 15m
proposed_openbao_path: platform/workloads/secrets-engine/approval-client
field: CLIENT_SECRET
proposed_kubernetes_secret: sso/keycape-secrets-engine-approval-client
kubernetes_key: client-secret
keycape_environment: KEYCAPE_SECRETS_ENGINE_APPROVAL_CLIENT_SECRET
custody_owner: railiance-platform
consumer: secrets-engine
- client_id: approval-engine-operator
subject: service:approval-engine-operator
tenant: tenant:platform
scopes: [approval:create, approval:read, approval:approve, approval:revoke, approval:supersede, approval:observe, approval:emit]
lifetime: 15m
proposed_openbao_path: platform/workloads/approval-engine/operator-client
field: CLIENT_SECRET
proposed_kubernetes_secret: sso/keycape-approval-engine-operator-client
kubernetes_key: client-secret
keycape_environment: KEYCAPE_APPROVAL_ENGINE_OPERATOR_CLIENT_SECRET
custody_owner: railiance-platform
consumer: approval-engine-operator
human_registration:
status: awaiting-exact-callback
blocks_service_client_rollout: false
# Owner identified 2026-09-09: informed-decision (hub repo cf4c7da8). It
# supplies client_id and callback URI from INFD-WP-0001-T07 once it has a
# deployed origin. approval-engine is a bearer-only resource server and never
# owned those strings.
owner: informed-decision
# approval:read added 2026-09-09 on approval-engine's finding: the surface
# cannot render a decision without GET /v1/approvals/{id} and /claim, so the
# earlier scope set let an approver submit what they could not display.
scopes: [openid, approval:read, approval:approve]
mfa_required: true
client_type: public
grant: authorization_code + S256 PKCE
never: [approval:consume]
# Required. Without it the token carries tenant:coulomb from the directory
# default and approval-engine refuses it. See docs/tenant-claim-contract.md.
tenant: tenant:platform
keycape_side_resolved: |
2026-09-09: a human token can now carry tenant:platform. A client
registration may declare a tenant; humanTenant() supplies it when the
directory has not placed the user, requires agreement when it has, and
refuses issuance on conflict rather than relabelling. Safe only because
registrations are static and deployment-owned. Still outstanding from
elsewhere: the exact client_id and callback URI from informed-decision
(INFD-WP-0001-T07), and whether the owners prefer the directory-sourced
resolution instead, which this implementation degrades into cleanly.
verification:
# The first two lines are now one runnable command per client; see
# docs/native-authentication.md, "Verifying a live registration". It writes
# nothing and prints no value, so it is safe to run against production.
- command: |
keycape verify-client -issuer https://kc.coulomb.social
-client-id secrets-engine-approval -audience approval-engine
-scope "approval:read approval:consume"
-secret-env KEYCAPE_SECRETS_ENGINE_APPROVAL_CLIENT_SECRET
-expect-subject service:secrets-engine -expect-tenant tenant:platform
-expect-roles secrets-engine
-deny-scope "approval:approve approval:revoke approval:supersede"
- command: |
keycape verify-client -issuer https://kc.coulomb.social
-client-id approval-engine-operator -audience approval-engine
-scope "approval:create approval:read approval:approve approval:revoke approval:supersede approval:observe approval:emit"
-secret-env KEYCAPE_APPROVAL_ENGINE_OPERATOR_CLIENT_SECRET
-expect-subject service:approval-engine-operator -expect-tenant tenant:platform
-expect-roles approval-operator
-deny-scope "approval:consume"
- Check KeyCape and consumer readiness without emitting secrets or tokens.
- Preserve existing registrations and signing key; record versions and image digest.
- Human consume denial is approval-engine's to verify at its resource; KeyCape
proves only that the human client is never issued a consume grant.
# Asked by railiance-platform 2026-09-09 (CCR-2026-0020 has no named presenting
# actor in any owner source, and they declined to guess one). This is KeyCape's
# view as the issuer of the identity, not a decision: who may hold the
# credential is approval-engine's call and the doctrine question is
# gate-house's.
presenting_actor_note:
client_id: approval-engine-operator
# ANSWERED 2026-09-09 by approval-engine: the presenter is nobody, and they have
# withdrawn the request. Nothing in their repository obtains an OAuth token; the
# engine only verifies them. They asked railiance-platform to cancel the
# client-side reader CCR-2026-0020 as an owner decision. Verifier custody
# CCR-2026-0018 stands. The separation-of-duties observation below is what
# prompted the question and is retained because it constrains the re-request:
# approval:approve must not travel with the operational scopes.
status: withdrawn-by-requesting-owner
already_live: true # provisioned in the 2026-09-09 attended rollout; withdrawal does not unprovision it
observation: |
The registration as issued carries both approval:create and approval:approve,
so a single presenter can create an entry and then approve it. That is a
separation-of-duties property of the credential holder, not a defect in the
token -- KeyCape issues exactly the grants approval-engine requested, and
splitting them would be a change to that request rather than to issuance.
options_keycape_can_support:
- Two registrations with disjoint grants, one creating and one approving, if
approval-engine wants the split enforced at issuance. KeyCape can do this
today; it needs approval-engine to say so, since it changes their contract.
- Keep one registration and constrain the holder by custody instead, which is
where it sits now.
keycape_does_not_decide: |
Who presents this credential, and whether self-approval is acceptable for the
lifecycle operator, are not KeyCape's to settle. Recorded here so the question
is answered from the registration rather than reconstructed from it.
blockers:
- Admit exact custody paths, field delivery, consumer identities and lifecycle authority.
- Resolve attended first-provision authority through the custody owner.
- Verify the actual upstream ID-token issuer before production image rollout.
custody_return:
owner_record: railiance-platform/workplans/RPF-WP-0035-credential-lane-implementation.md#Admit-KeyCape-approval-engine-client-custody-and-delivery
requests: [CCR-2026-0017, CCR-2026-0018]
status: proposed-awaiting-owner-approval
field_correction: CLIENT_SECRET
scope: KeyCape verifier-side copies only; client-side retrieval is not admitted.
human_registration_gate:
- The approver UI owner must supply its real client ID and exact callback.
- This gate blocks human approval entry; it does not block the two independent client_credentials registrations or service startup.
Reference in a new issue View git blame Copy permalink