tegwick
7fe5bccc7c
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
1.4 KiB
| id | type | title | domain | repo | status | owner | created | updated | state_hub_workstream_id |
|---|---|---|---|---|---|---|---|---|---|
| ADHOC-2026-09-07 | workplan | Document the KEY-WP-0016 authorization-code bindings for consumers | infotech | key-cape | finished | claude | 2026-09-07 | 2026-09-07 | c2fdc5cc-89be-561d-b832-f0b3019ea1c7 |
Publish the consumer-facing rollout note
id: ADHOC-2026-09-07-T01
status: done
priority: medium
state_hub_task_id: "2187cef2-07c0-5ac1-89ca-3bb25a160fa4"
KEY-WP-0016 changed /token and /userinfo behaviour without a consumer-facing
note; no document in docs/ mentioned redirect_uri at all, so the change would
have reached a deployment silently.
Published docs/authorization-code-bindings.md stating what an exchange must
send, who is affected and how to roll out. Verified the blast radius rather than
assuming it: all five browser registrations in config/dev-config.yaml
(openbao-admin, demo-app, netkingdom-bootstrap-console,
user-engine-portal, coulomb-social) are clientType: public with
grantTypes: ["authorization_code"], so the grant-type and confidential-client
bindings cannot affect them and only the redirect_uri requirement can. Named
the realistic failure — a client that sends redirect_uri to /authorize but
omits it at /token — and said plainly that it has not been observed against a
live consumer. Referenced the note from SCOPE.md.