---
id: ADHOC-2026-09-07
type: workplan
title: "Document the KEY-WP-0016 authorization-code bindings for consumers"
domain: infotech
repo: key-cape
status: finished
owner: claude
created: "2026-09-07"
updated: "2026-09-07"
state_hub_workstream_id: "c2fdc5cc-89be-561d-b832-f0b3019ea1c7"
---

## Publish the consumer-facing rollout note

```task
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.