coulomb/approval-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Refuse to invent the human approver client_id and callback URI

Browse source 
key-cape (KEY-WP-0013-T02) asked for two exact strings for the human
approver registration. This engine is a bearer-token resource server: no
redirect endpoint, no authorization-code/PKCE path, and no Ingress or
external origin, so neither string exists here. Record why, name the
missing owner (a browser-facing approver UI outside this repo), and
confirm that the access token — never the ID token — is what this
resource validates.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275879@bnt-lap001
Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad
This commit is contained in:
tegwick 2026-09-08 14:47:40 +02:00
parent d5d1e41035
commit 24ec18fe3f
2 changed files with 56 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

16
workplans/APPROVAL-WP-0002-production-readiness-and-consumer-adoption.md
View file

@ -121,6 +121,22 @@ This resolves the choice of value only. T01 stays `progress`: KeyCape still has
to own and prove these registrations, and credential materialization is
unchanged.
2026-09-08 follow-up: key-cape (`KEY-WP-0013-T02`) asked for the human approver
client's exact `client_id` and full callback URI. Neither is supplied, and
neither is guessed: this engine is a bearer-token resource server with no
redirect endpoint, no authorization-code/PKCE code and no Ingress or external
origin (`deploy/approval-engine.yaml` is Namespace + ClusterIP + StatefulSet),
so no callback URI exists here to register — and redirects match exactly at
`/authorize`, so an invented value either fails closed or registers an origin no
component owns. The human browser client belongs to an approver UI that this
repo does not contain and `APPROVAL-WP-0002` does not name; the two strings must
come from that component's owner. Confirmed to key-cape in the same reply: this
resource validates the **access** token (`Authorization: Bearer`, RS256 via the
issuer's `/jwks`, checking `iss`, `aud=approval-engine`, expiry, `sub`,
`principal_type`, `tenant`, `roles`, `scope`, `assurance`); `id_token` appears
nowhere in the codebase. Recorded in `docs/keycape-service-registrations.md`.
T01 stays `progress`.
## Harden durable storage and migrations
```task