tegwick
c9bb7fac58
All checks were successful
Build and Publish Container Image / build-and-push (push) Successful in 47s
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
149 lines
8.6 KiB
YAML
149 lines
8.6 KiB
YAML
# 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: submitted-2026-09-10
|
|
client_id: informed-decision-approver
|
|
redirect_uri: https://decisions.coulomb.social/auth/callback
|
|
# Origin verified live before submission: / and /auth/callback both 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 of an earlier draft.
|
|
# The path serves a placeholder while the surface is gated on
|
|
# APPROVAL-WP-0002-T01; the redirect is matched as a string and never fetched.
|
|
origin_verified: true
|
|
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: whether the owners prefer the directory-sourced resolution
|
|
instead, which this implementation degrades into cleanly.
|
|
resolved_2026_09_10: |
|
|
client_id and callback URI received and registered. GH-DEC-2026-013 granted
|
|
the registration-bound shape as a declared bounded gap, so the declared
|
|
tenant is admissible; the token says how it got there via tenant_source =
|
|
"registration", never "directory". Per gate-house's later correction the
|
|
tenant field carries three facts, and a registration-supplied value is
|
|
adequate for approval-engine's store-isolation gate and NEVER for doctrine
|
|
turning on this person's membership of the zone.
|
|
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.
|